UNIVERZITA PARDUBICE FAKULTA ELEKTROTECHNIKY A INFORMATIKY DIPLOMOVÁ PRÁCE Bc. Martin Mariška

Rozměr: px
Začít zobrazení ze stránky:

Download "UNIVERZITA PARDUBICE FAKULTA ELEKTROTECHNIKY A INFORMATIKY DIPLOMOVÁ PRÁCE. 2012 Bc. Martin Mariška"

Transkript

1 UNIVERZITA PARDUBICE FAKULTA ELEKTROTECHNIKY A INFORMATIKY DIPLOMOVÁ PRÁCE 2012 Bc. Martin Mariška

2 Univerzita Pardubice Fakulta elektrotechniky a informatiky AGENTOVĚ ORIENTOVANÉ SIMULAČNÍ MODELY PROVOZU OBSLUŽNÝCH SYSTÉMŮ Bc. Martin Mariška Diplomová práce

3 2012

4

5 PROHLÁŠENÍ AUTORA Prohlašuji, že jsem tuto práci vypracoval samostatně. Veškeré literární prameny a informace, které jsem v práci využil, jsou uvedeny v seznamu použité literatury. Byl jsem seznámen s tím, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorský zákon, zejména se skutečností, že Univerzita Pardubice má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle 60 odst. 1 autorského zákona, a s tím, že pokud dojde k užití této práce mnou nebo bude poskytnuta licence o užití jinému subjektu, je Univerzita Pardubice oprávněna ode mne požadovat přiměřený příspěvek na úhradu nákladů, které na vytvoření díla vynaložila, a to podle okolností až do jejich skutečné výše. Souhlasím s prezenčním zpřístupněním své práce v Univerzitní knihovně. V Pardubicích dne Bc. Martin Mariška

6 PODĚKOVÁNÍ Na tomto místě bych rád poděkoval svému vedoucímu diplomové práce prof. Ing. Antonínu Kavičkovi, Ph.D. za cenné rady, náměty a za odborné vedení během zpracování této práce.

7 ANOTACE Práce se věnuje problematice agentově orientované simulace. Další části se pak zaměřují na vytvoření a ověření mechanizmu pro modelování obslužných procesů v rámci agentově orientovaných simulačních modelů a implementaci mechanizmu do prostředí simulační platformy Repast Simphony 2. KLÍČOVÁ SLOVA Agentově orientovaná simulace, modelování obslužných systémů, simulační framework Repast Simphony 2.0 TITLE Agent-based simulation models of service systems ANNOTATION The work is devoted to agent based simulation. Next part is orientated on the creation and verification of a mechanism for modeling service processes within the agentoriented simulation models and implementation of the mechanism into the environment of simulation platform Repast Simphony 2. KEYWORDS Agent-based simulation, modelling service systems, simulation framework Repast Simphony 2.0

8 Obsah 1 Úvod Cíl diplomové práce Simulace jako experimentální výzkumná metoda Systém Model Modelování Simulace Aktivity a procesy Simulační experiment Agentově orientované simulace Struktura agentově orientovaného modelu Autonomní agenti Interakce mezi agenty Agent a jeho prostředí Metody návrhu modelu Otázky pro návrh modelu Bottom up, Top down Repast Suite Základní koncept frameworku Repast Simphony Repast Simphony Repast Java ReLogo Repast Flowchart Repast HPC Repast Simphony Service, proprietární software Popis problému obslužných systémů v AOS Systémy hromadné obsluhy Obslužný systém v AOS Požadavky Návrh Základní koncept

9 6.3.2 Aktivita Zdroj Obsluhy Technologický proces Implementace Aktivita Zdroj Obsluhy Technologický proces Vizuální podpora Případové studie obslužných systémů Model M/M/ Cíle případové studie Parametry modelu Analytické řešení systému M/M/ Závěr Model pneuservis Popis Cíle případové studie Návrh Parametry modelu a simulační scénáře Výsledky Závěr případové studie Model výstaviště Popis Cíle případové studie Návrh Problémy Parametry modelu a simulační scénář Výsledky Závěr případové studie Závěr Literatura Přílohy

10 Seznam Obrázků Obrázek 1 Ilustrace modelu kontejnerového přístaviště...14 Obrázek 2 Ilustrace modelu železničního uzlu (Villon)...14 Obrázek 3 Aktivita simulátoru. Zdroj: [12] Obrázek 4 Spojitá aktivita. Zdroj [12] Obrázek 5 Diskrétní aktivita. Zdroj: [12] Obrázek 6 Proces. Zdroj: [12] Obrázek 7 Struktura typického ABM. Zdroj [20] Obrázek 8 Typický agent. Zdroj [20] Obrázek 9 Přehled běžných topologií pro vztahy a interakce mezi agenty. Zdroj [20] Obrázek 10 Příklad implementace agenta chodce Obrázek 11 Běhové prostředí Repast Simphony s 2D a 3D pohledem Obrázek 12 Ukázka prostředí flowchart Obrázek 13 Systém hromadné obsluhy zdroj [27] Obrázek 14 - Koncept funkce technologického procesu Obrázek 15 Struktura balíčků RepastS Service Obrázek 16 Technologický proces nákupu s paralelní činností Obrázek 17 Ukázka modelu M/M/1 ve vizuálním prostředí Obrázek 18 Ukázka modelu pneuservisu ve vizuálním prostředí Obrázek 19 Schéma topologie výstaviště Obrázek 20 Vizuální ukázka výstaviště s problémem utlačování Obrázek 21 Vizuální ukázka výstaviště po aplikování gradientních map...61 Obrázek 22 Pseudokód vytvoření gradientní mapy (vzdáleností) Obrázek 23 Gradientní mapa (vzdálenosti) Obrázek 24 Gradientní mapa (směry) Obrázek 25 Zahlcený východ výstaviště Seznam tabulek Tabulka 1 Výsledky experimentu pneuservisu podle scénáře Tabulka 2 - Výsledky experimentu pneuservisu podle scénáře Tabulka 3 - Výsledky experimentu výstaviště podle scénáře Tabulka 4 - Výsledky experimentu výstaviště podle scénáře Seznam grafů Graf 1 - Výsledky experimentu pneuservisu podle scénáře Graf 2 - Výsledky experimentu pneuservisu podle scénáře Graf 3 - Výsledky experimentu výstaviště podle scénáře Graf 4 - Výsledky experimentu výstaviště podle scénáře Graf 5 - Výsledky vlivu doby nakládání na spokojenost návštěvníků

11 Seznam Zkratek ABM Agentově orientovaný model (agent based model) AS Agentové systémy (Agent Systems) BDI Představa, přání, záměr (Beleive Desire Intend) CA Celulární automat CSV Formát textového souboru (Comma Separated Value) DAI Distribuovaná umělá inteligence (Distributed Artificial Intelligence) GIS Geografický informační systém GUI Grafické uživatelské prostředí (Graphical User Interface) HPC Vysoce náročné výpočty (High Performance Computing) JGAP Java balíček genetických algoritmů (Java genetic algorithms package) MPI Rozhraní pro předávání zpráv (Message Passing Interface) SHO Systém hromadné obsluhy TP Technologický proces UML Unifikovaný modelovací jazyk (Unified modeling language) XML Rozšiřitelný značkovací jazyk (Extensible Markup Language) 2D, 3D Dvou a tříd dimenzionální (obvykle) prostor 11

12 1 Úvod Agentově orientovaná technologie je rychle se vyvíjející obor umělé inteligence a počítačové vědy. Jeho využití zasahuje v dnešní době do mnoha praktických i vědních oborů. Příkladem může být použití agentově orientovaného paradigmatu v softwarovém inženýrství, webových technologiích, robotice nebo modelování a simulaci. Multiagentní modely spadají do obecnější kategorie multiagentních systémů. Rozvoj multiagentního modelování umožnil až rozvoj moderní výpočetní techniky, především v posledních třech desetiletích. Modely slouží především k simulaci komplexních systémů v různých zájmových oblastech (ekonomie, biologie, sociální vědy), které jsou jinými způsoby výzkumu těžko proveditelné. Princip multiagentní simulace spočívá ve využití tzv. agentů. Agenti jsou autonomní entity, reprezentující reálné jednotky sledovaného systému, situované do definovaného kontextu prostředí. Agenti v daném prostředí jednají, reagují a mají schopnost se přizpůsobit vnějším podmínkám (adaptovat se). Tímto prostředím mohou být různé formy sítí a mřížek, vybrané podle sledovaného cíle a zvolených předpokladů, které by měly odpovídat simulované realitě. Simulace je pak sledována v diskrétním čase. V každém časovém kroku se vyhodnocuje chování všech agentů a stav prostředí, v závislosti na jejich výchozích parametrech. V první teoretické části této práce bude uveden obecný přehled problematiky agentově orientovaného modelování a simulace. Dále pak přehled agentově orientované simulační platformy Repast Simphony, která byla vybrána pro implementaci a realizaci zobecněného mechanizmu, který řeší problematiku obslužných systémů v agentově orientovaných modelech. Druhá část práce se zabývá navržením, implementací a ověřením softwarové nadstavby pro realizaci obslužných systémů v ABM. Obecná možnost rychlého prototypování nebo existence podpory pro tvorbu obslužných systémů ve specializovaných nástrojích zatím není dostupná. Tato diplomová práce poskytne koncept řešení a softwarové rozšíření platformy Repast Simphony 2, pro jeho realizaci a použití. Pro ověření vytvořeného proprietárního softwaru budou realizovány případové studie orientované na různou problematiku. 12

13 2 Cíl diplomové práce Hlavním cílem diplomové práce je návrh, implementace a ověření zobecněného mechanizmu pro zkoumání provozu obslužných systémů a jejich rychlejší výstavbu v agentově orientovaných modelech. Modely budou realizovány v rámci frameworku Repast Simphony 2. Za tímto účelem je třeba v teoretické části práce vypracovat: a) Přehled problematiky agentově orientovaných simulací b) Přehled softwarové simulační platformy Repast Simphony 2 V praktické části: a) Seznámit se s frameworkem Repast Simphony 2 b) Navrhnout a implementovat nadstavbu v prostředí zvoleného frameworku V experimentální části práce pak: a) Ověřit základní simulační vlastnosti frameworku Repast Simphony 2 ve vhodně zvolené případové studii b) Ověřit softwarovou nadstavbu aplikací ve vhodně zvolených případových studiích c) Výsledky z případových studií následně zhodnotit z pohledu náročnosti implementace a rychlosti výstavby konečného modelu 13

14 3 Simulace jako experimentální výzkumná metoda Pro uvedení definice modelování a simulace je nutné vysvětlit význam některých výchozích termínů. Mezi tyto termíny patří systém, model, modelování a další pomocné termíny. Uvedené definice a pojmy vychází z publikací [9], [11], [12], [17]. Předmětem simulace a modelování je výzkum a pozorování objektů hmotného světa, kde tyto objekty již v realitě existují (například stávající řešení železničního uzlu města Prahy, stávající řešení jaderné elektrárny, kontejnerový terminál v přístavišti), anebo by existovat mohly (železniční uzel hl. m. Prahy po rozšíření na další směry a jeho rekonstrukci, další výzkumná expedice na Mars). Obrázek 1 Ilustrace modelu kontejnerového přístaviště Obrázek 2 Ilustrace modelu železničního uzlu (Villon) 3.1 Systém V simulaci a modelování se zkoumá nějaká věc, resp. možné varianty nějaké věci, při čemž slovo věc chápeme tak, jak jej chápou filozofové: je to nějaký objekt hmotného světa, a to buď objekt, který vskutku existuje (např. organismus konkrétní osoby, konkrétní továrna, atd.), nebo o kterém uvažujeme, že by existovat mohl (např. stroj, budova či 14

15 výrobní provoz, který by měl být realizován). Na zkoumaných věcech se zavádí abstrakce, které zanedbávají některé aspekty těchto věcí. Zanedbané aspekty jsou vybrány tak, že aspekty, které zbývají, jsou daným vědeckým, technickým či společenským oborem zvládnutelné: mimo jiné, mohou o nich racionálně komunikovat. Takovou abstrakci budeme v modelování a simulaci nazývat systémem a podle charakteru profese, která systém na věci vidí, zavádí či definuje, dostává systém i přívlastek: např. železniční sít se běžně chápe jako dopravní systém, i když ekolog v ní muže vidět systém jiný. Abstrakce může, nebo nemusí zanedbat význam času. Např. význam času v systémech železniční dopravy nelze běžně zanedbat. Avšak při vytváření jízdního řádu v určitém roce konstruktér mapy železniční sítě České republiky zanedbává to, že se po jednotlivých tratích pohybují v čase vlaky a také to, že se železniční síť může měnit před rokem vzniku jízdního řádu i po něm. Systém, v němž se od významu času abstrahuje, se nazývá statickým systémem. Systém, jehož čas se nezanedbává a je přitom chápán newtonovsky 1, se v modelování a simulaci nazývá dynamickým systémem. Dynamický systém je v každém okamžiku své existence v jistém stavu. Změna stavu dynamického systému se nazývá událost. Simulace se jinými než dynamickými systémy nezabývá. V modelování a simulaci se chápe systém tak, že je složen z prvků. V dynamickém systému se může počet jeho prvků během jeho existence měnit: systém (např. biologický) může růst a smršťovat se, avšak v technických a ekonomických aplikacích jde nejčastěji o to, že prvky mohou do systému vstupovat a systém opouštět. Prvky, které jsou v dynamickém systému během celé jeho existence, se nazývají permanentní prvky. Naopak prvky s dočasnou existencí v systému nazýváme temporární. Prvky systému mají své vlastnosti, které se nazývají atributy. Ty přiřazují prvkům nějaké hodnoty, jež se mohou u prvků dynamického systému v čase měnit. Atributy bývají tzv. hodnotové, anebo referenční. Referenční atributy přiřazují prvkům systému jiné prvky. 3.2 Model Slovo model se používalo v běžné řeči nejprve pro předlohu. V odborném jazyku doby před simulací a virtuální realitou zůstal z této praxe termín funkční modely, a to pro první exemplář navrženého výrobku, který pracuje tak, jak by výrobek pracovat měl, přestože jiné vlastnosti výrobku (např. estetické) tento exemplář ještě nemá. Termín model je v oblasti modelování a simulace používán pro analogii mezi dvěma systémy: modelovaným (neboli originálem) a modelujícím. Jednoduché příklady nabízí mapa (model části země na papíře) nebo socha (model osoby, zvířete atd. v neživém materiálu). Model je tedy složitá struktura, která váže dva systémy, jejich prvky a jejich 1 Newtonovsky je jako v klasické fyzice, čili tak, že je smysluplné mluvit o tom, že dvě události nastaly v systému současně nebo jedna z nich nastala dříve než druhá. 15

16 atributy, a v případě simulačních modelů i existence obou systémů. V běžné mluvě se však ustálila praxe, že pod slovem model se rozumí modelující systém, i když tento termín není úplně výstižný a přesný. Místo termínu modelovaný systém se používá slova originál. Vztah obou systémů, modelovaného a modelujícího, je dán tím, že každému prvku modelovaného systému je přiřazen prvek modelujícího systému. Každému atributu prvku je přiřazen atribut h prvku a pro hodnoty atributu a h je dána nějaká relace. Její charakter není nějak obecně omezen, ale v případě, že i h jsou aritmetické atributy, bývá taková relace úměrnost nebo tolerance. V případě, že jde o simulační model, se raději mluví o systému simulovaném a simulujícím než o modelovaném a modelujícím. Existuje praxe, že se na místě termínu simulující systém používá termín simulační model nebo také simulátor. Aby se jednalo o simulační model (simulátor), musí model splňovat následující požadavky: Jejich modelující i modelované systémy jsou dynamické systémy. Existuje zobrazení τ existence modelovaného systému do existence modelujícího systému; je-li tedy okamžik, v němž existuje modelovaný systém, je mu přiřazen okamžik τ t =t, v němž existuje modelující systém, a tak je zobrazením τ přiřazen i stavu = systému stav = systému. Mezi stavy a jsou splněny požadavky na vztahy mezi prvky a jejich atributy, jak již bylo uvedeno při definici modelu. Zobrazení τ je neklesající; pokud nastane stav originálu před stavem téhož systému, pak stav, který odpovídá v modelujícím systému stavu, nastane před stavem, který odpovídá stavu nebo mohou oba stavy nastat současně. Tento požadavek vyjadřuje nutnost dodržovat vztahy kauzality z originálu i v modelujícím systému. 3.3 Modelování Podstatou modelování, ve smyslu výzkumné techniky, je náhrada zkoumaného systému jeho modelem (přesněji: systémem, který jej modeluje). Cílem modelování je získat pomocí pokusu s modelem informaci o původním zkoumaném systému. V tomto smyslu tedy platí, že bude vytvořen model, v němž modelovaným systémem je zkoumaný systém. Experimentovat se bude s modelujícím systémem, při čemž cílem bude dozvědět se něco o modelovaném systému. 3.4 Simulace Simulace je výzkumná technika (metoda), jejíž podstatou je náhrada zkoumaného dynamického systému (originálu) jeho simulátorem, s nímž se experimentuje s cílem získat informace o původním zkoumaném dynamickém systému. Nutno zdůraznit, že aby došlo k 16

17 simulaci, musí být cílem experimentů se simulátorem získání informací o simulovaném systému (originálu). 3.5 Aktivity a procesy Aktivity a procesy odrážejí dynamické vlastnosti systému, tj. plynutí času a změny stavu systému v čase. Aktivita představuje základní akční jednotku simulace, která je obrazem jisté činnosti v simulovaném systému (např. pohyb vlaku po koleji), přičemž pro ni platí: Má jisté časové trvání (Potenciálně) Mění stav systému. Obrázek 3 Aktivita simulátoru. Zdroj: [12]. Běh simulačního času je představován vykonáváním jednotlivých aktivit a to ve stejném pořadí, v němž se vykonávají jim odpovídající činnosti v simulovaném systému (tedy originále). Časová existence aktivity je charakterizovaná množinou reálných čísel (časových okamžiků), v nichž aktivita existuje, tedy může měnit stav systému. Z tohoto hlediska rozeznáváme dva druhy aktivit. Spojitá aktivita, může měnit stav systému během celé doby jejího trvání. Časová existence aktivity je tedy charakterizována intervalem časových okamžiků <, >. Obrázek 4 Spojitá aktivita. Zdroj [12] Diskrétní aktivita, může měnit stav systému jen v okamžiku ukončení aktivity ; v průběhu trvání aktivity se stav systému měnit nemůže. Aktivita existuje jen v okamžiku jejího ukončení. Ukončení diskrétní aktivity a následná změna stavu systému se nazývá událost. 17

18 Obrázek 5 Diskrétní aktivita. Zdroj: [12] V případě, že simulovaný systém obsahuje pouze spojité aktivity, potom mluvíme o spojité simulaci. Jestliže simulovaný systém obsahuje pouze diskrétní aktivity, pak mluvíme o diskrétní simulaci. Obsahuje li systém jak spojité, tak i diskrétní aktivity, potom příslušnou simulaci označujeme jako kombinovanou (diskrétně spojitou) simulaci. Proces je posloupnost přirozeně na sebe navazujících aktivit, které spolu tvoří jistý logický celek (např. průjezd vlaku vybraným fragmentem železniční sítě). Obrázek 6 Proces. Zdroj: [12] 3.6 Simulační experiment Program řídící výpočet při simulaci se nazývá simulačním programem, přičemž tento program je spouštěn pro různé konfigurace simulátoru za účelem provádění simulačních experimentů. Běh simulačního programu se nazývá simulační pokus (experiment) se simulátorem. V rámci simulačního pokusu zkoumáme chování originálu (vymezeného systému) při použití předem určených pravidel dynamického chování simulátoru. V literatuře se populárně uvádí, že pokus dává odpověď na otázku: Co se stane, když. V průběhu simulačního pokusu se eviduje čas, který v dané fázi simulačního výpočtu odráží čas v simulovaném systému. Měnící se čas v simulačním pokusu se označuje jako simulační čas. Simulační čas typicky ubíhá rychleji (výjimečně i pomaleji) než reálný čas, avšak doba provádění jednotlivých simulačních aktivit v simulátoru musí být proporcionální vůči době provádění aktivit v originálu. Simulační čas, stejně jako ten reálný, nemůže klesat. 18

