Rok / Year: 2013
Svazek / Volume: 15
Číslo / Issue: 5
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
[email protected] 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.
VOL.15, NO.5, OCTOBER 2013
Lokalizace kolejových vozidel s vyžitím technologie ORACLE Spatial a dynamických pohledů Jan Fikejz Fakulta elektrotechniky a informatiky Univerzita Pardubice Email:
[email protected]
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ů.
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]:
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í.
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
VOL.15, NO.5, OCTOBER 2013 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:
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ŽDCTUDC bylo vyhodnoceno, že pro návrh reprezentace železniční sítě postačují čtyři následující tabulky dat:
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.
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
Vizualizační vrstva Vizual-mikro Vizual-mezo
Data-makro Vizual-makro Obrázek 2: Model infrastruktury železniční sítě 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. 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í.
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
VOL.15, NO.5, OCTOBER 2013 Ilustrativní zobrazení segmentu modelu ŽS na úrovni mezovrstvy je zobrazena na obrázku 3.
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:
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.
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
48701
50.02274
15.33554
78
57
91547123022
14.02.11 04:34:25
48701
50.02654
15.34246
80
43
91547123022
14.02.11 04:34:55
48701
50.03077
15.34873
68
43
91547123022
14.02.11 04:35:25
48701
50.03495
15.35505
61
45
91547123022
14.02.11 04:35:55
310
VOL.15, NO.5, OCTOBER 2013 3.
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 aktuálního pohledu.
prováděny
do
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.
tohoto
311
VOL.15, NO.5, OCTOBER 2013 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: v sekundách Technika dotazu
Porovnání
časů
různých
technik
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
dotazů
Statement
Prepared Statement
Průměr
0,120897181
0,009185022
0,012439586
Min
0,059907
0,003553000
0,004768000
Max
3,28629
1,640714
1,607601
Medián
0,0994355
0,006620500
0,009731500
Modus
0,066694
0,004035000
0,010057
Odchylka
0,115109118
0,052007543
0,051450222
Celkový čas
120,897181
9,185022
12,439586
Celkový čas v Javě
195,717063164
53,824611413
60,935994212
Velikost pohledu Průměr
Oracle funkce
50x50
0,007474627
0,007914767
Min
0,003082
0,003242
0,003108
Max
1,370451
1,354342
1,568563
Medián
0,0052415
0,005647
0,005894
Modus
0,003895
0,005491
0,004772
0,043302936
0,0427506
0,049460025
7,312738
7,474627
7,914767
51,351476774
54,835111842
59,058458159
Celkový čas Celkový čas v Javě
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.
40x20
0,007312738
Odchylka
7.2 Optimalizace pomocí dynamických pohledů
10x10
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
Tabulka 3: Časy dotazů PreparedStatement nad pohledy různých velikostí v sekundách
Metodapohled
Oracle funkce 40x20
Průměr
0,007475
0,007537
PreparedStatement 40x20
Velikost pohledu
10x10
40x20
50x50
Min
0,003242
0,002815
Průměr
0,007647564
0,007537129
0,007978
Max
1,354342
1,157581
Min
0,002743
0,002815
0,003319
Medián
0,005647
0,005347
Max
1,454968
1,157581
1,261327
Modus
0,005491
0,003494
Medián
0,0049415
0,005347
0,006121
Odchylka
0,0427506
0,036910
Modus
0,004397
0,003494
0,004287
Celkový čas
7,4746270
7,537129
0,046213794
0,03691007
0,039899127
Celkový čas
7,647564
7,537129
7,977629
Celkový čas v Javě
54,835112
39,70152
Celkový čas v Javě
39,759844446
39,70151928
40,368371538
Odchylka
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.
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
VOL.15, NO.5, OCTOBER 2013 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.
Literatura: Obrázek 4: Graf srovnání jednotlivých optimalizací
[1] HLOUŠEK, P. Úvod do problematiky návrhu a
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.
[2]
[3]
Obrázek 5: Vizualizace dynamických pohledů
[4]
8 Závěr 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.
[5]
[6]
313
schvalování elektronických zabezpečovacích zařízení dle nových evropských norem. In: Vědeckotechnický sborník ČD [online]. 2010 [cit. 2013-10-04]. ISBN 1214-9047. Dostupné z: http://www.cdrail.cz/vts/CLANKY/1003.pdf 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. 80-85, ISBN 978-80-214-4576-5\ FIKEJZ, J. Možnosti lokalizace kolejových vozidel v železniční síti. Elektrorevue [online]. 2012, 2012/47, [cit. 2013-02-28]. ISSN 1213-1539. Dostupný z WWW: http://www.elektrorevue.cz/ëcz/clanky/ostatni1/0/moznosti-lokalizace-kolejovych-vozidel-vzeleznicni-siti/ BECKER, U., POLIAK, J. DEMOORT repositions trains with satellite. In: EURAILmag Business & Technology. 18. vyd. BLUE LINE & Bro, France, s. 216219. Technický popis systému EGNOS. Odbor kosmických technologií a družicových systémů [online]. [cit. 201204-22]. Dostupné z: http://www.spacedepartment.cz/3sekce/egnos/technicky-popis-systemu-egnos/ LIESKOVSKÝ, A., MYSLIVEC, I., ŠPAEK, P. ETCS a AVV - bezpečně a hospodárně. Sborník 3. konference
VOL.15, NO.5, OCTOBER 2013 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 2011. Gent : Reproduct nv, 2011, s. 225-231. ISBN 978-90-77381-66-3. [9] MURRAY, Ch, et al. ORACLE® Fusion Middleware : User’s Guide for ORACLE MapViewer 11g Release 1 (11.1.1) [online]. 2010 [cit. 2012-07-09]. Dostupné z: http://docs.ORACLE.com/cd/E14571_01/web.1111/e101 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. 366 -376. ISBN 978-907738173-1 [11] FIKEJZ, J. Možnosti lokalizace kolejových vozidel v železniční síti. Elektrorevue [online]. 2012, 2012/47, [cit. 2013-02-28]. ISSN 1213-1539. Dostupný z WWW: http://www.elektrorevue.cz/ëcz/clanky/ostatni1/0/moznosti-lokalizace-kolejovych-vozidel-vzeleznicni-siti/
314
