Lokalizace kolejových vozidel s vyžitím technologie ORACLE Spatial a dynamických pohledů

Transkript

1 Rok / Year: Svazek / Volume: Číslo / Issue: Lokalizace kolejových vozidel s vyžitím technologie ORACLE Spatial a dynamických pohledů Localization of rolling stock with utilization technology ORACLE Spatial and dynamic database views Jan Fikejz jan.fikejz@upce.cz Fakulta elektrotechniky a informatiky Univerzita Pardubice Abstrakt: Tento článek se zabývá problematikou lokalizace kolejových vozidel na železniční síti s využitím dynamických pohledů. Pozornost je věnována popisu lokalizace kolejových vozidel v rámci navrženého modelu železniční sítě. Dále je pozornost zaměřena na optimalizaci vyhledávacích operací databáze ORACLE a návrh optimalizace pomocí dynamických pohledů. Abstract: This article deals with the localization of rolling stock on the railway network using dynamic views. Attention is paid to describing the location of rolling stock in the designed model of railway network. Further is attention focused on optimizing search operations ORACLE database and design of the optimization using dynamic views.

2 Lokalizace kolejových vozidel s vyžitím technologie ORACLE Spatial a dynamických pohledů Jan Fikejz Fakulta elektrotechniky a informatiky Univerzita Pardubice jan.fikejz@upce.cz Abstrakt Tento článek se zabývá problematikou lokalizace kolejových vozidel na železniční síti s využitím dynamických pohledů. Pozornost je věnována popisu lokalizace kolejových vozidel v rámci navrženého modelu železniční sítě. Dále je pozornost zaměřena na optimalizaci vyhledávacích operací databáze ORACLE a návrh optimalizace pomocí dynamických pohledů. 1 Úvod Lokalizace kolejových vozidel je stále diskutovaným tématem, dotýkající se řady subjektů. Problém lokalizace kolejových vozidel bychom mohli rozdělit do dvou hlavních oblastí zájmu. Lokalizace pro potřebu (i) zabezpečovací techniky a lokalizace pro potřebu (ii) informačních a telematických systémů. V prvním případě je kladen velký důraz na spolehlivost a bezpečnost. Bezpečnost je v zabezpečovacích systémech dána úrovní integrity bezpečnosti, tzv. SIL (safety integrity level, úroveň 1 4) [1], jež vyjadřuje míru pravděpodobnosti nebezpečné poruchy. Tyto systémy však bývají často spjaty s vyššími náklady na realizaci, jelikož mnohdy vyžadují doplnění železniční infrastruktury o další komunikační či identifikační prvky/zařízení. V druhém případě lze akceptovat určitou mírou nepřesnosti či nespolehlivosti, což na druhou stranu často přináší výrazně levnější realizaci těchto řešení. V dnešní době se pak nejčastěji lokalizace kolejových vozidel spojuje s využitím satelitního navigačního systému GNSS (Global Navigation Satellite System). Tento systém lze například využít pro řešení lokalizace kolejových vozidel, zejména v rámci jednokolejných regionálních tratí České republiky, které oproti hlavním koridorům nedisponují tak vysokou mírou technické vybavenosti. Tento přístup lokalizace kolejových vozidel tak tvoří i základní ideu toho článku. Tento článek si primárně klade za cíl navrhnout a ověřit optimalizaci SQL dotazů pomocí dynamických pohledů jakožto dalšího stupně optimalizace. Tyto dynamické pohledy by tak mohly přinést další časové úspory při lokalizaci kolejových vozidel, které SQL dotazy v rámci své režie vyžadují. 2 Možné způsoby lokalizace polohy kolejového vozidla V oblasti lokalizace existuje celá řada přístupů, jak identifikovat polohu kolejového vozidla na trati, přičemž lze tento problém zjednodušeně rozčlenit do tří skupin [12]: lokalizace kolejových vozidel bez využití GNSS, lokalizace pomocí GNSS, lokalizace pomocí GNSS a dalších podpůrných systémů. První způsob lokalizace KV často vyžaduje doplnění infrastruktury železniční sítě o další stavební elementy/prvky, což sebou přináší i vysoké náklady na vlastní realizaci. Na druhou stranu tento typ lokalizace vykazuje vysokou přesnost a spolehlivost a je často využíván v zabezpečovací technice. Patří sem především systém ETCS (European Train Control System) úrovně 1-3, využití RFID (Radio Frequency Identification) či kolejové obvody [2]. V České republice jsou některé z těchto způsobů aplikovány (vzhledem k finanční náročnosti) na vybrané hlavní koridory. Při využití samotného systému GNSS pro různé aplikační úrovně je nutné počítat s chybou udávané polohy, která obecně vychází z charakteru satelitní navigace. U systémů, jež pracují s informací o poloze pouze v informativní rovině, lze určitou chybu akceptovat, avšak v oblasti zabezpečovací techniky je takováto nepřesnost nepřijatelná. Lze však implementovat různé doplňkové systémy (diferenciální GPS či služby EGNOS) [5], které tuto chybu eliminují (zcela, nebo alespoň z části), a tak polohu sledovaného objektu zpřesňují [3]. Třetí způsob lokalizace využívá další doplňkové systémy pro upřesnění informace z GNSS. Jedná se především o inerciální systémy skládající se z odometru, gyroskopu, či akcelerometru. Existují však i méně známe/standardní systémy založené například na snímání fyzikálních charakteristik (tzv. otisku) výhybky pomocí vířivých proudů [4]. 3 Identifikace polohy na regionálních tratích s využitím systému GNSS Využití systému GNSS pro lokalizaci KV je vhodné zejména v rámci jednokolejných regionálních tratí, které nedisponují 308