19 4 Agentově orientované simulace Agentově orientované modelování a simulace, je relativně nový přístup, jak modelovat komplexní systémy složené z autonomních agentů schopných vzájemné interakce. Agenti mají vlastní chování, často definované nějakými jednoduchými pravidly a teprve interakce s okolím tvoří jejich specifické chování. Vzory, struktury a chování celého systému se nemusí explicitně programovat. V agentově orientovaném modelu vyplyne celé systémové chování právě na základě interakcí a chování jednotlivců. Takovéto modely nabízejí například možnost, jak modelovat heterogenní sociální systémy, ve kterých se jednotliví agenti mohou ovlivňovat svým chováním. Na základě učení a zkušeností se mohou následně lépe adaptovat do cílového prostředí. Aplikace agentově orientovaných modelů zasahuje do rozsáhlého množství oblastí a disciplín, ve kterých by se daly použít. Například můžeme uvést ekonomické modely, nákupní modely a s tím spojené nákupní chování, predikce pandemických katastrof, predikce chování lidí v ohrožení biologickou hrozbou, adaptivní model imunitního systému, porozumění pádu starověkých říší, modelování námořních i leteckých bitev a spoustu dalších. Všechny tyto modely se již realizovaly a mají svůj přínos v této oblasti. Je nutné říci, že pojem abstrakce je při vytváření modelů důležitý. Některé modely jsou malé, ale elegantní a zachycují pouze základní prvky, které jsou třeba pro pozorování cíleného chování. Na druhou stranu existující i agentově orientované systémy (například v přírodě), které jsou na velice detailní úrovni a obsahují velký objem dat. Takovéto modely poskytují detailní informace a využívají se například pro podporu rozhodování. V dnešní době mohou být modely také mnohem sofistikovanější, protože vývoj a hardware nyní umožňuje do modelů zapracovat obrovské množství dat. S klesající úrovní abstrakce (zvyšuje se míra detailu) se dosáhne realističtějších výsledků. V rámci této kapitoly je uveden aktuální obecný pohled na agentově orientované simulace. Základní pojmy a důležité termíny. 4.1 Struktura agentově orientovaného modelu Typicky agentově orientovaný model obsahuje tři části: 1) Množinu agentů, jejich atributů a chování 2) Množinu relací a pravidel interakce mezi agenty (většinou je na pozadí nějaká topologie, která udává kdo a s kým může reagovat) 3) Prostředí, ve kterém agenti existují (agenti také reagují s prostředím a jsou omezováni jeho pravidly. Například prostorová aktivita agenta je dána fyzikálními pravidly daného prostředí). Návrhář modelu musí v první řadě identifikovat model a naprogramovat tyto tři výše zmíněné elementy, aby vznikl plnohodnotný agentově orientovaný model. Struktura takového modelu je prezentována na obrázku 7. 19

20 Obrázek 7 Struktura typického ABM. Zdroj [20] Pro správný běh ABM je potřeba zabezpečit, aby agenti mohli opakovaně vykonávat své chování a interakce, přičemž není podstatné, zda vykonávání bude spojité (stejné časové intervaly), diskrétní (různé časové intervaly), anebo založené na procesech (při dokončení jedné aktivity následuje aktivita další). Dnešní modelovací nástroje, programovací jazyky a ostatní implementace zaměřené na agentově orientovanou problematiku, již mají realizované simulační jádro a mechanizmy, které agentovou simulaci umožní. Důležité je zmínit, že některé nástroje jsou specializované na určitou kategorii ABM a některé jsou naopak obecné a univerzální pro široké možnosti použití. 4.2 Autonomní agenti V této kapitole jsou zmíněny některé definice a pojmy, které vycházejí hlavně z publikací [20], [21], [23], [25]. Na počátku vzniku a vývoje agentních systémů (AS) stojí distribuovaná umělá inteligence (DAI), v níž autonomní jednotky, které jsou schopné řešit určité problémy, se nazývají aktéři (Actors). Z nich se pak vyvinul pojem agenti (Agents). Princip autonomního agenta (tzv. reaktivního agenta) popsal Rodney Brooks, pracovník AI laboratoří MIT. Poté princip inteligentních agentů (Intelligent Agents) popsal M. J. Wooldridge. [21] V dnešní době existuje jediná základní charakteristika agenta, na které se dnes shodnou všichni, kteří se touto problematikou zabývají. Tato charakteristika definuje, že agent reaguje na vzniklou situaci autonomně (tedy nezávisle). Agent má v sobě zapouzdřeno vlastní chování, které mu umožňuje provádět nezávislá rozhodnutí. Ve 20

21 většině případů jsou agenti aktivní a snaží se pomocí vykonávání svých akcí dosáhnout nějakého svého interního cíle. Současně agent reaguje na vnější podměty přicházející od ostatních agentů nebo od prostředí, ve kterém existuje. Přesná definice, co je to agent, v literatuře není sjednocená. Někteří autoři považují za agenta jakoukoliv nezávislou komponentu (software, model, jedince, aj.). Z tohoto pohledu může být chování komponenty velice jednoduché (popsané množinou jednoduchých if then pravidel 2 ), anebo může být až velice komplexní (chování je modelované prvky umělé inteligence). Jiní autoři tvrdí, že chování musí být adaptivní. Znamená to, že agent musí být schopen se učit a měnit své chování na základě svých aktuálních zkušeností. Z praktického pohledu modelování, založeném na tom jaké jsou potřeby a možnosti modelování v dnešních nástrojích a na tom, jaké jsou současné požadavky na výstavbu agentových modelů, můžeme vyvodit následující základní charakteristiky agenta: Agent je nezávislý, modulární a unikátní (lze ho identifikovat). Modularita implikuje, že agent má určité meze působnosti (znamená to, že můžeme jednoduše říct co je součástí agenta a co není, případně co je sdílená část). Agent je autonomní a řídí se sám. Agent může fungovat nezávisle ve svém prostředí a reagovat na ostatní události (události z prostředí nebo ostatních agentů). Meze působnosti udávají pravidla prostředí (respektive modelu) a situace, která nás v daném případě zajímá. Agent má chování, které je úzce spojeno s informacemi, které získává ze svého okolí (prostředí, ostatní agenti). Na základě těchto informací pak provádí své další rozhodnutí a akce. Jeho chování může být specifikováno od jednoduchých pravidel až po abstraktní modely, jako jsou neuronové sítě nebo genetické algoritmy, které poskytují agentovi adaptivní mechanizmy. Agent má stav, který se mění v čase. Stejně jako kterýkoliv jiný systém má i agent stav, který je reprezentován množinou atributů odrážející aktuální situaci. Stav agentově orientovaného modelu v daném čase se skládá ze všech aktuálních stavů všech agentů a aktuálních stavů prostředí, ve kterých agenti existují. Agentovo chování je podmíněno právě jeho stavem. Můžeme tedy říci, že čím více stavů může agent mít, tím více by mohlo být jeho chování rozmanitější. V ABM tedy platí, že stav systému je množina všech informací v daném čase, které jsou potřeba pro posun systému z aktuálního stavu do jiného. Agent je společenský a provádí dynamické interakce s ostatními agenty, které mají vliv na jeho chování. Agenti mají pravidla pro vzájemnou interakci, komunikaci, pohyb a spory v prostoru, pro provádění změn do prostředí a jiné. Také jsou schopni rozeznat a odlišit rysy ostatních agentů. 2 If - then pravidlo má jenom dvě možnosti (pravdu, nepravdu). V případě pravdy nebo nepravdy se může provést nějaká akce. 21

22 Agenti mohou mít také další užitečné vlastnosti: Agent může být adaptabilní. Například může mít pravidla nebo nějaký abstraktní mechanizmus pro modifikování jeho chování. Agent by měl mít schopnost učit se a upravovat své chování dle narůstajících zkušeností. Učení také vyžaduje nějakou formu paměti. Kromě toho adaptace, na úrovni jednotlivých agentů, se může projevit v populaci agentů skrze proces výběru. Znamená to, že vhodnější agenti zvyšují svůj počet v cílovém prostředí a tím se celý systém lépe adaptuje. Agent může být cílově orientovaný. Znamená to, že má definované interní cíle, kterých se snaží dosáhnout, ale nesnaží se maximalizovat počet svých splněných cílů. V rámci snažení stále respektuje svá interní pravidla pro chování. Tato schopnost umožňuje agentovi porovnávat výstup jeho chování vzhledem k jeho interním cílům a tím přizpůsobit jeho požadavky a chování pro budoucí interakce. Agent může být heterogenní. Na rozdíl od simulace částic, které jsou poměrně homogenní (např. modely s plynnými částicemi, modelování molekulové dynamiky), se v agentově orientovaných modelech často uvažuje velký rozsah jednotlivých typů agentů v dané populaci. Charakteristiky a chování agentů se mohou v populaci velice lišit v závislosti na jejich rozsahu a sofistikovanosti. Rovněž na počtu informací, které může agent zvažovat v danou situaci, na tom jak moc velký model externího světa si může agent zapamatovat, na tom zda agent dokáže odhadnout reakci ostatních agentů v závislosti na provedení svých akcí, na tom kolik historických informací si dokáže zapamatovat, aby mohl následně adaptovat své chování. Agenti mohou mít také různý přístup k prostředkům, které poskytuje dané prostředí. To může omezit nebo rozšířit jejich možnosti interakce, anebo obor působnosti. 22

23 Obrázek 8 Typický agent. Zdroj [20] Typická struktura agenta dokumentuje Obrázek 8. V agentově orientovaném modelu platí, že vše co je spojené s agentem, je buď jeho atributem, anebo metodou, která operuje nad agentovými daty. Agentovy atributy mohou být buď statické (nemění se v průběhu simulace), nebo dynamické (mění se v průběhu simulace). Pro příklad statickým atributem agenta je jeho jméno a dynamickým atributem je paměť provedených akcí (historie akcí). Agenti disponují metodami, které reprezentují jeho interní chování (chování je založené na vydefinovaných pravidlech nebo nějakém abstraktním modelu např. neuronová síť). Takovéto struktury spojují jednotlivé situace s možnými akcemi nebo množinou možných akcí, které může agent v danou chvíli provést. Příkladem může být metoda, kterou agent použije pro identifikování svého okolí. Agenty lze z pohledu komplexnosti autonomního chování rozlišit na následující kategorie: Agent inteligentní má schopnost plnit cíle s využitím logické dedukce Agent reaktivní má schopnost reakce na podněty Agent deliberativní (rozvážný) má schopnost plánovat postup svých akcí, provádět výpočty, ovlivňovat prostředí tak, aby získal výhodu (proaktivita) Agent kognitivní má schopnost vyvozovat logické závěry ze svých pozorování okolního prostředí. Je schopen se učit a vytvářet bázi znalostí (ukládá informace a znalosti získané dedukcí). Musí mít deliberativní schopnosti. Pak může provádět vnitřní akce jako je analýza scény, překlad a získávání dalších znalostí. 23

24 Agent racionální musí mít všechny výše uvedené schopnosti. Jeho struktura obsahuje plánovací jednotku i kognitivní jednotku, včetně báze znalostí. Na základě svých poznatků je schopen se učit a pak racionálním způsobem plánovat svou činnost pro dosažení cílů. Znalosti agenta lze kategorizovat: Problémově orientované znalosti (problem oriented knowledge) asociální typ znalostí, sloužící k lokálnímu, samostatnému řešení úloh (např. poskytování expertizy, hledání ve vlastní databázi agenta atd.) Znalosti o sobě samém (self knowledge) znalosti o vlastním chování, vnitřním stavu, závazcích apod. Sociální znalosti (social knowledge) znalosti o chování jiných agentů, o jejich schopnostech, zatížení, zkušenostech, závazcích, o jejich znalostech, záměrech a víře Znalosti umožňují agentům: Delegovat odpovědnost Dekomponovat úlohu na jednodušší úlohy Kontrahovat optimálně spolupracující agenty Formovat týmy a koalice Vyhledávat chybějící informace Při modelování agentova chování pro dané situace nebo souvislosti, které agenta v modelu potkají, existují i teorie kolektivního chování. Někteří začínají s normativním modelem, ve kterém se agenti pokoušejí optimalizovat své vnitřní hodnoty (zisk, užitek, aj.). Pro počáteční vývoj je to jednoduché, pochopitelné, hodně popisné, ale hlavně vznikne i reálný heuristický model chování. Někteří mohou začít s implementací již popsaného modelu chování, ke kterému je dostupná teorie chování a empirická data. Například existuje numerický model pro popis chování nakupujícího zákazníka (využívá se v ekonomické sféře), který může být implementován a jeho chování může být ověřeno pomocí agentově orientované simulace. Kognitivní věda a související obory se soustředí na agentovo sociální chování. Vzniknul tak modelovací framework nazývaný BDI 3 (Believe Desire Intent), který kombinuje modální 4 a temporární 5 logiku, jako základ pro reaktivní plánování a agentův výběr následné akce (Wooldridge, 2000). 3 Softwarový model Belief-Desire-Intention (představy-přání-záměry) je přístup ke tvorbě softwarově implementovaných agentních a multiagentních systémů inspirovaný teoriemi filosofa M. E. Bratmana. 4 Modální logika je oblast logiky zkoumající logické operace, tzv. modality (modální operátory jsou například je možné, je nutné, je nemožné ). 24

25 V aplikacích pro agentově orientované modelování, ve kterých se klade důraz na schopnost učit se, je důležité, zda je učení na úrovni jedince, anebo se učí celý kolektiv najednou. Další výhodou je využití strojového učení 6 jako dalšího zdroje učících se algoritmů například pro rozpoznávání vzorů nebo souvislostí v datech (data mining). Strojové učení poskytuje techniky jako učení s učitelem, učení bez učitele nebo zpětnovazebné učení. Dalším představitelem můžou být zmíněny genetické algoritmy. Všechny tyto techniky se běžně využívají při výstavbě a modelování ABM. 4.3 Interakce mezi agenty S agentově orientovaným modelováním nedílně souvisí i modelování vztahů a interakcí mezi agenty. Mezi dva základní problémy modelování interakcí patří kdo je (anebo by mohl být) spojen a s kým a druhým problémem je samotný mechanizmus dynamiky těchto spojení. Oba dva aspekty musejí být vyřešené již na úrovní vývoje ABM. Jedna ze zásad komplexních systémů a agentově orientovaného modelování je, že agent má k dispozici pouze lokální informace. Agentově zaměřené systémy jsou silně decentralizované. Typicky neexistuje žádná centrální autorita, která by shromažďovala všechny informace a dodávala je přímo agentům, anebo by řídila jejich chování za účelem optimalizace výkonu. Dále je důležité, že všichni agenti spolu nekomunikují ve stejnou chvíli a také, že mají většinou omezené možnosti a komunikují typicky pouze s některými agenty ze svého okolí, tak jako tomu je v reálném světě. Lokální informace jsou získávány z interakcí, které vzniknou v okolí agenta (ne mezi jakýmkoliv agentem nebo všemi agenty) a z jeho lokálního prostředí (ne z jakékoliv části prostředí). Dále je také typické, že agentovo okolí se s probíhající simulací stále mění (například prostorová aktivita agenta). Způsob, jakým jsou agenti propojeni, je dán topologií nebo mechanizmem konektivity. Typickou topologií je prostorová mřížka nebo síťový graf skládající se z vrcholů (agentů) a hran (vztah nebo propojení mezi agenty). Topologie udává, kdo je s kým propojen (a může s ním například komunikovat, interagovat). Některé aplikace umožňují agentům interagovat pomocí více topologií. Například model pandemického šíření nemoci. V něm agenti reagují v první řadě v prostorové mřížce, pro modelování fyzického kontaktu mezi agenty. Agenti se mohou tedy nakazit při provádění každodenních prací a akcí. V druhé řadě jsou pak součástí nějaké své sociální sítě, která zahrnuje blízké agenty (rodinu, přátelé, známé). Tato síť představuje nejpravděpodobnější kontakty jednotlivého agenta. Okolí agenta je obecný koncept, který je aplikovatelný na jakékoliv místo definované v modelu. Například ve výše zmíněném modelu mohou agenti reagovat pouze na okolí, které je fyzicky (geograficky) blízko danému agentovi a zároveň bude vyhledávat ve svém okolí agenty ze své sociální sítě. 5 Temporální logika je odvětví logiky, které zkoumá logickou strukturu výroků o čase, s nimiž se klasická výroková nebo predikátová logika nedokáže plnohodnotně vypořádat. Například výrok: Od teď bude stále pršet. 6 Strojové učení je podoblastí umělé inteligence zabývající se algoritmy a technikami, které umožňují počítačovému systému učit se. 25

26 První prostorový agentově orientovaný model byl implementovaný ve formě tzv. Celulárního automatu 7 (CA). Jeho použití bylo prezentováno v modelu Hra života 8 od pana Conwaye. CA je realizována na prostorové mřížce. Každá buňka má své bezprostřední sousední buňky, kterým říkáme okolí. V CA každá buňka může být reprezentována agentem, který má právě dva stavy (vypnutý, zapnutý) a interaguje s fixní množinou okolních buněk. Mnoho prvních modelů mělo podobu právě CA. Pan Epstein a Axtell představili model zvaný Sugarscape, kde byla topologie komplexnější než v jednoduchém CA. V Sugarscape modelu byli agenti mobilní a byli tedy schopni se přemísťovat z buňky do buňky. V těchto výše zmíněných modelech můžeme říct, že prostorová mřížka se stala pro agenty jejich prostředím. Toto prostředí agentům umožňovalo získávat zdroje a informace, které byly rozprostřené po celém prostředí mřížky. V dnešní době je mnohem více běžných topologií (viz. Obrázek 9), které se v praxi využívají. V CA modelu se agenti mohou pohybovat pouze z buňky do buňky a to tak, že v jednu chvíli může být v jedné buňce pouze jeden agent. Okolí podle pana von Neumanna (5 sousedů) zobrazuje Obrázek 9a. Dále existuje ještě další nejběžnější okolí podle pana Moora (9 sousedů). Moorovo okolí vypadá jako u pana Neumanna, ale přidává buňky i v šikmých směrech. V Eukleidovském prostoru se mohou agenti pohybovat ve dvou, třech nebo více dimenzionálních prostředích (viz. Obrázek 9b). Obecné spojení mezi agenty se nejlépe definuje pomocí síťové topologie. Ta může být obecně statická, anebo dynamická (Obrázek 9c). Ve statických sítích jsou spojení předdefinované a v průběhu času se nemění. Naopak dynamické sítě, hrany a vrcholy se mohou formovat až za běhu podle vnitřního mechanizmu modelu. Dalším typickým představitelem topologií je tzv. GIS topologie (využívaná v geografických informačních systémech), kde se agenti přesouvají mezi jednotlivými územími (reálné uzemní celky, viz. Obrázek 9d). V bezrozměrném modelu (někdy označováno jako omáčka, džus ) agenti nemají žádnou informaci o poloze, protože pro tento typ modelu není podstatná (viz. Obrázek 9e). Různé náhodné páry jsou z takovéhoto modelu vybírány k vzájemné interakci a zase navráceny zpět. Velká většina agentově orientovaných modelů obsahuje více topologií, které udávají možné interakce mezi agenty a rozšiřují tak možnosti agenta a celého systému. 7 CA je souhrnné označení pro určitý typ fyzikálního modelu reálné situace, ať již v podobě reálného přístroje či mnohem častěji počítačového algoritmu (programu). Slouží k časové i prostorové diskrétní (nespojité) idealizaci (ideální modelaci) fyzikálních systémů, kde hodnoty veličin nabývají pouze diskrétních hodnot v průběhu času. 8 Hra života je dvourozměrný, dvoustavový celulární automat, který svým fungováním připomíná vývoj společenství živých organismů. 26

27 Obrázek 9 Přehled běžných topologií pro vztahy a interakce mezi agenty. Zdroj [20] 4.4 Agent a jeho prostředí Prostředím nazýváme vše, s čím agent přichází za své existence do styku. Agenti provádějí interakce přímo s prostředím, anebo s ostatními agenty. Prostředí může být jednoduše použito k poskytnutí informací jako je prostorová pozice agenta vzhledem k ostatním agentům, anebo může poskytovat množinu geografických informací (jako je tomu v GIS modelech). Agentova pozice je z tohoto pohledu dynamický atribut, který je v některých případech potřeba sledovat. Například ve chvíli, kdy agent vyžaduje nějaké prostředky (z prostředí, od druhého agenta) nebo při vyskytnutí se nějaké situace (konkrétně výbuch se týká pouze určitého území, v ostatních částech území jsou agenti nezasažení), je nutné sledovat, zda atribut prostoru umožňuje interakci. Komplexní environmentální modely mohou být použity pro modelování agentových prostředí. Například hydrologické a atmosférické disperzní modely mohou poskytnout specifická lokační data pro výšku hladiny podzemní vody nebo úroveň atmosférického znečištění. Respektive jsou dostupná data, která v modelu agenti poskytují. Prostředí může naopak také definovat omezující podmínky pro agentovo chování a jeho akce (příkladem může být právě prostorové umístění). Pokud budeme mít agentově orientovaný dopravní model, ve kterém je na jednotlivých cestách definováno kapacitní omezení vozovky, může to v danou chvíli zapříčinit omezení při pohybu po dopravní síti. Na některých cestách může dojít ke 27

