UNIVERZITA PARDUBICE FAKULTA ELEKTROTECHNIKY A INFORMATIKY

Transkript

1 UNIVERZITA PARDUBICE FAKULTA ELEKTROTECHNIKY A INFORMATIKY DIPLOMOVÁ PRÁCE 2012 Bc. Jiří Popelka

2 Univerzita Pardubice Fakulta elektrotechniky a informatiky Agentově orientovaný simulační model pro distribuci zboží Bc. Jiří Popelka Diplomová práce 2012

3

4

5 Prohlášení autora Prohlašuji: Tuto práci jsem 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 Jiří Popelka

6 Poděkování Touto cestou bych chtěl poděkovat svému vedoucímu práce Ing. Michaelu Bažantovi Ph.D., který mi umožnil toto zajímavé téma zpracovat a také za jeho odbornou pomoc a rady při psaní této diplomové práce.

7 Anotace Cílem práce je vytvořit agentově orientovaný simulační model pro experimentování s distribučním systémem v rámci vybraného fragmentu silniční sítě. Vytvořený simulační model poslouží k získání výsledků, které budou uplatněny v rámci projektu Green Logistics s primárním zaměřením na zkoumání produkce škodlivin produkovaných nákladními vozidly do ovzduší a vyhodnocení vybraných algoritmů v rámci simulačního modelu. Klíčová slova lantime, dálniční hierarchie, agent, agentově orientovaná simulace, repast, plánování cest Title Agent based simulation model for the distribution of goods. Annotation The aim is to create an agent-based simulation model for experimenting with the distribution system within the selected fragment of the road network. The simulation model will be used to obtain results that will be applied within the project Green Logistics with primary focus on exploring production of pollutants produced by trucks into the air and evaluation of selected algorithms in the simulation model. Keywords lantime, highway hierarchies, agent, agent-based simulation, repast, routing

8 Obsah 1 Úvod Agentově orientované programování Agent Vlastnosti agenta Druhy agentů Prostředí Agenti v simulacích Agentově orientovaná architektura simulačního modelu Multiagentní přístup Komunikace Architektura ABASim RepastSuite Základní koncept frameworku Repast Simphony Repast Simphony Repast Java ReLogo Repast Flowchart Repast HPC LANTIME Úvod Road Timetable Vytvoření Road Timetable Nejrychlejší cesta Časové intervaly Vlastnost First-In First-Out Formulace a návrh algoritmu Souhrn celého algoritmu Nejrychlejší cesta pomocí dálniční hierarchie...41

9 5.1 Předpoklady Grafy a cesty Dijkstrův algoritmus Obecný popis techniky Lokalita Dálniční hierarchie Konstrukce Fáze 1 Konstrukce stromu částečných cest Ukončovací kritérium Příklad fáze Fáze 2 Výběr dálničních hran Popis algoritmu Zrychlení konstrukce Kontrakce dálniční sítě Nalezení nejkratší cesty Algoritmus výběru nejkratší cesty Realizace modelu Vstupní data Datové úložiště Oracle Database 11g Express Edition Struktura databáze Tabulka network Tabulka default_speed Tabulka speed Tabulka timetable Problémy s daty Použitá dopravní síť Vytvoření Road Timetable Model...57

10 6.2.1 Popis Agent Controller Agent Depo Agent Customer Agent Vehicle Agent Scheduler Experimenty Scénář 1: Jedno vozidlo s kapacitou 50 jednotek Scénář 2: Jedno vozidlo s kapacitou 100 jednotek Scénář 3: Dvě vozidla s kapacitou 50 jednotek Scénář 4:Čtyři vozidla s kapacitou 20 jednotek Scénář 5: Šest vozidel s kapacitou 20 jednotek Scénář 6: Deset vozidel s kapacitou 10 jednotek Závěr...66 Seznam použité literatury Přílohy...69 Seznam obrázků Obrázek 1Interakce agenta s okolím. Zdroj:[1]...13 Obrázek 2Klasifikace agentů. Zdroj:[2] Obrázek 3Funkce agenta. Zdroj: [2]...17 Obrázek 4Schopnosti agenta. Zdroj:[2] Obrázek 5Hierarchická struktura agentů a modelů. Zdroj: [2]...19 Obrázek 6Vrstvy simulačního modelu. Zdroj: [2] Obrázek 7Příklad implementace agenta chodce. Zdroj: [5]...26 Obrázek 8Běhové prostředí Repast Simphony s 2D a 3D pohledem. Zdroj: [5] Obrázek 9Ukázka prostředí flowchart. Zdroj: [5] Obrázek 10 Časové intervaly. Zdroj: [7] Obrázek 11 Pseudokód výpočtu času příjezdu. Zdroj: [7] Obrázek 12 Čtyři druhy přesunu v sousedství. Zdroj: [6]...38