3 moderními systémy typu ETCS [6][7]. Na regionálních tratích často můžeme jen evidovat, že vlak odjel/přijel z/do stanice, avšak na širé trati je lokalizace kolejového vozidla bez doplnění infrastruktury identifikačními elementy výrazně složitější. Jak již bylo dříve uvedeno, lokalizace pomocí GNSS je zatížena vždy chybou pramenící z charakteru satelitní navigace. Přesto lze tento typ lokalizace s výhodou využívat, například v rámci doplňkové podpory dispečerského řízení či v různých informačních systémech pracující s polohou KV. Jedním ze základních způsobů lokalizace kolejového vozidla je možnost využití komunikačního terminálu se systémem GNSS. V České republice jsou současné době vybraná KV osazeny komunikačními terminály: Telerail TLR-ZJ (výrobce Unicontrols, a.s.), Radiostanice VS67 (výrobce T-CZ, a.s.). Tyto dálkově konfigurovatelné komunikační terminály periodicky odesílají definované zprávy, jejichž součástí je i informace o poloze KV. Datové zprávy se pomocí protokolu UDP následně přenáší do řídícího centra. K přenosu dat je primárně využívána přenosová síť GSM-R (Global System for Mobile Communications Railway) a v případě její nedostupnosti se data přenáší pomocí klasické sítě GSM. Jelikož jsou informace o poloze KV v souřadnicovém systému WGS 84 (využívaných i systémech GPS), je možné tyto informace vizualizovat, například do mapového podkladu Google maps, Obrázek 1. 4 Model železniční sítě Jedním z klíčových problémů v oblasti lokalizace KV je, jak identifikovat polohu kolejového vozidla vzhledem k infrastruktuře železniční sítě. Experimentálně bylo zjištěno, že pro návrh modelu železniční sítě lze vyjít z dat staničení (hektometrovníků), kde každé staničení, mimo jiné, disponuje i koordinátem GPS. Tyto data nepopisují přesně kompletní infrastrukturu železniční sítě (především ve stanicích), nicméně pro návrh modelu železniční sítě lze tyto data využít [8]. Dále na základě analýzy poskytnutých dat ze SŽDC- TUDC bylo vyhodnoceno, že pro návrh reprezentace železniční sítě postačují čtyři následující tabulky dat: tabulka hektometrovníků, tabulka supertras, tabulka železničních stanic a tabulka definičních nadúseků. přičemž klíčovým pojítkem mezi jednotlivými tabulkami je vždy TUDU (traťový definiční úsek) Pomocí navržených algoritmů [8] bylo možné sestavit model infrastruktury železniční sítě (ŽS) odrážející datovou strukturu neorientovaný graf a to ve dvou datových vrstvách (mikro/makro vrstva) a třech vizualizačních vrstvách (mikro/mezo/makro). Výsledek navrhnutého modelu železniční sítě je uveden na obrázku 2 Datová vrstva Data-mikro Data-makro Vizualizační vrstva Vizual-mikro Vizual-mezo Vizual-makro Obrázek 2: Model infrastruktury železniční sítě Obrázek 1: Zobrazení polohy kolejového vizidla do mapového podkladu Tomuto způsobu vizualizace však chybí jakákoliv vazba GPS informace o poloze KV na infrastrukturu železniční sítě. Jinými slovy, nelze získat datovou informaci na jaké trati či na jakém kilometru se KV nachází. Datová struktura neorientovaný graf byla implementována jako tabulka-tabulka přímo v databázi ORACLE s nadstavbou Spatial. Pro práci s prostorovými daty databáze ORACLE definuje speciální objektový datový typ SDO_GEOMETRY, který umožnuje uchovávat řadu prostorových informací a geometrických typů, jako jsou například různé body, oblouky, liniové řetězce či polygony. Pro vizualizaci navrženého modelu infrastruktury železniční sítě byl použit vizualizační nástroj MapViewer [9] vyvinutý v jazyce Java. MapViewer je J2EE služba pro vykreslování mapových podkladů vycházející z prostorových dat (například objektový datový typ SDO_GEOMETRY) spravovaných pomocí ORACLE Spatial. Pomocí této technologie lze zakládat škálovatelné mapové vrstvy s různou podrobností zobrazovaných informací. 309