28 snížení rychlosti agentů, na jiných k úplnému ucpání (zamezí se tím průjezd a agenti musí volit náhradní cestu). Prostředí agenta můžeme kategorizovat: Dostupné nebo nedostupné - Dostupné prostředí je takové, o němž má agent úplné informace - Efektivně dostupné prostředí je takové, o němž má agent všechny informace, které potřebuje k rozhodování - V dostupném prostředí agent nepotřebuje udržovat svou vnitřní reprezentaci světa, protože vše vnímá Deterministické nebo nedeterministické - Deterministické prostředí následující stav závisí pouze na předchozím stavu a akci agenta - Nedeterministické prostředí stav prostředí může být ovlivněn náhodnými stavovými změnami v prostředí Epizodické nebo neepizodické - V epizodickém prostředí se zkušenost agenta skládá z epizod. Epizodu tvoří vjem a následná akce, přičemž akci volí agent pouze na základě jednoho předchozího vjemu. Statické nebo dynamické - Statické prostředí se nemění v čase mezi vjemem a akcí agenta, v dynamickém prostředí ke změnám dochází - Statické prostředí se lépe zkoumá a učení agenta je v něm snazší Diskrétní nebo souvislé - V diskrétním prostředí je přípustná pouze omezená množina vjemů a akcí 4.5 Metody návrhu modelu Správné navržení modelu závisí také na akcích, které tomu předchází. V první řadě mezi počáteční akce a rozhodnutí patří: Zda je originální systém vhodný k modelování a následné simulaci Zda jsou stanoveny cíle simulace (projektu) 28

29 Zda existují (nebo jsou dostupné) potřebné informace k jeho následné výstavbě a realizaci Zda lze vymezit na originálním systému objekt zkoumání a následně zkoumaný (simulovaný) systém Zda je možné zodpovědět otázky, které budou zmíněny v další podkapitole otázky pro návrh modelu V praxi se můžeme setkat hlavně s iterativním přístupem. U složitějších systémů je nutné navrhnout model (po menších částech) a následně provádět verifikaci navržených změn (při špatném výsledku verifikace lze okamžitě upravovat návrh modelu). Tato činnost se opakuje v iteracích, tak dlouho, dokud není model kompletní a verifikovaný jako celek. Pokud by se použila pouze sekvenční metoda (celý model by se navrhnul a namodeloval najednou), pak by mohlo dojít k selhání verifikace a obtížně by se identifikovaly problémy spojené s chybami v různých podsystémech. Samotný návrh ABM by měl proběhnout v těchto fázích: Analýza reálného (modelovaného) systému Navržení společenství agentů, vymezit jejich kompetence, určit hranice jednotlivých typů agentů a určit orientaci na daný typ problému, vydefinování jejich chování Navržení prostředí, ve kterém budou agenti kooperovat a komunikovat Navržení relací: mezi agenty, mezi agenty a prostředím Určení vhodnosti navrženého modelu z implementačního pohledu Otázky pro návrh modelu V době návrhu agentově orientovaného modelu je dobré se zeptat na následující otázky a pokusit se formulovat jejich odpovědi. Zodpovězení těchto otázek vede k počátečnímu návrhu modelu. Otázky jsou: Co je specifický problém, který by měl model řešit? Jaká je nosná otázka, na kterou by měl model odpovědět? Jaká je přidaná hodnota agentově orientovaného modelu oproti ostatním modelovacím technikám a přístupům? Je agentově orientovaný model vhodný pro daný problém? Co budou agenti v modelu představovat? Kdo v daném modelu rozhoduje? Které entity budou mít chování? Která data agenta jsou popisná (statická)? Které agentovy atributy by měly být zpracovávány vnitřně modelem a aktualizovány v agentech (dynamické atributy)? 29

30 V jakém prostředí budou agenti existovat? Jak budou agenti interagovat s prostředím? Je pohyb agenta v prostoru relevantní? Jaké chování nás na agentovi zajímá? Jaké rozhodnutí budou muset agenti provádět? Jaké chování je nosné pro akce agenta? Jakými akcemi bude agent disponovat? Jak budou agenti interagovat (komunikovat) mezi sebou? Interakce agentů budou expanzivní nebo specializované? Odkud by měla data pocházet, obzvláště pak u agentova chování? Jak velké bude lokální okolí agenta a jaké informace z něj bude chtít získávat? Jak může být model validován a verifikován? Jak může být validováno chování agenta? Zodpovědět tyto otázky je základní částí procesu návrhu agentově orientovaného modelu. Pro dnešní dobu existuje zase více metodik a přístupů jak modelovat. Celkově nejpřínosnější metodikou pro praxi se zdají být iterativní metody návrhu. Z praktického pohledu vývoje je iterativní přístup efektivní (lze sledovat částečné výsledky již v průběhu vývoje). Moderní softwarové (a modelovací) vývojové praktiky definují, že by návrh modelu měl být nezávislý na implementaci modelu. Znamená to, že implementace výsledného modelu by měla být možná v libovolném programovacím jazyce. Agentově orientovaným inženýrstvím se ve své publikaci zabývá pan Aleš Kubík [16], kde uvádí, že vhodnou implementační platformou se jeví právě objektově orientované jazyky například Java. Správný a detailní popis komunikace v modelu, návrhových předpokladů modelu a detailní popis elementů jsou základem pro pochopení a využití modelu dalšími vývojáři, kteří by chtěli dále model používat nebo rozšířit. Problematikou popisu modelu se zabýval pan Volker Grimm [8]. Grimm navrhl a publikoval standardní protokol pro popisování agentově orientovaných (a příbuzných) modelů Bottom up, Top down Tyto dvě strategie (přístupy) pochází z oboru informačního procesu a můžeme se na ně dívat, jako na přístup nebo styl myšlení, učení. Nejvíce se s tímto termínem můžeme setkat při vývoji softwaru, ale používá se i v ostatních oborech. Pro oba termíny je možné v literatuře nalézt synonyma. Termín top down ( od shora dolů ) je někdy nahrazován pojmem analýza nebo dekompozice. Termín bottom up ( od spoda nahoru ) je zase nahrazován synonymem syntéza. Přístup Top down (známý i jako sestupný návrh) je rozkládání systému na jeho jednotlivé podsystémy a tím se získává přehled o jeho struktuře. V prvním kroku jsou definovány podsystémy a jejich přibližné charakteristiky. Dále se každý podsystém znovu rozebírá a analyzuje (může se rozpadat na další podsystémy). Tímto postupem se systém 30

31 rozebere až na určitou dostačující úroveň detailu (většinou to bývá specifikování až na základní elementy systému). Přístup Bottom up je založen na postupném skládání základních elementů a podsystémů do sebe tak, aby ve výsledku vznikl plnohodnotný funkční systém. Většinou se podsystémy postupně formují s přibývajícími informacemi o konečném systému. V tomto přístupu jsou již atributy základních prvků specifikovány ve velkém detailu. Nadále jsou elementy kombinovány a spojovány do větších celků (i ve více vrstvách) dokud se nezkompletuje cílený systém. Největším úskalím tohoto přístupu je velká míra detailu již v počátku návrhu a vývoje. Proto se doporučuje zhotovit základní kostru (skelet) systému v té nejjednodušší funkční formě a potom ho rozšiřovat a rozvíjet jeho komplexnost. 31

32 5 Repast Suite Repast Suite 9 je skupina pokročilých, zdarma šiřitelných, open source softwarů. Tyto softwary jsou určeny pro podporu a vývoj agentově orientovaného modelování a simulace. Všechny součásti jsou kolektivně vyvíjeny více než 10 let skupinou z Chicagské univerzity v Illinois (USA). Mezi původní vývojáře patří David Sallach, Nick Collier, Tom Howe, Michael North. Tito lidé vytvořili první koncept původního frameworku Repast (z angl. The Recursive Porous Agent Simulation Toolkit ). Je důležité zmínit, že Repast Simphony je rozšíření původního frameworku Repast a přináší nový přístup k vývoji a provádění agentově orientovaných simulací. Zahrnuje navíc i mnoho pokročilých výpočetních technik pro aplikace, které simulují například sociální modely. Framework v aktuální verzi nabízí dva základní softwary a to Repast HPC (High Performance Computing) a Repast Simphony 2. První zmíněný software je implementován v C++a je určen pro simulaci masivního množství agentů. Druhý zmíněný je implementován v jazyku Java a je určen pro široké uplatnění. Umožňuje využívat všechny nativní možnosti Javy a je možné do něj i integrovat knihovny třetích stran (tím využít jejich funkčnost). Repast Simphony má další podružené softwary (ReLogo, Flowchart), které usnadňují návrh, modelování a simulaci. ReLogo na rozdíl od Repast Java má již předpřipravené abstraktní třídy (Turtle, Patch, Observer) pro základní implementaci agentů. Pro vývoj se využívá jazyka Groovy 10, ten by měl značně urychlit samotné kódování modelu. Dále existuje Repast Flowchart, který dále usnadňuje výstavbu modelu. Pro výstavbu modelu se používá vestavěný grafický editor, který umožňuje skládat agenta z grafických komponent (Property, Behavior, Task, Decision, Join, Loop, End). 5.1 Základní koncept frameworku Repast Simphony Všechny Repast softwary respektují stejné koncepty a vlastnosti. Tím je zjednodušeno používání celé platformy, případný přechod mezi platformami Repastu. Nejobecnějším konceptem je, že agenti jsou implementováni jako Objekty (pro Javu i C++ to jsou instance tříd). Stav agenta je reprezentován jeho vnitřními atributy a agentovo chování představují instanční metody. Například agent chodec v simulaci davu, může být implementován s atributy, jako je rychlost a směr. Metoda pohyb může pohnout chodcem o vzdálenost odpovídající jeho směru a aktuální rychlosti. 9 Framework je dostupný na webové adrese: 10 Groovy je objektově orientovaný programovací jazyk pro platformu Java. Jde o alternativu k programovacímu jazyku Java. Můžeme se na něj dívat jako na skriptovací jazyk pro java platformu. Inspiraci čerpal z jazyků Python, Ruby, Perl a Smalltalk. 32