11 Obrázek 13 Neorientovaný graf s cestou a podcestou. Zdroj:[12] Obrázek 14 Prohledávací prostor Dijkstrova algoritmu. Zdroj: [12]...43 Obrázek 15 Dvojsměrný Dijkstrův algoritmus. Zdroj: [12] Obrázek 16 Sousedství vrcholu s o velikosti 5. Zdroj:[12] Obrázek 17 Částečná nejkratší cesta. Zdroj: [12]...44 Obrázek 18 Ukončovací kritérium. Zdroj:[12] Obrázek 19 Konstrukce - fáze 1. Zdroj: [12]...45 Obrázek 20 Konstrukce - fáze 2. Zdroj: [12]...46 Obrázek 21 Konstrukce Slacková metoda. Zdroj: [12] Obrázek 22 Porovnání konstrukčních metod. Zdroj: [12]...47 Obrázek 23 Dálniční síť a přiložený strom se zkratkami. Zdroj: [12]...48 Obrázek 24 Dálniční hierarchie. Zdroj: [12] Obrázek 25 Pseudokód vyhledávání nejkratší cesty. Zdroj: [11] Obrázek 26 Architektura JDBC...53 Obrázek 27 Struktura tabulky network...54 Obrázek 28 Struktura tabulky default_speed Obrázek 29 Struktura tabulky speed...55 Obrázek 30 Struktura tabulky timetable Obrázek 31 Dopravní síť použitá v modelu...57 Obrázek 32 Náhled zobrazení modelu...59 Obrázek 33Scénář 1 průměrné vzdálenosti Obrázek 34 Scénář 1- produkce CO 2 podle metody plánovaní tras...60 Obrázek 35 Scénář 2 průměr vzdálenosti Obrázek 36 Scénář 2 - produkce CO 2 podle metody plánovaní tras...61 Obrázek 37Scénář 3 průměr vzdálenosti Obrázek 38 Scénář 3 - produkce CO 2 podle metody plánovaní tras...62 Obrázek 39Scénář 4 průměr vzdálenosti Obrázek 40Scénář 4 - produkce CO 2 podle metody plánovaní tras...63

12 Obrázek 41 Scénář 5 průměr vzdálenosti Obrázek 42Scénář 5 - produkce CO 2 podle metody plánovaní tras...64 Obrázek 43 Scénář 6 průměr vzdálenosti Obrázek 44Scénář 6 - produkce CO 2 podle metody plánovaní tras...65 Seznam tabulek Tabulka 1Defaultní rychlosti podle úrovně silnici a timeslotu Tabulka 2 Data soubor s dopravní sítí Tabulka 3 Struktura souboru upravující rychlost hrany...52 Seznam zkratek ACL KQML FIPA ABAsim C++ Java IDE GUI jazyk pro komunikaci v prostředí multiagentních systémů jazyk a protokol pro výměnu informací a znalostí sdružení fyzikcé inteligentní agenty agentově orientovaná simulace programovací jazyk programovací jazyk vývojové prostředí grafické uživatelské prostředí 2D, 3D dvou a tří rozměrný prostor XML CSV JGAP MPI mph FIFO API JDBC OJDBS CPU GHz RAM m/s rozšiřitelný značkovací jazyk (Extensible Markup Language) jednoduchý souborový formát pro výměnu tabulkových hodnot Java balíček genetických algoritmů (Java genetic algorithms package) knihovna pro podporu paralelního řešení výpočetních problémů v clusterech míle za hodinu datová struktura typu fronta, (first-in-firtst-out) aplikační informační rozhraní Java Database Connectivity JDBC API pro Oracle procesor Giga Hertz, jednotka frekvence operační paměť metr za sekundu

13 1 Úvod Diplomová práce je primárně zaměřená na ověření algoritmu LANTIME a následné simulování pohybu vozidel po reálné dopravní síti, za účelem zjištění možné minimalizace množství vypouštěného oxidu uhličitého do ovzduší. Téma jsem si vybral, neboť mi přišlo zajímavé a zaujala mě také možnost podílet se na projektu Green Logistics a získat nové zkušenosti s frameworkem Repast Suite, ve kterém je agentově orientovaný model realizovaný. V této práci nejprve vysvětlím, co je agentově orientované programování a jaké základní prvky ho tvoří. Následně naznačím principy agentově orientovaného simulačního modelu. Ve třetí kapitole Vás obeznámím s frameworkem Repast Suite, který slouží k vytváření agentově orientovaných simulačních modelů. Ve čtvrté kapitole je popsaný plánovací algoritmus LANTIME. Je zde popsána metodika vytváření Road Timetables a způsob, jakým algoritmus přiřazuje zakázky na doručení zásilek jednotlivým automobilům tak, aby vypouštěly co nejmenší množství oxidu uhličitého. V páté kapitole popíši, jakým způsobem efektivně vypočítat nejkratší cestu na rozsáhlé dopravní síti (resp. orientovaném grafu). Zaměřím se na tvorbu úrovní potřebných pro dálniční hierarchii a hned po té na algoritmus pro vyhledávání nejkratší cesty. Po teoretické části se dostávám k implementaci konkrétního simulačního modelu. Jsou zde hlavně popsána data potřebná pro simulační model a vyskytlé problémy s těmito daty. Po implementaci agentově orientovaného simulačního modelu je připraveno několik experimentů k ověření funkčnosti. V závěru své diplomové práce se zamýšlím nad možností rozšíření simulačního modelu a zhodnotím průběh její tvorby a její přínos. 12

14 2 Agentově orientované programování Tato kapitola se věnuje definici základních pojmů agentově orientovaného programování, jako je agent, prostředí či komunikace mezi agendy. Je zde také popsán princip agentově orientované simulace. 2.1 Agent V 60. letech 20. století se v počítačové terminologii poprvé objevil pojem agent. Agent je definovaný jako autonomní systém, který je schopný vnímat okolí ve kterém se nachází, dokáže s ním komunikovat a dokonce je schopný samostatného rozhodování, jaké další akce vykoná. V nynější době se v souvislosti pojmu agent představují multiagentní systémy.[1] Agenty můžeme nalézt téměř kdekoliv, nejen v počítačové terminologii. Může jím být člověk, jakož to biologický agent, robot jako technická agent atd. Agentem proto můžeme nazvat cokoliv, co dokáže vnímat své okolí a následně reagovat. Pro vnímání okolí používá agent senzory, pomocí nichž dostává zprávy. Pro ovlivnění okolí, používá agent efektory (obr. 1). Pro dosažení daného cíle je agent schopný samostatného rozhodování, jakých akcí pro to použije.[1] 2.2 Vlastnosti agenta Obrázek 1Interakce agenta s okolím. Zdroj:[1] Mezi základní vlastnosti agenta patří dle [2]: Autonomie - jeli agent cílově orientovaný modul, schopný samostatného řešení určitých úloh bez nezbytné komunikace s okolím, avšak schopný komunikace, koordinace činnosti či kooperace s jinými agenty v rámci určité komunity. Mají možnost dobrovolně vstupovat a opouštět komunitu, poskytovat či požadovat výsledky. Reaktivita - znamená to, že je agent schopen adekvátní reakce na změny ve svém okolí. Společenské chování - spočívá v tom, že je agent schopen komunikace s jiným agentem nebo člověkem pomocí nějaké formy komunikace. 13