4 Ilustrativní zobrazení segmentu modelu ŽS na úrovni mezovrstvy je zobrazena na obrázku 3. Obrázek 3:Zobrazení mezo vrstvy modelu železniční sítě Nad prostorovými objekty databáze ORACLE s nadstavbou Spatial [10] lze vyžít různé operátory a funkce. Jedním z nich je operátor SDO_NN (Near Neighbor), který umožňuje vyhledání nejbližší geometrii (tzv. souseda), v našem případě nejbližší vrchol, respektive hranu neorientovaného grafu. Pokud tedy disponujeme GPS informací o aktuální pozici KV, lze uplatniti tento operátor pro nalezení nejbližšího vrcholu/hrany a následně tak například provést vizualizaci polohy do mapového podkladu, vybudovaného pomocí technologie MapViewer. Mimo lokalizace KV lze však získat i celou řadu dalších informací, které se k poloze KV a infastruktuře železniční sítě úzce vztahují. Zejména jde o: TUDU na němž se KV nachází, kilometrickou pozici dle staničení, výskyt vlaku v obvodu stanice, směr pohybu kolejového vozidla pomocí azimutu (z/do které stanice se pohybuje), vzdálenost do nejbližší stanice, název a číslo trati dle občanského jízdního řádu (OJŘ), relevantnost aktuální GPS pozice. 5 Simulace provozu V rámci ověřování navrženého modelu infrastruktury, jakož i původního softwarového demonstračního prostředku InfraRAIL určeného pro doplňkovou podporu dispečerského řízení železničního provozu, bylo nutné pomocí diskrétní simulace provést simulaci reálného provozu [11]. Jak již bylo výše uvedeno, jsou vybraná hnací vozidla osazena komunikačními terminály vysílajícími data, jejichž součástí jsou i aktuální GPS souřadnice kolejového vozidla. Pokud je vozidlo v pohybu, pak tento komunikační terminál zašle informace s údaji o poloze každých 30 vteřin. Příklad vzorku zaznamenaných dat je uveden v tabulce 1. Pro simulaci provozu na vybraném segmentu železniční sítě byla navržena testovací aplikace využívající následující softwarové prostředky: NetBeans - Java 1.6, ORACLE s nadstavbou Spatial, MapViewer, ORACLE Map Builder. Aplikace využívá knihovnu mvclient.jar, která umožnuje přes Java API komunikaci se službou MapViewer. Pomocí příslušných metod lze volat požadované funkce, a lze tak vizualizovat polohy kolejových vozidel přímo do připraveného mapového podkladu. Jelikož zaznamenaná historická data o polohách kolejových vozidel na železniční síti obsahují i časová razítka (Tabulka 1), lze interpretací těchto dat následně realizovat diskrétní simulaci provozu včetně vizualizace měnících se poloh kolejových vozidel. 6 Optimalizace SQL dotazu Pokud využíváme databázi a jazyk SQL, pak je velice vhodné věnovat se i optimalizaci požadovaných dotazů. V našem případě se jedná optimalizaci SQL dotazů databáze ORACLE využívající operátor SDO_NN, přičemž se primárně zaměříme na optimalizaci SQL dotazů volaných přímo z aplikace implementované v jazyce JAVA. Tabulka 1: Záznam průjezdu vybraného kolejového vozidla Číslo vlaku Zeměpisná šířka Zeměpisná délka Rychlost Azimut Identifikace vlaku Čas :34: :34: :35: :35:55 310