33 public class Chodec { private double směr; private double rychlost; } public void pohyb() { // metoda pro agentuv pobyb } Obrázek 10 Příklad implementace agenta chodce Simulace postupuje v čase pomocí plánovače (kalendáře událostí). Plánovač má interní frontu událostí, ze které se v každém kroku vybírají události a zároveň se provádějí. Konkrétně Repast HPC vlastní diskrétní kalendář událostí s konzervativní metodou synchronizace. Uživatel plánuje události na specifický tik, kde tik udává relativní pořadí, ve kterém se mají události provést. Například můžeme mít tvrzení, že událost A je naplánována na tik = 3 a událost B je naplánována na tik = 5. Z tohoto tvrzení a dřívějšího popisu tedy vyplývá, že se událost A provede dříve než událost B. Kontext je další pojem, který se ve frameworku používá k zapouzdření populace agentů. Jedno z implementačně hlídaných pravidel je, že každá instance kontextu může obsahovat pouze jedinou instanci každého agenta (nelze do Kontextu přidat stejný objekt dvakrát). Když jsou agenti vytvořeni, lze je přidat do Kontextu a pokud se jejich životní cyklus ukončí, lze je z Kontextu odebrat. Kontext je asociován s tzv. projekcí. Projekce předepisuje relační strukturu mezi agenty v Kontextu. Pro příklad můžeme uvést mřížkovou projekci (grid projection), která vkládá agenty do maticové struktury (typicky mřížka), kde každý agent zabírá nějakou buňku (buňka má navíc atribut udávající pozici buňky v maticové struktuře). Síťová projekce dovoluje agentům definovat síť, ve které může uchovávat informace o relacích mezi agenty. Další vlastností Kontextu je, že po přidání agenta do Kontextu se agent automaticky stává i součástí všech projekcí, které jsou s Kontextem asociovány. Příklad: Kontext je asociován se síťovou projekcí, tedy po přidání agenta do kontextu se agent stane novým vrcholem v síťové projekci. Následně má možnost si dynamicky, dle svého chování, dále vytvářet spojení k ostatním agentům. Repast disponuje 5 základními projekcemi (z toho 3 jsou implementované i v HPC). Dostupné projekce jsou: Continous Space / projekce souvislého (reálného) prostoru (HPC) Geography / geografická projekce Grid / maticová projekce (HPC) Network / síťová projekce (HPC) PhysicsSpace / fyzikální projekce 33

34 Simulace v Repast frameworku je složena z množiny agentů, jednoho nebo více kontextů, které obsahují zmíněnou množinu agentů a žádné nebo více projekcí. Kontexty se mohou hierarchicky větvit a tím vytvářet různé podmnožiny projekcí a agentů. Uživatel je zodpovědný za psaní kódu agenta a framework poskytuje implementace kontextů a projekcí. Každý simulační výpočet typicky vybírá z kalendáře událostí následující událost, která byla uživatelem naplánována pro provedení. Událost vyvolá specifikované chování agenta, který je zařazen aspoň do jednoho kontextu a užívá žádnou nebo více projekcí. Například každou simulační iteraci může každý agent vytvořit nové spojení s agenty, kteří jsou dostupní v jeho lokálním okolí (okolní buňky) v maticové projekci. 5.2 Repast Simphony 2 Je inovovaný framework založený na koncepci původního frameworku Repast. V první finální verzi byl uvolněn 5. března 2012 a je to interaktivní, multi platformní modelovací systém založený na jazyku Java. Podporuje vývoj extrémně flexibilních agentově orientovaných modelů. Software je určen pro simulace na stolních počítačích nebo malých výpočetních clustrech. Repast Simphony podporuje vývoj modelů několika různými formami zahrnující prototypování modelů pomocí nadstavby ReLogo nebo využití grafického modelování ve vizuálním prostředí pomocí Flowcharts. Pro nejflexibilnější modely je k dispozici vývoj přímo v jazyce Java nebo Groovy. Všechny tyto přístupy jsou úzce propojeny vývojovým prostředím Eclipse IDE, který je dodáván již přeinstalovaný a přednastavený v základním instalačním balíčku Repast Simphony 2. Obrázek 11 Běhové prostředí Repast Simphony s 2D a 3D pohledem 34

35 Běhové prostředí Repast Simphony poskytuje GUI aplikaci, která je připravena pro vizuální konfiguraci modelu a jeho spouštění. Běhové prostředí poskytuje: GUI aplikaci pro vizuální nastavení prostředí a provádění operací s modelem Integrované 2D, 3D a mnoho dalších vizualizačních pohledů, které mohou zobrazovat aktuální stavové informace modelu Automatické připojení na zdroje dat různého typu (XML, CSV) Automatické propojení s externími programy třetích stran pro statistické zpracování, analýzu a vizualizaci výsledků modelu Distribuování modelu i s běhovým prostředím jako spustitelné aplikace, pro další osoby, které mohou s modelem dále experimentovat. Repast Simphony byl úspěšně využit v mnoha aplikačních doménách jako například sociální věda, podpora prodeje produktů, zásobovací řetězce, model budoucí vodní infrastruktury a mnoho dalších. Jednou z dalších mnohých výhod je, že k této verzi frameworku je dostupné velké množství již hotových modelů. Například model CA, Game of Life, Sugarscape a mnoho dalších. Výhodou je i částečná kompatibilita s modely, které byly vytvořené v dřívějších verzích frameworku a lze je konvertovat a využít i ve stávající verzi frameworku Repast Java Repast Java je pouze označení, ale ve své podstatě je to základní implementace Repast Simphony 2. Je to tedy nejnižší a nejflexibilnější přístup pro modelování a vývoj vlastních modelů. Na této úrovni může být agentem instance každé obyčejné třídy. To přináší obrovské možnosti implementace. Na druhou stranu je to i úskalí, protože není připravený žádný prototyp agenta a agent musí být vystavěn od samého základu. Základní množství dostupných knihoven je velké a již v základu nám framework nabízí pomocné implementace pro nativní použití genetických algoritmů (framework JGAP 11 ), neuronových sítí (framework Joone 12 ), anebo regresní analýzy (framework OpenForecast 13 ). Navíc je možné využívat vlastních knihoven nebo knihoven třetích stran, pro dosažení požadované funkcionality ReLogo Rozšíření ReLogo je nadstavba nad Repast Java. V základu poskytuje předem připravené abstraktní třídy pro snadnější implementaci a prototypování agentů. ReLogo je 11 JGAP, Java genetic algorithms package je rozšíření pro aplikaci genetických algoritmů v Javě. Informace a celá knihovna je dostupná na adrese: 12 Java Object Oriented Neural Engine (joone) je nadstavba pro realizaci neuronových sítí. Knihovna je dostupná na adrese: 13 OpenForecast je rozšíření pro použití regresní analýzy. Knihovna je dostupná na adrese: 35

36 dostupné, ve vývojovém prostředí dodávaným v instalačním balíčku, při založení ReLogo projektu. Vývojáři poskytují také možnost konvertovat starší modely typu NetLogo pomocí průvodce dostupného v nabídce vývojového prostředí. ReLogo poskytuje tyto typy předpřipravených tříd, které pocházejí z původního programovacího jazyka Logo: Turtles / Želvy jsou mobilní agenti Patches / Místa jsou fixní agenti Links / Propojení spojují želvy, aby vytvářeli sítě Observer / Pozorovatel poskytuje celkové řízení modelu Logo modely jsou realizovány vždy ve dvou dimenzionálním spojitém prostoru. Např. Želvy mohou být lokalizovány na jakémkoliv místě v prostoru, zato Místa se mohou vyskytovat pouze na diskrétních celočíselných lokacích a to pouze po jednom na dané lokaci. Modely fungují tak, že Želvy představují hlavní agenty, kteří mají chování a provádějí interakce mezi sebou a Místy Repast Flowchart Repast flowchart je další rozšíření, které umožňuje vizuální tvorbu agenta v grafickém prostředí pomocí skládání a propojování grafických komponent (ukázka na obrázku 12). Grafické prostředí je založené na frameworku Flow4J 14 od vývojářů prostředí Eclipse. Prostředí je schopné na základě definic v grafickém prostředí generovat na pozadí Java nebo Groovy kód. Ten je dále použit v běhovém prostředí. Proto jsou ve vývojovém prostředí vždy dva soubory a to například Chodec.agent (soubory s příponou agent je možné upravovat právě pomocí editoru flowcharts) a automaticky generovaný soubor Chodec.groovy, kde se při uložení flowchart souboru automaticky vygeneruje příslušný kód. 14 Framework je dostupný na webové adrese 36

37 Obrázek 12 Ukázka prostředí flowchart 5.3 Repast HPC Repast HPC (High Performance Computing) je druhá implementace Repast Simphony frameworku (je založen na stejných principech a vývojovém konceptu jako Repast Simphony). Je určen pro vysoce náročné distribuované výpočty a paralelní operace. Software je implementován v programovacím jazyce C++ s využitím MPI (Message Passing Interface), rozhraní pro paralelní operace. Výhodou je jeho možné rozšíření pomocí boost 15 knihovny. MPI je standardizované rozhraní pro předávání zpráv a lze ho tedy jednoduše rozšířit i jinými nástroji. Typickými kandidáty pro Repast HPC jsou simulační modely s masivními lokálními interakcemi a velkým počtem agentů. 15 Knihovna boost je dostupná z adresy: 37

38 Repast HPC momentálně podporuje pouze tři výše zmíněné projekce a to: Grid, ContinousSpace a Network. Jak již bylo řečeno v úvodu, Repast HPC disponuje dynamickým diskrétním kalendářem událostí, který využívá konzervativní metody synchronizace. 38

39 6 Repast Simphony Service, proprietární software V této kapitole je popsáno vlastní řešení softwarové nadstavby nazývané Repast Simphony Service (zkráceně pak RepastS Service), které bylo vyvinuto pro rozšíření možností základního frameworku a umožňuje tak modelování širší třídy systémů. Podkapitoly uvádí popis požadavků, návrh, popis vnitřní struktury a důležité koncepty pro jeho použití. Motivace pro vytvoření této nadstavby je absence mechanizmu pro rychlý vývoj obslužných systémů v prostředí ABM. Přitom mnoho modelů, které se v praxi realizují je právě kombinace agentových systémů interagujících (nebo se účastnících) právě systémů hromadné obsluhy. Například můžeme uvést model letiště, kde je zahrnut pohyb lidí po letištní hale a letadel po letišti. Lidé se přitom snaží v hale nakupovat zboží (občerstvení, suvenýry), zakoupit si letenku a následně nastoupit do letadla. 6.1 Popis problému obslužných systémů v AOS Systémy hromadné obsluhy Proces uspokojování náhodně i hromadně vznikajících požadavků na obsluhu se nazývá proces hromadné obsluhy. Předmětem teorie hromadné obsluhy, někdy také označované jako teorie front (z anglických slov queueing theory), je matematické rozpracování a analyzování systémů poskytujících hromadnou obsluhu nějakých zařízení. Systém hromadné obsluhy je obsluhové zařízení, poskytující obsluhu určitého druhu. Do tohoto zařízení vstupují zákazníci požadující konkrétní obsluhu. Zde je nutné podotknout, že pod pojmem zákazníci se rozumí nejen lidé, ale i neživé věci. Proto se také někdy, místo pojmu zákazníci, používá termín požadavky na obsluhu. Po obsloužení zákazníci opouštějí systém hromadné obsluhy. Obsluhové zařízení se může skládat z jednoho nebo více míst, na kterých se poskytuje konkrétní obsluha. Tato místa se nazývají linky obsluhy.[27] Systém hromadné obsluhy (SHO) je základní teoretický model pro realizaci obslužných procesů. SHO je tvořený obslužnými kanály, které poskytují obsluhu požadavkům, přicházejícím ve vstupním proudu. Po ukončení obsluhy trvající stanovenou dobu se kanál uvolňuje a realizovaný požadavek odchází ve výstupním proudu.[27] 39

40 Pokud v okamžiku příchodu požadavku není volný žádný kanál, řadí se požadavek do fronty. Obrázek 13 Systém hromadné obsluhy zdroj [27] (A vstup požadavků do systému, B odmítnuté požadavky, C realizované položky) Systém hromadné obsluhy je vždy tvořen následujícími prvky: vstupní proud fronta obslužné kanály výstupní proud V reálném světě a tedy i v simulačním modelu se může takovýchto systémů objevovat více najednou. Obslužným systémem budeme tedy rozumět systém hromadné obsluhy, který by mohl v realitě existovat Obslužný systém v AOS V agentově orientovaných systémech je typické, že se agenti mohou účastnit jednotlivých obslužných systémů, které jsou v modelu dostupné. Obecně lze říci, že v ABM je takovýchto jednotlivých obslužných systémů mnoho. Právě tato skutečnost je motivací pro vytvoření obecného mechanizmu, který umožní zjednodušit implementaci obslužných systémů v agentově orientovaných modelech. V reálném světě obslužné systémy zachycují nějaký reálný proces, který je spouštěn příchozími požadavky. Obslužné systémy lze ve většině případů popsat posloupností procesů a elementárních aktivit, které musí aktéři modelu (zákazníci, obslužné zdroje) provést pro úspěšné dokončení obsluhy. Tento postup lze zachytit například pomocí síťového grafu (nebo množinou síťových grafů), kde jednotlivé hrany grafu vyjadřují jednotlivé elementární aktivity. Vrcholy síťového grafu v našem případě, 40

41 pouze propojují posloupnosti aktivit mezi sebou, aby bylo možné identifikovat, v jakém pořadí se mají provést. Tento síťový graf má jeden počáteční vrchol, kde obslužný proces začíná a jeden cílový vrchol, kde proces končí. 6.2 Požadavky Pro správnou funkčnost softwaru je nutné definovat požadavky, které jsou kladeny na navrhovanou nadstavbu. Mezi hlavní požadavky patří: Nadstavba musí umožnit lokální realizaci obslužného systému v agentově orientovaném prostředí. Nadstavba musí být jednoduše integrovatelná do agentově orientovaných simulačních modelů ve frameworku Repast Simphony 2. A dále přehled doplňujících požadavků, které vyplynuly při konzultacích a vývoji softwarové nadstavby: K Nadstavbě musí být vypracována programová dokumentace v podobě vygenerovaného Javadoc a programátorská příručka, jako návod k použití nadstavby pro další vývojáře. Nadstavba musí mít možnost volitelné vizuální podpory pro elementární akce, které jsou při obslužném procesu prováděny (umožňuje názornější vizuální analýzu modelu). Nadstavba musí umožnit, aby délka trvání provádění aktivity mohla být zadána staticky i dynamicky (proud náhodných čísel z konkrétního rozdělení pravděpodobnosti). Programovací jazyk je dán platformou frameworku. Jelikož je základní implementace Repast Simphony 2 dostupná v jazyce Java, byl zvolen stejný programovací jazyk i pro vývoj nadstavby. 6.3 Návrh Z teorie o systémech hromadné obsluhy, která je uvedena v kapitole 6.1, vyplývají některé požadavky a hlavní otázky pro návrh. V následujícím textu bude uvedeno, které jednotlivé části sytému jsou pro realizaci mechanizmu podstatné a které ne. Vstupní proud požadavků zajišťuje prostředí s agenty, to tedy není předmětem návrhu ani realizace. Předmětem návrhu je, jak v simulačním prostředí realizovat obslužný proces (obslužnou událost). Dále je potřeba řešit případ, kdy není dostatek obslužných kanálů. Tím vznikají (a musíme řešit) fronty požadavků. Po dokončení obslužného procesu je požadavek úspěšně dokončen a je možné obsloužit další následující požadavek na obsluhu. V rámci diplomové práce byl tedy navržen obecný mechanizmus, jakým lze dosáhnout realizace obslužného systému pro použití v simulačním prostředí. Řekněme, že 41

42 se obslužný proces může skládat z libovolného nenulového a nezáporného počtu obslužných aktivit. Tyto aktivity jsou dané konkrétním obslužným procesem a dokončení všech obslužných aktivit vede k dokončení obslužného procesu. Počet aktivit v daném obslužném procesu je dán úrovní abstrakce, která se uplatní při návrhu simulačního modelu. Může tedy dojít k situaci, že se jeden obslužný proces bude skládat pouze z jedné aktivity. Aktivita je reálná nebo abstraktní činnost, která může a nemusí trvat nějaký (simulační) čas. Další otázkou je, proč vznikají fronty při obslužném procesu? V našem případě je to kvůli omezenému počtu obslužných kanálů. Obslužné kanály budeme chápat jako nějakou věc (dále budeme takovouto věc nazývat obslužným zdrojem), která je potřeba k tomu, aby se mohl provést a dokončit jeden konkrétní obslužný proces (respektive některá jeho aktivita). Při neomezeném počtu obslužných zdrojů se tedy nebudou tvořit žádné fronty, protože může současně probíhat potřebný počet obslužných procesů (existuje neomezený počet obslužných kanálů). V případě, že jsou obslužné zdroje omezené (v reálném světě tomu tak je), lze současně provádět jen omezený počet obslužných procesů a ostatní požadavky se musí zařadit do fronty a počkat, až na ně přijde řada. Nadstavba je navržena tak, aby odrážela fungování reálného světa a tím by mělo být její použití pochopitelnější, jednodušší a intuitivní. Mechanizmus nadstavby je obecný, ale z pohledu implementace je závislý na platformě Repast Simphony. Nicméně to nebraní dalšímu rozšíření a obecný princip implementovat i v jiných modelovacích nástrojích Základní koncept Základní myšlenkou je reprezentovat obslužný proces jako proveditelný síťový graf. Jednotlivé hrany síťového grafu reprezentují elementární obslužné aktivity. Síťový graf nám umožňuje definovat souběžné i sekvenční posloupnosti aktivit, jako tomu je v reálném světě a je tedy dostatečně dynamický pro modelování všech případů reálného světa. Tento obslužný proces, který je reprezentovaný síťovým grafem, budeme dále nazývat technologickým procesem. Úroveň abstrakce modelu pak udává složitost modelu. To určuje, do jaké míry dekomponujeme modelovaný problém a jak ho rozdělíme na jednotlivé technologické procesy a jejich aktivity. Dalším pravidlem je, že aktivita může trvat libovolnou nezápornou dobu a pro své provedení může vyžadovat zdroj obsluhy. V případě nedostupnosti zdroje obsluhy, se žádající instance řadí do fronty a čekají na uvolnění zdroje. Tímto konceptem jsme schopni popsat a zapouzdřit jakýkoliv obslužný systém do technologického procesu. 42

43 Technologický proces 1 Spuštění TP z prostředí Aktivita 1 Aktivita 2 Aktivita 3 Aktivita 4 Provedený obslužný proces Manažer Zdrojů 1 Blokující fronta požadavků na zdroj Sdílená část Manažer Zdrojů 2 Požadavky jiných TP Obrázek 14 - Koncept funkce technologického procesu Aktivita Aktivita představuje elementární hranu technologického procesu. Může mít nezáporné trvání a pro její provedení může vyžadovat zdroj obsluhy. Pro definování jednotlivých aktivit do technologického procesu jsou k dispozici tři základní typy aktivit a další doplňující, které poskytují rozšířené možnosti. Typy aktivit jsou: Zpožďovací aktivita (Delay Activity) její provedení trvá nějakou dobu (jediný element, který provádí posun simulačního času) Alokační / přidělovací aktivita (Seize Activity) pro její spuštění je potřeba zdroj obsluhy. Po přidělení zdroje obsluhy se zdroj do aktivity uloží a aktivita se dokončí Dealokační / uvolňovací aktivita (Release Activity) při jejím dokončením je uvolněn uložený zdroj obsluhy Kombinace výše zmíněných typicky je potřeba kombinovat aktivitu trvání s aktivitou, která vyžaduje obslužný zdroj Speciální aktivity například aktivita, která umožní spuštění jiného technologického procesu a doba trvání je stejná jako doba trvání interního technologického procesu. Dalším příkladem je předání řízení jiné struktuře, pak aktivita čeká, dokud není znovu aktivována z vnějšího okolí danou strukturou Příkladem jedné aktivity může být výměna zadního kola automobilu, která trvá přibližně 3 až 5 minut. 43

44 6.3.3 Zdroj Obsluhy Zdrojem obsluhy se rozumí objekt (člověk, věc), který je nutný pro vykonání konkrétní obslužné aktivity. Například v modelu obchodního domu, by po vybrání produktů, měli zákazníci zaplatit na pokladně. V případě, že na pokladně není pokladní (ta v tuto chvíli představuje obslužný zdroj), nelze provést zaplacení nákupu. Tímto způsobem se vytváří fronty. Ve chvíli, kdy pokladní je k dispozici, může pokračovat v obslužném procesu a úspěšně ho tak dokončit. Zdroje obsluhy tedy omezují kapacitně provádění jednotlivých obslužných procesů a to jak interně, tak i mezi jednotlivými obslužnými procesy. Pro příklad můžeme rozšířit příklad s pokladní. Pokladen by bylo více a zákazník by si mohl vybrat, u které zaplatí. Pro všechny pokladny je zdrojem obsluhy elektřina, bez které nemůžou obsluhovat pokladní své terminály. V případě, že vypneme elektřinu (odebereme zdroj obsluhy), se zastaví veškerá činnost všech pokladen Technologický proces Obslužný proces realizovaný síťovým grafem je v prostředí nadstavby nazván technologickým procesem. Ten představuje návod nebo šablonu, podle které má obecně objekt jednotlivé elementární aktivity provést a v jakém pořadí aktivity vykonat. V nadstavbě jsou vytvářeny pro agenty (obecně tedy objekty modelu) instance technologického procesu. Tyto instance odráží aktuální stav právě prováděného obslužného procesu. Každý agent vlastní svou instanci. Je to z toho důvodu, že každý agent může být v jiné fázi svého obslužného procesu. Technologický proces tedy zapouzdřuje posloupnost aktivit, které postupným prováděním vedou k dokončení obslužného procesu. Trvání technologického procesu je sumou délky trvání všech aktivit, které obsahuje. 6.4 Implementace Nadstavba je realizována dle návrhu v předchozí kapitole a implementována v jazyce Java. Její třídy závisí na knihovnách frameworku Repast Simphony 2. Každý hlavní objekt z návrhu má své rozhraní 16 například IActivity, ITechnologicalProcess, IResource. Rozhraní je veřejná část, se kterou lze implementovat ABM. Řešení nadstavby je schválně navrženo tak, aby byl programátor nucen programovat proti výše zmíněnému rozhraní. Vytváření nových objektů je implementováno pomocí továrních tříd, které umožňují kompletně skrýt implementaci jednotlivých objektů. Skrytí implementace je důležité pro případné další rozšiřování nebo úpravu nadstavby. 16 Názvy rozhraní v nadstavbě respektují konvenci popisu rozhraní z jazyka C#, tedy každý název rozhraní začíná velkým písmenem I. Například rozhraní IOsoba. 44

45 Obrázek 15 Struktura balíčků RepastS Service Zdrojové kódy jsou rozděleny do balíčku dle logického uspořádání (viz. Obrázek 15): Patterns balíček obsahuje rozhraní pro použité návrhové vzory. Processing balíček obsahuje kód spojený s výkonnou částí kódu. o Activity obsahuje rozhraní a implementace všech aktivit. Poskytuje veřejnou tovární třídu pro vytváření instancí jednotlivých aktivit. Ostatní třídy jsou dostupné pouze v rámci balíčku. o Technological process obsahuje rozhraní a implementace technologického procesu. Resource obsahuje rozhraní a skeletální implementaci 17 obslužného zdroje. Repast interface obsahuje pomocné třídy pro zjednodušení přístupu a použití frameworku Repast Simphony. Tyto pomocné třídy slouží také jako částečné oddělení kódu nadstavby a frameworku. Všechny UML diagramy související s návrhem a implementací nadstavby jsou uvedeny na obrázcích v příloze A. V příloze je uveden diagram tříd pro všechny rozhraní aktivit a na dalším diagramu jejich návaznost na technologický proces Aktivita Jednotlivé instance aktivit lze získat pomocí tovární třídy ActivityFactory (návrhový vzor factory), která poskytuje instance všech dostupných typů aktivit a zapouzdřuje tak vytváření instancí aktivit. Rozhraní aktivity definuje akce jako: start, násilně ukončit, je běžící, je ukončená a další. Základní implementace aktivity je stavová třída, která uchovává informace potřebné pro správnou funkčnost. Při vytváření aktivity, která má délku trvání, lze zadat reálné číslo (statický způsob), anebo jí lze předat objekt typu AbstractDistribution (z knihovny Colt ), který představuje proud náhodných čísel konkrétního pravděpodobnostního rozdělení. Aktivita si před startem načte náhodnou 17 Skeletální implementace umožňuje programátorům velmi snadno poskytnout vlastní implementace rozhraní. zdroj: [3] 18 Projekt Colt je open source projekt pro náročné vědecké a technické výpočty realizovaný v jazyku Java. Dostupný na adrese 45

46 dobu trvání a uloží si ji pro interní použití. Aktivita s délkou trvání je jediná aktivita, která plánuje událost do centrálního kalendáře událostí a tím provádí posun simulačního času. Aktivita si naplánuje událost, která ji po uplynulé době znovu zpětně oznámí, že je čas pokračovat a dokončit celou aktivitu (případně provést stavové změny). UML diagram tříd a rozhraní je dokumentován v příloze A Zdroj Obsluhy Pro zdroj obsluhy nebylo zamýšleno implementovat vlastní abstraktní třídu, protože zdrojem obsluhy může být v modelu obecně jakýkoli objekt, který implementuje rozhraní IResource. Pro případ, že by někdo chtěl použít již hotové řešení. Nadstavba poskytuje jednoduchou skeletální implementaci rozhraní v podobě třídy AbstractResource. Programátor si tedy může vybrat, zda chce přímo implementovat rozhraní nebo využít dědičnosti. V modelu se instance zdrojů nepoužívají samostatně. Využívá se takzvaného manažera zdrojů obsluhy. Objekt představující manažera zdrojů je interně navržen jako návrhový vzor Fond. Při vytvoření je v něm interně vytvořena zásoba daného počtu instancí typu IResource. Manažer pak tyto instance na požádání poskytuje a čeká na jejich vrácení. Instance manažerů lze získat pomocí statických metod třídy ResourceManagerFactory. Nadstavba poskytuje dva typy manažerů zdrojů, které se liší použitím. Níže jsou uvedeny rozhraní objektů, které vrací tovární třída manažerů: 1. IResourceManager neumožňuje automatické čekání na zdroj, pokud zdroj není aktuálně žádný k dispozici. V případě, že nelze alokovat zdroj, generuje chybovou výjimku. Je umožněno manuální zaregistrování do fronty pomocí metody definované v tomto rozhraní. 2. IResourceManagerQueued tento manažer je použit pro automatický technologický proces a poskytuje automatické řazení do fronty, pokud nejsou aktuálně dostupné volné zdroje. V případě potřeby má v rozhraní definovanou metodu pro odstranění čekající instance z fronty Technologický proces Pro prostředí nadstavby představuje technologický proces síťový graf skládající se z jednotlivých aktivit (aktivita odpovídá hraně grafu). Každý technologický proces implementuje rozhraní ITechnologicalProcess, které definuje jeho základní metody. Aktuálně je k dispozici jedna implementace TP a to tzv. AutomaticTechnologicalProcess. Tato třída poskytuje implementaci, která se automaticky stará o spouštění zaregistrovaných aktivit s ohledem na podmínkové aktivity, které byly předány v parametru při registraci nové aktivity. Podmínkovou aktivitou se rozumí taková aktivita, která musí být dokončena před spuštěním aktuální aktivity. V síťovém grafu je to aktivita, která vchází do vrcholu a podmiňuje tím všechny aktivity, které z vrcholu vychází. 46

47 Pro vytvoření a získání nové instance je nutné zavolat příslušnou statickou metodu třídy TechnologicalProcessFactory Registrace aktivit Registrace aktivit probíhá pomocí metody registeractivity (nová Aktivita, [výčet podmínkových Aktivit]). Důležité je pochopit, jak funguje princip volání této metody, protože umožňuje vkládání a zároveň uspořádání aktivit v grafu. Princip použití je následovný. Jako první parametr se uvádí instance nově přidávané aktivity. Pokud má tato nová aktivita čekat na dokončení jiných aktivit, je možné tyto aktivity uvést jako další parametry. Tímto způsobem lze dosáhnout i paralelního provádění aktivit. V případě použití podmínkových aktivit, musí být tyto instance již zaregistrované v TP. Příklad definice paralelního provádění: ITechnologicalProcess tp = TechnologicalProcessFactory.createAutomaticTechnologicalProcess(); tp.registeractivity(.registeractivity(pridelitpokladni); tp.registeractivity(.registeractivity(namarkovatnakup, pridelitpokladni); tp.registeractivity(.registeractivity(vytahnoutpenezenku, pridelitpokladni); tp.registeractivity(zaplatitnakup, vytahnoutpenezenku, namarkovatnakup); tp.registeractivity(uvolnitpokladni, zaplatitnakup); Vizuální podoba obslužného procesu pro výše zmíněný kód dokumentuje Obrázek 16. Názvy proměnných v kódu pro názornost odpovídají názvům hran v obrázku. V kódu jsou podtržením označeny aktivity, které se po spuštění technologického plánu provedou současně. Obrázek 16 Technologický proces nákupu s paralelní činností Vizuální podpora Vizuální podpora jako taková není potřeba, protože ji Repast Simphony již řeší implicitně. Běhové prostředí poskytuje konfigurovatelné vizualizační prostředí pro zobrazování stavového prostoru agentově orientovaného modelu. Vizualizační možnosti jsou relativně široké a lze částečně implementovat i vlastní mechanizmy vizualizace na základě informací ze stavového prostoru modelu. 47

48 Jak bylo již zmíněno, problém při provádění aktivity obslužného procesu nespočívá v její vizualizaci, ale v tom, jak se projeví provádění aktivity ve stavovém prostoru. Proto byla pro potřeby aktivit doplněna podpora pro automatický pohyb. Automatický pohyb je volitelná součást k aktivitám (přidává se pomocí parametru při vytváření aktivity). Přidává možnost automatického pohybu jednotlivých účastníků při provádění aktivity. Účastníkem může být objekt, který spouští aktivitu (dále ho budeme nazývat exekutorem ), alokovaný zdroj nebo bod v prostoru. Rozhraní IActivityMovementParams definuje potřebné informace pro vytvoření různých podporovaných typů pohybů. Například informace pro pohyb exekutora ke zdroji nebo zdroje ke specifikovanému bodu v prostoru. Instance parametrů lze přidat jako parametr při vytváření aktivity a tím zapnout automatický pohyb účastníků dané aktivity. Pro generování instancí parametrů pohybu je potřeba získat instanci rozhraní IActivityMovementParamsFactory, která se stará o konstrukci správných instancí parametrů pohybu pro daný typ projekce. Pro tyto potřeby je implementována třída ActivityMovementParamsFactory. Tato třída vytváří pro různé projekce odlišné implementace rozhraní IActivityMovementParamsFactory (podle návrhového vzoru abstract factory). Pomocí tohoto návrhového vzoru dosáhneme nezávislosti pohybu na projekci, lze tedy případně implementovat pohyb i v dalších projekcí. Aktuální implementace poskytuje automatický pohyb pro nejpoužívanější projekci a to tzv. souvislého prostoru (z angl. continuous space). 48

49 7 Případové studie obslužných systémů Případové studie byly zvoleny pro ověření aplikovatelnosti softwarové nadstavby v různých typech agentově orientovaných modelů s obslužnými systémy a minoritně pro prozkoumání možností platformy Repast Simphony 2. V následujících kapitolách budou uvedeny 3 případové studie. Každá z nich má jiný specifický cíl, který bude uveden v jejím popisu. Popis případové studie zahrnuje obecné představení modelované situace, popis modelu a jeho konceptuální návrh, ukázku realizace a vyhodnocení vzhledem k cíli případové studie. 7.1 Model M/M/1 Tato případová studie se zaměřuje na jednoduchý exponenciální model označován v teorii hromadné obsluhy jako M/M/1. Je zvolen kvůli své jednoduchosti a z důvodu existence analytického řešení systému. Tento model předpokládá jednu obslužnou linku s dobou obsluhy, která se řídí exponenciálním rozdělením a předpokládá vstup jednotek do systému také pod exponenciálním rozdělením. Není li dáno jinak, předpokládá se systém fronty typu FIFO a neomezený počet míst ve frontě. [27] Implementace modelu byla realizována ve spolupráci s panem Bc. Jiřím Popelkou, který realizoval model pomocí metody snímání aktivit. V závěru bude tedy uveden pouze výsledek jeho experimentu a v této práci bude model řešen asynchronní metodou plánování událostí. fronta Obrázek 17 Ukázka modelu M/M/1 ve vizuálním prostředí Cíle případové studie Cílem této případové studie je ověřit správnou funkčnost simulační platformy Repast Simphony 2. Funkcionalita bude ověřena implementací modelu do prostředí frameworku a experimentální metodou se bude zjištěna střední hodnota doby pobytu zákazníka ve frontě. Následně budou porovnány experimentální výsledky s analytickým řešením systému. 49

50 7.1.2 Parametry modelu Obecný popis modelu byl uveden na začátku kapitoly. Pro porovnání je potřeba definovat počáteční podmínky pro experiment, analytické řešení a následné porovnání. Parametry modelu jsou: exponenciální vstupní proud o intenzitě λ = 1 (znamená průměrně 1 požadavek obsluhy za 1 časovou jednotku) exponenciální intenzita obsluhy µ = 10 / 9 (znamená, že obsluha je schopna průměrně obsloužit 9 zákazníků z 10) Implementace modelu pro následné experimentování proběhne dvěma přístupy a to: Asynchronní metodou plánování událostí představitel diskrétní metody. Synchronní metodou snímání aktivit v našem případě představitel spojité metody. Parametrem pro porovnání je střední hodnota doby pobytu zákazníka ve frontě. Ta by se v případě experimentálního zjištění (při dostatečném počtu opakování nebo délce simulace) měla blížit analytickému řešení Analytické řešení systému M/M/1 Následující text byl převzat z materiálu [12]. Níže je uvedeno exaktní řešení pro simulovaný obslužný model M/M/1 se zvolenými parametry. Intenzita vstupního proudu: λ [zákazníků/jednotku času] Intenzita obsluhy: μ [zákazníků/jednotku času] Využití linky obsluhy: ρ=(λ/μ)x100 [%] Průměrný počet zákazníků v systému: L = λ/(μ-λ) [zákazníků] Průměrný pobyt zákazníka v systému: w = 1/(μ-λ) [čas. jednotek] Průměrný pobyt zákazníka ve frontě: wq = λ/(μ(μ-λ)) [čas. jednotek] λ = 1 zákazník/min μ = 10/9 zákazníků/min ρ = (λ/μ) x 100 = 90 % L = λ / (μ-λ) = 9 zákazníků w =1/(μ-λ) = 9 minut wq=λ/(μ(μ-λ)) = 8,1 minuty Závěr Experimentálním způsobem byl naměřen výsledný průměrný čas, který stráví zákazník ve frontě. Průměr se rovná 8,06 ± 0,49 jednotky času. Jelikož je analytické řešení 50

51 v intervalu spolehlivosti, můžeme říci, že se výsledky přibližně rovnají. Tímto závěrem je tedy ověřena funkčnost simulační platformy Repast Simphony 2. Pan Bc. Popelka Jiří ve svém modelu dospěl k podobnému řešení, které dokazuje, že i synchronní metodou snímání aktivit, lze dosáhnout experimentální cestou stejného řešení. Podrobná data z měření jsou přiložena v souboru na přiloženém CD. 7.2 Model pneuservis V této případové studii bude objektem zkoumání model pneuservisu. Zadání pro případovou studii bylo převzato ze studijních materiálů [11], [12] a je uvedeno v popisu modelu. Hlavní motivací tohoto modelu je realizace typického obslužného systému v agentově orientované platformě Repast Simphony Popis Velká provozovna pneuservisu se připravuje na kritické období před nástupem zimní sezóny, kdy (jako každoročně) očekává obrovský zájem motoristů o výměnu pneumatik na vozidlech. V tomto roce se v provozovně rozhodli, v rámci zhruba tří kritických týdnů, vyčlenit svoji velkou dílnu pouze pro účely provádění výměn letních pneumatik za zimní. Obrázek 18 Ukázka modelu pneuservisu ve vizuálním prostředí Na obrázku B.1 jsou uvedeny technologické postupy dvou typů výměn pneumatik ve formě síťových grafů. Jednotlivé orientované hrany těchto grafů odpovídají elementárním technologickým činnostem. U každé hrany je na uvedeném obrázku v závorce popsán typ zdroje (Z zvedák, M montážní mechanik, V vyvažovací zařízení spolu s mechanikem vyvažovačem [uvažováno jako nedělitelná dvojice]), který je pro zabezpečení této činnosti potřebný. Podle aktuální disponibility zdrojů, resp. 51

52 uplatňované řídící strategie, je možné každé technologické činnosti (kromě vjezdů nebo výjezdů ze zvedáku) přidělit 1 2 instance potřebného typu zdroje, přičemž počet aktuálně přidělených instancí ovlivní dobu potřebnou k provedení této činnosti. Pro potřeby modelování technologických procesů jsou prezentovány na obrázku A.2 elementární technologické aktivity, které jsou obohaceny o alokace a dealokace obslužných zdrojů, případně o jejich nástupy a odstupy (způsobují časové prodlevy) od obsluhovaných objektů Cíle případové studie V tomto simulačním modelu se zaměříme na integraci vyvinuté nadstavby do servisně orientovaného modelu tak, aby usnadnil jeho implementaci a případně umožnil jeho jednoduché rekonfigurování či rozšíření. Lze tedy říci, že cílem studie je praktické použití nadstavby pro realizaci modelu a následné zhodnocení náročnosti implementace Návrh V první fázi identifikujeme hlavní problém, který model řeší. Model má modelovat situaci, kde zákazníci požadují dva typy obsluhy (každý z obslužných procesů je popsán síťovým grafem na obrázku B.1). Zákazníci vstupují do systému s určitou intenzitou λ z a jsou obsluhováni příslušnou technologickou linkou. V případě, že není dostupná žádná linka, zákazníci čekají na odbavení Definice entit, agentů a chování V agentově orientovaném modelu je potřeba specifikovat, které entity budou představovat agenty a jakou budou mít odpovědnost a chování. Přehled navržených agentů a jejich chování: Vstupní agent vytváří nové zákazníky dle parametrů pravděpodobnostního rozdělení (pro náš případ je to exponenciální rozdělení) a vkládá je do modelu. Výstupní agent odebírá zákazníky ze systému. Agent zákazník jeho úkolem je pohybovat se v prostoru, najít agenta pneuservisu, účastnit se technologického procesu, po úspěšné obsluze odejít z pneuservisu Agent pneuservisu jeho úkolem je identifikovat požadavek zákazníka a vygenerovat příslušný technologický proces Přehled zdrojů obsluhy: Montážní technik Vyvažovací technik Zvedák zvedá zákazníkovo vozidlo, aby bylo možné provést opravu Vyvažovací přístroj používá ho vyvažovací technik pro vyvážení pneumatik 52

53 Volba prostředí Při volbě prostředí musíme zvážit požadavky na model. Jeden z požadavků je vizuální prezentace stavových změn. Protože cílová platforma umí implicitně zobrazovat pouze stavový prostor a změny v něm, je potřeba zvolit takové prostředí, ve kterém se agenti mohou pohybovat. Z toho také plyne, že prostorová aktivita agentů je relevantní a je nutné zvolit prostorové prostředí Volba komunikačního mechanizmu V tomto případě nebudeme zavádět žádný specializovaný mechanizmus komunikace. Agenti spolu komunikují přímým voláním metod druhé instance. Jediné omezení je prostorové. Agenti mohou komunikovat pouze s agenty v jeho těsném prostorovém okolí Koncept fungování modelu Nyní je potřeba specifikovat, jak bude celý model fungovat. V první řadě se agenti zákazníků dostaví k agentovi pneuservisu. Zákazník podá požadavek na konkrétní typ obsluhy a agent pneuservisu vygeneruje příslušný obslužný proces v podobě technologického procesu. Zákazník začne provádět jednotlivé akce dle poskytnutého TP. Technologický proces zapouzdřuje posloupnost činností tak, jak jsou popsány v síťovém grafu na obrázku B.1. Pokud jednotlivé činnosti potřebují pro své provedení zdroj obsluhy, čekají až do doby, kdy je daný zdroj obsluhy dostupný. V případě, že není dostupný žádný volný zvedák pro vozidlo zákazníka, tak si zákazník stoupne do fronty, kde čeká na uvolnění zvedáku. Po dokončení technologického procesu zákazník odchází směrem k agentovi výstupu, kde je odstraněn z modelu Parametry modelu a simulační scénáře Scénář 1 Scénář předpokládá neomezený provoz. Je nutné experimentálním způsobem zjistit, kolik je potřeba najmout zaměstnanců, aby ve frontě před pneuservisem stáli v průměru max. 3 zákazníci. Pro tři zákazníky pneuservis připravil čekárnu s kávovarem a posezením, kde by měli zákazníci pohodlně strávit čas, než se dostanou na řadu. Hlavní cíle optimalizace: průměrný počet zákazníků [X p<= 3] využití zdrojů [MAX] počet zaměstnanců (typ Z, M i V) [MIN] Scénář 2 Scénář s omezenými zdroji. Pro každou montážní směnu je k dispozici 5 montážních techniků a 3 vyvažovací technici. Vedení pneuservisu zajímá, zda má smysl rozšířit dílnu o další zvedák (stávající řešení má k dispozici 2 zvedáky). Hlavní cíle optimalizace: průměrný počet čekajících zákazníků [MIN] využití zdrojů [MAX] 53

54 7.2.5 Výsledky Scénář 1 č. Z V M Využití zdrojů (Z, V, M) [%] Průměrný počet čekajících 1 2 (4) (4) 99,5%; 35,2%; 47,2% 123, (6) (6) 85,6%; 30,1%; 40,5% 2, (8) (8) 64,7%; 22,7%; 30,5% 0, ,3%; 36,0%; 48,8% 2, ,0%; 47,0%; 63,25% 3, ,6%; 61,0%; 82,0% 4, ,3%; 61,3%; 61,7% 11, ,0%; 45,7%; 49,0% 3,12 Tabulka 1 Výsledky experimentu pneuservisu podle scénáře Výsledky experimentů pneuservisu poměrná hodnota (pro účely porovnání) počet zdrojů [min] využití zdrojů [max] Průměrný počet čekajících Graf 1 - Výsledky experimentu pneuservisu podle scénáře Scénář 2 č. Z V M Využití zdrojů (Z, V, M) [%] Průměrný počet čekajících Tabulka 2 - Výsledky experimentu pneuservisu podle scénáře 2 54

55 poměrná hodnota (pro účely porovnání) Výsledky experimentů pneuservisu počet zdrojů [min] využití zdrojů [max] průměrný počet čekajících 1 2 Graf 2 - Výsledky experimentu pneuservisu podle scénáře Závěr případové studie Platforma Repast Simphony 2 nativně nepodporuje vyhodnocování dat mezi jednotlivými běhy simulačního modelu (tzv. replikacemi). Proto byl u všech měření zvolen přístup dostatečně dlouhého simulačního běhu, který zajistí ustálení hodnot. Z měření modelu nastaveného dle prvního scénáře bylo zjištěno, že optimální konfigurace (zaměstnanců a techniky) byla v simulačním experimentu č. 8 (viz. Tabulka 1). U této konfigurace sice byl zanedbán patrný přesah zadané podmínky, že průměrný počet zákazníků ve frontě musí být maximálně 3 (naměřený průměrný počet je 3,12), ale v celkovém zhodnocení vyhovuje ze všech nejvíce. Graf 1 zobrazuje data pro vizuální porovnání. Je z něj i patrné, že simulační experiment č. 6 sice nesplňuje původní podmínku, ale do budoucnosti by to byla větší úspora pro provozovatele pneuservisu. Čekárna by se rozšířila o další místo pro dalšího zákazníka a v pneuservisu by stačili pouze 3 montážní a 3 vyvažovací technici. Z dlouhodobého hlediska je výhodnější zaměstnávat o 3 zaměstnance méně. Z naměřených hodnot druhého scénáře vyplynulo, že se vyplatí investovat do dalšího zvedáku. Graf 2 zachycuje, že přidáním dalšího zvedáku se sníží počet čekajících zákazníků a zároveň bude stávající počet zaměstnanců lépe vytížen. Z pohledu náročnosti výstavby modelu, je samotná implementace obslužného systému minimalizována právě vyvinutou nadstavbou. Pokud by tato případová studie nesloužila jako demonstrační příklad pro servisně orientovanou nadstavbu, bylo by už v době návrhu vyhodnoceno, že se tento model nehodí realizovat v agentově orientovaném prostředí. Například Arena Simulation Software (od firmy Rockwell Automation) je 55

56 prostředí, se kterým se mohou studenti setkat při výuce předmětu modelování a simulace. Tento software podporuje vizuální tvorbu modelu pomocí definování a spojování funkčních bloků. Tento model by tímto nástrojem byl realizován mnohem rychleji a jednodušeji. Pokud vezmeme v potaz i znalost programovacího jazyka, tak pro práci s nástrojem Arena není jeho znalost vůbec vyžadována. 7.3 Model výstaviště Model výstaviště je zvolen kvůli jeho vhodnosti pro modelování v agentově orientovaném prostředí. Předmětem modelování by měl být náhodný pohyb zákazníků (agentů) po hale výstaviště, kde se zákazník rozhoduje, který stánek by chtěl navštívit a něco si zakoupit. Dále poskytuje vhodné podmínky pro lokální obslužné systémy v podobě stánku na výstavišti, kde si mohou zákazníci prohlédnout, anebo si koupit nějakou věc zájmu. Tento model by měl umožnit kompozici typického agentově orientovaného modelu s obslužnými systémy realizovanými pomocí vyvinuté nadstavby Popis Výstaviště je velká hala, kde se každoročně uskutečňuje přehlídka jednotlivých firem, které se zabývají oblastí informačních technologií. Všechny firmy si navážejí své zásoby propagačních materiálů a produktů k prodeji do skladu, který je pro tyto účely postaven přímo u areálu výstaviště. Před otevřením výstaviště mají firmy možnost si dopravit libovolné množství produktů přímo do propagačního stánku, kde si je budou moci po otevření koupit návštěvníci. Návštěvníků je každým rokem čím dál více a majitele výstaviště by zajímalo, jaká je maximální intenzita a kapacita výstaviště při letošní topologii rozmístění stánků (viz obrázek C.1), aby v reálném provozu nedošlo k nehodám zapříčiněných právě velkým počtem návštěvníků na výstavišti. Dle interních pravidel výstaviště se mohou stánky stavět pouze po obvodu vnějších stěn, anebo po obvodu stěny vnitřního sloupu, jak je dokumentováno na schématu níže. 56

57 Obrázek 19 Schéma topologie výstaviště Zelená šipka na schématu označuje, odkud přichází vstupní proud návštěvníků. Červená šipka naopak místo, kudy mají možnost návštěvníci odcházet. Na schématu je také dokumentováno umístění skladu, ze kterého vyjíždí zásobovací vozíky. Výstaviště disponuje dispečerem skladu, který sbírá požadavky na dodávku z jednotlivých stánků, řídí skladištní prostor a přerozděluje kompetence zásobování výstaviště na jednotlivé vozíky Cíle případové studie Prezentovat nativní možnosti simulační platformy Repast Simphony 2 v kombinaci s vyvinutou nadstavbou. Mezi prezentovanými možnostmi bude: Autonomní pohyb zákazníka Autonomní centrálně řízená zásobovací sekce výstaviště Lokální obslužný systém jednoho stánku je realizován vyvinutou nadstavbou Návrh V případě modelu výstaviště je více hlavních problémů, jelikož se nejedná o triviální model. V tomto modelu je nutné řešit problém autonomního pohybu na úrovni agenta. Dále řízení a koordinaci skladovací části výstaviště, obslužný proces na úrovni jednotlivého stánku a kompletaci infrastruktury výstaviště Definice entit, agentů a chování V další fázi návrhu provedeme rozdělení a klasifikaci jednotlivých entit, které se vyskytují v modelu. V přehledu entit provedeme i výčet chování a jednotlivých odpovědností, které entity v modelu budou mít. Seznam entit a agentů: Vstupní agent vytváří nové zákazníky dle parametrů pravděpodobnostního rozdělení (exponenciální) a vkládá je do modelu. 57

58 Výstupní agent odebírá zákazníky ze systému. Návštěvník pohybuje se po prostředí výstaviště, nakupuje ve stáncích. Stánek řídí svůj obslužný proces nákupu, kontroluje stav zásob (s predikcí podává požadavek dispečerovi na doplnění). Prodávající osoba zdroj obsluhy pro stánek. Zásobovací vozík pohybuje se po prostoru mezi návštěvníky, nakládá a rozváží zboží dle požadavků. Zásobovací dispečer sbírá požadavky na doplnění zásob a přerozděluje je na jednotlivé zásobovací vozíky Volba prostředí Dalším krokem je zvolit vhodné prostředí pro realizaci modelu. Volba prostředí by byla nejrealističtější v tzv. spojitém prostoru (reálné souřadnice), ale protože framework zatím neumožňuje implicitně řešit problém kolizí ve spojitém prostoru, zvolíme pouze prostředí mřížky (ve frameworku je označován jako Grid). V rámci abstrakce modelu budeme muset zvolit nejmenší velikost jedné buňky mřížky tak, aby odpovídala velikosti jednoho návštěvníka. Ostatní velikosti budou voleny v poměru, aby se výsledný model blížil realitě. Tato abstrakce souvisí s implementací projekce mřížky ve frameworku. Je to z toho důvodu, že framework nepočítá s proměnlivou velikostí agentů a projekce mřížky nebyla pro tento účel přizpůsobena Volba komunikačního mechanizmu Speciální komunikační mechanizmus pro tento model nebudeme zavádět. Umožníme komunikovat agentům přímým voláním instančních metod, ale pouze v případě, že jsou agenti prostorově v těsném kontaktu Koncept fungování modelu Fungování modelu rozepíšeme po částech podle typu problému, který se v modelu řeší. První popíšeme funkcionalitu návštěvníka. Návštěvník si při příchodu do modelu vybere několik míst (stánků), které by chtěl navštívit. Vybere si libovolný stánek ze svého seznamu a pohybuje se směrem k němu. V případě, že se ke stánku nemůže dostat (například je u stánku spoustu lidí), pak si vybírá ze seznamu další stánek, stávající odloží na později. Dále u návštěvníka zavedeme tzv. odmítnutí. Odmítnutí nastává, pokud má zákazník problém se dostat k jakémukoliv stánku po dlouhou dobu. Příčinnou může být velká zácpa, chyba v infrastruktuře atd. V tomto případě se návštěvník rozhodne odejít z modelu a stánky dále nenavštěvuje. Úroveň spokojenosti návštěvníka hodnotíme podle splněných plánů. Spokojený návštěvník navštívil všechny plánované stánky a jeho spokojenost odpovídá 100%. Návštěvník navíc disponuje jedním speciálním chováním a to 58

59 pro případ, kdy se blíží k agentovi zásobovací vozík. V tomto případě se agent snaží vozíku vyhnout. Dalším objektem je stánek, který slouží jako nákupní místo a temporární sklad produktů. Každý stánek má určitý počet interních prodávajících osob. Tyto osoby představují obslužné zdroje potřebné pro nákup. Nelze tedy, aby nastala situace, kdy u stánku nakupuje více návštěvníků než je počet obslužných zdrojů. Stánek při vydávání zboží kontroluje, zda má dostatečný počet zásob. V našem případě stačí, aby při kontrole bylo na skladě více než 20% maximální skladovací kapacity stánku. Pokud není, tak stánek pošle požadavek centrálnímu skladu, že by potřeboval doplnit zásoby produktů. Vizuální podoba stánku odráží stav zásob, které má k dispozici. Plně zásobený stánek je světle zelený a s úbytkem zásob přechází do červené barvy. Sytě červená označuje stánek bez skladových zásob. Pro zásobování jednotlivých stánků výstaviště disponuje sekcí skladu, kde je centrální dispečer a zásobovací vozíky. Dispečer sbírá požadavky od stánků, přerozděluje je a systematicky deleguje jejich vyřízení na dostupné zásobovací vozíky. Aktuální návrh je takový, že se může vozíkům přidělit určitý maximální počet požadavků (daný konfigurací modelu) na jednu cestu. Zbylé požadavky čekají na další vozík. Ve chvíli, kdy vozík dostane požadavek ke zpracování, začne nakládat potřebné množství nákladu a po naložení odjíždí na výstaviště. Vozík při rozhodování, který stánek obslouží, volí vždy cestu k nejbližšímu stánku, u kterého zatím nevyložil zásoby. Toto navržené řešení není globálně optimální, ale je pro účely modelu vyhovující. Implementace optimálního řešení je námět k dalšímu rozšíření případové studie. Tento problém se obecně nazývá problém obchodního cestujícího a jeho popisem a efektivním řešením se zabývá publikace [11] Implementační detaily V poslední fázi vysvětlím některé řešení, které souvisí s implementaci frameworku a modelu. Mřížka (Grid) implicitně umožňuje obsazení jedné buňky pouze jedním agentem. Tuto vlastnost využijeme pro řešení kolizí v prostoru. Nebude tedy možné, aby dva agenti měli stejné kartézské souřadnice, nebo aby agent prošel infrastrukturou, která je již od začátku vložena do prostředí mřížky Problémy Jeden z problémů byl zapříčiněn špatným použitím frameworku. Ve chvíli, kdy je pro projekci mřížky nastaveno, že do každé buňky může být vložen pouze jeden agent, může vzniknout situace, kdy model zamrzne. Je to způsobeno implicitní implementací pro vkládání objektů do projekce. Pokud se vloží objekt do buňky, kde už nějaký objekt je, implicitní implementace na to není připravena. Dojde k výjimce, která ukončí běh celé simulace. Problém byl vyřešen vlastním umísťovacím objektem, který v případě vkládání na obsazené místo, zvolí náhodně v blízkosti jinou volnou buňku. V průběhu implementace modelu se vyskytl i další problém, který nebyl z počátku identifikován jako významný. Při realizaci autonomního chování návštěvníka se na začátku předpokládala relativně jednoduchá implementace chování chodce (návštěvníka). Původní 59

60 implementace byla navržena tak, aby se agent mohl pohybovat přímým směrem k cíli (umožňuje framework). Pro případ, že narazil na překážku, měl agent k dispozici heuristickou funkci, která z jeho okolí vypočítala nejvhodnější pole pro další krok. Tento přístup je funkční a byl úspěšně verifikován. Bohužel v agentově orientovaném prostředí, kde mnoho agentů provádí stejným způsobem ve stejnou chvíli podobné chování, dochází k tzv. utlačování. Při stávající topologii existovala místa, kde se dalo předpokládat, že agenti budou při obcházení překážek řešit tento problém. Bohužel, při velkém počtu, byli první agenti obklopeni ostatními agenty a nebyl jim umožněn další pohyb. Obrázek 20 Vizuální ukázka výstaviště s problémem utlačování Po prozkoumání dané problematiky, kterou se zabývá publikace [15] a [28], jsem se rozhodl vypracovat řešení pomocí gradientních map a využít množinu předem vytvořených map jako datovou strukturu, která umožní agentům lepší orientaci v prostoru a určit optimální trasu. Tedy základní chování pro nalezení překážky zůstává, ale nepoužívá se přímý pohyb k cíli. Pro pohyb je využita metoda zvaná následování gradientu, kde si agenti z gradientní mapy přečtou, kterým směrem vede optimální cesta k cíli. Pro názornost je níže dokumentována vizualizace prostředí po zavedení gradientních map. Vizuální ukázka stavu systému je sejmuta přibližně ve stejném simulačním čase. 60

61 Obrázek 21 Vizuální ukázka výstaviště po aplikování gradientních map Gradientní mapa Pro naše potřeby jsem implementoval jednoduchý algoritmus pro vytvoření dvou dimenzionální gradientní mapy. Algoritmus pracuje ve dvou fázích: 1) Vytvoření dvourozměrného pole se vzdálenostmi od počátku počáteční lokace (x 0,y 0 ) (pole má stejný počet polí, jako má modelovaná mřížka). 2) Vytvoření dvou rozměrného pole s hodnotami směru (ukládané v radiánech) Vytvoření 2D pole se vzdálenostmi proběhne za pomoci datové struktury fronta. Následující pseudokód demonstruje algoritmus: 61

62 function vytvorpolevzdalenosti (){ fronta = new Fronta(); počátečníbuňka = new Buňka(); počátečníbuňka.x = 5; počátečníbuňka.y = 1; počátečníbuňka.hodnota = 0; fronta.vlož(počátečníbuňka); while(fronta.jeprazdná() == false){ aktuálníbuňka = fronta.vyber(); vytvorokolnibuňky(aktuálníbuňka, fronta); } } function vytvorokolnibuňky(buňka, fronta){ if(zkontrolujrozmery(buňka.x, buňka.y)) return; pole[buňka.x, buňka.y] = buňka.hodnota; //uložíme hodnotu do vytvářeného pole novahodnota = buňka.hodnota + 1; fronta.vlož(new Buňka(buňka.x, buňka.y -1, novahodnota)); fronta.vlož(new Buňka(buňka.x, buňka.y+1, novahodnota)); fronta.vlož(new Buňka(buňka.x+1, buňka.y, novahodnota)); fronta.vlož(new Buňka(buňka.x-1, buňka.y, novahodnota)); fronta.vlož(new Buňka(buňka.x-1, buňka.y-1, novahodnota)); fronta.vlož(new Buňka(buňka.x-1, buňka.y+1, novahodnota)); fronta.vlož(new Buňka(buňka.x+1, buňka.y-1, novahodnota)); fronta.vlož(new Buňka(buňka.x+1, buňka.y+1, novahodnota)); } Obrázek 22 Pseudokód vytvoření gradientní mapy (vzdáleností) V další fázi se vytvoří druhé pole, které doplní informaci o směru. Ten projde postupně všechny buňky a v každém kroku zvolí směr k nejnižší hodnotě uložené v buňce v těsném okolí. Pro názornost je příklad demonstrován na obrázcích níže (Obrázek 23 znázorňuje okolí buňky s hodnotou 44 a zvolený směr, kde šedé místo je překážka s hodnotou ). Obrázek 23 Gradientní mapa (vzdálenosti) 62

63 Obrázek 24 Gradientní mapa (směry) Pro lepší vizuální představu je na obrázku C.2 zdokumentováno testovací prostředí, kde je zobrazeno hodnotové pole. Velikost pole je velká a hodnoty v jednotlivých buňkách by nebyly vidět, hodnoty jsou pro názornost nahrazeny barvou. Na obrázku prostředí se objevuje zelená barva (představuje vysoké hodnoty) a pomalu přechází do barvy černé (představuje minimum). Na dokumentovaném obrázku se vyskytuje ještě modrá barva, která představuje překážky. Agenti při svém pohybu směřují k minimálním hodnotám. Cíleným sledováním gradientní mapy dojde k automatickému obcházení statických překážek a cestování po optimální trase. Minimum představuje cílový bod. Obrázek C.3 dokumentuje příklad gradientní mapy z modelu výstaviště (Cílový stánek se vyskytuje vpravo dole) Parametry modelu a simulační scénář Mezi parametry modelu, které jsou platné pro všechny scénáře, patří: Pohyb zákazníků je částečně náhodný. Snaží se následovat optimální trasu ke zvolenému bodu zájmu (využívá gradientní mapu), ale interval odečítání optimálního směru je náhodný. Interval se zmenšuje s přibližováním k bodu zájmu. Při vstupu agentů do systému je volba jednotlivých stánků z rovnoměrného rozdělení. Rozměr jedné buňky mřížky je zvolen na 0,5 metru a ostatní rozměry jsou přizpůsobeny v tomto poměru, aby přibližně odpovídali realitě. Zásobovací agenti se pohybují v prostoru výstaviště spolu s návštěvníky a autonomně si volí cestu k zásobovanému místu Scénář 1 Scénář předpokládá neomezený počet zásob v systému. Hlavním úkolem je zjistit, jaká je maximální intenzita vstupního proudu, aby nedocházelo k zahlcení systému (při stávající topologii infrastruktury). Stav zahlcení systému identifikujeme tak, že není umožněno návštěvníkům odejít z výstaviště, anebo je v systému zaplněno více než 60%- 70% plochy (počítají se stánky i návštěvníci). V této situaci tedy nejsou již vhodné podmínky pro pohodlný pohyb po výstavišti. 63

64 Hlavní cíle optimalizace: intenzita vstupního proudu [MAX] Scénář 2 Scénář předpokládá omezený počet zásob a 2/3 intenzitu vstupního proudu návštěvníků, která byla zjištěna při neomezeném provozu. V modelu probíhá kontinuální doplňování zásob z připraveného skladu. Výstaviště momentálně disponuje 6 zásobovacími vozíky. Provozovatele by zajímala optimální konfigurace vozíků a predikce stánků, aby bylo možné zabezpečit co možná nejvyšší spokojenost návštěvníků. Dále by provozovatele výstaviště zajímalo, zda má velký vliv doba nakládání zboží na celkový provoz skladu (lze zajistit brigádníky, aby bylo umožněno nakládat 2x rychleji). Hlavní cíle optimalizace: spokojenost návštěvníků [MAX] predikce zásobování [MIN] počet zásobovacích vozíků [MIN] Výsledky Scénář 1 č. intenzita vstupu prům. spokojenost [%] prům. počet návš. v systému [ks] trend ustálený ustálený ustálený ustálený rostoucí rostoucí rostoucí Tabulka 3 - Výsledky experimentu výstaviště podle scénáře 1 64

65 Výsledky experimentu výstaviště poměrná hodnota (pro účely porovnání) intenzita vstupu prům spokojenost [%] prům. počet návš. v systému [ks] experiment č. Graf 3 - Výsledky experimentu výstaviště podle scénáře Scénář 2 č. vozíků [ks] predikce stánků [%] spokojenost [%] doba nakládání Tabulka 4 - Výsledky experimentu výstaviště podle scénáře 2 Výsledky výstaviště scénář Vozíků [ks] predikce stánků [%] spokojenost [%] č. experimentu Graf 4 - Výsledky experimentu výstaviště podle scénáře 2 65

66 Porovnání s nulovou dobou nakládání (přerušovaně je zkrácená doba nakládání) predikce stánků [%] spokojenost [%] predikce stánků [%] spokojenost [%] experiment č. Graf 5 - Výsledky vlivu doby nakládání na spokojenost návštěvníků Závěr případové studie Platforma Repast Simphony 2 nativně nepodporuje vyhodnocování dat mezi jednotlivými běhy simulačního modelu (tzv. replikacemi). Proto byl u všech měření zvolen přístup dostatečně dlouhého simulačního běhu, který zajistí ustálení hodnot. V prvním scénáři byla zjištěna maximální intenzita vstupního proudu návštěvníků. Identifikace zahlceného systému byla zjišťována vizuálně a pomocí trendu grafu aktuálního počtu zákazníků v systému. V případě zahlcení počet zákazníků stále roste (není umožněn odchod ze systému). Proto nejsou při vyhodnocení uvažovány experimenty s rostoucím trendem. Maximální intenzita, při které ještě nedošlo k zahlcení je 0,725 (experiment č. 4). K zahlcení došlo v místě východu (viz. Obrázek 25). Pro další zvyšování intenzity by bylo nutné zvětšit (nebo jinak upravit) stávající východ. Obrázek 25 Zahlcený východ výstaviště 66

67 Dle zadání druhého scénáře byla zjištěna optimální konfigurace pro provoz výstaviště. Z tabulky uvedené v kapitole s výsledky a grafu, lze vyhodnotit, že (spokojenost [max] predikce [min] počet vozíků [min]) je optimální v experimentech č. 7 a 8. Tyto konfigurace dosahují velké míry spokojenosti návštěvníků a relativně stejné nízké hodnoty predikce doplňování zboží do stánků. Určitě by, z hlediska úspory nákladů na provoz, byl upřednostněn experiment č. 7, který má o jeden zásobovací vozík méně než experiment č. 8. Ale upřesnění priorit je na provozovatelích výstaviště. První čtyři experimenty byly pro porovnání provedeny bez čekací doby na naložení zásob. Graf 5 porovnává výsledky experimentů, kde přerušovanou čarou jsou experimenty, kdy zásobovací vozík ihned odjížděl naložený skladovými zásobami. V případě plné čáry trvalo naložení polovinu času z celkového počtu naložených zásob (100 ks nakládaných zásob zabere 50 jednotek času). Lze tedy zhodnotit, že zásobovací doba ovlivní výsledek simulace pouze v malé míře. Naopak doba, kterou potřebuje vozík k dojetí na zásobovací místo a predikce nedostatku zásob stánku, ovlivňují výsledek mnohem více (viz. experiment č. 4). Všechny ostatní grafy jsou pro úplnost přiložené v příloze a jsou označeny číslem experimentu a popiskem, ke které případové studii patří. Jako nativní řešení obslužného systému se v tomto modelu použila vyvinutá nadstavba, která umožnila implicitní omezení nakupujících agentů u stánku. Lokální obslužný proces je tímto způsobem dobře zapouzdřen a jeho další rozšíření nebo úprava jsou otázkou několika minut. Agentově orientovaný přístup přináší obrovské výhody v rychlé rekonfiguraci modelu, jelikož jeho jednotlivé části (i lokální obslužné systémy) jsou navzájem dobře oddělené a zapouzdřené v nějakém logickém celku. Model výstaviště lze dále rozvíjet a rekonfigurovat tak, aby modeloval skutečný systém nějakého výstaviště nebo letištní haly. Lze ho tedy po rozšíření uplatnit např. jako pomůcku pro rozhodování. Námětem pro rozšíření by mohla být úplná implementace chování chodce. Obecně se chodec vyskytuje ve všech modelech a přínos realistického chování přináší velké výhody při odhadování, jak se bude systém chovat. Samozřejmě pouze tam, kde chodci tvoří nezanedbatelnou část modelu. 67

68 8 Závěr Všechny cíle diplomové práce byly splněny. V první teoretické části práce je zpracován přehled agentově orientovaného modelování a simulace. Dále je pak zhotoven přehled simulační platformy Repast Simphony 2. V praktické části byl proveden návrh mechanizmu pro snadnou implementaci obslužných systémů v prostředí agentově orientovaných simulací. Mechanizmus, je ve své podstatě, obecný náhled jak problém řešit a lze ho tedy použít i v jiných agentově orientovaných modelovacích platformách. Implementace mechanizmu je v této práci provedena přímo pro simulační framework Repast Simphony 2. Nadstavba tak volně rozšiřuje základní funkcionalitu platformy. Usnadňuje a urychluje výstavbu servisně orientovaných simulačních modelů. Třetí experimentální část, pomocí vhodně zvolených případových studií, ověřuje a testuje, jak práci s platformou Repast Simphony, tak i implementaci vyvinuté nadstavby. První případovou studií byla ověřena funkčnost frameworku na standardním modelu M/M/1 (jednoduchý systém hromadné obsluhy, pro který existuje jednoduché analytické řešení). V druhé případové studii bylo ověřeno použití nadstavby. Nadstavba výrazně usnadnila a urychlila výstavbu obslužného systému a hlavně umožnila jeho jednoduchou následnou rekonfiguraci. Na třetí případové studii byl ověřen typický agentově orientovaný přístup (využití nativních možností frameworku) v kombinaci s lokálními obslužnými systémy. Kvůli problémům s realizací chování chodců, v třetí případové studii, byl navíc zhotoven algoritmus pro vytvoření gradientních map, které usnadňují nalezení optimálních cest v prostorovém prostředí modelu. Velkou výhodou gradientních map je jejich statický charakter. Není tedy nutné, aby mobilní entity v modelu byly stále zatěžovány výpočtem optimální cesty, tím bylo dosaženo ušetření výpočetního času. Obecně lze říci, že agentově orientovaný přístup umožnil modely vybudovat komponentním způsobem. Taková struktura modelu je velice užitečná při provádění změn a úprav, které jsou v simulačních modelech velice časté a z pohledu zkoumání většího počtu možných případů zkoumání podstatné. Modely vytvořené v této práci je samozřejmě možné dále rozšiřovat a použít je pro další výzkum, anebo praxi. Tato práce, za pomoci vedoucího práce, se stala součástí výzkumné činnosti fakulty informatiky a elektrotechniky na Univerzitě v Pardubicích. 68

69 9 Literatura [1] ARUNACHALAM, S., R. ZALILA-WENKSTERN a R. STEINER. Environment mediated Multi Agent Simulation Tools: A Comparison. In: [online]. The University of Texas at Dallas, 2008 [cit ]. Dostupné z: [2] BANKS, J. Handbook of simulation. New York: John Wiley & Sons, s. ISBN [3] BLOCH, Joshua. Java efektivně: 57 rad softwarového experta. Grada Publishing, 2002, s. 10. ISBN [4] COLLIER, N.T., NORTH M.J., "Repast SC++: A Platform for Large-scale Agentbased Modeling," in W. Dubitzky, K. Kurowski, and B. Schott, eds., Large-Scale Computing Techniques for Complex System Simulations, Wiley (In Press 2011). [5] FOSTER, Ian. Message Passing Interface. [online] [cit ]. Dostupné z: [6] FRIEBELOVÁ, J., J. KLICNAROVÁ a L. FRIEBEL. Teorie hromadné obsluhy. In: [online]. Jihočeská univerzita v Českých Budějovicích, 2006 [cit ]. Dostupné z: [7] GALOTTI, K. Cognitive Psychology: In and out of the laboratory. USA: Wadsworth, [8] GRIMMA Volker, BERGER Uta, GRIMM Finn Bastiansen. A standard protocol for describing individual-based and agent-based models. In: [online] [cit ]. Dostupné z: [9] HONZÁK, Roman. Experimentování s čekacími dobami vlaků v osobních železničních stanicích v rámci simulačního modelu. Pardubice, s. Univerzita Pardubice, Fakulta Elektrotechniky a Informatiky. Vedoucí diplomové práce Ing. Michael Bažant. [10] JENSEN, Finn Rosenbech. Using the travellingsalesman problem in bioinformatic algorithms. [online]. AARHUS UNIVERSITY, 2010 [cit ]. Dostupné z: [11] KAVIČKA, Antonín. Pokročilé techniky modelování a simulace. [elektronické sylaby k předmětu] Pardubice : Univerzita Pardubice, [12] KAVIČKA, Antonín. Modelování a simulace. [elektronické sylaby k předmětu] Pardubice : Univerzita Pardubice, [13] KAVIČKA, Antonín. Aplikace paradigmatu autonomních agentů na architekturu simulačního modelu. In: [online]. Univerzita Pardubice, 2001 [cit ]. Dostupné z: [14] KAVIČKA, A., KLIMA, V., ADAMKO, N. Agentovo orientovaná simulacia dopravních uzlov. Žilina: EDIS - vydavatelstvo ŽU, s. Monografie. ISBN [15] KORMANOVÁ, Anna. Metódy simulácie správania sa chodcov. Žilina, Písemná práce k dizertační zkoušce. Žilinská Univerzita, Fakulta Riadenia a Informatiky. Vedoucí práce Doc. Mgr. Valent Klima, CSc. 69

70 [16] KUBÍK, Aleš. Agentově-orientované inženýrství: nové paradigma pro tvorbu softwaru?. In: [online]. Ústav informatiky, Slezská univerzita, 2007 [cit ]. Dostupné z: [17] KŘIVÝ, Ivan, KINDLER, Evžen. Simulace a modelování. Ostrava : Ostravská univerzita, s. [18] Logo (programovací jazyk). In: Wikipedia: the free encyclopedia [online]. 2006, [cit ]. Dostupné z: [19] MACAL, Charles M., NORTH Michael J. TOWARD TEACHING AGENT-BASED SIMULATION. In: [online]. Argonne National Laboratory. Argonne, USA, 2010 [cit ]. Dostupné z: [20] MACAL, Charles M., NORTH Michael J. Tutorial on agent-based modelling and simulation. In: [online]. Journal of Simulation. The University of Chicago, 2010 [cit ]. Dostupné z: [21] NETRVALOVÁ, A. Úvod do problematiky multiagentních systémů. In: [online]. ZČU v Plzni, FAV, KIV, 2005 [cit ]. Dostupné z: [22] NORTH, M.J., TATARA E., COLLIER N.T., OZIK J., "Visual Agent-based Model Development with Repast Simphony," In: [online]. Proceedings of the Agent, 2007 Conference on Complex Interaction and Social Emergence, Argonne National Laboratory, Argonne, IL USA [cit ]. Dostupné z: [23] NORTH, M.J., HOWE T.R., COLLIER N.T., VOS J.R., "A Declarative Model Assembly Infrastructure for Verification and Validation," in S. Takahashi, D.L. Sallach and J. Rouchier, eds., Advancing Social Simulation: The First World Congress, Springer, Heidelberg, FRG (2007). [24] PELÁNEK, Radek. Modelování založené na agentech (ABM). [online]. [cit ]. Dostupné z: [25] Repast Homepage [online] [cit ]. Dostupné z: [26] Státnicové otázky z předmětu ITEI - Informační management [online]. FIM UHK, 2009 [cit ]. Dostupné z: [27] ŠIROKÝ, Jaromír: Aplikace počítačů v provozu vozidel. Ostrava: VŠB TU Ostrava s ISBN [skriptum]. [cit ]. Dostupný z: [28] VARGA, Michal. Modelovanie získavania informácií a ich využitie pri inteligentnom rozhodovani v agentovo orientovaných simulačných modeloch. Žilina, Písemná práce k dizertační zkoušce. Žilinská Univerzita, Fakulta Riadenia a Informatiky. Vedoucí práce prof. Ing. Karol Matiaško, PhD. 70

71 10 Přílohy Příloha A Obrázek A.1 UML diagram vnitřní implementace aktivit a jejich rozhraní 71

72 Obrázek A.2 UML diagram rozhraní aktivit a technologického plánu 72

73 Příloha B Obrázek B.1 Technologické postupy v modelu pneuservisu. zdroj: [11] 73

74 Obrázek B.2 technologické procesy v modelu pneuservisu. zdroj: [11] 74

75 Obrázek B.3 technologické procesy v modelu pneuservisu. zdroj: [11] 75

76 Příloha C Obrázek C.1 Topologie výstaviště 76

77 Obrázek C.2 Gradientní mapa testovacího prostředí (modrá infrastruktura, černá minimum, světle zelená maximum) 77

78 Obrázek C.3 Gradientní mapa stánku (v pravém dolním rohu) 78

79 Příloha D Obsah přiložených souborů K práci je přiloženo CD, jež obsahuje elektronickou verzi této práce ve formátech PDF a DOC a následující adresáře: 79

80 Příloha E Pneuservis Scénář 1 Obrázek E.1 Experiment S1 / č. 2 80

81 Obrázek E.2 Experiment S1 / č. 4 81

82 Scénář 2 Obrázek E.3 Experiment S2 / č. 1 82

83 Obrázek E.4 Experiment S2 / č. 2 83

84 Výstaviště Scénář 1 Obrázek E.5 Experiment S1 / č. 3 84

85 Obrázek E.6 Experiment S1 / č. 4 85

86 Obrázek E.7 Experiment S1 / č. 6 86

87 Scénář 2 Obrázek E.8 Experiment S2 / č. 5 87

88 Obrázek E.9 Experiment S2 / č. 7 88

89 Obrázek E.10 Experiment S2 / č. 9 89

90 Obrázek E.11 Experiment S2 / č

UNIVERZITA PARDUBICE FAKULTA ELEKTROTECHNIKY A INFORMATIKY DIPLOMOVÁ PRÁCE. 2012 Bc. Martin Mariška

UNIVERZITA PARDUBICE FAKULTA ELEKTROTECHNIKY A INFORMATIKY DIPLOMOVÁ PRÁCE. 2012 Bc. Martin Mariška UNIVERZITA PARDUBICE FAKULTA ELEKTROTECHNIKY A INFORMATIKY DIPLOMOVÁ PRÁCE 2012 Bc. Martin Mariška Univerzita Pardubice Fakulta elektrotechniky a informatiky AGENTOVĚ ORIENTOVANÉ SIMULAČNÍ MODELY PROVOZU

Více

UNIVERZITA PARDUBICE FAKULTA ELEKTROTECHNIKY A INFORMATIKY

UNIVERZITA PARDUBICE FAKULTA ELEKTROTECHNIKY A INFORMATIKY UNIVERZITA PARDUBICE FAKULTA ELEKTROTECHNIKY A INFORMATIKY DIPLOMOVÁ PRÁCE 2012 Bc. Jiří Popelka Univerzita Pardubice Fakulta elektrotechniky a informatiky Agentově orientovaný simulační model pro distribuci

Více

IMOSI - MODELACE A SIMULACE LEARN 2013 správně možná špatně

IMOSI - MODELACE A SIMULACE LEARN 2013 správně možná špatně IMOSI - MODELACE A SIMULACE LEARN 2013 správně možná špatně Simulátor označujeme jako kredibilní v případě, že: byla úspěšně završena fáze verifikace simulátoru se podařilo přesvědčit zadavatele simulačního

Více

Unifikovaný modelovací jazyk UML

Unifikovaný modelovací jazyk UML Unifikovaný modelovací jazyk UML Karel Richta katedra počíta tačů FEL ČVUT Praha richta@fel fel.cvut.czcz Motto: Komunikačním m prostředkem informační komunity se postupem času stala angličtina. Chcete-li

Více

Dominik Vymětal. Informační technologie pro praxi 2009, Ostrava 1.-2.10.2009 1

Dominik Vymětal. Informační technologie pro praxi 2009, Ostrava 1.-2.10.2009 1 Dominik Vymětal 2009, Ostrava 1.-2.10.2009 1 Procesní model Výhody Orientace na konkrétní činnosti a možnost reengineeringu Nevýhody Malá orientace na průřezové nebo opakované činnosti Modely na základě

Více

Vývojové nástroje pro multiagentové systémy

Vývojové nástroje pro multiagentové systémy Vývojové nástroje pro multiagentové systémy Znalostní technologie III materiál pro podporu studia OBSAH Úvod... 3 Swarm... 3 NetLogo... 5 Repast... 6 Porovnání prostředí Swarm, NetLogo a RePast... 7 Mason...

Více

Moderní systémy pro získávání znalostí z informací a dat

Moderní systémy pro získávání znalostí z informací a dat Moderní systémy pro získávání znalostí z informací a dat Jan Žižka IBA Institut biostatistiky a analýz PřF & LF, Masarykova universita Kamenice 126/3, 625 00 Brno Email: zizka@iba.muni.cz Bioinformatika:

Více

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda 1. Lze vždy z tzv. instanční třídy vytvořit objekt? 2. Co je nejčastější příčinou vzniku chyb? A. Specifikace B. Testování C. Návrh D. Analýza E. Kódování 3. Je defenzivní programování technikou skrývání

Více

Principy UML. Clear View Training 2005 v2.2 1

Principy UML. Clear View Training 2005 v2.2 1 Principy UML Clear View Training 2005 v2.2 1 1.2 Co je touml? Unified Modelling Language (UML) je univerzálníjazyk pro vizuální modelování systémů Podporuje všechny životní cykly Mohou jej implementovat

Více

MBI - technologická realizace modelu

MBI - technologická realizace modelu MBI - technologická realizace modelu 22.1.2015 MBI, Management byznys informatiky Snímek 1 Agenda Technická realizace portálu MBI. Cíle a principy technického řešení. 1.Obsah portálu - objekty v hierarchiích,

Více

POČÍTAČOVÁ SIMULACE PODNIKOVÝCH PROCESŮ. Ing. V. Glombíková, PhD.

POČÍTAČOVÁ SIMULACE PODNIKOVÝCH PROCESŮ. Ing. V. Glombíková, PhD. POČÍTAČOVÁ SIMULACE PODNIKOVÝCH PROCESŮ Ing. V. Glombíková, PhD. SIMULACE nástroj pro studium chování objektů reálného světa SYSTÉM určitým způsobem uspořádána množina komponent a relací mezi nimi. zjednodušený,

Více

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ 1) PROGRAM, ZDROJOVÝ KÓD, PŘEKLAD PROGRAMU 3 2) HISTORIE TVORBY PROGRAMŮ 3 3) SYNTAXE A SÉMANTIKA 3 4) SPECIFIKACE