15 Iniciativnost - agent by měl mít schopnost reakce na změny ve svém okolí, ale měl by mít i chování zaměřené na dosažení cíle, který ovlivňuje akce agenta. Podle potřeb jednotlivých aplikací, ve kterých mají být agenti použiti, je i ovlivněna realizace agenta. Podle toho na jakou vlastnost je kladen důraz, vychází i samotná technická realizace agenta. 2.3 Druhy agentů Klasifikace druhů agentů není v dnešní době jednoznačná, avšak pomocí tří kritérií, můžeme agenty rozdělit na základní skupiny. Těmito kritérii jsou dle[2]: Mobilita - schopnost jejich pohybu v prostředí. Podle tohoto kritéria se agenti děli na statické a mobilní. Statičtí agenti setrvávají na jednom místě v rámci prostředí nebo v počítačové síti na jednom počítači. Oproti tomu mobilní agenti se mohou pohybovat. Míra iniciativnosti - rozlišujeme uvažující a reaktivní agenty. Uvažující agenti jsou založeni na logickém uvažování nebo v sobě zahrnují model okolního prostředí, jsou tedy schopni kdykoliv rozhodnout o tom jakou činnost v daném momentu vykonávat. Reaktivní agenti fungují na principu podnět odezva. Jejich rozhodnutí tedy vyplývá z aktuálního stavu prostředí, v němž jsou umístěni. Reaktivní agenti tedy pouze reagují na podněty z okolí. Autonomnost, kooperace a schopnost učit se - rozlišujeme tedy kooperativní agenty, agenty rozhraní, kooperativní učící se agenty a inteligentní agenty. Na obrázku (Obr. 2) jsou znázorněné vzájemné průniky dle uvedených vlastnosti agentů. Obrázek 2Klasifikace agentů. Zdroj:[2]. Kromě těchto základních uvedených členění je možné dále klasifikovat podle jejich konkrétního aplikačního poslání (například internetový agent působí v 14

16 prostředí internetu, informační agent pracuje ve spojení s určitým informačním systémem atd.) anebo podle použitého koncepčního přístupu (filozofie), který je při konstrukci agenta uplatněný. V případě, že je při tvorbě jednotlivého agenta použita kombinace vícerých koncepčních přístupů, které byly diskutované, tak hovoříme o hybridním agentovi (ten může například kombinovaně využívat principy uvažujících a reaktivních agentů apod.)[1] Existuje i důsledná klasifikace, jež určí přesné začlenění agenta. Já zde však uvedu pouze jednodušší klasifikaci zdůrazňující nejvíce používané typy agentů. Agenti se tedy člení dle [2] na: Kooperativní agenty. Agenty rozhraní. Mobilní agenty. Informační/internetové agenty. Reaktivní agenty. Hybridní agenty. Inteligentní agenty. V případě, že aplikace kombinuje použití dvou nebo více z výše uvedených druhů agentů, říkáme, že se jedná o heterogenní (různorodý) systém agentů.[2] 2.4 Prostředí Prostředí je vše, s čím agent přichází během své činnosti do styku. Je to tedy agentní systém bez jediného svého prvku - agenta. Prostředí z hlediska agenta pak může být dle [2]: Plně pozorovatelné/částečně pozorovatelné. Prostředí je pro agenta plně pozorovatelné, pokud může svými senzory sledovat jeho kompletní stav. Statické/Dynamické. Prostředí je pro agenta statické, pokud se může měnit pouze jeho akcemi. Deterministické/Nedeterministické. Prostředí je deterministické, jestliže je jeho stav po vykonání nějaké akce dán pouze touto akcí a předcházejícím (původním) stavem tohoto prostředí. Diskrétní/Spojité. Prostředí je diskrétní, pokud má konečně nebo spočetně mnoho stavů. Pro agenta založeného na číslicových počítačích/procesorech je každé prostředí diskrétní. Údaje ze senzorů se totiž ukládají do konečného binárního řetězce, a proto existuje pouze konečná množina stavů tohoto prostředí. 15