5 6.1 Objekt Statement Využití objektu Statement patří v prostředí JAVA k základním univerzálním dotazovacím technikám. Hlavním úkolem instancí třídy Statement je provádění databázových příkazů, jejich použití umožňuje: vracet výsledky dotazů, vytvářet tabulky, vkládat, aktualizovat a mazat řádky v tabulkách, vytvářet a upravovat pohledy a ostatní databázové objekty, práci s procedurami jazyka PL/SQL, a obecně umí vykonávat jakékoli DDL či DML operace. Hlavní nevýhodou této techniky je neustálé sestavování nového dotazu, i když se v SQL dotazu mění například pouze jeden parametr. 6.2 Objekt PreparedStatement V rámci vyšší bezpečnosti, komfortu a optimalizace lze v jazyce Java využít řešen v podobě služeb třídy PreparedStstement s vázanými proměnnými. Celý princip spočívá v použití základního SQL příkazu a vázaných proměnných. Databázový stroj tak dostává stále stejný příkaz SQL (se stejným hascode) lišící se pouze jinými hodnotami parametrů. Protože se využívá již jednou vytvořený exekuční plán, který je stále uložen v paměti, dochází k časové optimalizaci práce s databází. 6.3 Volání funkce uložené v databázi Další možností je využití jakékoli funkce vytvořené přímo v databázi pomocí procedurálního jazyka ORACLE, PL/SQL. Proměnné uvnitř procedur/funkcí a parametry vstupující do nich jsou vždy vázané. Je využít stejný exekuční plán a tím dochází optimalizaci požadovaného dotazu. Příkaz SQL napsaný uvnitř funkce využívající vypočtené či předané hodnoty se tak automaticky optimalizují na připravený příkaz s proměnnou sadou parametrů. 6.4 Optimalizace pomocí dynamických pohledů I přes pokročilé optimalizační techniky databáze ORACLE se nabízí otázka, zda je nutné provádět vždy dotaz do celé tabulky vrcholů respektive hran. V hledem k tomu, že se dotazujeme na pozici KV, které z logiky věci nezmění skokově pozici o více než několik desítek metrů, nabízí se uplatnit omezení bázových dat vrcholů/hran pomocí databázového pohledu. Základní idea dynamických pohledů vychází z následujících předpokladů: 1. Pro každé nové KV se vytvoří prvotní dynamický pohled. 2. Dotazy jsou periodiky prováděny do tohoto aktuálního pohledu. 3. Pokud se již KV v aktuálním pohledu nenachází, je dynamicky vytvořen pohled nový a to s ohledem na azimut pohybu KV. Předchozí pohled je následně odstraněn. Jinými slovy, pro identifikaci polohy KV využívá operátor SDO_NN relevantně redukovanou bázi dat, omezenou databázovým pohledem, přičemž se tento pohled dynamicky mění podle pohybu KV a to vždy s ohledem na jeho směr pohybu. Tím dochází k optimalizaci a k celkové časové úspoře dotazu. 7 Testování Testování navržené optimalizace vybraných vyhledávacích operací by mělo prokázat, zda byly uvažované předpoklady využití dynamických databázových pohledů správné. Testovány byly jednotlivé techniky vyhledávací operací nad tabulkou čítající přibližně stotisíc, a nad dynamickými pohledy, které bázi prohledávaných dat účelově redukovaly. Pro účel testování bylo vždy ve vybrané oblasti vygenerováno tisíc bodů s GPS koordináty, přičemž báze dat, do kterých byly prováděny dotazy, čítala cca sto tisíc záznamů. V rámci vygenerovaných bodů byly prováděny dotazy na vyhledání nejbližšího souseda (vrchol grafu). Jednotlivé časy potřebné na realizaci dotazů byly v databázi měřeny a uloženy pro pozdější statistické zpracování. Pro druhotné porovnání slouží změřené celkové časy jednotlivých testů v rámci aplikace, kde se projeví i režie ve formě obsluhy databáze, spojení s databází a zpracování výsledků v jazyce Java. Pro změření časů jednotlivých dotazů bylo využito záznamů v systémové tabulce databázového stroje ORACLE v$sql a hodnot ze sloupce ELAPSED_TIME. Tyto hodnoty byly převedeny z mikrosekund na milisekundy a následně byly zpracovány. V případě dotazů s vázanými proměnnými bylo nutné upravit získávání časů. V rámci interní optimalizace se dotaz připraví pouze jednou a poté jsou již jen předávány vázané proměnné. Takovýto dotaz je v tabulce v$sql uložen jako jeden záznam, kterému se při každém dalším volání zvýší počet provedení a čas provádění se navýší o dobu trvání posledního provedeného dotazu. Pro výpočet času posledního dotazu tedy bylo nutné si vždy pamatovat původní sumu časů a od nově aktualizované sumy ji odečíst. 7.1 Techniky dotazů V této části byly otestovány techniky, pomocí nichž lze sestavit dotaz na nalezení vrchol grafu v rámci výpočtu přesné pozice kolejového vozidla. Jedná se o volání obyčejného dotazu pomocí skládání SQL z řetězců objektem Statement v jazyce Java, volání jednou připraveného dotazu pomocí objektu PreparedStatement s vázanými proměnnými a volání dotazu v databázové funkci uložené přímo v databázi Oracle. Následující tabulka 2 srovnává jednotlivé techniky dotazu na celé tabulce UZLY_CR. 311