Více

Vývoj informačních systémů. Obecně o IS

Vývoj informačních systémů. Obecně o IS Vývoj informačních systémů Obecně o IS Informační systém Informační systém je propojení informačních technologií a lidských aktivit směřující k zajištění podpory procesů v organizaci. V širším slova smyslu

Více

2. přednáška z předmětu GIS1 Data a datové modely

2. přednáška z předmětu GIS1 Data a datové modely 2. přednáška z předmětu GIS1 Data a datové modely Vyučující: Ing. Jan Pacina, Ph.D. e-mail: jan.pacina@ujep.cz Pro přednášku byly použity texty a obrázky z www.gis.zcu.cz Předmět KMA/UGI, autor Ing. K.

Více

1. Dědičnost a polymorfismus

1. Dědičnost a polymorfismus 1. Dědičnost a polymorfismus Cíl látky Cílem této kapitoly je představit klíčové pojmy dědičnosti a polymorfismu. Předtím však je nutné se seznámit se základními pojmy zobecnění neboli generalizace. Komentář

Více

MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ

MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ M. Sysel, I. Pomykacz Univerzita Tomáše Bati ve Zlíně, Fakulta aplikované informatiky Nad Stráněmi 4511, 760 05 Zlín, Česká republika

Více

INFORMATIKA. Jindřich Kaluža. Ludmila Kalužová