17 2.5 Agenti v simulacích Co vlastně přináší uplatnění agentů v oblasti simulací? Za prvé to je vysoký stupeň decentralizace z toho vyplývá, že není potřeba tvořit žádný globální model řízení celého společenství agentů, neboť každý z nich je autonomní. Za druhé je to vysoká životaschopnost systému. Uvedené rysy by mohly být poměrně zajímavé pro tvorbu komplexních simulačních modelů (např. území rozsáhlých obslužných systémů anebo biologických společenstev), pro které by bylo možné navrhnout dobře udržovatelnou a srozumitelnou strukturu členěnou například na přirozené autonomní jednotky řazení (např. při složitých obslužných systémech) anebo na jednotlivé autonomní jedince (např. u biologických společenstev). Právě agenti se jeví jako dobří kandidáti na realizaci takovýchto autonomních řídících jednotek, resp. autonomních jedinců.[1] Pokud již existuje implementačně-technická podpora, třeba specializovaný software pro tvorbu agentově-orientovaného programování, je možné ji použít. Pokud není dostupná nebo nevyhovuje daným potřebám, pak nezbývá, nežli navrhnout a realizovat vlastní. Zde se řeší především to, jakým způsobem mají být implementováni jednotliví agenti, jak má být zabezpečený mechanizmus jejich komunikace a jaká koncepce bude použita na synchronizaci simulačního výpočtu. 2.6 Agentově orientovaná architektura simulačního modelu Zatím pojem architektura simulačního modelu je dosti volné téma, proto uvedu alespoň dva základní prvky, na kterých tato architektura stojí. Za prvé, základní strukturální anebo funkčně-akční jednotky, s jejichž pomocí je simulační model postavený (např. událost, aktivita, proces, agent apod.). Za druhé je to rozdělení simulačního výpočtu na výpočtové jednotky. Z tohoto hlediska existují dva druhy. Pokud je simulační model realizován na jednoprocesorovém počítači jedná se o monolitickou architekturu. V opačném případě se jedná o paralelní (distribuovanou) architekturu, která je realizována na víceprocesorovém počítači, nebo v počítačové síti. Každý typ architektury má možnost různým způsobem implementovat synchronizaci simulačního výpočtu. Následuje popis specifických funkcí agenta v architektuře simulačního modelu inspirovaného filozofii reaktivních agentů (Obr. 3). Každý agent má zadán určitý cíl, jež má plnit. Tento cíl mu je buď zadán, nebo v případě inteligentních agentů si jej identifikuje sám. V souladu s tím, pro co je agent zkonstruován, realizuje svůj životní cyklus a to následovně: rozpoznání situace rozhodování o řešení výkon řešení. Život a tedy rozhodování agenta je dáno také tím v jakém se nachází prostředí, to zahrnuje všechny ostatní agenty a také tu část prostoru simulačního modelu, ve kterém je agent oprávněný vykonávat změny. Prostředí působení agenta může být buď vymezené, nebo se v případě mobilních agentů může dle potřeby měnit. 16

18 Pokud se agent rozhoduje, pak používá funkci návrhu řešení problémů a komunikace s jinými agenty. Dostane-li agent podnět a řešení dané situace, které je v jeho kompetenci, pak pomáhá řešit problém jiným agentům tím, že je na tuto skutečnost upozorní. Obrázek 3Funkce agenta. Zdroj: [2]. K tomu, aby mohl agent efektivně vykonávat výše uvedené funkce, je nutné, aby disponoval jistými schopnostmi (Obr. 4.). Obrázek 4Schopnosti agenta. Zdroj:[2]. 17

19 Pro komunikaci agentů s jinými agenty nebo s člověkem mu slouží komunikační mechanizmus. Agent má schopnost navrhovat jednorázové řešení problémů (např. volání optimalizačních algoritmů), dále má schopnost sestavovat dlouhodobější plány k vykonávání obslužných činností jako je např. rozvržení zdrojů. Tato činnost však není vyjádření o tom, jak se bude chovat agent v budoucnosti. Senzorická činnost umožňuje agentovi se ptát na stav systému či snímat části svého okolního prostředí. Svou výkonnou funkcí realizuje buď aktivací akce, která okamžitě mění stav systému nebo spustí proces, který mění stav systému v určitém časovém intervalu v jistých časových okamžicích bez jakýchkoliv vnějších zásahů. Schopnosti agenta je vhodné rozdělit do skupin a každou takovouto schopnost implementovat jako samostatnou interní komponentu. Hlavními důvody pro tuto dekompozici agenta jsou: Možnost případného sdílení komponenty vícero agenty a její opakované použití. Možnost implementace vícerých alternativních verzí jedné komponenty, ze které si uživatel vybere jeden vhodný při sestavování scénáře simulačního experimentu.[1] 2.7 Multiagentní přístup V nejjednodušším případě modelování reálného světa můžeme pracovat i jen s jediným agentem, popisujícím jediný systém. Nicméně běžnější je situace, kdy reálný svět modelujeme prostřednictvím sady agentů, modelujících různé relativně samostatné podsystémy a také relace a interakce mezi nimi. V takovém případě mluvíme o multiagentních systémech. Teorie multiagentních systémů je poměrně mladou vědeckou oblastí, zatím v ní nejsou ustálená jasná pravidla. Multiagentní systém je tvořen skupinou agentů, kteří představují aktivní prvky, dále zde mohou být objekty, které žádnou aktivitu nevyvíjejí, ale svojí existencí ovlivňují chování agentů. Toto vše je zasazeno do určitého prostředí, které zprostředkovává interakci mezi agenty i objekty. Prostředí má rovněž vliv na chování agentů, respektive je jimi ovlivňováno. Prostředí rovněž svými vlastnostmi vymezuje možnou interakci mezi agenty navzájem stejně jako interakci agentů s objekty. Agenti a objekty zde vstupují do celé řady vzájemných vztahů. Multiagentní systémy většinou pracují v diskrétních časových krocích. Za multiagentní lze považovat takový systém, který se skládá z následujících komponent dle[1]: Prostředí E, jehož jednou z vlastností může být i prostorovost, tj. může se jednat o prostor, který je obecně n-rozměrný. Množina objektů O. Tyto objekty jsou situované, tj. v kterémkoliv okamžiku je možné k objektu přiřadit polohu v E. Objekty jsou zpravidla pasivní, mohou být vnímány, vytvářeny, odstraňovány a modifikovány agenty. 18