6 Z výsledků lze vyčíst, že nejrychlejší technikou je použití objektu PreparedStatement. Následuje použití funkce uložené přímo v databázi Oracle a daleko za nimi zaostává obyčejný dotaz pomocí metod třídy Statement. Pomocí použití vhodné techniky dotazu lze snížit průměrný čas až třináct krát. Tabulka 2: Porovnání časů různých technik dotazů v sekundách Technika dotazu Statement Prepared Statement Oracle funkce Průměr 0, , , Min 0, , , Max 3, , , Medián 0, , , Modus 0, , , Odchylka 0, , , čas čas v Javě 120, , , , , , Optimalizace pomocí dynamických pohledů Pokud omezíme zdrojovou oblast dat na okolí vyhledávaného bodu, mělo by dojít ke zrychlení vyhledávání. První test byl proveden s technikou PreparedStatement (Tabulka 3) na pohledech o velikosti 10x10 km, 40x20 km a v poslední řadě čtvercovým pohledem o straně 50 km odvozených od tabulky UZLY_CR. Tabulka 3: Časy dotazů PreparedStatement nad pohledy různých velikostí v sekundách Velikost pohledu 10x10 40x20 50x50 Průměr 0, , , Min 0, , , Max 1, , , Medián 0, , , Modus 0, , , Odchylka 0, , , čas 7, , , čas v Javě 39, , , Srovnání různých velikostí pohledů napovídá, že všechny tyto pohledy optimalizují už tak rychlý připravený dotaz na přesnou pozici. Nejrychlejší je pohled o velikosti 40x20 km. Pomocí této optimalizace byl snížen čas z původního času 0,0092 sekund o dalších pár tisícin sekundy. Minimální čas se již pohybuje pod hodnotou 0,003 sekundy. Dalším testovaným přístupem bylo volání uložené funkce v databázi ORACLE, tabulka 4. Tabulka 4: Časy dotazů v ORACLE funkci nad různě velkými pohledy v sekundách Velikost pohledu 10x10 40x20 50x50 Průměr 0, , , Min 0, , , Max 1, , , Medián 0, , , Modus 0, , , Odchylka 0, , , čas čas v Javě 7, , , , , , V tomto případě byl zjištěn jako nejrychlejší dotaz dynamického pohledu při omezení oblasti 10x10 km. V porovnání s objektem PreparedStatement došlo při volání dotazu uvnitř funkce k dalším časovým úsporám, přičemž k nejvýraznější úspoře došlo při restrikci základní báze dat pomocí databázového pohledu o velikosti 10x10 a 40x20 km. Tabulka 5: Časy různých technik dotazů nad pohledem 40x20 km v sekundách Metodapohled Oracle funkce 40x20 PreparedStatement 40x20 Průměr 0, , Min 0, , Max 1, , Medián 0, , Modus 0, , Odchylka 0, , čas čas v Javě 7, , , ,70152 Celkové časy v Javě při použití funkce v databázi ORACLE jsou však oproti připravenému dotazu PreparedStatement znatelně vyšší. Přestože je vnitřní dotaz velmi rychlý, režie vynaložená na volání a převzetí výsledků funkce je výrazně pomalejší než u optimalizovaného dotazu PreparedStatement. Z toho tedy vyplývá, že i přes zlepšení času není vhodné upřednostnit funkci v databázi ORACLE před připraveným dotazem. 312