INFORMATIKA. Jindřich Kaluža. Ludmila Kalužová INFORMATIKA Jindřich Kaluža Ludmila Kalužová Recenzenti: doc. RNDr. František Koliba, CSc. prof. RNDr. Peter Mikulecký, PhD. Vydání knihy bylo schváleno vědeckou radou nakladatelství. Všechna práva vyhrazena.

Více

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Osnova přednášky Co to je softwarové inženýrství Softwarový proces Metodika a metoda Evoluce softwarových

Více

Buněčné automaty a mřížkové buněčné automaty pro plyny. Larysa Ocheretna

Buněčné automaty a mřížkové buněčné automaty pro plyny. Larysa Ocheretna Buněčné automaty a mřížkové buněčné automaty pro plyny Larysa Ocheretna Obsah Buněčný automat: princip modelu, vymezení pojmů Mřížkový buněčný automat pro plyny Příklady aplikace principů mřížkových buněčných

Více

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů.

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů. Modely datové Existují různé úrovně pohledu na data. Nejvyšší úroveň je úroveň, která zachycuje pouze vztahy a struktury dat samotných. Konceptuální model - E-R model. Další úrovní je logická úroveň Databázové

Více

7.5 Diagram tříd pokročilé techniky

7.5 Diagram tříd pokročilé techniky 7.5 Diagram tříd pokročilé techniky Stereotypy - jeden ze základních prostředků rozšiřitelnosti UML - pro modelovací konstrukce neexistující v UML, ale podobné předdefinované v UML definované uživatelem