20 Množina agentů A. Agenti jsou podmnožinou objektů a jsou schopné vykonávat určité akce. Představují aktivní entity systému. Množina polí F. Agenti mohou šířit do svého okolí prostřednictvím prostředí E signály v podobě polí a jiná pole mohou naopak vnímat. Množina míst L určujících možné polohy objektů (z množiny O) v prostoru, tj. v prostředí E. Množina relací R, které vzájemně spojují objekty a také agenty. Množina operací Op, dávajících agentům schopnost vnímat, manipulovat, vytvářet, odstraňovat objekty z O, a reprezentujících především akce agentů. Množina operátorů U, reprezentujících aplikace operací z Op na prostředí a reakcí světa na tento pokus o jeho modifikaci. Operátory U jsou nazývány zákony univerza. Takto lze definovat obecný multiagentní systém, který může být i prostorový. [3] Multiagentní hierarchický systém můžeme demonstrovat na ilustračním příkladě (Obr. 5), kde A 0 (např. agent dopravní sítě) rozděluje správu celé sítě S 0 na dvě částečné správy regionů S 1 a S 2. Hovoříme, že agent A 0 delimituje správu sítě na dva rovnocenné regionální agenty A 1 a A 2, přičemž od nich může být informovaný o závažných skutečnostech, tykající se celé sítě a též jim může sám odevzdávat pro ně důležité regionální informace.[1] Obrázek 5Hierarchická struktura agentů a modelů. Zdroj: [2] Předpokládá se, že v každém ze dvou regionů se budou vykonávat stejné správní činnosti. Každý z regionálních agentů používá na plnění svých cílů dalších úzce specifikovaných agentů, na kterých deleguje část svých kompetencí. Z uvedeného obrázku je zřejmé, že regionální agent A 1 využívá pro splnění daných úloh jinou strukturu podřadných agentů než jeho kolega A 2. Z jiného pohledu je možné na hierarchickou strukturu agentů (množinu A) pohlížet jako na hierarchickou strukturu modelů (množinu M, M = A ), přičemž každý model Mi M, 19

21 (Mi A) sestavenou ze stromu agentů s kořenem/agentem Ai A, i=0,..., A -1. Agenta Ai nazýváme představitelem (bossem) modelu Mi, přičemž Mi alternativně označujeme jako model Ai.[1] Modely na nejnižší úrovni hierarchie jsou jednoagentní modely. V algebraickém vyjádření můžeme potom strukturu modelů M 0 z obrázku vyjádřit výrazem M 0 [M 1 (M 3, M 4, M 5 ),M 2 (M 6,M 7 (M 8, M 9 ))], přičemž modely v hranatých závorkách vznikli delimitací a modely v kulatých závorkách vznikly delegováním funkcí jejich nadřízeného modelu.[1] Komunikace Akce, které agent vykonává, transformují stav prostředí. V multiagentním systému však tvoří agentovo okolí i ostatní agenti, kteří se nachází v tomto systému. Z hlediska agenta je proto každý agent pouze dalším prvkem systému, vůči kterému může působit vykonávat akce. Podobně jako v případě neagentních prvků okolí, může být agentovým záměrem změnit vnitřní (mentální) stav jiného agenta. Obecně se rozlišují dva přístupy, kterými může agent mentální stav jiného agenta změnit.[4] Nepřímé ovlivnění: Agent nepůsobí přímo na jiného agenta, ale mění stav jeho okolí tak, aby ten při kontaktu s tímto okolím změnil svůj postoj žádaným směrem. Přímé ovlivnění: Agent působí na jiného agenta přímo a jediným možným způsobem tohoto ovlivnění je komunikace. Důvodů ke komunikaci může mít agent několik. Já zde uvádím šest základních typů dialogu.[4] Dotazování: Agent hledá nějakou informaci a dotazuje se jiného agenta, o kterém věří, že mu tuto informaci může poskytnout. Hledání informace: Agenti společně pátrají po informaci, která není známá žádnému z nich. Přesvědčování: Agent se snaží přesvědčit jiného agenta, aby přijal některé z jeho záměrů. Vyjednávání: Agenti vyjednávají o podmínkách sdílení prostředků, nebo o poskytnutí služeb tak, aby všichni zúčastnění dosáhli maximálního zisku. Porada: Cílem porady je nalézt řešení problému, které je v zájmu všech zúčastněných. Agenti poskytují své znalosti a schopnosti a usnáší se na dalším postupu. Eristický dialog: Eristický dialog je dialog, během kterého si agenti vyměňují expresivně informace za účelem dosažení svých záměrů. Tyto informace nejsou ani logickou podporou argumentu, ani vyjednáváním či dotazováním. Typickým takovým dialogem je hádka. Vlastní komunikace je proces, během kterého si dva nebo více agentů vyměňují informace ve formě elementárních komunikačních zpráv. Každá 20