7 7.3 Vyhodnocení testů Testy prokázaly, že stanovené předpoklady časové úspory SQL dotazů s využitím dynamických pohledů byly správné. Na obrázku 4 je zobrazen graf, který demonstruje postupné zrychlování SQL dotazů s využitím operátoru SDO_NN pomocí dílčích optimalizací. Rovněž je z obrázku patrné, že využívání SQL dotazu typu Statement výrazně zaostává za dotazy s optimalizací. V rámci demonstrační aplikace InfraRAIL je implementováno jádro diskrétní simulace, které umožňuje simulaci pohybu KV v modelu ŽS. Pro vizualizaci je využita technologická nadstavba MapViver, která umožňuje na základě prostorových dat z databáze vytvářet mapové vrstvy. V další části se článek zabývá optimalizací SQL dotazů, které jsou využívány pro vyhledání aktuální polohy KV na vrženém modelu ŽS. Mimo standardních druhů optimalizace je navržena optimalizace pomocí dynamických pohledů. V rámci testování bylo poukázáno na významnost dotazů s vázanými proměnnými a jejich následná časová úspora. Optimalizace pomocí dynamických pohledů přinesla další časové zrychlení SQL dotazů. Je však nutné podotknout, že toto zrychlení je významnější především v případě většího množství aktivních vlaků (cca více než 100) s nižší periodou dotazování na aktuální polohu KV (cca do 10 sekund). V těchto případech je vhodná kombinace techniky připraveného dotazu PreparedStatement a dynamického pohledu 40x20 km, případně 50x50 km (nižší potřeba realokace nového pohledu). Tím dojde k zrychlení celé aplikace o celé sekundy. Navržená a otestovaná optimalizace pomocí dynamických pohledů byla implementována do stávající demonstrační aplikace InfraRAIL. Obrázek 4: Graf srovnání jednotlivých optimalizací Tyto poznatky byly následně zakomponovány do demonstrační aplikace pro lokalizaci kolejových vozidel InfraRAIL. Vizualizace softwarového demonstrátoru s využitím dynamických pohledů v rámci modelu železniční sítě je znázorněno na obrázku 5. 8 Závěr Obrázek 5: Vizualizace dynamických pohledů Tento článek se věnuje lokalizaci kolejových vozidel na železniční síti. V úvodní části se článek stručně zaměřuje na popis existujících systémů umožňující lokalizaci ve třech rovinách dle využívaných technických prostředků. Dále se článek věnuje lokalizaci KV s využitím technologie GNSS. Je popsán návrh modelu železniční sítě, jehož základ tvoří neorientovaný graf vybudovaný přímo v databázi ORACLE. Literatura: [1] HLOUŠEK, P. Úvod do problematiky návrhu a schvalování elektronických zabezpečovacích zařízení dle nových evropských norem. In: Vědeckotechnický sborník ČD [online] [cit ]. ISBN Dostupné z: [2] FIKEJZ, J.; KAVIČKA, A. Rolling Stock Localization Within the Model of Railway Infrastructure. In: Proceedings of Third International Conference on Computer Modelling and Simulation, Brno, CZ, FIT VUT, 2012, s , ISBN \ [3] FIKEJZ, J. Možnosti lokalizace kolejových vozidel v železniční síti. Elektrorevue [online]. 2012, 2012/47, [cit ]. ISSN Dostupný z WWW: 1/0/moznosti-lokalizace-kolejovych-vozidel-vzeleznicni-siti/ [4] BECKER, U., POLIAK, J. DEMOORT repositions trains with satellite. In: EURAILmag Business & Technology. 18. vyd. BLUE LINE & Bro, France, s [5] Technický popis systému EGNOS. Odbor kosmických technologií a družicových systémů [online]. [cit ]. Dostupné z: sekce/egnos/technicky-popis-systemu-egnos/ [6] LIESKOVSKÝ, A., MYSLIVEC, I., ŠPAEK, P. ETCS a AVV - bezpečně a hospodárně. Sborník 3. konference 313

8 Moderní technologie a diagnostika v železniční telekomunikační a zabezpečovací technice, České Budějovice, 2007 [7] CHUDAČEK, V., LOCHMAN, L. Vlakový zabezpečovací systém ERTMS/ETCS in Vědeckotechnicky sborník ČD, č. 5/1998 [8] FIKEJZ, J., KAVIČKA, A. Utilisation of computer simulation for testing additional support for dispatching rail traffic. In The European Simulation and Modelling Conference Gent : Reproduct nv, 2011, s ISBN [9] MURRAY, Ch, et al. ORACLE Fusion Middleware : User s Guide for ORACLE MapViewer 11g Release 1 (11.1.1) [online] [cit ]. Dostupné z: 45.pdf [10] FIKEJZ, J., KAVIČKA, A. Modelling and simulation of train positioning within the railway network. In: KLUMPP, Matthias. ESM'2012. The European simulation and modelling conference. Ostende: EUROSIS - ETI, 2012, s ISBN [11] FIKEJZ, J. Možnosti lokalizace kolejových vozidel v železniční síti. Elektrorevue [online]. 2012, 2012/47, [cit ]. ISSN Dostupný z WWW: 1/0/moznosti-lokalizace-kolejovych-vozidel-vzeleznicni-siti/ 314