Více

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz UML a jeho použití v procesu vývoje Jaroslav Žáček jaroslav.zacek@osu.cz Různé pohledy na modelování Různé pohledy na modelování Unified Modeling Language UML není metodikou ani programovacím jazykem,

Více

FORTANNS. havlicekv@fzp.czu.cz 22. února 2010

FORTANNS. havlicekv@fzp.czu.cz 22. února 2010 FORTANNS manuál Vojtěch Havlíček havlicekv@fzp.czu.cz 22. února 2010 1 Úvod Program FORTANNS je software určený k modelování časových řad. Kód programu má 1800 řádek a je napsán v programovacím jazyku

Více

Wonderware Information Server 4.0 Co je nového

Wonderware Information Server 4.0 Co je nového Wonderware Information Server 4.0 Co je nového Pavel Průša Pantek (CS) s.r.o. Strana 2 Úvod Wonderware Information Server je výrobní analytický a reportní informační portál pro publikaci výrobních dat

Více

7. Geografické informační systémy.

7. Geografické informační systémy. 7. Geografické informační systémy. 154GEY2 Geodézie 2 7.1 Definice 7.2 Komponenty GIS 7.3 Možnosti GIS 7.4 Datové modely GIS 7.5 Přístup k prostorovým datům 7.6 Topologie 7.7 Vektorové datové modely 7.8

Více

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER váš partner na cestě od dat k informacím globtech spol. s r.o. karlovo náměstí 17 c, praha 2 tel.: +420 221 986 390 info@globtech.cz

Více

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 12. Virtuální sítě (VLAN) Studijní cíl Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 1 hodina VLAN Virtuální síť bývá definována jako logický segment LAN, který spojuje koncové uzly, které

Více

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování 1. Teoretické základy modelování na počítačích 1.1 Lambda-kalkul 1.1.1 Formální zápis, beta-redukce, alfa-konverze 1.1.2 Lambda-výraz jako data 1.1.3 Příklad alfa-konverze 1.1.4 Eta-redukce 1.2 Základy

Více

METODY DOLOVÁNÍ V DATECH DATOVÉ SKLADY TEREZA HYNČICOVÁ H2IGE1

METODY DOLOVÁNÍ V DATECH DATOVÉ SKLADY TEREZA HYNČICOVÁ H2IGE1 METODY DOLOVÁNÍ V DATECH DATOVÉ SKLADY TEREZA HYNČICOVÁ H2IGE1 DOLOVÁNÍ V DATECH (DATA MINING) OBJEVUJE SE JIŽ OD 60. LET 20. ST. S ROZVOJEM POČÍTAČOVÉ TECHNIKY DEFINICE PROCES VÝBĚRU, PROHLEDÁVÁNÍ A MODELOVÁNÍ

Více

Profilová část maturitní zkoušky 2013/2014

Profilová část maturitní zkoušky 2013/2014 Střední průmyslová škola, Přerov, Havlíčkova 2 751 52 Přerov Profilová část maturitní zkoušky 2013/2014 TEMATICKÉ OKRUHY A HODNOTÍCÍ KRITÉRIA Studijní obor: 78-42-M/01 Technické lyceum Předmět: TECHNIKA

Více

Specializace Kognitivní informatika

Specializace Kognitivní informatika Specializace Kognitivní informatika Otevřené dveře specializace Kognitivní informatika, 10.5.2007 V rámci projektu, financovaného Evropským sociálním fondem pod č. 3206 Multi- a transdisciplinární obor

Více

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/34.0333 Vzdělávání v informačních a komunikačních technologií

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/34.0333 Vzdělávání v informačních a komunikačních technologií VY_32_INOVACE_31_02 Škola Střední průmyslová škola Zlín Název projektu, reg. č. Vzdělávací oblast Vzdělávací obor Tematický okruh Téma Tematická oblast Název Autor Vytvořeno, pro obor, ročník Inovace výuky

Více

MATEMATICKÁ TEORIE ROZHODOVÁNÍ

MATEMATICKÁ TEORIE ROZHODOVÁNÍ MATEMATICKÁ TEORIE ROZHODOVÁNÍ Podklady k soustředění č. 5 Komunikace a kooperace Komunikace se jako jeden z principů objevuje v umělé inteligenci až v druhé polovině 80. let. V roce 1986 uveřejňuje M.

Více

UITS / ISY. Ústav inteligentních systémů Fakulta informačních technologií VUT v Brně. ISY: Výzkumná skupina inteligentních systémů 1 / 14

UITS / ISY. Ústav inteligentních systémů Fakulta informačních technologií VUT v Brně. ISY: Výzkumná skupina inteligentních systémů 1 / 14 UITS / ISY Výzkumná skupina inteligentních systémů Ústav inteligentních systémů Fakulta informačních technologií VUT v Brně ISY: Výzkumná skupina inteligentních systémů 1 / 14 Obsah Představení skupiny

Více

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz Vývoj moderních technologií při vyhledávání Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz INFORUM 2007: 13. konference o profesionálních informačních zdrojích Praha, 22. - 24.5. 2007 Abstrakt Vzhledem

Více

Analýza a Návrh. Analýza

Analýza a Návrh. Analýza Analysis & Design Návrh nebo Design? Design = návrh Není vytváření použitelného uživatelského prostředí (pouze malinká podmnožina celého návrhu) Často takto omezeně chápáno studenty nedokáží si představit,

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

Metody tvorby ontologií a sémantický web. Martin Malčík, Rostislav Miarka

Metody tvorby ontologií a sémantický web. Martin Malčík, Rostislav Miarka Metody tvorby ontologií a sémantický web Martin Malčík, Rostislav Miarka Obsah Reprezentace znalostí Ontologie a sémantický web Tvorba ontologií Hierarchie znalostí (D.R.Tobin) Data jakékoliv znakové řetězce

Více

Problémové domény a jejich charakteristiky

Problémové domény a jejich charakteristiky Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 02 1/16 Problémové domény a jejich charakteristiky Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta

Více

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz RUP - Disciplíny Jaroslav Žáček jaroslav.zacek@osu.cz Disciplíny Množství disciplíny v dané iteraci Disciplíny podle RUP Šest základních: Business modeling - pro pochopení problémové domény Requirements

Více

MOŢNOSTI VYUŢITÍ ROLÍ, AKTORŮ A AGENTŮ PŘI DESIGNU BYZNYS PROCESŮ

MOŢNOSTI VYUŢITÍ ROLÍ, AKTORŮ A AGENTŮ PŘI DESIGNU BYZNYS PROCESŮ MOŢNOSTI VYUŢITÍ ROLÍ, AKTORŮ A AGENTŮ PŘI DESIGNU BYZNYS PROCESŮ Ing. Jan Smolík Vysoká škola finanční a správní PROČ JINÝ ZPŮSOB MODELOVÁNÍ PROCESŮ Základní žurnalistické otázky Co, kdo, kdy, kde, jak,

Více

INFORMAČNÍ SYSTÉM VIDIUM A VYUŽITÍ MODERNÍCH TECHNOLOGIÍ

INFORMAČNÍ SYSTÉM VIDIUM A VYUŽITÍ MODERNÍCH TECHNOLOGIÍ INFORMAČNÍ SYSTÉM VIDIUM A VYUŽITÍ MODERNÍCH TECHNOLOGIÍ Michal Brožek, Dominik Svěch, Jaroslav Štefaník MEDIUM SOFT a.s., Cihelní 14, 702 00 Ostrava, ČR Abstrakt Neustále rostoucí význam sběru dat, možnost

Více

P R O J E K T O V É Ř Í Z E N Í A M A R K E T I N G 1. Akad. rok 2015/2016, LS Projektové řízení a marketing - VŽ 1

P R O J E K T O V É Ř Í Z E N Í A M A R K E T I N G 1. Akad. rok 2015/2016, LS Projektové řízení a marketing - VŽ 1 P R O J E K T O V É Ř Í Z E N Í A M A R K E T I N G 1 Akad. rok 2015/2016, LS Projektové řízení a marketing - VŽ 1 Vznik a historie projektového řízení Akad. rok 2015/2016, LS Projektové řízení a marketing

Více

MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH. Jindřich Kaluža Ludmila Kalužová

MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH. Jindřich Kaluža Ludmila Kalužová MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH Jindřich Kaluža Ludmila Kalužová Recenzenti: prof. Ing. Milan Turčáni, CSc. prof. Ing. Ivan Vrana, DrSc. Tato kniha vznikla za finanční podpory Studentské grantové

Více

Geografické informační systémy GIS

Geografické informační systémy GIS Geografické informační systémy GIS Prohloubení nabídky dalšího vzdělávání v oblasti zeměměřictví a katastru nemovitostí ve Středočeském kraji CZ.1.07/3.2.11/03.0115 Projekt je finančně podpořen Evropským

Více

TEORIE ZPRACOVÁNÍ DAT

TEORIE ZPRACOVÁNÍ DAT Vysoká škola báňská - Technická univerzita Ostrava Fakulta elektrotechniky a informatiky TEORIE ZPRACOVÁNÍ DAT pro kombinované a distanční studium Jana Šarmanová Ostrava 2003 Jana Šarmanová, 2003 Fakulta

Více

OPS Paralelní systémy, seznam pojmů, klasifikace