22 elementární komunikační zpráva má odesílatele, příjemce, obsah a informaci o typu, který určuje význam obsahu zprávy. [4] Pokud agent chce komunikovat, musí mít schopnost nalézt partnera vhodného pro záměry, kterých hodlá touto komunikací dosáhnout. Řešení nastíněného problému může vycházet z nástrojů, které jsou již nyní využívány pro distribuované systémy, jako například vysílání (broadcasting) nebo nástěnky. Jiné přístupy nabízí výsledky bádání přímo v oblasti agentních systémů. Hledání vhodného partnera pro komunikaci může být řešeno například přes adresáře služeb, nebo adresáře agentů, přítomných na agentních platformách. Dále lze využít speciálních agentů pro zprostředkovávání komunikace nebo pro vyhledávání služeb, ti se nazývají mediátoři, brokeři, nebo facilitátoři. Posledním známým přístupem jsou sociální modely. Komunikace v sociálních modelech je založena na vysílání požadavku uvnitř skupiny a teprve v případě neúspěchu se požadavek vysílá i k ostatním skupinám v systému.[4] Posledním tématem agentní komunikace jsou interakční protokoly. Tyto protokoly udávají pravidla komunikace mezi agenty. Komunikační protokoly se liší podle druhu komunikace a částečně kopírují rozdělení typů dialogu uvedené výše. Každý komunikační jazyk pro komunikaci agentů je, stejně jako všechny ostatní jazyky, dán abecedou, syntaxí a sémantikou. V současné době je hlavním jazykem pro komunikaci agentů ACL (Agent Communication Language). ACL vychází z jazyka KQML (Knowledge Query Manipulation Language), řeší některé nedostatky, kvůli kterým býval KQML kritizován a jeho standardizace je uvedená ve specifikacích FIPA.[4] Architektura ABASim ABASim (Agent-Based Architecture of Simulation model) architektura byla vyvinutá kolektivem pracovníků na Fakultě řízení a informatiky na Žilinské univerzitě. Tato architektura umožňuje tvořit flexibilní simulační modely komplexních obslužných systémů. Simulační model je složen z kooperujících reaktivních agentů, kteří jsou organizování v hierarchické struktuře. Hierarchická struktura je typická pro obslužné systémy. Každý agent této architektury se skládá z komponent, které zabezpečují senzorickou, výkonnou a komunikační činnost agenta. Následující text se bude podrobně věnovat této architektuře. V abasie architektuře jsou systémy modelované z hlediska rozhodování a řízení. Jak bylo uvedeno výše, řídící prvky mají určité kompetence a jsou hierarchicky organizované. Řídící prvek má zabezpečit předem definovaný cíl. Při plnění cíle se rozhoduje, zda bude spolupracovat se svými podřízenými řídícími prvky nebo zda danou úlohu zpracuje sám. Řídící prvky se modelují pomocí agentů. Agent tvoří základní stavební a funkční jednotku v modelu obsahuje totiž funkce potřebné prořízení a aplikaci svých rozhodnutí. Každý model se skládá z jednoho nebo více kooperujících agentů. Agent má několik hlavních funkcí jako je identifikace cíle, rozpoznává situaci, rozhoduje o řešení a vykonává řešení. Agent při rozhodování o řešení může použít funkce návrhu řešení problému a kooperaci s jinými agenty nebo s člověkem. 21

23 Obrázek 6Vrstvy simulačního modelu. Zdroj: [2]. Rozklad agenta na jeho jednotlivé vnitřní součásti do dvou skupin (manažeři a asistenti) nastiňuje myšlenku dívat se na celý model jako na systém založený z jednotlivých vrstev (Obr. 6). Jednak je to vrstva managementu, která se rozhoduje a vydává pokyny pro realizaci svých rozhodnutí. Potom je zde vrstva zpracování, kde její součásti asistují managementu a realizují požadované výkony ve vymezeném prostoru simulačního modelu. V modelu je možné uvažovat také o další vrstvě. Vrstva entit vytváří stavový prostor simulačního modelu a nese informační a fyzické entity. Fyzické entity odpovídají všem prvkům simulovaného modelu. Všechny fyzické entity jsou modelovány komplexní modelovou strukturou, která odráží stav simulovaného modelu. Informační entity nesou informace, které nejsou přímo součástí fyzických entit, ale jsou potřebné k řízení systému nebo popisují chování modelu v čase. V popisované architektuře existuje komunikace jednak mezi agenty a jednak vnitřní komunikace mezi manažerem a jeho asistenty. Oba dva druhy jsou v abasie architektuře realizované pomocí zasílání zpráv a z tohoto hlediska je možné označit abasie architekturu jako zprávou orientovanou. Existují zde tři vrstvy, na kterých probíhá komunikace. Následuje přehled, jaké zprávy se používají v jaké vrstvě. 22

24 Pro komunikaci mezi agenty (mezi jejich manažery) se používají typy zpráv dle [2]: Gotice (oznámení), je zpráva, na kterou se neočekává žádná odpověď. Regest (žádost) je zpráva obsahující určitý požadavek (na poskytnutí služby či informace), přičemž odesílatel očekává na ni od adresáta odpověď. Response (reakce/odezva), která reprezentuje povinnou odpověď na zprávu typu Regest, přičemž může být doručená pouze jejímu odesílateli. Pokyny, které může manažer dávat svým asistentům, jsou realizované pomocí následujících typů zpráv dle [2]: Start, po přijetí zprávy tohoto druhu začne adresát (musí to být kontinuální asistent) svojí autonomní činnost. Brek, představuje jediný způsob, jak může manažer ovlivnit autonomní běh kontinuálního asistenta, který je po přijetí této zprávy nezvratně ukončen (tento typ se používá jen ve výjimečně a to v případech, kdy nastaly v simulačním modelu takové podmínky, při kterých již nemá smysl, aby kontinuální asistent dokončil svoji činnost). Exekute, je specifickým typem zprávy, určené pro promptního asistenta, který okamžitě vykoná odpovídající činnost a obratem zprávu vrátí svému manažeru (odesílateli) s vyznačeným výsledkem svoji činnosti. Posledním druhem zpráv, které se v architektuře ABAsim používají, jsou zprávy, které odesílají kontinuální asistenti v čase svojí autonomní činnosti dle [2]: Finish je zpráva, kterou každý z kontinuálních asistentů povinně zašle svému manažerovi v okamžiku své činnosti. Notice jsou zprávy, které mohou být zaslané v zásadě kdykoliv v průběhu činnosti kontinuálního asistenta, kdy kontinuální asistent potřebuje oznámit svému manažeru výskyt pro něho důležité situace. Hold je jedinou zprávou, která obsahuje tzv. časovou pečeť určující čas na její dokončení, přičemž tuto zprávu si kontinuální asistent zásadně posílá sám sobě (kontinuální asistent může po odeslání této zprávy opět pokračovat ve svojí činnosti až od toho okamžiku simulačního času, kdy je mu tato zpráva doručena. Do té doby je neaktivní). V ABAsim architektuře se běh simulačního času zabezpečuje výlučně zasláním zpráv typu Hold, a tedy časová synchronizace modelu se vlastně realizuje synchronizací činností kontinuálních asistentů. Ve vrstvě managementu se zprávy s časovými pečetěmi nepoužívají, a tedy zde se simulační čas neovládá a nesynchronizuje. V případě aplikace architektury v distribuovaném prostředí je 23

25 nutné vybavit i zprávy managementu časovými pečetěmi pro případ, že jsou tyto zprávy zasílané do jiného uzlu v síti s jiným lokálním simulačním časem, než má odesílatel. Po vysvětlení zásad komunikace v ABAsim architektuře je zřejmé, že popsaná komunikace slouží hlavně pro realizaci diskrétních simulačních modelů. Nicméně je možné rozšířit mechanizmus komunikace tak, aby se dal použít i při tvorbě diskrétně-spojitých simulačních modelů. 24

26 3 RepastSuite Repast Suite 1 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 ). Celá tato kapitola je převzata z [5]. 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 jazyka Java 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 2, 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). 3.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 v zadaném tiku o vektor odpovídající jeho směru a aktuální rychlosti. 1 Framework je dostupný na webové adrese: 2 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 javovskou platformu. Inspiraci čerpal z jazyků Python, Ruby, Perl a Smalltalk. [zdroj wikipedie] 25

27 Obrázek 7Příklad implementace agenta chodce. Zdroj: [5] 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: ContinousSpace / projekce souvislého (reálného) prostoru (HPC) Geography / geografická projekce Grid / maticová projekce (HPC) Network / síťová projekce (HPC) PhysicsSpace / fyzikální projekce 26

28 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. 3.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ředinstalovaný a přednastavený v základním instalačním balíčku Repast Simphony 2. Obrázek 8Běhové prostředí Repast Simphony s 2D a 3D pohledem. Zdroj: [5]. 27

29 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ědy, 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 3 ), neuronových sítí (framework Joone 4 ), anebo regresní analýzy (framework OpenForecast 5 ). Navíc je možné využívat vlastních knihoven nebo knihoven třetích stran, pro dosažení požadované funkcionality. 3 JGAP, Java genetic algorithms package je rozšíření pro aplikaci genetických algoritmů v Javě. Informace a celá knihovna je dostupná na adrese: 4 Java Object Oriented Neural Engine (joone) je nadstavba pro realizaci neuronových sítí. Knihovna je dostupná na adrese: 5 OpenForecast je rozšíření pro použití regresní analýzy. Knihovna je dostupná na adrese: 28

30 3.2.2 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 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 9). Grafické prostředí je založené na frameworku Flow4J 6 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. 6 Framework je dostupný na webové adrese 29

31 3.3 Repast HPC Obrázek 9Ukázka prostředí flowchart. Zdroj: [5]. 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 7 knihovny. MPI je standardizované 7 Knihovna boost je dostupná z adresy: 30

32 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ů. 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. 31

33 4 LANTIME Je heuristicky algoritmus, který je určen pro plánování nejrychlejších tras pro distribuční automobily, přitom zohledňuje proměnlivost průměrné rychlosti na silnicích, podle toho v jaký čas automobil vyjede. Variabilita je způsobena kongescí, které jsou typicky největší během ranní a večerní dopravní špičky. Algoritmus se používá pro obsazování flotily distribučních automobilů na jihozápadě Spojeného Království. Konvenční metody, které nepočítají se změnou rychlosti v průběhu času, když plánují, můžou vést k tomu, že některé cesty zaberou příliš dlouho dobu na přejetí. Výsledky ukazují, že použitím algoritmu LANTIME vede k úspoře vylučování oxidu uhličitého okolo 7%.[6] 4.1 Úvod Algoritmy pro plánování tras jsou většinou vyvíjeny pro dopravní sítě, které berou průměrnou rychlost vozidla jako konstantní pro jednotlivé úseky sítě. Někdy jsou různé průměrné rychlosti použity pro různé typy silnic nebo pro cesty v částech nějakého území, ale často průměrná rychlost není měněna v průběhu plánování. V praxi plynulost dopravy může podléhat přetížení, které vede ke snížení průměrné rychlosti v jednotlivých částech dne nebo noci. Průměrná rychlost velmi často také závisí na dni v týdnu, ročním období či jiném vlivu, jako třeba podnebí.[6] Nyní máme k dispozici o mnoho více dopravních informací, které umožňují plánovat cesty s přihlédnutím ke kongesci, které jsou předvídatelné z historických údajů. Tento přístup nepočítá s možností vzniku neočekávané situace, která může způsobit kongesci, jako je například dopravní nehoda, ale běžnou kongesci způsobenou objemem dopravy nebo dlouhotrvající prací na silnici mohou být předvídatelné ze získaných dat z dřívějška.[6] Tato data mohou být použita k vytvoření Road Timetable 8, který ukazuje nejkratší dobu mezi zákazníky v různých časech zahájení jízdy. Nejkratší cesta může být v některých případech změněna, v závislosti na kongesci vznikající v průběhu dne.[6] Tato práce popisuje plánovací algoritmus pro distribuční vozy zvaný LANTIME, který je schopný přijímat data z Road Timetable a vykonstruuje množinu cest pro distribuční vozy s minimálním celkovým časem potřebným pro doručení zboží z depa k množině zákazníkům s ohledem na některá omezení. Možná omezení zahrnují: kapacitu vozidla, doby přípustné pro každého řidiče a vozidlo nebo časové okno, kdy má být zboží doručeno zákazníkovi.[6] 8 Road Timetable TM (silniční harmonogram) je obchodní značkou, proto v textu nebude překládáno 32