OPS Paralelní systémy, seznam pojmů, klasifikace Moorův zákon (polovina 60. let) : Výpočetní výkon a počet tranzistorů na jeden CPU chip integrovaného obvodu mikroprocesoru se každý jeden až dva roky zdvojnásobí; cena se zmenší na polovinu. Paralelismus

Více

Agentově orientované modelování a simulace

Agentově orientované modelování a simulace Agentově orientované modelování a simulace Znalostní technologie III materiál pro podporu studia OBSAH ÚVOD... 3 CO JE AGENT?... 3 POTŘEBA AGENTOVĚ ORIENTOVANÉHO MODELOVÁNÍ... 4 ABMS... 4 HLAVNÍ MYŠLENKY

Více

X36SIN: Softwarové inženýrství. Životní cyklus a plánování

X36SIN: Softwarové inženýrství. Životní cyklus a plánování X36SIN: Softwarové inženýrství Životní cyklus a plánování 1 Kontext Minule jsme si řekli, co to je deklarace záměru, odborný článek, katalog požadavků, seznam aktérů a seznam událostí. Seznam aktérů a

Více

Centrum pro rozvoj dopravních systémů

Centrum pro rozvoj dopravních systémů Centrum pro rozvoj dopravních systémů Martin Hájek VŠB - TU Ostrava Březen 2013 Témata 1. Představení centra RODOS 2. Řízení dopravy při modernizaci D1 výstupy centra Centrum pro rozvoj dopravních systémů

Více

5.1.7 Informatika a výpočetní technika. Časové, obsahové a organizační vymezení. ročník 1. 2. 3. 4. hodinová dotace 2 2 0 0

5.1.7 Informatika a výpočetní technika. Časové, obsahové a organizační vymezení. ročník 1. 2. 3. 4. hodinová dotace 2 2 0 0 5.1.7 Informatika a výpočetní technika Časové, obsahové a organizační vymezení ročník 1. 2. 3. 4. hodinová dotace 2 2 0 0 Realizuje se vzdělávací obor Informatika a výpočetní technika RVP pro gymnázia.

Více

Infrastruktura UML. Modelování struktury v UML. Superstruktura UML. Notace objektů. Diagramy objektů

Infrastruktura UML. Modelování struktury v UML. Superstruktura UML. Notace objektů. Diagramy objektů Infrastruktura UML v UML Karel Richta listopad 2011 Richta: B101TMM - v UML 2 Superstruktura UML Směr pohledu na systém dle UML Diagramy popisující strukturu diagramy tříd, objektů, kompozitní struktury,

Více

GIS Libereckého kraje

GIS Libereckého kraje Funkční rámec Zpracoval: Odbor informatiky květen 2004 Obsah 1. ÚVOD...3 1.1. Vztah GIS a IS... 3 2. ANALÝZA SOUČASNÉHO STAVU...3 2.1. Technické zázemí... 3 2.2. Personální zázemí... 3 2.3. Datová základna...

Více

PHP framework Nette. Kapitola 1. 1.1 Úvod. 1.2 Architektura Nette

PHP framework Nette. Kapitola 1. 1.1 Úvod. 1.2 Architektura Nette Kapitola 1 PHP framework Nette 1.1 Úvod Zkratka PHP (z anglického PHP: Hypertext Preprocessor) označuje populární skriptovací jazyk primárně navržený pro vývoj webových aplikací. Jeho oblíbenost vyplývá

Více

Prezentace CRMplus. Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách

Prezentace CRMplus. Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách Prezentace CRMplus Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách Obsah prezentace Představení společnosti Technodat Develop, s.r.o. CRMplus základní charakteristika

Více

Analýza a modelování dat. Helena Palovská

Analýza a modelování dat. Helena Palovská Analýza a modelování dat Helena Palovská Analýza a modelování pro SW projekt Strukturovaný přístup Dynamická část (procesy, aktivity, funkce) Statická část (data) Objektově orientovaný přístup use case

Více

Neuronové časové řady (ANN-TS)

Neuronové časové řady (ANN-TS) Neuronové časové řady (ANN-TS) Menu: QCExpert Prediktivní metody Neuronové časové řady Tento modul (Artificial Neural Network Time Series ANN-TS) využívá modelovacího potenciálu neuronové sítě k predikci

Více

ANALÝZA A OPTIMALIZACE VÝROBNÍCH PROCESŮ MALOSÉRIOVÉ SLOŽITÉ VÝROBY V NOVÝCH VÝROBNÍCH PROSTORECH NA ZÁKLADĚ DISKRÉTNÍ SIMULACE

ANALÝZA A OPTIMALIZACE VÝROBNÍCH PROCESŮ MALOSÉRIOVÉ SLOŽITÉ VÝROBY V NOVÝCH VÝROBNÍCH PROSTORECH NA ZÁKLADĚ DISKRÉTNÍ SIMULACE ANALÝZA A OPTIMALIZACE VÝROBNÍCH PROCESŮ MALOSÉRIOVÉ SLOŽITÉ VÝROBY V NOVÝCH VÝROBNÍCH PROSTORECH NA ZÁKLADĚ DISKRÉTNÍ SIMULACE Doc. Václav Votava, CSc. (a), Ing. Zdeněk Ulrych, Ph.D. (b), Ing. Milan Edl,

Více

Bridge. Známý jako. Účel. Použitelnost. Handle/Body

Bridge. Známý jako. Účel. Použitelnost. Handle/Body Bridge Bridge Známý jako Handle/Body Účel odděluje abstrakci (rozhraní a jeho sémantiku) od její konkrétní implementace předchází zbytečnému nárůstu počtu tříd při přidávání implementací používá se v době

Více

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce WORKFLOW Procesní přístup Základ perspektivního úspěšného podnikového řízení Funkčnířízení založené na dělbě práce Procesní řízení princip integrace činností do ucelených procesů 1 Funkční řízení Dělba

Více

7 Jazyk UML (Unified Modeling Language)

7 Jazyk UML (Unified Modeling Language) 7 Jazyk UML (Unified Modeling Language) 7.1 Základní charakteristika jazyka Motivace - vznik řady OO metod a metodologií (konec 80. let a první polovina 90.let) podobné notace vyjadřující totéž, komplikující

Více

xrays optimalizační nástroj

xrays optimalizační nástroj xrays optimalizační nástroj Optimalizační nástroj xoptimizer je součástí webového spedičního systému a využívá mnoho z jeho stavebních bloků. xoptimizer lze nicméně provozovat i samostatně. Cílem tohoto

Více

Modelování procesů (2) 23.3.2009 Procesní řízení 1

Modelování procesů (2) 23.3.2009 Procesní řízení 1 Modelování procesů (2) 23.3.2009 Procesní řízení 1 Seznam notací Síťové diagramy Notace WfMC Notace Workflow Together Editor Aktivity diagram (UML) FirsStep Designer Procesní mapa Select Prespective (procesní

Více

Příprava dat v softwaru Statistica

Příprava dat v softwaru Statistica Příprava dat v softwaru Statistica Software Statistica obsahuje pokročilé nástroje pro přípravu dat a tvorbu nových proměnných. Tyto funkcionality přinášejí značnou úsporu času při přípravě datového souboru,

Více

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Architektury Informačních systémů Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Nutné pojmy Co je to informační systém? Jaké oblasti zahrnuje? Jaká je vazba IS na podnikovou strategii?

Více

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1 Metodický list č. 1 Cíl: Cílem předmětu je získat přehled o možnostech a principech databázového zpracování, získat v tomto směru znalosti potřebné pro informačního manažera. Databázové systémy, databázové

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 29. Otázka : Zpracování událostí: mechanismus událostí a jejich zpracování (Event/Listener), nepřímá invokace (Observer/Observable). Obsah : 1. Mechanisums

Více

Softwarová podpora v procesním řízení

Softwarová podpora v procesním řízení Softwarová podpora v procesním řízení Zkušenosti z praxe využití software ATTIS Ostrava, 7. října 2010 www.attis.cz ATTN Consulting s.r.o. 1 Obsah Koncepce řízení výkonnosti Koncepce řízení výkonnosti

Více

Architektury počítačů a procesorů

Architektury počítačů a procesorů Kapitola 3 Architektury počítačů a procesorů 3.1 Von Neumannova (a harvardská) architektura Von Neumann 1. počítač se skládá z funkčních jednotek - paměť, řadič, aritmetická jednotka, vstupní a výstupní

Více

GEOGRAFICKÉ INFORMAČNÍ SYSTÉMY 6

GEOGRAFICKÉ INFORMAČNÍ SYSTÉMY 6 UNIVERZITA TOMÁŠE BATI VE ZLÍNĚ FAKULTA APLIKOVANÉ INFORMATIKY GEOGRAFICKÉ INFORMAČNÍ SYSTÉMY 6 Lubomír Vašek Zlín 2013 Obsah... 3 1. Základní pojmy... 3 2. Princip rastrové reprezentace... 3 2.1 Užívané

Více

Projektově orientované studium Základní principy a filozofie PBL Co a co není PBL Co je to projekt. CIIV červenec 2013 odpovědný manažer: Petr Hynek

Projektově orientované studium Základní principy a filozofie PBL Co a co není PBL Co je to projekt. CIIV červenec 2013 odpovědný manažer: Petr Hynek Základní principy a filozofie PBL Co a co není PBL Co je to projekt Projektově orientované studium není nic nového Po celou historii je stále a znova voláno po praktické výuce Fantazie je důležitější než

Více

RD.CZ : EVIDENCE DIGITALIZOVANÝCH DOKUMENTŮ A SLEDOVÁNÍ PROCESU ZPRACOVÁNÍ

RD.CZ : EVIDENCE DIGITALIZOVANÝCH DOKUMENTŮ A SLEDOVÁNÍ PROCESU ZPRACOVÁNÍ RD.CZ : EVIDENCE DIGITALIZOVANÝCH DOKUMENTŮ A SLEDOVÁNÍ PROCESU ZPRACOVÁNÍ Pavel Kocourek, Incad Praha Přestože mnohé knihovny v České republice digitalizují své dokumenty a další se na to chystají, neprobíhá

Více

1 Strukturované programování

1 Strukturované programování Projekt OP VK Inovace studijních oborů zajišťovaných katedrami PřF UHK Registrační číslo: CZ.1.07/2.2.00/28.0118 1 Cíl Seznámení s principy strukturovaného programování, s blokovou strukturou programů,

Více

ZÁKLADY PROGRAMOVÁNÍ. Mgr. Vladislav BEDNÁŘ 2014 5.3-5.8 9/14

ZÁKLADY PROGRAMOVÁNÍ. Mgr. Vladislav BEDNÁŘ 2014 5.3-5.8 9/14 ZÁKLADY PROGRAMOVÁNÍ Mgr. Vladislav BEDNÁŘ 2014 5.3-5.8 9/14 Co je vhodné vědět, než si vybereme programovací jazyk a začneme programovat roboty. 1 / 12 0:40 UML unifikovaný modelovací jazyk Zkratka tohoto

Více

PowerOPTI Řízení účinnosti tepelného cyklu

PowerOPTI Řízení účinnosti tepelného cyklu PowerOPTI Řízení účinnosti tepelného cyklu VIZE Zvýšit konkurenceschopnost provozovatelů elektráren a tepláren. Základní funkce: Spolehlivé hodnocení a řízení účinnosti tepelného cyklu, včasná diagnostika

Více

Bakalářský studijní obor informatika

Bakalářský studijní obor informatika Bakalářský studijní obor informatika Předpoklady Struktura studia Přihlášky Poradenství Vzdělání v bakalářském oboru informatika nabízeném na Technické univerzitě v Chemnitz představuje vyvážený kompromis

Více

Podklady pro ICT plán

Podklady pro ICT plán Podklady pro ICT plán Škola: ICT - Hodnocení: Vstupní hodnocení Indikátor Aktuální stav k 1.3.2012 Plánovaný stav k 28.2.2014 1. řízení a plánování Na vizi zapojení ICT do výuky pracuje jen omezená skupina

Více

ZÁKLADY PROGRAMOVÁNÍ. Mgr. Vladislav BEDNÁŘ 2014 7.4 13/14

ZÁKLADY PROGRAMOVÁNÍ. Mgr. Vladislav BEDNÁŘ 2014 7.4 13/14 ZÁKLADY PROGRAMOVÁNÍ Mgr. Vladislav BEDNÁŘ 2014 7.4 13/14 Co je vhodné vědět, než si vybereme programovací jazyk a začneme programovat roboty. 1 / 13 0:40 Implementace Umělá inteligence (UI) Umělá inteligence

Více

End User Experience Monitoring Měření kvality IT služeb 7.10.2010, Brno Jiří Vozňák. information technology

End User Experience Monitoring Měření kvality IT služeb 7.10.2010, Brno Jiří Vozňák. information technology End User Experience Monitoring Měření kvality IT služeb 7.10.2010, Brno Jiří Vozňák information technology Základ firemní strategie Strategie firmy Lidé Procesy Nástroje Portfolio nabídky a služeb Crux

Více

Role BI v e-business řešeních pohled do budoucnosti

Role BI v e-business řešeních pohled do budoucnosti Ing. Ota Novotný, Ph.D. katedra informačních technologií Vysoká škola ekonomická v Praze novotnyo@vse.cz katedra informačních technologií VŠE Praha jsme uznávanou autoritou v oblasti aplikované informatiky

Více

Vlákno (anglicky: thread) v informatice označuje vlákno výpočtu neboli samostatný výpočetní tok, tedy posloupnost po sobě jdoucích operací.

Vlákno (anglicky: thread) v informatice označuje vlákno výpočtu neboli samostatný výpočetní tok, tedy posloupnost po sobě jdoucích operací. Trochu teorie Vlákno (anglicky: thread) v informatice označuje vlákno výpočtu neboli samostatný výpočetní tok, tedy posloupnost po sobě jdoucích operací. Každá spuštěná aplikace má alespoň jeden proces

Více

1 VZNIK, VÝVOJ A DEFINICE MECHATRONIKY

1 VZNIK, VÝVOJ A DEFINICE MECHATRONIKY 1 VZNIK, VÝVOJ A DEFINICE MECHATRONIKY 1.1 VÝVOJ MECHATRONIKY Ve vývoji mechatroniky lze vysledovat tři období: 1. etapa polovina 70. let, Japonsko, založení nového oboru shrnuje poznatky z mechaniky,

Více

Centrum pro rozvoj dopravních systémů

Centrum pro rozvoj dopravních systémů Centrum pro rozvoj dopravních systémů SMART CITY VŠB - TU Ostrava Září 2013 Témata 1. Představení centra RODOS 2. První výstupy centra RODOS pilotně provozované systémy Centrum pro rozvoj dopravních systémů

Více

POKROČILÉ POUŽITÍ DATABÁZÍ

POKROČILÉ POUŽITÍ DATABÁZÍ POKROČILÉ POUŽITÍ DATABÁZÍ Barbora Tesařová Cíle kurzu Po ukončení tohoto kurzu budete schopni pochopit podstatu koncepce databází, navrhnout relační databázi s využitím pokročilých metod, navrhovat a

Více

Simluátor Trilobota. (projekt do předmětu ROB)

Simluátor Trilobota. (projekt do předmětu ROB) Simluátor Trilobota (projekt do předmětu ROB) Kamil Dudka Jakub Filák xdudka00 xfilak01 BRNO 2008 1 Úvod Jako školní týmový projekt jsme si zvolili simulátor trilobota 1 a jeho prostředí. Simulátor komunikuje

Více

Paralelní výpočty ve finančnictví

Paralelní výpočty ve finančnictví Paralelní výpočty ve finančnictví Jan Houška HUMUSOFT s.r.o. houska@humusoft.cz Výpočetně náročné úlohy distribuované úlohy mnoho relativně nezávislých úloh snížení zatížení klientské pracovní stanice

Více

SYSTÉMOVÁ METODOLOGIE (VII) Kybernetika. Ak. rok 2011/2012 vbp 1

SYSTÉMOVÁ METODOLOGIE (VII) Kybernetika. Ak. rok 2011/2012 vbp 1 SYSTÉMOVÁ METODOLOGIE (VII) Kybernetika Ak. rok 2011/2012 vbp 1 ZÁKLADNÍ SMĚRY A DISCIPLÍNY Teoretická kybernetika (vědecký aparát a metody ke zkoumání kybernetických systémů; používá abstraktní modely

Více

Služby pro zařízení vysokého napětí. Spolehlivé sledování stavu zařízení

Služby pro zařízení vysokého napětí. Spolehlivé sledování stavu zařízení Služby pro zařízení vysokého napětí Spolehlivé sledování stavu zařízení Strategie údržby Jaký přístup je nejlepší? Údržba dle skutečného stavu zařízení Údržba založená na průběžném monitorování funkce

Více

Základní pojmy teorie grafů [Graph theory]

Základní pojmy teorie grafů [Graph theory] Část I Základní pojmy teorie grafů [Graph theory] V matematice grafem obvykle rozumíme grafické znázornění funkční závislosti. Pro tento předmět je však podstatnější pohled jiný. V teorii grafů rozumíme

Více

Úvod do principů objektově orientovaného programování

Úvod do principů objektově orientovaného programování OBSAH DISTANČNÍHO E-LEARNINGOVÉHO KURZU PROFESNÍ RŮST ANALYTIKA OD ZÁKLADŮ (BASE) ÚVOD DO TECHNOLOGIÍ INFORMAČNÍCH SYSTÉMŮ Jak funguje počítač na základní úrovni Základy HTML Skripty ve webovských technologiích

Více

Biologicky inspirované výpočty. Schématické rozdělení problematiky a výuky

Biologicky inspirované výpočty. Schématické rozdělení problematiky a výuky Biologicky inspirované výpočty Schématické rozdělení problematiky a výuky 1 Biologicky inspirované výpočty - struktura problematiky Evoluční systémy: evoluční algoritmy, evoluční hardware, víceúčelová

Více

Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace

Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace B5 Program Téma obsahuje informace o programech a programovém řízení a klade si za cíl především vysvětlit

Více

GEOGRAFICKÉ INFORMAČNÍ SYSTÉMY Mgr. Aleš RUDA Teorie, základnz kladní principy Organizovaný, počíta tačově založený systém m hardwaru, softwaru a geografických informací vyvinutý ke vstupu, správě,, analytickému

Více

4.9.59. Seminář z chemie

4.9.59. Seminář z chemie 4.9.59. Seminář z chemie Seminář z chemie si mohou žáci zvolit ve třetím ročníku je koncipován jako dvouletý. Umožňuje žákům, kteří si jej zvolili, prohloubit základní pojmy z chemie, systematizovat poznatky

Více

Ing. Petr Hájek, Ph.D. Podpora přednášky kurzu Aplikace umělé inteligence

Ing. Petr Hájek, Ph.D. Podpora přednášky kurzu Aplikace umělé inteligence APLIKACE UMĚLÉ INTELIGENCE Ing. Petr Hájek, Ph.D. Podpora přednášky kurzu Aplikace umělé inteligence Aplikace umělé inteligence - seminář ING. PETR HÁJEK, PH.D. ÚSTAV SYSTÉMOVÉHO INŽENÝRSTVÍ A INFORMATIKY

Více

Emergence chování robotických agentů: neuroevoluce

Emergence chování robotických agentů: neuroevoluce Emergence chování robotických agentů: neuroevoluce Petra Vidnerová, Stanislav Slušný, Roman Neruda Ústav Informatiky, AV ČR Kognice a umělý život VIII Praha 28. 5. 2008 Evoluční robotika: EA & neuronové

Více

EXTRAKT z české technické normy

EXTRAKT z české technické normy EXTRAKT z české technické normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním 35.240.60 materiálem o normě. Komunikační infrastruktura pro pozemní mobilní zařízení (CALM) Architektura

Více

Masterský studijní obor datové & webové inženýrství

Masterský studijní obor datové & webové inženýrství Masterský studijní obor datové & webové inženýrství Předpoklady Struktura studia Přihlášky Poradenství Masterský studijní obor datové & webové inženýrství představuje ve studijním konceptu fakulty informatiky

Více

Business Intelligence

Business Intelligence Business Intelligence Josef Mlnařík ISSS Hradec Králové 7.4.2008 Obsah Co je Oracle Business Intelligence? Definice, Od dat k informacím, Nástroj pro operativní řízení, Integrace informací, Jednotná platforma

Více

Manažerský informační systém na MPSV. Mgr. Karel Lux, vedoucí oddělení koncepce informatiky MPSV

Manažerský informační systém na MPSV. Mgr. Karel Lux, vedoucí oddělení koncepce informatiky MPSV Manažerský informační systém na MPSV Mgr. Karel Lux, vedoucí oddělení koncepce informatiky MPSV Konference ISSS-2009 Hradec Králové Aldis 6. dubna 2009 MIS na MPSV časové údaje projektu Vytvoření MIS MPSV

Více