34 4.2 Road Timetable Většina operátorů komerčních vozidel rozpozná (např. z analýzy tachografu), že rychlost na silnici se mění individuálně z hodiny na hodinu, podle dne v týdnu a ročního období. Studie provedená pro jednoho velkého britského komerčního operátora, provedena pomocí analýzy tachometrů a s pomocí stopovacího systému zjistila, že na jednom úseku dálnice v Severní Anglii se rychlost vozidla měnila v jednom týdnu od 5 mph(v pondělí 08.45) do 55 mph (ve středu v 20.15). Avšak když se porovnaly uložené hodnoty rychlostí za období deseti týdnů, proměnlivost rychlosti v ten samy čas byla s rozdílem menším než 5%. Z toho vyplývá, že rychlost můžeme pro každou silnici v kterýkoliv čas předpovědět. Z toho můžeme také dojít k závěru, že čím větší je odchylka rychlosti vozidel na silnicích během dne, tím větší je nepřesnost plánovacích systémů, které využívají k výpočtu doby trasy rychlost vozidla podle kategorie silnice.[7] Jednou překážkou k zahrnutí časově závislé doby trasy v minulosti byla nedostupnost dat. Ovšem takováto data nyní začínají být dostupná prostřednictvím několika dopravních monitorovacích systémů. Buď mohou být nainstalované statické radary k monitorování rychlosti vozidel na různých místech dopravní sítě, anebo využitím alternativních systémů, které monitorují pozici a rychlost vozidla, které jsou umístěny ve sledovacích zařízeních. Společnost ITIS FloatingVehicle Data poskytuje monitorovací systém nad národní dopravní sítí. Tento systém může být použit pro aktualizaci času trasy založené na současných dopravních podmínkách, ale také poskytuje zaznamenaná dřívější data, takže dopravní podmínky mohou být rozřazeny podle částí dne, dne v týdnu a ročního období. Tato data jsou použita k vytvoření informací pro časově závislé doby tras na dopravní síti. Těmto informacím říkáme Road Timetable.[7] Vytvoření Road Timetable Road Timetable obsahuje obrovské množství dat. Z každého počátečního místa dopravní sítě je určen minimální čas a nejrychlejší čas do každého cílového místa na dopravní síti, pro různou počáteční dobu zahájení trasy. [7] Pro každou hranu v dopravní síti potřebujeme potřebná data pro patřičný čas, ve kterém chceme hranu přejíždět. V praxi bude čas potřebný na přejetí hrany různý pro různé typy vozidel. Proto musíme v datech upravit rychlosti, které přesahují maximální přípustnou rychlost požadovaného typu vozidel. I když je čas spojitou veličinou, většina dopravních informací je udávána v časových úsecích. Proto čas potřebný na přejetí hrany je krokovou funkcí v průběhu dne. Tato časově závislá data můžeme uložit buď jako rychlosti nebo jako časy potřebné na přejetí hrany.[7] Nejrychlejší cesta Výpočet nejrychlejší cesty a její doby může být efektivně uděláno pomocí Dijkstrova algoritmu[8] využívající časově závislé doby cest. Některé adaptace Dijkstrova algoritmu můžete nalézt ve zdroji [9],[7]. V případech, kdy počátky a cíle cest jsou známy předem, může být síť konstruována tak, že všechny počátky a cíle odpovídají uzlům sítě. Pokud není síť 33

35 příliš velká, můžeme vypočítat pro všechny páry počátků a cílů Road Timetable na standardním PC v rozumném čase. Nejkratší cesta v časově závislé dopravní síti závisí na počátečním čase jízdy a může se měnit, i když je počáteční čas v jednom stejném časovém úseku. To protože příjezdy do vrcholů mezi počátkem a cílem mohou být v různých časových intervalech. Protože nejsme schopní získat z Road Timetable nejkratší cestu pro jakýkoliv počáteční čas, musíme si pomoc pomocí aproximace a uložit nejkratší cesty, pro které jejich počáteční čas spadá do předem určeného časového intervalu.[7] V kapitole 5 se zaměřím na efektivní výpočet nejkratší cesty pro rozsáhlé dopravní sítě, které obecný Dijkstrův algoritmus není schopen spočítat v přijatelném čase Časové intervaly ITIS FloatingVehicle Data poskytují reálná data rychlostí každého úseku v dopravní síti v intervalu patnácti minut. Avšak hodnoty sousedících intervalů se příliš nemění, například pozdě v noci a brzy ráno, kdy jsou silnice většinou prázdné. Porovnáním průměrné rychlosti po sobě jdoucích časových úseků je možné zredukovat na přijatelné množství těchto úseků. Pro můj model bylo rozhodnuto použití 15 časových intervalů, které pokryjí 24 hodin. Nejmenší má 30 minut v průběhu dopravní špičky a nejširší má 8 hodin, který pokrývá noční provoz. Časové úseky jsou znázorněné na obrázku 10.[7] Vlastnost First-In First-Out Obrázek 10 Časové intervaly. Zdroj: [7]. Pokud používáme časově závislá data, je třeba zvážit, zda funkce pro určení doby jízdy má vlastnost konzistence FIFO. To znamená, pokud vozidlo cestuje z vrcholu i* do vrcholu j*, kde oba vrcholy náleží jedné dopravní síti, začínaje v jakýkoliv čas T z vrcholu i*, pak dorazí do vrcholu j* později, než kterékoliv vozidlo stejného typu, které vyjelo z vrcholu i* dříve než v čase T. Tato vlastnost znázorňuje to samé, jako když po silnici jedou auta za sebou se stejnou rychlostí, pak dosáhnou cíle ve stejném pořadí, v jakém vyjely.[7] Předpokládejme, že chceme najít čas příjezdu do vrcholu j, a j, poté co cestoval z vrcholu i do vrcholu j přes jednu hranu ij, s počátečním časem jízdy s i. Nechť čas potřebný na přejetí z i do j je uložen jakot k v databázi, když t k t<t k+1, t k znamená hranici časového úseku k, k = 1, n a n je celkový počet časových 34