Fakulta stavební. Obor: Geoinformatika. Vývoj NTRIP Casteru

České vysoké učení technické v Praze Fakulta stavební Katedra vyšší geodézie Obor: Geoinformatika Vývoj NTRIP Casteru DIPLOMOVÁ PRÁCE Vypracoval: Luboš Truhlář Vedoucí práce: Ing. Zdeněk Lukeš, Ph.D. Rok: 2012

Před svázáním místo téhle stránky vložíte zadání práce s podpisem děkana (bude to jediný oboustranný list ve Vaší práci)!!!!

Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady (literaturu, projekty, SW atd.) uvedené v přiloženém seznamu. V Kralupech nad Vltavou dne 13.5.2012... Luboš Truhlář

Poděkování Děkuji Ing. Zděnku Lukešovi, Ph.D. za jeho vedení při tvorbě této diplomové práce, za jeho nápady a připomínky, které ji obohatily, a za jeho pomoc při tvorbě samotné aplikace. Dále, jak je dobrým zvykem, děkuji své rodině a přátelům, kteří mi poskytli nezbytnou podporu během celého studia. Luboš Truhlář

Název práce: Vývoj NTRIP Casteru Autor: Obor: Druh práce: Luboš Truhlář Geoinformatika Diplomová práce Vedoucí práce: Ing. Zdeněk Lukeš, Ph.D. Katedra vyšší geodézie, Fakulta stavební, České vysoké učení technické v Praze Konzultant: Abstrakt: Tato diplomová práce je zaměřena na návrh a implementaci serverové aplikace NTRIP Caster. Práce se rovněž věnuje důvodům vzniku protokolu NTRIP, jeho použití v praxi a detailnímu popisu, jak z pohledu klienta, tak serveru. Dále se práce zaměřuje na implementaci protokolu v nově vzniklé serverové aplikaci NTRIP Caster. Aplikace je detailně popsána z uživatelského i programátorského pohledu. Čtenář je rovněž seznámen s výsledky testování aplikace zaměřené na použitelnost aplikace v praxi a na její výkonnostní parametry. Klíčová slova: NTRIP, Caster, GPS, C++, QT, RTCM, DGPS Title: Development of NTRIP Caster Author: Luboš Truhlář Abstract: This diploma thesis is focused on development of server application NTRIP Caster. The thesis applies on reasons for development of NTRIP protocol, its usage in practice and detail description from client side and server side. Additionally this thesis is focused on implementation of NTRIP protocol in new server application NTRIP Caster. The application is described to the detail from user side and from development side also. Readers are introduced with testing results focused on usability of application in real environment and on its performance parameters. Key words: NTRIP, Caster, GPS, C++, QT, RTCM, DGPS

Obsah 1 Úvod 1 2 Globální družicové polohové systémy 4 2.1 Struktura GNS systémů.............................. 5 2.1.1 Kosmický segment............................. 5 2.1.2 Řídicí a monitorovací segment....................... 6 2.1.3 Uživatelský segment............................ 7 2.2 Princip fungování GNSS.............................. 8 2.2.1 Základní vlastnosti............................. 8 2.2.2 Rádiový signál............................... 9 2.2.3 Kódová měření............................... 11 2.2.4 Fázová měření............................... 12 2.2.5 Chyby a parametry ovlivňující přesnost určení polohy......... 14 2.2.6 Diferenční měření.............................. 16 2.3 CZEPOS...................................... 19 3 NTRIP protokol 20 3.1 Networked Transport of RTCM via Internet Protocol.............. 20 3.2 Základní funkcionalita............................... 21 3.3 Prvky systému NTRIP............................... 23 3.3.1 NTRIP Source............................... 23 3.3.2 NTRIP Server............................... 23 3.3.3 NTRIP Caster............................... 23 3.3.4 NTRIP Client............................... 24 3.4 Komunikace NTRIP Server - NTRIP Caster................... 24 3.5 Komunikace NTRIP Client - NTRIP Caster................... 26 3.6 Source-table..................................... 30 4 Aplikace 35 4.1 Aplikace K152 Caster............................... 36 4.1.1 Základní funkce K152 Casteru...................... 36 4.1.2 Spuštění K152 Casteru........................... 37 4.2 K152 GUI...................................... 38 4.2.1 Základní funkce K152 GUI........................ 39 4.2.2 Spuštění K152 GUI............................ 39 4.2.3 Popis aplikace K152 GUI......................... 41 vi

4.3 Pluginovací systém................................. 50 4.4 Další aplikace.................................... 51 4.4.1 VirtualClient................................ 51 4.4.2 VirtualGenerator.............................. 52 4.5 Komunikace Caster - GUI............................. 52 4.6 Databáze...................................... 55 4.6.1 Konfigurace MySQL............................ 56 4.6.2 Popis databázových tabulek........................ 56 5 Testování 69 5.1 Test komunikace s reálnými klienty........................ 69 5.2 Test zpoždění dat v Casteru............................ 70 5.3 Test zpoždění RTK................................. 70 5.4 Test maximálního počtu připojujících se klientů................. 71 5.5 Zátěžový test.................................... 72 6 Závěr 74 Seznam použitých zdrojů 75 Obsah vii

Kapitola 1 Úvod Je to již několik let, co Spojené Státy Americké vypnuly selektivní dostupnost, neboli umělé rušení GPS 1 signálu. Do té doby převážně vojensky užívaný systém se stal použitelný pro všechny lidi na celé planetě a stal se postupně výborným pomocníkem řadě profesí od lesníků po geodety. Toto umělé rušení, nazývané anglicky Selective Availability (zkr. SA), způsobovalo při měření chyby v řádu desítek až stovek metrů. Armáda USA a další vybrané instituce vlastnily kódy, díky kterým bylo možné vyhnout se tomuto umělému rušení. GPS (oficiální název NAVSTAR GPS) není jediný globální polohovací systém, který známe. Své GNSS 2 mají i další země jako Rusko, Čína nebo Evropská unie, která prozatím tento systém buduje. GPS je nejpoužívanější a nejznámější, proto se budeme převážně zabývat tímto systémem. S příchodem turistických navigací, navigací do automobilů a mobilních telefonů s GPS přijímači, zažil systém GPS doslova uživatelský boom. Díky těmto produktům jsou dnes na světě milióny uživatelů GPS systému. Málokdo z nich však ví, že absolutní přesnost určení jejich polohy pomocí GPS může dosahovat chyby i v řádu desítek metrů. Není se čemu divit. Většině lidí tato přesnost naprosto dostačuje a navíc moderní aplikace dokáží tuto chybu před uživateli skrýt (například program v auto-navigaci umístí automobil vždy na nejbližší silnici, i když GPS měření ukazuje polohu automobilu mimo silnici). Proto si uživatel ani tuto chybu v určení jeho polohy nemusí uvědomit. Na druhou stranu, pro řadu profesí je metrová přesnost běžného měření nedostačující a potřebují měření o několik řádů lepší. Nejlépe s přesností na centimetry, respektive milimetry. I měřením pomocí GPS je možné dosáhnout takovéto přesnosti. K tomu je ale zapotřebí měření pomocí lepších GPS přijímačů a použití jiných metod měření. 1 Global Positioning System, zkráceně GPS, je vojenský globální družicový polohový systém provozovaný Ministerstvem obrany Spojených států amerických, s jehož pomocí je možno určit polohu a přesný čas kdekoliv na Zemi nebo nad Zemí 2 Global Navigation Satellite System - globální (celosvětový) polohovací satelitní systém 1

K určení takto přesné polohy je potřeba provádět takzvaná diferenciální měření, která v nejjednodušším případě spočívají v současném měření na dvou místech. Na jednom místě musíme znát přesné souřadnice (zjištěné předcházejícími měřeními) a na místě druhém (nepříliš vzdáleném místu prvnímu) provádíme měření. Zjednodušeně můžeme říci, že chyby měření na prvním i druhém místě jsou stejné a tedy, když známe polohu prvního místa přesně, jsme schopni zavést určité korekce, které nám pomohou určit přesněji i polohu místa druhého. Tyto korekce je nutné přenést z prvního místa na druhé a je potřeba, aby přijímač těmto korekcím rozuměl a dokázal si tak díky nim svoji polohu opravit. Protože žijeme v době internetu a připojení na tuto celosvětovou sít je již dostupné téměř odkudkoliv, nabízí se distribuování korekcí po internetu. Aby byla zajištěna spolupráce přijímačů od všech výrobců s dalšími prvky systému, byly zavedeny takzvané standardy (v elektronické komunikaci se používá spíše termín protokoly). Pro nás nejdůležitější jsou v této oblasti dva standardy - formát RTCM 3 a protokol NTRIP 4. Protokol RTCM popisuje formát GNSS korekcí, se kterým by měly umět pracovat všechny GNSS přístroje umožnující real-time 5 zpracování dat. Protokol NTRIP popisuje celý systém distribuce těchto korekcí a vzájemnou komunikaci jednotlivých prvků v systému. Tyto protokoly se většinou užívají společně (skrze komunikační protokol NTRIP jsou distribuována data ve formátu RTCM), ale nemusí to být nutně pravidlem. NTRIP protokolem mohou být šířeny korekce různých formátů a dokonce i jakákoliv jiná data (binární atd.). NTRIP protokol popisuje a rozděluje systém distribuce dat na čtyři části. První částí je zdroj dat, tzv. NTRIP Source, který je, jak název napovídá, zdrojem GNSS korekcí. Tento prvek je spojen s NTRIP serverem, který má za úkol korekce doručit do NTRIP Casteru. NTRIP Caster je klíčovým prvkem v tomto systému a stará se jak o příjímání dat z NTRIP serverů, tak i o rozesílání dat NTRIP klientům. NTRIP Caster musí být konfigurovatelný, spolehlivý a snadno ovladatelný. Musí poskytovat další řadu funkcí, nejen přijímání a distribuci dat, ale například musí umožnit i správu uživatelů, poskytovat statistiky týkající se klientů i serverů a měl by umožnit monitorování jednotlivých spojení nebo datových přenosů. Cílem této práce bylo navrhnout a hlavně realizovat NTRIP Caster, který by všechny zmíněné funkce poskytoval. Základem bylo umožnit administrátorovi Casteru jeho správu v přehledné a uživatelsky přívětivé GUI 6 aplikaci, která dokáže s Casterem komunikovat po 3 RTCM je název komise The Radio Technical Commission for Marine Services, která vytvořila několik protokolů, mimo jiné i protokol nazývaný RTCM Standart 10403.1 Differential GNSS Services - version 3, který se zkráceně označujeme RTCM 3. V tomto protokolu je popsán formát korekcí. O tomto formátu poté hovoříme jako formát RTCM. Verzí protokolu RTCM existuje celá řada - 2.0, 2.1, 3.0. Tato komise vydala například i protokol NTRIP. 4 Networked Transport of RTCM via Internet Protocol byl vyvinut pod patronací Německé Bundesamt für Kartographie und Geodesie na počátku 21. století. 5 Zpracování měření a korekcí v reálném čase. Přístroj přijímá korekce během měření a rovnou je aplikuje. 6 Grafické uživatelské rozhraní 2

síti a nemusí být na stejném počítači jako vlastní NTRIP Caster. Hlavně tímto přístupem se liší K152 Caster od jiných Casterů volně dostupných na internetu. Většina takovýchto Casterů neposkytuje GUI administrátorské rozhraní, ale pouze ovládání přes příkazovou řádku nebo přes konfigurační soubory. 3

Kapitola 2 Globální družicové polohové systémy Již od pradávna bylo jedním z hlavních problémů člověka určování jeho polohy a s tím spojená navigace do cílového místa. Při tažení armád krajinou, při obchodních cestách na moři, vždy bylo nutné vědět, kde se člověk nachází a jakým směrem má pokračovat. Lidé k těmto účelům postupem času vynalezli mnoho způsobů. Od těch nejprimitivnějších v podobě určování severu pomocí lišejníků, až po velice důmyslné, jako je například měření hvězd pomocí astrolábů. K těmto účelům začal s postupem času vývoj prvního globálního družicového polohového systému. Globální družicový polohový systém je systém družic a dalších objektů, umožnující určení polohy kdekoliv na Zemi, případně i v blízkém okolí Země. Do skupiny GNSS jsou často řazeny i tzv. regionální navigační družicové systémy, které fungují jen nad určitou částí Země a které jsou také většinou předchůdci budoucích plnohodnotných GNSS. Pro představu seznam nejznámějších družicových polohovacích systémů, jejich země původu a typ: Transit - USA - již nefunkční Cikada - SSSR - již nefunkční Doris - Francie - globální NAVSTAR GPS - USA - globální GLONASS - Rusko - globální Compass (dříve Beidou) - Čína - globální Galileo - Evropská Unie - globální 4

QZSS - Japonsko - regionální IRNSS - Indie - regionální Dále se budeme převážně zabývat systémem GPS, případně systémem GLONASS. Obecné principy a vlastnosti jsou však společné pro všechny systémy. 2.1 Struktura GNS systémů Družicové polohové systémy se skládají ze tří hlavních segmentů: kosmický segment - družice řídící segment - pozemní stanice uživatelský segment - přijímače 2.1.1 Kosmický segment Kosmický segment GNSS se skládá z několika desítek družic. V případě systému GPS je nutné, aby na oběžné dráze Země bylo minimálně 24 družic. Poté je možné vyhlásit tzv. FOC 1. Družice se pohybují po předem určených drahách. V každém okamžiku je tak známa poloha každé družice. V důsledku různých vlivů se družice postupem času od této predikované dráhy vychylují. Toto vychýlení družice je jednou z chyb, která může ovlivňovat výslednou přesnost určení polohy. Obrázek 2.1: Ilustrace jednotlivých segmentů GPS systému. Zdroj: www.gps.gov 1 Full Operational Capability - plná operační schopnost. 5

2.1.2 Řídicí a monitorovací segment Do tohoto segmentu patří pozemní stanice rozmístěné po celé Zemi. Jejich hlavním úkolem je monitorování a řízení družic. Stanice se obecně dělí na tři druhy: Monitorovací stanice jsou rozmístěny po celé Zemi tak, aby dokázaly monitorovat co největší počet družic po co nejdelší dobu. Jejich úkolem je přijímat signál, který družice vysílají, a předávat data do hlavní řídicí stanice. Hlavní řídicí stanice zpracovává data od monitorovacích stanic, na jejichž základě vypočítává nové efemeridy 2 družic, korekce atomových hodin a korekce pro atmosférické vlivy. Tyto korekce se poté předávají komunikačním stanicím. Komunikační stanice jsou většinou totožné s monitorovacími stanicemi. Vysílají družicím korekce přijaté od hlavní stanice. Družice si upraví na jejich základě údaje o vlastní poloze a čase, které následně vysílají. Tyto informace (spolu s korekcemi pro atmosférické vlivy) vysílají ve své navigační zprávě. Hlavními úkoly řídícího segmentu je tedy správa a monitoring kosmického segmentu. Řídicí segment se stará o aktualizaci informací o poloze a čase na jednotlivých družicích. Řídicí segment je nezbytnou součástí každého GNSS. Obrázek 2.2: Rozmístění stanic GPS systému. Zdroj: www.gps.gov 2 Efemeridy družice jsou informace potřebné k výpočtu polohy, rychlosti a zrychlení družice 6

2.1.3 Uživatelský segment Uživatelský segment je tvořen všemi uživateli a přijímači. Rozdělení uživatelského segmentu můžeme provést na základě několika kritérií: Podle přístupu k datům: autorizovaní uživatelé mají přístup i k datům umožnujícím přesnější určení polohy neautorizovaní uživatelé mohou využívat pouze část dat vysílaných družicemi Podle počtu kanálů zpracovávaných přijímači: jednokanálové vícekanálové Podle způsobu určení polohy: kódová fázová a kódová Obrázek 2.3: Přijímač GPS (zjednodušené blokové schéma). Běžný uživatelský přijímač GPS signálu, který je dnes například součástí mobilního telefonu nebo navigace do automobilu, je jednofrekvenční, vícekanálový a využívá kódových 7

měření k výpočtu polohy. V případě dobré viditelnosti družic se přesnost měření pomocí tohoto GPS přijímače pohybuje kolem 10 metrů. Přijímač obvykle tvoří následující bloky (viz. obrázek 2.3): anténa a bloky anténní elektroniky rádiová část přijímače navigační počítač řídící a zobrazovací jednotka 2.2 Princip fungování GNSS 2.2.1 Základní vlastnosti GNS systémy fungují v jednoduchosti na základě následujícího principu: 1. Družice vysílají k Zemi rádiový signál obsahující informace o jejich poloze a časovou značku vyslání signálu. 2. Určení polohy objektu na Zemi se provádí na základě změření vzdáleností objektu od družic. Obrázek 2.4: Ukázka měření na tři družice a možná poloha přijímače (průnik kulové plochy a kružnice - 2 body). Zdroj: [12, Rapant, 2002] 8

3. Vzdálenost od družice je vypočtena na základě rozdílu času vyslání signálu a jeho příjmu. Rychlost signálu je známou veličinou. 4. Poloha je následně vypočtena jako průnik několika kružnic viz. obr. 2.4. 2.2.2 Rádiový signál Výsledný rádiový signál, který družice vysílají, vznikne modulováním základní nosné vlny družice dálkoměrným kódem a navigační zprávou. Základní frekvence nosných vln jsou odvozeny od frekvence atomových hodin na palubě družice. To zaručuje dobrou stabilitu signálu. Přijímač radiového signálu musí být schopen rozlišit, která družice signál vyslala. Toto rozlišení se provádí dvěma způsoby. Družice systému GPS a Galileo vysílají na stejných frekvencích a k rozlišení jednotlivých družic používají tzv. PRN 3 kódy, které je přijímač schopen rozpoznat a odfiltrovat signál ostatních družic. V případě systému GLONASS vysílá každá družice na vlastní frekvenci, která je jen málo odlišná od frekvence základní, kterou má systém GLONASS odlišnou od systémů GPS a Galileo. Obrázek 2.5: Schéma modulace signálu GPS. Zdroj: gmat.unsw.edu.au 3 Pseudorandom Noise Code - pseudonáhodný fázový šum, unikátní pro každou družici. 9

Nosné vlny systému GPS: L1 - (1575,42 Mhz) L2 - (1227.60 MHz) L5 - (1176.45 MHz) - pro letectví a dopravu Nosné vlny jsou modulovány následujícími kódy: C/A kód, kterým je modulována nosná vlna L1 (označení L1 C/A) C kód, kterým je modulována nosná vlna L2 (označení L2 C) P(Y)kód, k tomuto kódu mají přístup jen autorizovaní uživatelé. Tímto kódem jsou modulovány nosné vlny L1 a L2 (označení L1 P(Y) a L2 P(Y)) M kód - vojenský kód, kterým jsou modulovány vlny L1 a L2 Vysílání jednotlivých druhů GPS signálu je závislé na typu družice. Starší družice vysílají pouze část z uvedených signálů. V plánu je další modernizace družic a rozšíření například o signál L1C, který by měl být společný pro systémy GPS a Galileo. Nosné vlny systému Glonass a základní frekvence: L1 - (1602 MHz) L2 - (1246 MHz) L3 - (1202 MHz) V případě systému GLONASS rozlišujeme pouze dva fungující kódy: C/A kód, kterým je modulována nosná vlna L1 a L2 (označení L1 C/A a L2 C) P kód, k tomuto kódu mají přístup jen autorizovaní uživatelé. Tímto kódem jsou modulovány nosné vlny L1 a L2 Kosmický segment systému GLONASS je také neustále modernizován a doplňován dalšími družicemi. Teprve v roce 2012 bylo poprvé na orbitu současně 24 družic nutných k plnému fungování systému po celé Zemi. 10

Navigační zpráva Navigační zpráva je vlastně další kód, kterým je modulována vlna, kterou vysílá družice směrem k Zemi. Navigační zpráva obsahuje tyto základní informace: Efemeridy družice jsou informace potřebné k výpočtu polohy, rychlosti a zrychlení družice. Družice je získá z komunikačních stanic řídícího segmentu. Čas vysílání navigační zprávy. Koeficienty ionosférického modelu jsou údaje popisující stav ionosféry. Přijímač je na jejich základě schopen odhadnout vliv chyby ionosféry na měření. Používají se pouze v případě jednofrekvenčního měření. Družice je získá z komunikačních stanic řídicího segmentu. Almanach je soubor dat obsahující informace o všech družicích v systému, jejich predikované dráhy a stav. Stav družice informuje uživatele o funkčnosti družice. Zda je možné družici používat pro měření. Obrázek 2.6: Struktura navigační zprávy GPS signálu. Zdroj: www.aldebaran.cz 2.2.3 Kódová měření Podívejme se na rovnici 2.1, kde c je rychlost světla, t i je čas vyslání signálu z družice a t k je čas přijímače při přijetí signálu. Tato rovnice určuje vztah pro výpočet vzdálenosti mezi přijímačem a družicí. Tento vztah je zatížen mnoha chybami a proto hovoříme o pseudovzdálenosti. Mezi největší chyby patří chyba hodin přijímače, kterou zahrneme do výpočtu jako čtvrtou neznámou spolu se souřadnicemi přijímače. Aby bylo možné tyto čtyři neznámé vypočítat, je nutné pozorovat současně nejméně čtyři družice. 11

ρ i k = c(t k t i ) (2.1) Poté, co je signál zachycen anténou, přijímač rozliší, ze které družice byl signál vyslán. Zpravidla se použije C/A kódu, který je pro každou družici charakteristický. Měření pseudovzdálenosti proběhne zhruba následovně: přijímač pomocí oscilátoru vygeneruje referenční vlnu, kterou moduluje známým PRN kódem družice. Takto vygenerovanou vlnu koreluje s vlnou přijatou a korelace poskytne rozdíl času t k t i. [8, Mervart, 1997] Uved me pro přehled rovnici (2.2) pozorování pro kódová měření. P i F k = ρi k + cδ k cδ i + I i k + ρi k (2.2) ρ i k - geometrická vzdálenost přijímače a družice δ k - chyba hodin přijímače δ i - chyba hodin družice I i k ρ i k - oprava z vlivu ionosférické refrakce - oprava z vlivu troposférické refrakce Kódová měření jsou jednoduchá, rychlá a spolehlivá. Používají je všechny běžné (levné) GPS přijímače. Při dobré viditelnosti a konstelaci družic se dá dosáhnout přesnosti v řádu metrů. 2.2.4 Fázová měření Fázová měření jsou založena na stejném principu jako určování vzdálenosti elektrooptickými dálkoměry. Fázová měření nevyužívají k určení polohy kódy vysílané družicemi, ale měří jako klasické elektrooptické dálkoměry na samotné vlně vyslané družicí. Rádiová vlna, která je vyslaná družicí, má frekvenci f, od níž se odvíjí vlnová délka λ, viz. vzorec 2.3. λ = c f (2.3) Rovnice pozorování pro fázová měření - rovnice 2.4. L i F k = ρi k + cδ k cδ i + I i k + ρi k + λ F n i F k (2.4) n i F k - počáteční fázová ambiguita 12

Vzdálenost přijímače od družice je součtem celých vlnových délek, které vlna urazila a tzv. doměrku (desetinné části vlnové délky). Viz. schéma na obrázku 2.7. Obrázek 2.7: Znázornění vlnové délky a doměrku. Jakmile přijímač zachytí rádiovou vlnu, je schopen poměrně přesně určit její fázový posun oproti referenční vlně generované v přijímači, z čehož se dá určit výše zmíněný doměrek. Zbývá tedy určit celý počet vln mezi družicí a přijímačem. Říkáme, že fázová měření vykazují určitou s měření, označované spíše anglickým termínem ambiguity. K vyřešení ambiguit existuje celá řada matematických metod. Jednou z nejpoužívanějších metod pro zpřesnění fázových měření se stala metoda RTK 4, jejíž součástí je i metoda pro určování ambiguit. RTK je metoda, kdy blízká referenční stanice o známých souřadnicích poskytuje svá měření a vypočtené korekce a přijímač je schopen na jejich základě přesněji určit svoji polohu. Stanice vysílají tato data rádiovými vlnami nebo po internetu. Data bývají ve formátu RTCM a v případě distribuce přes internet se používají ke komunikaci protokol NTRIP. Protokol NTRIP je blíže popsán v kapitole 3. Jakmile dojde k zafixování (vyřešení ambiguity), přijímač je dále schopen snadno a přesně určovat další změny v počtu vlnových délek i fázového posunu. Je možné s přijímačem například i pohybovat bez ztráty přesnosti. Fázová měření jsou závislá na dobré stabilitě signálu. Při jakémkoliv výpadku signálu dojde ke ztrátě informace o počtu vlnových délek mezi družicí a přijímačem a celý proces fixování musí začít znovu. Hlavní nevýhodou fázových měření oproti kódovým, je jejich časová náročnost a nutnost použití speciálních a drahých měřících přístrojů. Na druhou stranu jejich výhodou je mnohem 4 Real Time Kinematic 13

větší přesnost měření, která se může pohybovat i v řádu milimetrů. 2.2.5 Chyby a parametry ovlivňující přesnost určení polohy Všechna měření jsou ovlivněna určitými chybami. Nejinak to je i v případě měření pomocí GNSS. Blíže si popíšeme všechny chyby ovlivňující GNSS měření. 1. Chyba vzdálenosti Ovlivňuje kódová i fázová měření. Je způsobena nepřímou trajektorií signálu. Signál neletí nejkratší cestou od družice k přijímači, ale tou nejrychlejší. V případě kódových i fázových měření má chyba za následek nepřesné určení vzdálenosti od družice. Relativní hodnota této chyby dosahuje 1 % - 2 % vlnové délky. Tato chyba se nedá žádným způsobem eliminovat, ale její velikost je natolik malá, že se v praxi neuvažuje. Obrázek 2.8: Příklad vlivu ionosféry a troposféry na dráhu signálu. 2. Chyba v poloze družice Ovlivňuje kódová i fázová měření. Protože určujeme polohu přijímače na základě vzdálenosti od družice, projevuje se chyba v poloze družice v plné míře na určení polohy přijímače. 14

Chyba může dosahovat až 2 metrů. Chyba se dá eliminovat diferenciálním měřením nebo pomocí RTK. 3. Chyba hodin družice Ovlivňuje kódová i fázová měření. Chyba může dosahovat velkých hodnot až v řádu metrů. Tato chyba se dá eliminovat diferenciálním měřením nebo pomocí RTK. 4. Atmosférické vlivy Ovlivňují kódová i fázová měření. Způsobují zpomalování šíření signálu z družice. Tyto chyby jsou větší pro družice nízko nad obzorem (kvůli delšímu průchodu signálu atmosférou) a menší pro družice vysoko nad obzorem. Jedná se hlavně o působení ionosféry a troposféry. Vlivy ionosféry jsou poměrně homogenní v rámci jedné oblasti. Vlivy troposféry jsou hodně nahodilé. Tyto chyby mohou dosahovat až stovek metrů. GPS signál obsahuje ve svém kódu korekci pro ionosférické vlivy. Tyto korekce jsou průběžně aktualizovány pozemním segmentem. Zároveň existuje spousta služeb, poskytující tyto korekce (např. IGS 5 nebo GEISS 6 ). Ionosférické chyby lze eliminovat měřením na více frekvencích, diferenciálním měřením nebo pomocí RTK. 5. Multipath 7 Ovlivňuje kódová i fázová měření. Kódová měření jsou touto chybou ovlivněna mnohem více než fázová měření. Dochází k odrazu signálu od objektů kolem přijímače. Signál neputuje do přijímače nejkratší cestou. Může způsobovat chyby v řádu metrů (kódová měření), centimetrů (fázová měření). Chyby se dají eliminovat vhodným umístěním antény, typem antény, případně jejím speciálním tvarem. 5 International GPS Service for Geodynamics - Mezinárodní GPS služby pro geodynamiku 6 GPS Ephemeris & Ionospheric Correction Sharing Service 7 vícecestné šíření signálu - signál se šíří všemi směry a odráží se 15

Obrázek 2.9: Znázornění multipath efektu při šíření signálu. Zdroj: geosoft-gps.de Dilution of Precision Výsledná chyba určení polohy je rovněž ovlivněna rozmístěním družic na obloze. Tento vliv na výsledek měření je označován DOP 8. DOP je rozdělen na dílčí složky - vertikální (VDOP), horizontální (HDOP), časový (TDOP), geometrický (GDOP). Více informací o tématice DOP v [9, Langley, 1999]. Uvedeme zde jen základní vztah 2.5. GDOP = HDOP 2 + V DOP 2 + T DOP 2 (2.5) Jednotlivé složky DOP jsou závislé na rozmístění družic na obloze. Jejich rozmístění je zase závislé na zeměpisné šířce přijímače. Například v případě GPS, od 56. rovnoběžky směrem k pólům roste především VDOP, nebot na této rovnoběžce družice inklinují zpět k rovníku. 2.2.6 Diferenční měření V části 2.2.5 jsme zmínili chyby ovlivňující GNSS měření. Přesnost GNSS měření je dostačující maximálně pro běžnou veřejnost, zdaleka však nedosahuje přesnosti, kterou by potřebovali geodeti, vodohospodáři a další subjekty. Během let tak byly vyvinuty metody, kterými lze tato měření zpřesnit. Jako první byla používána klasická metoda průměrování. Tato metoda je náročná na dobu měření, ale přináší poměrně dobré výsledky (v případě kódových měření). Pokud se budeme zabývat čistě systémem GPS, tak moderní metody pro zpřesnění měření 8 Dilution Of Precision / rozptyl přesnosti 16

Obrázek 2.10: Vliv rozmístění satelitů na chybu v určování polohy. Zdroj: [9, Langley, 1999] se obecně nazývají diferenční GPS (DGPS). Základní princip metod DGPS spočívá v určování relativní polohy vůči jinému bodu. Tento bod musí mít předem známé souřadnice a zároveň musí na tomto bodě probíhat simultánní měření. Metody vyhodnocení Metody DGPS se používají pro zpřesnění kódových i fázových měření. Můžeme je rozdělit na: Metody vyhodnocení v reálném čase. Dochází k příjmu korekcí přímo při měření. Korekce jsou distribuovány rádiovými vlnami nebo po internetu. Uživatel musí mít speciální přijímač schopný tyto korekce přijmout a zahrnout do měření. Korekce jsou většinou ve formátu RTCM. Metody vyhodnocení post-processingem (po měření). Měření jednotlivých referenčních stanic jsou ukládána a data jsou následně poskytnuta ke stažení (zdarma nebo za poplatek) uživatelům. Data jsou převážně ukládána do souborů formátu RINEX 9. 9 Receiver Independent Exchange Format 17

Typy korekcí Dále můžeme DGPS rozdělit podle typu korekcí, které poskytují. Korekce polohy jsou výsledné diference φ λ h nebo X Y Z, o které se liší vypočtená poloha od skutečné. O tyto hodnoty si opraví přijímač svoji vypočtenou polohu. Předpokládá se, že pokud je přijímač v blízkosti referenčního bodu a oba měří na stejnou sadu družic (jediné dvě podmínky pro aplikaci těchto korekcí), chyby, ke kterým dojde při měření na obou místech, jsou stejné. Tento typ korekcí se v dnešní době již téměř nepoužívá. Korekce vzdáleností jsou opravy naměřených pseudovzdáleností k družicím. Přijímač na referenčním bodě zná svoji polohu, zná polohu družice z efemerid a je tak schopen vypočítat skutečnou vzdálenost k družici. Z měření vypočte pseudovzdálenost a z rozdílu těchto hodnot vypočte opravu naměřené vzdálenosti. Pro každou družici je vypočtena jedna oprava pseudovzdálenosti. Na určovaném bodě může druhý přijímač aplikovat korekce jen pro družice, které používá k měření. Tento typ korekcí je mnohem přesnější, ale náročnější na realizaci. Surová data měření - pseudovzdálenosti a fázová měření pro L1 a L2. Tato data zpracuje software přijímače a aplikuje do vlastních měření. Aby bylo možné provést opravy měření, je nutné měřit na dvou bodech zároveň (na určovaném bodě a na referenčním, známém bodě), což znamená poměrně velké materiální (dva GNSS přijímače) i personální (dva měřiči) náklady. V dnešní době už tyto požadavky odpadají díky sítím permanentních referenčních stanic, které existují v mnoha zemích světa. Tyto referenční stanice plně nahrazují funkci referenčního přijímače a poskytují svá měření k dipozici ostatním. Mezi tyto sítě patří například EUREF 10 nebo CZEPOS. Zdroj korekcí Poslední rozdělení tedy můžeme provést na základě druhu použitého referenčního přijímače. Vlastní GNSS přijímač kterým měříme současně s prvním přijímačem. Permanentní stanice která poskytuje korekce ostatním subjektům (většinou za poplatek). Virtuální referenční stanice (tzv. VRS). VRS je umístěna do blízkosti měřiče, většinou v okruhu 5 km od místa observace. To umožňuje mnohem přesnější určení polohy než v případě použití korekcí z permanentní stanice (která s velkou pravděpodobností je mnohem dále). 10 EUREF je Evropská sít referenčních stanic. 18

Měření VRS jsou generována na základě sít ového řešení z několika stanic, případně ještě doplněna o diference korekcí z vedlejších stanic. 2.3 CZEPOS CZEPOS je sít permanentních GNSS stanic České republiky. Je pod správou ČUZK11. Do sítě CZEPOS patří 23 stanic vhodně rozmístěných po celé České republice v rámci budov katastrálních úřadů a 4 externí stanice zřízené na vědeckých pracovištích. Veškeré informace o stavu sítě, souřadnice stanic, jejich fotografie, parametry antén a další data jsou zveřejněna na internetových stránkách http://czepos.cuzk.cz. Seznam služeb CZEPOS pro vyhodnocení měření v reálném čase: DGPS - určená pro kódová měření s výslednou přesností do 10 cm. RTK - určená pro fázová měření s výslednou přesností v řádu centimetrů. Jedná se vždy o korekce z jedné konkrétní stanice. VRS - určená pro fázová měření s výslednou přesností v řádu centimetrů. Jedná se o korekce z virtuální stanice, kterou systém umístí do lokality blízko uživatele. Korekce této stanice jsou vypočteny ze sít ového řešení několika stanic. Pro využití těchto korekcí je nutné mít přijímač schopný zpracovávat RTCM korekce v reálném čase. Přijímač musí být připojen na internet (nejčastěji přes GPRS 12 ) a musí umět komunikovat protokolem NTRIP. Seznam služeb CZEPOS pro vyhodnocení post-processingem: RINEX - soubor měřených dat z konkrétní stanice CZEPOS. Virtuální RINEX - soubor dat z virtuální stanice, který je vypočten na základě sít ového řešení několika stanic. Pro aplikaci těchto korekcí je nutné vlastnit software umožnující zpracování post-processingem (Topcon Tools, Leica Geo Office, Trimble Geomatics Office a další). Součástí korekcí mohou být i data získaná měřením na družice GLONASS. 11 Český úřad zeměměřický a katastrální 12 General Packet Radio Service je služba umožňující připojení k internetu přes klasické mobilní GSM (Globální systém pro mobilní komunikaci) sítě. 19

Kapitola 3 NTRIP protokol Tato kapitola čerpá především z oficiální dokumentace NTRIP protokolu 1. V části 2.2.5 jsme se dozvěděli, že určování polohy měřením pomocí GNSS je nepřesné. Výslednou přesnost ovlivňuje celá řada chyb. Tyto chyby mohou dosahovat takových hodnot, že měření se stanou nepoužitelná pro účely vyžadující zvýšenou přesnost (v řadu centimetrů), například geodetická měření. V odstavci 2.2.6 byly nastíněny metody, jakými lze tyto chyby odstranit nebo alespoň částečně eliminovat tak, aby se GNSS dalo používat i pro tyto účely. Pomocí těchto metod lze dosáhnout zvýšené přesnosti v určování polohy až v řádu centimetrů. V této kapitole se blíže podíváme na protokol NTRIP, který se nejčastěji používá k šíření GNSS korekcí po internetu. Protokol NTRIP je pouze komunikační protokol. Vlastní GNSS korekce jsou nejčastěji ve formátu RTCM. 3.1 Networked Transport of RTCM via Internet Protocol Na počátku 21. století začal v německé BKG (Německá národní agentura pro kartografii a geodézii) vývoj protokolu NTRIP. Úkolem bylo vyvinout snadno implementovatelný a zároveň spolehlivý protokol, kterým by se zajistila distribuce GNSS korekcí ve formátu RTCM po internetu. NTRIP protokol byl postaven na nejpoužívanějším protokolu vůbec - HTTP 2. Data, která mohou být tímto protokolem distribuována, nemusí být vůbec ve formátu RTCM, ale může se jednat o jakákoliv data (i binární). NTRIP protokol je pouze komunikační protokol. Protože byl tento protokol primárně určen pro distribuci dat ve formátu RTCM, byl pojmenován Networked Transport of RTCM via Internet Protocol - zkráceně NTRIP. 1 [13] Radio Technical Commission For Maritime Services: RTCM recommended standards for networked transport of RTCM via internet protocol [online], 2004, [cit. 2012-04-05], dostupné z WWW: http://igs.bkg.bund.de/root_ftp/ntrip/documentation/ntripdocumentation.pdf 2 Hyper Text Transfer Protocol - používá se například pro komunikaci webového serveru a prohlížeče (prohlížení internetových stránek). 20

Dále se budeme zabývat NTRIP protokolem pouze ve verzi jedna. NTRIP, stejně jako HTTP, je protokol aplikační vrstvy postavený nad protokoly TCP/IP. HTTP protokol je optimalizován na velký počet spojení, ale není primárně určen pro aplikace, které streamují 3 data přes internet (což je případ NTRIP protokolu). NTRIP protokol umožňuje simultánní přístup neomezeného počtu uživatelů ke všem korekcím. Do systému NTRIP spadají čtyři základní objekty: NTRIP Source - je zdroj GNSS korekcí, které jsou posílány NTRIP serverem do NTRIP Casteru a odtud rozesílány jednotlivým klientům. NTRIP Server - označení server je v tomto případě trochu matoucí. Jedná se o klienta (podle sít ové architektury klient-server 4 ), který posílá data generovaná v NTRIP Source do NTRIP Casteru. NTRIP Caster - je server (podle sít ové architektury klient-server). Přijímá data od NTRIP serverů a rozesílá je NTRIP klientům. NTRIP Client - je běžný klient (podle sít ové architektury klient-server). Po připojení k NTRIP Casteru může přijímat data od jednotlivých NTRIP serverů. 3.2 Základní funkcionalita Schéma jednotlivých prvků systému je znázorněno na obrázku 3.1. Jedna GNSS anténa, představuje jeden zdroj dat tzv. NTRIP Source. Tento NTRIP Source má v NTRIP Casteru přidělen svůj tzv. mountpoint. Pro každý NTRIP Source musí existovat v Casteru jeden mountpoint. Mountpoint je tak zástupným názvem pro NTRIP Source. Mountpoint musí být v NTRIP Casteru předem nadefinován administrátorem - má unikátní jméno a heslo. Přenos dat z NTRIP Source do NTRIP Casteru má na starosti NTRIP Server. NTRIP Server se musí připojit ke Casteru, vytvořit mountpoint (k tomu musí znát přidělené jméno a heslo) a poté může začít posílat data. NTRIP Client se připojí na Caster a vyžádá si data z NTRIP Source podle přiděleného mountpointu. Pokud klient neví, které mountpointy jsou na Casteru dostupné, může si vyžádat jejich seznam. NTRIP Caster pak vrátí klientovi seznam aktuálních mountpointů. Stejně tak, 3 Výraz streamují se používá pro aplikace, které nepřetržitě odesílají data. Klasická komunikace klienta a serveru skrze HTTP protokol je rychlá. Klient se připojí k serveru, zašle požadavek, počká na odpověd serveru (stáhne data) a odpojí se. Vše proběhne většinou během několika vteřin (záleží samozřejmě na rychlosti serveru a objemu stahovaných dat). Při streamování je naopak klient k serveru připojen delší dobu a stahuje data nepřetržitě. 4 Sít ová architektura klient-server definuje dva typy objektů. První objekt - klient je aktivní, inicializuje spojení na server a žádá server o službu (stažení dat, spuštění programu, poslání e-mailu atd.). Druhý objekt - server je pasivní, čeká na spojení od klientů a vyřizuje jejich požadavky. 21

Obrázek 3.1: Schéma NTRIP objektů. pokud klient požádá o data z neexistujícího mountpointu, Caster vrátí klientovi aktualizovaný seznam mountpointů. Tento seznam se nazývá source-table. Source-table obsahuje seznam všech aktivních 5 mountpointů s popisem dat, která jsou posílána do Casteru, popisem parametrů sítě do které NTRIP Source patří a také obsahuje seznam dalších NTRIP Casterů a jejich parametrů. Za aktualizaci a vložení správných záznamů do source-table je zodpovědný administrátor Casteru (případně NTRIP server, ve kterém jsou definovány parametry dat generovaných v NTRIP Source). Administrátor Casteru musí být ve spojení se správci NTRIP serverů a musí jim být schopen poskytnout hesla a jména přidělených mountpointů. Zároveň musí společně definovat parametry jednotlivých NTRIP Source/mountpointů v source-table. 5 Aktivním mountpointem zde rozumíme mountpoint, ke kterému je připojen NTRIP server a odesílá data. Naopak neaktivní mountpoint je ten, který je pouze definován v Casteru a NTRIP server není připojen nebo neposílá žádná data. 22

3.3 Prvky systému NTRIP Do systému NTRIP řadíme čtyři základní prvky NTRIP Source, NTRIP Server, NTRIP Caster a NTRIP Client. Můžeme se setkat se situací, kdy je několik prvků spojeno do jednoho objektu (nejčastěji NTRIP Source a NTRIP Server). 3.3.1 NTRIP Source NTRIP Source je označován objekt, který generuje GNSS korekce. V NTRIP Source probíhá výpočet korekcí na základě dostupných měření. GNSS korekce jsou převážně generovány ve formátu RTCM a jsou přenášeny do NTRIP Serveru a odtud do NTRIP Casteru. Pokud je NTRIP Server součástí NTRIP Source, tak jsou korekce rovnou odesílány do Casteru. Jeden NTRIP Source reprezentuje jednu GNSS anténu. Parametry NTRIP Source jako přesná verze formátu dat, použité GNS systémy (GPS, GLONASS, Galileo), souřadnice místa měření atd. jsou uvedeny v jednom záznamu source-table uloženém v Casteru. Pro každý NTRIP Source musí být v Casteru definován jeden unikátní mountpoint. 3.3.2 NTRIP Server NTRIP Server je objekt, který má na starosti komunikaci s NTRIP Casterem. Úkolem NTRIP serveru je přenášet korekce generované v NTRIP Source do Casteru. NTRIP Server musí rozumět protokolu NTRIP, kterým komunikuje s Casterem. Vlastní spojení s Casterem je postaveno na protokolech TCP/IP. Data z NTRIP Source do NTRIP serveru tečou většinou sériovým portem, po síti nebo je NTRIP Server a NTRIP Source spojen do jednoho objektu. Jeden NTRIP Server může odesílat data z několika NTRIP Source, zároveň může data posílat do několika NTRIP Casterů. 3.3.3 NTRIP Caster NTRIP Caster je hlavní objekt v tomto systému. Caster čeká na spojení od NTRIP serverů a NTRIP klientů. Caster musí mít otevřen port pro komunikaci se servery a klienty. Standardním portem pro komunikaci v rámci protokolu NTRIP je port 2101. V Casteru jsou definovány mountpointy pro jednotlivé NTRIP Source a hesla, která zabezpečují přístup k těmto mountpointům. Caster zároveň spravuje přístup koncových uživatelů k jednotlivým mountpointům. Přístup na jednotlivé mountpointy může být veřejný nebo omezený jen pro určité uživatele. Caster by měl uchovávat statistiky o přístupu uživatelů k mountpointům a také o datových tocích z NTRIP Serverů. NTRIP Caster může být spojen s NTRIP Serverem do jednoho objektu a pouze se starat o přístup uživatelů k datům. 23

K administraci Casteru se nejčastěji používá webové rozhraní, příkazový řádek nebo v případě této práce, desktopová 6 aplikace. 3.3.4 NTRIP Client NTRIP Client je označován každý uživatel, který se připojí ke Casteru a vyžádá si data z některého mountpointu. Caster poté začne přeposílat GNSS korekce přijaté od NTRIP serveru tomuto NTRIP klientovi. Komunikace mezi klientem a Casterem je podobná komunikaci, jako v případě použití protokolu HTTP (webový prohlížeč a server). Pokud není mountpoint veřejně přístupný (STR záznam v source-table pro tento mountpoint nemá uvedeno authorization = N)), klient musí odeslat své přihlašovací údaje, aby mohl z tohoto mountpointu přijímat data. Pokud klient neví, ke kterému mountpointu se připojit, může si vyžádat source-table, ve které nalezne informace o aktivních mountpointech a popis dat (korekcí), které je možné přijímat z jednotlivých mountpointů. 3.4 Komunikace NTRIP Server - NTRIP Caster Komunikace NTRIP Serveru s NTRIP Casterem probíhá následovně: 1. NTRIP Server se připojí na adresu a port, na kterém běží Caster. 2. NTRIP Server zašle Casteru zprávu typu SOURCE pomocí které se autentifikuje. 3. Caster odpoví Serveru a čeká na příjem dat (v případě správné autentifikace) nebo ukončí spojení (v případě nesprávné autentifikace). 4. Pokud Caster neukončil spojení, Server začne posílat data. 5. Server ukončí spojení - odpojí se od Casteru. Teoreticky by k ukončení spojení ani nemuselo dojít, Server může posílat data nepřetržitě. Definice zprávy SOURCE SOURCE [password] [mountpoint] <CR><LF> Source-Agent: NTRIP [produkt] <CR><LF> STR: [STR_source-table] <CR><LF> <CR><LF> [data] 6 Aplikace určená pro běh na stolních počítačích s grafickým rozhraním. 24

Password je heslo, které zabezpečuje přístup k mountpointu. Jenom po zadání platné kombinace hesla a mountpointu je povoleno Serveru posílat data. Pokud je zadána neplatná kombinace hesla a mountpointu, Caster odmítne požadavek Serveru a ukončí spojení. Heslo se posílá nešifrovaně. Předpokládá se, že komunikace mezi Casterem a Serverem probíhá po zabezpečeném kanále (lokální sít ). Hesla musí vytvořit administrátor Casteru a předat správci NTRIP Serveru. Mountpoint je zástupný název pro NTRIP Source v Casteru. Mountpoint je zabezpečen heslem proti neoprávněnému přístupu. Mountpoint musí mít unikátní název v celém Casteru. Produkt obsahuje informace o NTRIP Serveru, který komunikuje s Casterem. STR source-table - volitelný atribut. Server může definovat STR záznam v source-table pro daný NTRIP Source/mountpoint. Pokud je atribut [STR source-table] zadaný, musí obsahovat všechny atributy, které source-table v Casteru obsahuje, počínaje třetí položkou (první atribut je STR a druhý je název mountpointu). Jednotlivé parametry v [STR source-table] jsou odděleny středníkem ( ; ). Ukázka komunikace NTRIP Server s NTRIP Caster. NTRIP Server pošle zprávu: SOURCE pass1234 /CPRG3 Source-Agent: NTRIP NtripServerTest/1.1 STR: Praha;RAW;1(1);2;GPS;CZEPOS;CZE;50;15;0;0;none;N;N;500;no <CR><LF> 1. Pokud je heslo správné, NTRIP Caster odpoví: ICY 200 OK A začne přijímat data od NTRIP Serveru. 2. Pokud je heslo špatně, NTRIP Caster odpoví: ERROR Bad Password A ukončí spojení se Serverem. 25

3.5 Komunikace NTRIP Client - NTRIP Caster Celá komunikace mezi NTRIP Casterem a NTRIP klientem může být trochu složitější, proto zde raději uvedeme pouze schéma znázorněné na obrázku 3.2. Obrázek 3.2: Schéma komunikace NTRIP Client - NTRIP Caster. Definice zprávy GET GET [mountpoint] HTTP/1.0 <CR><LF> Host: [hostname] <CR><LF> User-Agent: NTRIP [produkt] <CR><LF> Accept: */* <CR><LF> Authorization: [metoda] [credentials] <CR><LF> Connection: close <CR><LF> <CR><LF> 26

Mountpoint je zástupný název pro NTRIP Source v Casteru, od kterého klient žádá data. Mountpoint musí být aktivní (NTRIP Server musí do mountpointu posílat data), aby se mohl klient připojit. Hostname je IP adresa nebo hostname 7 serveru, na kterém běží NTRIP Caster (ke kterému je klient připojen). Produkt obsahuje informace o typu NTRIP klienta, který komunikuje s Casterem. Metoda určuje způsob autentifikace uživatele (Basic nebo Digest). Credentials je řetězec znaků jméno:heslo zašifrované pomocí base64 algoritmu. Ukázka komunikace NTRIP Client s NTRIP Caster. NTRIP Client pošle zprávu: GET /CPRG3 HTTP/1.0 Host: czeposr.cuzk.cz User-Agent: NTRIP NtripClientTest/1.1 Connection: close <CR><LF> 1. Pokud mountpoint CPRG3 existuje a nevyžaduje autentifikaci, tak NTRIP Caster odpoví: ICY 200 OK A začne posílat data z mountpointu klientovi. 2. Pokud mountpoint CPRG3 neexistuje, NTRIP Caster pošle klientovi aktuální sourcetable aktivních mountpointů. SOURCETABLE 200 OK Server: NTRIPCASTER/1.0 Content-Type: text/plain Content-Length: 218 STR;P4143;P4143;RTCM 3;1004(1),1005/1007(5),PBS(10);2;GPS... 7 zástupný název pro zařízení připojené k síti např. czepos.cuzk.cz 27

CAS;72.233.250.5;8080;WSRN2;Seattle 0;USA;47.4;237.6;0.0... NET;WSRN2;Seattle Utilities;B;http://72.233.250.5;... ENDSOURCETABLE A následně ukončí spojení. 3. Pokud mountpoint CPRG3 existuje, ale vyžaduje autentifikaci uživatele, NTRIP Caster odpoví klientovi: HTTP/1.0 401 Unathorized a pošle zprávu: Server: NTRIPCaster/1.0 WWW-Authenticate: Basic realm="/cprg3" Content-Type: text/html Connection: close <html> <head><title>401 Unathorized</title></head> <body> <h1><center>the server does not recognize your privileges to the requested entity/stream</center></h1> </body> </html> Klient musí poté poslat znovu požadavek na daný mountpoint, ale musí uvést své přihlašovací údaje (jméno:heslo), oddělené dvojtečkou a kódované pomocí base64. GET /CPRG3 HTTP/1.0 Host: czeposr.cuzk.cz User-Agent: NTRIP NtripClientTest/1.1 Authorization: Basic ahvnb2jibjpodwdvznfkjbzkj Connection: close <CR><LF> (a) Pokud uživatel zadal správné přihlašovací údaje, Caster odpoví: ICY 200 OK a začne klientovi posílat GNSS data z požadovaného NTRIP Source/mountpointu. 28

(b) Pokud uživatel zadal neplatné přihlašovací údaje, Caster odpoví stejně jako v případě, kdyby uživatel nezadal žádné. V případě, že klient ví o tom, že mountpoint vyžaduje autentifikaci, může poslat své přihlašovací údaje hned v první zprávě. Přihlašovací údaje se v tomto případě posílají jako šifrovaný řetězec znaků, který ale může být útočníkem zachycen a následně zneužit. Metoda Digest Authentication Pokud uživatelé a aplikace vyžadují vyšší bezpečnost přihlašování, mohou použít metodu Digest Authentication. Tato metoda je blíže popsána v [14, Rivest, 1992]. Připojení NTRIP klienta k VRS mountpointu Jak jsme se dozvěděli v 2.2.6, existují tzv. virtuální referenční stanice (VRS), které poskytují RTK korekce, stejně jako permanentní stanice, ale jsou umístěné do blízkosti klienta. Aby bylo možné VRS umístit do blízkosti klienta, je nutné znát jeho polohu. VRS jsou v NTRIP Casteru zastoupeny tzv. VRS mountpointem (mountpoint pro virtuální referenční stanici). VRS mountpoint má v SRC záznamu v source-table uveden atribut nmea rovno 1. V případě připojení NTRIP klienta k VRS mountpointu probíhá komunikace mezi Casterem a klientem trochu odlišně. Klient se připojí ke Casteru, odešle zprávu typu GET a pokud se správně autentifikoval, musí ještě odeslat NMEA zprávu, ve které udává mimo jiné svoji polohu. NTRIP Caster následně pomocí dalšího software začne generovat data ze sít ové řešení pro VRS, která odesílá klientovi skrze VRS mountpoint. K VRS mountpointu může být připojeno libovolné množství NTRIP klientů. Pro každého klienta Caster generuje odlišná data. 4. Ukázka komunikace NTRIP klienta a NTRIP Casteru s NMEA zprávou: GET /MAX3C HTTP/1.1 Host: czeposr.cuzk.cz User-Agent: NTRIP NtripClientTest/1.1 Accept: rtk/rtcm, dgps/rtcm Authorization: Basic ahvnb2jibjpodwdvznfkjbzkj $GPGGA,1038.00,3334.23134,N,11211.05769,W,2,04,5.4,354.68,M,-26.54,M,7.0,138*79 Poté, co Caster přijme a zpracuje NMEA zprávu (a za předpokladu, že klient se správně autorizoval), začne posílat klientovi data. 29

3.6 Source-table NTRIP Caster musí být schopen klientům poskytnout informace o svých NTRIP Source, které vysílají skrze Caster data. Tyto informace, spolu s informacemi o dalších (záložních) NTRIP Casterech a parametry referenční sítě, uchovává v tzv. source-table. Source-table obsahuje tři základní záznamy: popis korekcí generovaných v NTRIP Source - STR záznam specifikace sítě - NET záznam informace o dalších NTRIP Casterech - CAS záznam Všichni klienti musí být schopni pracovat se záznamy typu STR, které jsou pro ně nejdůležitější. Záznamy typu NET a CAS jsou volitelné. Zároveň je možné specifikovat další, vlastní typy záznamů. Klient získá od Casteru aktuální source-table v případě, že zadá neplatný název mountpointu nebo pokud nezadá název vůbec. Ukázka komunikace NTRIP Client a NTRIP Caster: Klient požádá o source-table posláním zprávy typu GET bez názvu mountpointu: GET / HTTP/1.0 Host: czeposr.cuzk.cz User-Agent: NTRIP NtripClientTest/1.1 Connection: close NTRIP Caster odpoví aktuální source-table: SOURCETABLE 200 OK <CR><LF> Server: [caster\_identifier]/[version] <CR><LF> Content-type: text/plain <CR><LF> Content-length: [velikost] <CR><LF> <CR><LF> [source-table] ENDSOURCETABLE caster identifier je popis Casteru nebo název provozovatele Casteru, version je verze protokolu NTRIP, kterou Caster komunikuje, 30

velikost source-table (v bajtech), source-table - každý záznam je na jednom řádku. Jednotlivá pole v záznamu jsou oddělena středníkem. 31

STR záznam Atribut Popis Formát Příklad typ Typ záznamu 3 znaky STR mountpoint Název mountpointu max. 100 znaků CPRG3 identifikátor Identifikátor NTRIP Source, neomezeně znaků Praha název města formát Formát dat neomezeně znaků RTCM2, RAW, CMR další informace Dodatečné informace o formátu neomezeně znaků 1(1), 2(1), o dat, v závorkách frekvence aktu- LB(2) formátu alizací v sekundách nosná vlna Informace o měření na vlnách: číslo 0,1,2 0 = Ne, 1 = L1, 2 = L1+L2 GNSS Název používaného GNSS neomezeně znaků GPS, GLONASS sít stanice Název sítě referenčních stanic neomezeně znaků CZEPOS, EUREF stát ISO zkratka státu, ve kterém 3 znaky CZE, DEU stanice leží zeměpisná Zeměpisná šířka přijímače desetinné číslo 50.24 šířka zeměpisná délka Zeměpisná délka přijímače desetinné číslo 15.76 nmea 0 = klasický mountpoint, číslo 0, 1 1 = mountpoint pro virtuální referenční stanici řešení Původ dat: 0 = data z jedné stanice, číslo 0, 1 1 = data ze sít ového řešení generátor generátor dat neomezeně znaků GPSNet komprese Algoritmus pro kompresi nebo kryptování dat neomezeně znaků žádná autentifikace Způsob autentifikace klientů: 1 znak N, B, D N = žádná, B = Basic, D = Digest, poplatek Zpoplatněný mountpoint: 1 znak Y, N Y = Ano, N = Ne datový tok Rychlost datového toku (b/s) číslo 500 další info Dodatečné informace neomezeně znaků nic 32

NET záznam Atribut Popis Formát Příklad typ Typ záznamu 3 znaky NET identifikátor Identifikátor sítě referenční neomezeně EPN, IGLOS stanice (NTRIP Source) znaků operátor Provozovatel sítě referenčních neomezeně CZEPOS, EUREF stanic znaků autentifikace Způsob autentifikace klientů: N = žádná, B = Basic, D = Digest, 1 znak N, B, D poplatek Poplatek za připojení k 1 znak Y, N mountpointům z této sítě: Y = Ano, N = Ne web-net Webové stánky s informacemi neomezeně http://czepos.cuzk.cz o síti. znaků web-str Webové stránky s informacemi neomezeně http://czepos.cuzk.cz o NTRIP Source znaků web-reg Webové stránky nebo mailová neomezeně http://czepos.cuzk.cz adresa k registraci znaků další info Dodatečné informace neomezeně znaků nic 33

CAS záznam Atribut Popis Formát Příklad typ Typ záznamu 3 znaky CAS host IP adresa nebo hostname max. 128 czeposr.cuzk.cz Casteru znaků port Číslo portu, na kterém čeká číslo 2101 Caster na spojení identifikátor Identifikátor Casteru, jméno provozovatele neomezeně znaků CZEPOS operátor Provozovatel referenčních neomezeně Zeměměřický úřad stanic znaků stát ISO zkratka státu kam stanice 3 znaky CZE, DEU patří zeměpisná Zeměpisná šířka přijímače desetinné 50.24 šířka číslo zeměpisná délka Zeměpisná délka přijímače desetinné číslo 15.76 záložní host IP adresa nebo hostname neomezeně 90.0.15.164 záložního Casteru znaků záložní port Port záložního Casteru číslo 1080 další info Dodatečné informace neomezeně znaků nic 34

Kapitola 4 Aplikace Celý projekt vývoje NTRIP Casteru, můžeme rozdělit na dvě části. První částí je vývoj vlastního NTRIP Casteru, pojmenovaného K152 Caster. Druhou částí je vývoj administračního rozhraní, K152 GUI. Mezi těmito aplikacemi leží komunikační kanál reprezentovaný databází MySQL. Schéma celého projektu je znázorněno na obr. 4.1. Obrázek 4.1: Schéma komunikace K152 Caster s K152 GUI. K152 Caster je klasický server vzhledem k NTRIP Server a NTRIP Client, podle sít ové architektury klient-server (vysvětlení této architektury na straně 21). Caster umožňuje přenos dat od NTRIP Server (klient odesílající data) k NTRIP Client (klient přijímající data). K152 GUI je administrační GUI 1 aplikace, kterou ovládáme K152 Caster. 1 Grafické uživatelské rozhraní. 35

4.1 Aplikace K152 Caster K152 Caster je serverová aplikace, primárně určená pro běh na Linuxových operačních systémech (i bez GUI). Portování Casteru na OS Windows by bylo snadné díky použití multiplatformní knihovny QT 2, pomocí které je aplikace naprogramována. Pro spuštění aplikace K152 Caster je nutné umožnit Casteru přístup do databáze MySQL. Aplikace Caster je TCP server, který se po spuštění naváže 3 na určené IP adresy a porty, na nichž čeká na příchozí spojení. 4.1.1 Základní funkce K152 Casteru K152 Caster plně implementuje protokol NTRIP verze 1. Základní funkce K152 Casteru jsou následující: 1. připojení NTRIP serverů a NTRIP klientů ke Casteru 2. přenos dat od NTRIP serverů k NTRIP klientům 3. zakládání mountpointů NTRIP servery 4. řízení přístupu uživatelů (klientů) k mountpointům 5. zobrazení source-table 6. zaznamenávání statistik o NTRIP serverech a NTRIP klientech 7. ukládání záznamů o jednotlivých spojení 8. změna formátu korekcí (konverze datového toku od NTRIP serveru do jiného formátu) pomocí pluginů. Více o této funkci v kapitole 4.3. 9. podpora VRS mountpointů díky použití programu VirtualGenerator viz. 4.4.2, případně jiného software 10. odpojování NTRIP klientů z Casteru (na příkaz od aplikace K152 GUI) 11. přeposílání datového toku z NTRIP serveru do K152 GUI 2 QT je multiplatformní knihovna postavená na programovacím jazyku C++. Více informací o QT na domovské stránce projektu http://qt-project.org/ 3 Navázat (v odborné terminology se spíše používá termín nabindovat) je termín užívaný pro aplikace typu server. Navázat znamená, na které IP adrese server bude přijímat spojení. Obecně platí, že každý počítač, respektive sít ové rozhraní, může mít přiděleno více IP adres a server může čekat na spojení jenom na některé z nich. 36

4.1.2 Spuštění K152 Casteru Start programu má pouze jeden povinný parametr, cestu k textovému souboru, specifikující připojení k databázi. Formát souboru specifikující připojení k databázi: HOST= 1 2 7. 0. 0. 1 # IP adresa BASE=c a s t e r # nazev databaze PORT=3306 # port databaze USER=root # u z i v a t e l s k e jmeno PASS=t r u h l i k # h e s l o Program má další dva nepovinné parametry. První z nich je IP adresa, na kterou se má K152 Caster navázat (pokud není parametr zadán, Caster se naváže na všechny dostupné IP adresy). Druhý parametr je port, na kterém bude server čekat na spojení (pokud není port zadán, server čeká na spojení na portu 2101). Tento port je označen v této práci jako N port. Je to port pro komunikaci s NTRIP servery a NTRIP klienty. Příklad spuštění K152 Casteru poslouchajícího na IP adrese 127.0.0.1 a portu 1080../caster settings.txt 127.0.0.1 1080 K152 Caster potřebuje pro komunikaci s GUI ještě druhý port. Port pro komunikaci s GUI je značen v této práci jako G port. K152 Caster používá G port vždy o 1 větší než N port. Po spuštění programu se Caster pokusí detekovat maximální počet připojení do MySQL databáze. Dále se Caster pokusí zvýšit limit pro maximální počet otevřených souborů na 4096. Zvýšení limitu se povede pouze v případě, pokud byla aplikace spuštěna rootem. V Linuxu je tento limit standardně nastaven na 1024. Tento počet je pro K152 Caster značně omezující. Caster potřebuje mít otevřené 4 soubory pro každé spojení (1 socket 4 vlastního spojení, 1 socket spojení do databáze a 2 PIPE 5, které tvoří QT automaticky pro každé vlákno). Tímto limitem (1024) se tak omezuje maximální počet konkurenčních spojení na cca 250. V dalším kroku se nastaví připojení k databázi. V databázi se vytvoří všechny tabulky, které program potřebuje (pokud už jsou tabulky vytvořeny, vyčistí se od případných záznamů, které mohly zůstat v databázi od minulého spuštění). Po nastavení databáze se vytvoří objekty Server a OperationServer, které začnou naslouchat na zadaných IP adresách a portech. Objekt Server si otevře N port a čeká na spojení od NTRIP serverů a NTRIP klientů. OperationServer si otevře G port a čeká na spojení z aplikace K152 GUI. 4 Socket je objekt, přes který si sít ové aplikace posílají data. Socket je v OS Linux implementován jako soubor. Socket je charakterizován IP adresou a portem. 5 Mechanismus pro komunikaci mezi jednotlivými procesy v programu. 37

Pro každého klienta (klient je zde míněno NTRIP Client i NTRIP Server, oba jsou z pohledu architektury klient-server klienti ve vztahu k NTRIP Casteru), který se připojí ke Casteru, se vytvoří nové vlákno 6 (Thread), ve kterém se zpracovávají zprávy od klienta. Pokud klient odešle zprávu typu GET (viz. 3.5), je vytvořen objekt Receiver a klient je označen za NTRIP Client. Pokud odešle zprávu typu SOURCE (viz. 3.4), je vytvořen objekt Mountpoint a klient je označen jako NTRIP Server. Obrázek 4.2: Grafické rozhraní aplikace GUI. 4.2 K152 GUI GUI aplikace byla vytvořena pro snadnou správu a monitorování K152 Casteru. V jednoduchém grafickém rozhraní, rozděleném na několik záložek, jsou umístěny tabulky s mountpointy, NTRIP klienty, uživateli, source-table se všemi záznamy, statistiky a logy. V GUI je možné zakládat nové mountpointy, vytvářet uživatele a upravovat záznamy v source-table a definovat práva uživatelů pro přijení k mountpointům. Aplikace K152 GUI je naprogramována pomocí knihoven QT. Aplikaci je nutné spouštět na počítačích s grafickým rozhraním. K152 GUI je možné provozovat na OS Windows i Linux. 6 Vlákno, neboli thread, je samostatné výpočetní vlákno procesoru. Užívá se k paralelnímu zpracování úkolů vícejaderným procesorem. 38

Přílohou této práce jsou zkompilované 7 aplikace pro oba tyto operační systémy. V aplikaci je rovněž použita knihovna QWT 8, která umožňuje mimo jiné snadnější vytváření grafů. Většina komunikace mezi GUI a Casterem je realizována skrze databázi. Pouze část funkcí (zobrazení datového toku a odpojení klienta od Casteru) vyžaduje přímé spojení mezi oběma aplikacemi. 4.2.1 Základní funkce K152 GUI Níže je uveden seznam základních funkcí aplikace K152 GUI: správa mountpointů (definice, nastavení práv pro připojení NTRIP serveru, rušení) monitorování připojených NTRIP serverů zobrazení datové toku z NTRIP serveru (možnost konvertování datového toku do jiného formátu pomocí pluginů) zobrazení grafu znázorňujícího množství odeslaných dat NTRIP serverem v čase monitorování připojených NTRIP klientů odpojení NTRIP klienta od K152 Casteru zobrazení mapy s přehledem připojených NTRIP klientů a NTRIP serverů správa uživatelů (vytváření, smazání, nastavení práv uživatelů pro připojení k mountpointům) zobrazení statistik mountpointů a uživatelů (množství přenesených dat, doba připojení atd.) správa source-table (přidávání, úprava a smazání jednotlivých záznamů) zobrazení záznamů z různých událostí (připojení klienta nebo serveru ke Casteru, NTRIP příkazy odeslané na Caster, odpojení klienta nebo serveru od Casteru, záznamy týkající se změn provedených v GUI) 4.2.2 Spuštění K152 GUI Při startu programu je možné uvést jeden volitelný parametr - cestu k souboru, specifikující připojení k databázi. Formát souboru je stejný jako v případě aplikace K152 Caster, viz. kapitola 4.1.2. Pokud parametr není uveden, je možné připojení nastavit v dialogovém okně, které se zobrazí po startu aplikace (obr. 4.3). 7 Převod zdrojových kódů programu do podoby, které rozumí procesor počítače. Zkompilované aplikace je možné rovnou spouštět. 8 Více informací o knihovně QWT na domovských stránkách projektu http://qwt.sourceforge.net/ 39

Obrázek 4.3: Dialogové okno pro nastavení připojení k databázi. Dále je nutné nastavit připojení ke Casteru, aby fungovaly všechny funkce. GUI se pokusí spojit s Casterem na základě údajů uložených v tabulce Settings (ip adresa a port). Pokud se spojení nepodaří, nabídne administrátorovi opět dialogové okno s možností vlastní konfigurace (obr. 4.4). Obrázek 4.4: Dialogové okno pro nastavení připojení ke Casteru. Jakmile se nastaví připojení k databázi, aplikace načte a zpracuje záznamy za posledních 60 minut z tabulky Mountpoint Stats, aby mohla vykreslit administrátorovi graf zobrazující počet připojených NTRIP serverů a NTRIP klientů. Po zpracování těchto záznamů se zobrazí hlavní okno aplikace spolu s již vykresleným grafem (obr. 4.2). 40

4.2.3 Popis aplikace K152 GUI Aplikaci K152 GUI můžeme rozdělit na 3 části. V horní části aplikace (obr. 4.5) jsou zobrazeny informace o: 1. NTRIP Casteru (ip adresa, čas spuštění a maximální počet připojení), 2. NTRIP klientech a uživatelých (počet definovaných uživatelů, počet uživatelů připojených ke Casteru a objem přenesených dat uživatelům), 3. NTRIP serverech a mountpointech (počet definovaných mountpointů, počet připojených NTRIP serverů ke Casteru a objem přenesených dat od serverů). Obrázek 4.5: Horní část aplikace K152 GUI V prostřední části aplikace (obr. 4.6) je umístěn graf znázorňující počet připojených NTRIP serverů a NTRIP klientů za posledních 60 minut. Obrázek 4.6: Graf znázorňující počet připojených NTRIP serverů a NTRIP klientů za posledních 60 minut. V dolní části aplikace je umístěno 6 záložek (obr. 4.7). Záložky jsou v aplikaci použité, kvůli přehlednějšímu rozdělení GUI. Na každé záložce je zobrazen jiný typ záznamů a informací. Obrázek 4.7: Hlavní záložky v aplikaci K152 GUI. 41

Záložka Mountpoints Na záložce Mountpoints je přehled definovaných mountpointů v Casteru spolu informacemi o NTRIP serverech připojených ke K152 Casteru. Obrázek 4.8: Údaje v tabulce na záložce Mountpoints V tabulce umístěné na záložce Mountpoints (obr. 4.8) jsou na každém řádku následující informace: jméno mountpointu IP adresu ze které se musí NTRIP server připojit, aby mohl daný mountpoint vytvořit (0.0.0.0 znamená libovolná IP adresa) heslo pro vytvoření mountpointu datum a čas připojení NTRIP Serveru počet připojených klientů k mountpointu IP adresa NTRIP serveru označení, zda se jedná o VRS mountpoint nebo normální objem přijatých dat od NTRIP serveru způsob autentifikace uživatelů k mountpointu Obrázek 4.9: Dialogové okno pro definování nového mountpointu. Soupis funkcí a tlačítek na záložce Mountpoints: tlačítko Add - přidání záznamu do tabulky (definování nového mountpointu, obr. 4.9) 42

tlačítko Edit - úprava záznamu v tabulce (změna již definovaného mountpointu) tlačítko Delete - smazání záznamu z tabulky (zrušení mountpointu) tlačítko Graph - zobrazení grafu přenesených dat NTRIP serverem (obr. 4.11) tlačítko Stream - zobrazení datového toku z NTRIP serveru (obr. 4.10). V tomto okně je možné zvolit plugin (pokud je dostupný), kterým se bude datový tok konvertovat. Více o pluginech v sekci 4.3. tlačítko Refresh - obnovení informací z databáze Obrázek 4.10: Okno s datovým tokem z NTRIP Serveru. Záložka Client Connections Na záložce Client Connections je přehled připojených NTRIP klientů ke K152 Casteru. V tabulce umístěné na záložce Client Connections (obr. 4.12) jsou na každém řádku následující informace: datum a čas připojení NTRIP klienta IP adresa NTRIP klienta mountpoint ke kterému je klient připojen objem odeslaných dat klientovi uživatelské jméno zeměpisná délka uživatele zeměpisná šířka uživatele 43

Obrázek 4.11: Grafu zobrazující množství odeslaných dat NTRIP serverem. Obrázek 4.12: Údaje v tabulce na záložce Client Connections stav fixace počet satelitů na které uživatel měří výška nad mořem uživatele Soupis tlačítek a funkcí na záložce Client Connections: tlačítko Disconnect - odpojení NTRIP klienta od Casteru tlačítko Stream - zobrazení datového toku z NTRIP serveru (obr. 4.10). V tomto okně je možné zvolit plugin (pokud je dostupný), kterým se bude datový tok konvertovat. Více o pluginech v sekci 4.3. tlačítko Map - zobrazení okna s mapou, na které jsou umístěni NTRIP klienti a NTRIP servery (obr. 4.13). Mapa je zobrazena pomocí Google Maps API 9. tlačítko Refresh - obnovení informací o NTRIP klientech z databáze 9 Google Maps API je java-scriptové rozhraní, kterým můžeme vložit do libovolné webové stránky interaktivní mapu světa. Více informací o tomto API můžete nalézt na https://developers.google.com/maps/ 44

Obrázek 4.13: Dialogové okno s mapou Záložka Sourcetable Na záložce Sourcetable jsou umístěny další tři záložky: STR - záložka pro source-table záznamy typu SRC NET - záložka pro source-table záznamy typu NET CAS - záložka pro source-table záznamy typu CAS Na každé z těchto záložek je umístěna tabulka, ve které jsou zobrazeny informace pro daný source-table záznam. Nebudeme zde popisovat jednotlivé tabulky, protože přesně odpovídají tabulkám v databázi, které jsou popsány v sekci 4.6.2 (jedná se o tabulky STR Sourcetable, NET Sourcetable, CAS Sourcetable). Soupis tlačítek a funkcí na záložce Sourcetable: tlačítko Add - přidání záznamu do tabulky tlačítko Edit - úprava záznamu v tabulce tlačítko Delete - smazání záznamu z tabulky 45

Záložka Users Na záložce Users je přehled definovaných uživatelů, kteří se mohou připojit ke K152 Casteru. Obrázek 4.14: Údaje v tabulce na záložce Users V tabulce umístěné na záložce Users (obr. 4.14) jsou na každém řádku následující informace: uživatelské jméno (přihlašovací jméno) jméno uživatele (skutečné jméno) heslo kredit označení, zda se uživatel může připojit ke Casteru nebo je mu připojení zakázáno maximální počet připojení uživatele ke Casteru (0 = neomezeně) Obrázek 4.15: Dialogové okno pro vytvoření nového uživatele. Soupis funkcí a tlačítek na záložce Users: tlačítko Add - přidání záznamu do tabulky (vytvoření nového uživatele, obr. 4.15) tlačítko Edit - úprava záznamu v tabulce (změna již založeného uživatele) 46

tlačítko Delete - smazání záznamu v tabulce (zrušení uživatele) tlačítko Rights - zobrazení dialogového okna s možností nastavení práv uživatele pro přístup k jednotlivým mountpointům (obr. 4.16). Zaškrtnutím nebo odškrtnutím příslušných políček můžeme udělit, respektive odebrat, práva uživateli na připojení se k danému mountpointu. tlačítko History - zobrazení dialogového okna s přehledem jednotlivých spojení uživatele ke Casteru (obr. 4.17). tlačítko Refresh - obnovení informací o uživatelích z databáze Obrázek 4.16: Okno pro nastavení uživatelských práv. Obrázek 4.17: Statistiky připojení uživatele ke Casteru. 47

Obrázek 4.18: Tlačítka na záložce Statistics Záložka Statistics Na záložce Statistics jsou umístěny další dvě záložky - záložka Mountpoints a záložka Users. Na obou těchto záložkách najdeme statistiky týkající se mountpointů a uživatelů. Pro obě záložky jsou zde umístěna společná tlačítka (obr. 4.18): tlačítko Refresh - načte data z databáze podle specifikovaného filtru (od, do a políčko Value určuje název mountpointu nebo jméno uživatele) tlačítko Export - exportuje zobrazená data do souboru ve formátu CSV 10. Záložka Statistics - Mounpoints Na záložce Statistics - Mounpoints je tabulka se statistikami mountpointů. Obrázek 4.19: Údaje v tabulce na záložce Statistics - Mounpoints V této tabulce (obr. 4.19) jsou na každém řádku následující informace: jméno mountpointu objem odeslaných dat za zvolené období průměrný počet připojených uživatelů. Toto číslo se většinou bude blížit nule, protože se počítá, kolik bylo průměrně připojených uživatelů za celé zvolené období. procento určující, kolik času ze zvoleného období byl mountpoint aktivní (NTRIP server odesílal data) Na této záložce je jediné tlačítko Graph, které zobrazí nové dialogové okno s grafem znázorňujícím objem přenesených dat NTRIP serverem (obr. 4.11). 48

Obrázek 4.20: Údaje v tabulce na záložce Statistics - Users Záložka Statistics - Users Na záložce Statistics - Users je tabulka se statistikami uživatelů. V této tabulce (obr. 4.20) jsou na každém řádku následující informace: uživatelské jméno jméno uživatele objem přijatých dat uživatelem za zvolené období procento určující, kolik spojení z celkové počtu měl uživatel fixováno počet připojení ke Casteru za zvolené období celková doba připojení ke Casteru za zvolené období Na této záložce je jediné tlačítko History, které zobrazí dialogové okno s přehledem jednotlivých spojení uživatele ke Casteru (obr. 4.17). Obrázek 4.21: Údaje v tabulce na záložce Logs Záložka Logs Na záložce Logs je přehled záznamů, které uchovávají informace o různých událostech. V tabulce umístěné na záložce Logs (obr. 4.21) jsou na každém řádku následující informace: identifikátor spojení datum a čas zapsání záznamu IP adresa, které se událost týká popis zaznamenané události 10 Comma-Separated Values je formát souboru ve kterém jsou jednotlivé položky odděleny čárkou. 49

Soupis funkcí a tlačítek na záložce Logs: tlačítko Save logs - exportuje zobrazená data do souboru ve formátu CSV tlačítko Refresh - načtení záznamů z databáze ze zvoleného dne 4.3 Pluginovací systém Plugin je jednoduchá komponenta (funkce, program), která lze importovat do jiné aplikace. Plugin je většinou jednoduchý a jednoúčelový. Plugin pouze aplikaci rozšiřuje o další funkce. Aplikace je bez pluginu samostatně funkční. Výhodou použití pluginů je možnost rozšiřovat aplikace o další funkce bez nutnosti znovu překládání zdrojových kódů, respektive není potřeba mít přístup ke zdrojovým kódům vůbec. Pluginy lze většinou do aplikace importovat i bez restartování aplikace (možnost rozšiřování funkcionality při běhu programu). Pro aplikace K152 Caster i K152 GUI mohou být vytvořeny pluginy, které umí konvertovat data mezi různými formáty. Obě aplikace využívají stejných typů pluginů. Možnost použití pluginů značně rozšiřuje možnosti K152 Casteru. Je možné online konvertovat data posílána NTRIP serverem do jiných formátů. To je možné například využít v případě, že máme starší anténu (NTRIP Source), která umí generovat data jen v RTCM 2 formátu. Díky pluginu jsme schopni tato data konvertovat pro všechny připojené uživatele do jakéhokoliv jiného formátu (např. RTCM 3). Tyto změny v konvertování dat můžeme dělat při běhu Casteru, změnou jediného parametru v source-table bez jakéhokoliv vypnutí nebo restartování Casteru. V případě K152 GUI je možné pluginy použít pro konvertování dat při zobrazení datového toku. Data jsou většinou nečitelná a při použití vhodného pluginu si můžeme data zobrazit v námi čitelném formátu. Plugin pro K152 Caster a K152 GUI musí implementovat rozhraní StreamInterface, které definuje funkce pluginů. c l a s s S t r e a m I n t e r f a c e { p u b l i c : v i r t u a l S t r e a m I n t e r f a c e ( ) ; v i r t u a l QString name()= 0 ; v i r t u a l QString convert ( const QString &message ) = 0 ; } ; Q DECLARE INTERFACE( StreamInterface, StreamConvertInterface ) ; 50

Každý plugin, kterým chceme dekódovat data, musí dědit z tohoto interface, a tudíž musí implementovat metody: convert() - konverzní algoritmus. Na vstupu je původní zpráva a na výstupu je zpráva zkonvertovaná. name() - jméno pluginu např. vstupní a výstupní formát (RTCM v2 to RTCM v3). Zdrojový kód jednoduchého pluginu EchoPlugin implementující StreamInterface (ukázka implementace): c l a s s EchoPlugin : p u b l i c QObject, S t r e a m I n t e r f a c e { Q OBJECT Q INTERFACES( S t r e a m I n t e r f a c e ) p u b l i c : QString convert ( const QString &message ) ; QString name ( ) ; } ; V konfiguračním souboru projektu (*.pro) je potřeba změnit způsob kompilace z APP na LIB. Kompilací projektu vznikne knihovna, kterou lze použít pro K152 Caster i K152 GUI. Knihovnu je nutné umístit do adresáře plugins, vytvořeném v adresáři se spouštěcími soubory aplikace. TEMPLATE = LIB 4.4 Další aplikace Pro účely této práce bylo nutné vytvořit další menší aplikace, které nám usnadnily testování Casteru. 4.4.1 VirtualClient K příjemnějšímu testování K152 Caster byla vytvořena aplikace VirtualClient. Tato aplikace nahrazuje typického NTRIP klienta uživatele s přijímačem. Aplikace obsahuje jedno grafické okno, ve kterém je možné definovat připojení k NTRIP Casteru a parametry odesílané v NMEA zprávě. Po stisknutí tlačítka Generate je vygenerováno zadané množství dotazů (spojení na Caster). Ukázka aplikace na obrázku 4.22. 51

Obrázek 4.22: Grafické rozhraní aplikace VirtualClient. 4.4.2 VirtualGenerator K otestování funkcionality VRS mountpointů (mountpoint pro virtuální referenční stanici) bylo nutné zajistit generování dat na základě NMEA zprávy poslané NTRIP klientem. Proto vznikla jednoduchá aplikace VirtualGenerator, která zajistí generování nebo spíše přeposílání těchto dat z VRS mountpointů CZEPOSu. Pokud se připojí klient na VRS mountpoint, musí nejprve odeslat NMEA zprávu. K152 Caster tuto zprávu zpracuje a uloží záznam do tabulky Virtuals. Aplikace VirtualGenerator běží na pozadí a v pravidelných intervalech kontroluje tuto tabulku. Po zjištění nového záznamu v tabulce Virtuals, spustí VirtualGenerator aplikaci ntripserver 11, která se připojí na CZEPOS Caster, přepošle původní NMEA zprávu od klienta a začne přeposílat přijatá data z CZEPOSu přes K152 Caster NTRIP klientovi (viz. obr. 4.23). 4.5 Komunikace Caster - GUI Jak je ze schématu na obrázku 4.1 patrné, tak GUI i Caster mohou běžet na jiných počítačích. Komunikace mezi těmito aplikacemi je hlavně realizována skrze databázi. Bylo nutné vytvořit systém zapisování a načítání informací z databáze tak, aby se jedna aplikace vždy co nejdříve dozvěděla o změně, kterou vykoná aplikace druhá. Na druhou stranu bylo nutné optimalizovat tento proces, aby se databáze a spojení mezi databází a aplikacemi příliš nezatěžovalo. 11 Aplikace ntripserver je volně ke stažení ze stránek http://igs.bkg.bund.de/ntrip/download. Jedná se o program, který na jedné straně přijímá data a na druhé straně data odesílá. Vstupem a výstupem tohoto programu může být NTRIP Caster, sériový port a další. 52

V prvním návrhu aplikací se všechny informace aktualizovali jednou za vteřinu. To se později projevilo zejména na zpomalení aplikace K152 GUI, když bylo v tabulkách větší množství záznamů. Ve finální verzi obou aplikací je načítání a obnova informací z databáze řešená různě pro různé typy záznamů. Některé záznamy se aktualizují pravidelně každých X vteřin, některé jsou aktualizovány pouze při akci (spuštění programu, stisknutí tlačítka). K152 Caster zapisuje do databáze: při spuštění zapíše informace (ip adresu, číslo G portu, max. počet spojení) do tabulky Settings při připojení NTRIP klienta vytvoří záznam v tabulce Receivers a User Stats při připojení NTRIP serveru vytvoří záznam v tabulce Mountpoints při připojení NTRIP klienta k VRS mountpointu vytvoří záznam v tabulce Virtuals každou minutu zapíše statistiky (počet přijatých dat, počet připojených klientů) pro každý NTRIP server do tabulky Mountpoint Stats každých 10 vteřin obnoví informace (počet odeslaných dat klientovi) pro každého připojeného NTRIP klienta v tabulce Receivers při odpojení NTRIP klienta smaže záznam z tabulky Receivers a aktualizuje záznam v tabulce User Stats při odpojení NTRIP serveru smaže záznam z tabulky Mountpoints při načtení nového pluginu vytvoří záznam v tabulce Plugins K152 Caster - načítání údajů z databáze K152 Caster načítá z databáze informace pravidelně každých 10 vteřin. K152 Caster načítá tyto záznamy: definice mountpointů definice uživatelů práva uživatelů pro připojení k mountpointům source-table záznamy 53

K152 GUI načítá z databáze následující údaje: nastavení K152 Casteru a informace pro připojení ke Casteru - při spuštění statistiky mountpointů z tabulky Mountpoint Stats - při spuštění programu a při zobrazení statistik mountpointu (možno vyvolat na několika místech v programu) informace o mountpointech a NTRIP serverech z tabulky Mountpoints - obnova každých 5 sekund informace o klientech (NTRIP klienti) z tabulky Receivers - obnova každých 5 sekund source-table záznamy z tabulek STR Sourcetable, NET Sourcetable, CAS Sourcetable - obnova při změně záznamu informace o uživatelích z tabulky Users - obnova při změně záznamu statistiky uživatelů z tabulky User Stats - obnova při zmáčknutí tlačítka Refresh na záložce Statistics - Users záznamy o různých událostech z tabulky Log Connections - obnova při zmáčknutí tlačítka Refresh na záložce Logs práva uživatelů pro připojení k mountpointům z tabulky MP User Perm - pouze při zmáčknutí tlačítka Rights na záložce Users informace o pluginech z tabulky Plugins - obnova každou minutu různé sumace (počet všech definovaných a počet aktivních - mountpointů, uživatelů a objem přenesených dat) z tabulek Mountpoints, Sources, Receivers a Users - obnova každou minutu K152 GUI - zápis do databáze K152 GUI zapisuje do databáze vždy při změně (přidání, úpravě nebo smazání) některého z následujících záznamů: mountpoint uživatel záznam source-table práva uživatele pro připojení k mountpointům 54

Kromě tohoto způsobu komunikace (přes databázi), bylo nutné vytvořit i přímé spojení Caster - GUI, aby fungovaly některé nadstandardní funkce (zobrazení datové toku a odpojování klientů od Casteru). K152 GUI si také pravidelně pomocí tohoto spojení kontroluje dostupnost Casteru. Pro přímé spojení má Caster otevřen druhý port - G port. Číslo tohoto portu je vždy o jedno číslo větší než N port. Při spuštění Casteru ve standardní konfiguraci má G port číslo 2102. Pro odpojení klienta od Casteru odešle GUI na G port příkaz: KILL [ID klienta] [mountpoint ke kterému je klient připojen] např. KILL 123 CPRG3 Pro zobrazení datového toku z NTRIP Serveru odešle GUI na G port příkaz: STREAM [jméno mountpointu] např. STREAM CPRG3 4.6 Databáze Předávání informací mezi K152 Caster a K152 GUI probíhá přes databázi. Databáze zároveň slouží jako úložiště statistik a nastavení Casteru. Řešení s ukládáním dat do databáze má tyto hlavní výhody: rychlost přístupu k datům univerzálnost programu snadná správa/údržba možnost využití externích programů pracujících s daty v databázi přístup k datům po síti Primárně tento projekt vznikl pro databázi MySQL, která je dnes asi nejpoužívanější databází vůbec. MySQL je open-source databáze, kterou je možné provozovat na počítačích s OS Windows i Linux. Více informací na http://www.mysql.com/ V případě potřeby je snadné projekt upravit tak, aby spolupracoval i s jinými typy databází (SQLite, MSSQL atd.). Pro K152 Caster je doporučeno použití MySQL databáze ve verzi 5.5. 55

4.6.1 Konfigurace MySQL V základním nastavení po instalaci má MySQL databáze omezení na maximálně 100 konkurenčních spojení. Toto omezení může být limitující pro K152 Caster. Caster vyžaduje pro každého připojeného klienta (NTRIP Server i NTRIP Client) jedno spojení do databáze. Tento limit je proto nutné zvýšit úpravou konfiguračního souboru databáze (Debian) /etc/mysql/my.conf, nastavením parametru max connections na vyšší hodnotu (doporučeno alespoň 350, ale záleží samozřejmě na využití Casteru) a restartováním databáze. $ s e r v i c e mysql r e s t a r t Nastavení tohoto parametru na jiných operačních systémech je stejné, liší se pouze umístění konfiguračního souboru a způsob restartování databáze. Při startu programu Caster kontroluje, zda v databázi, do které mu byl přidělen přístup, jsou všechny tabulky. Pokud některá tabulka chybí, tak ji Caster vytvoří. Caster nedetekuje strukturu jednotlivých tabulek, ale pouze jejich přítomnost v databázi. Proto je nutné při upgrade na novější verzi Casteru, ve které byla změněna struktura tabulek v databázi, provést úpravu manuálně. Na obr. 4.24 je znázorněno celé schéma databáze. 4.6.2 Popis databázových tabulek Seznam tabulek v databázi: Sources - zakladání mountpointů Mountpoints - informace o připojených NTRIP serverech Mountpoint Stats - statistiky mountpointů Users - seznam uživatelů User Stats - statistiky uživatelů MP User Perm - práva uživatelů k mountpointům Receivers - připojení NTRIP klienti STR Sourcetable - záznamy typu STR NET Sourcetable - záznamy typu NET CAS Sourcetable - záznamy typu CAS Virtuals - klienti připojení na VRS mountpoint 56

Settings - nastavení Casteru Plugins - informace o pluginech Log Connections - záznamy Tabulka Sources V tabulce Sources je seznam definovaných mountpointů, IP adres a hesel. Při připojení NTRIP serveru je kontrolováno heslo a IP adresa serveru vůči záznamům v této tabulce. Jakmile definuje administrátor nový mountpoint, K152 GUI přidá nový řádek do této tabulky. jméno popis typ id Primární klíč, identifikátor int name Jméno mountpointu varchar(100) ip IP adresa NTRIP Serveru, int který může vytvořit mountpoint (0 = jakákoliv IP). password Heslo k mountpointu varchar(255) (ALL = jakékoliv heslo). Tabulka Mountpoints Do tabulky Mountpoints se ukládají informace o NTRIP serverech připojených ke Casteru. Tabulka obsahuje informace o připojení NTRIP serveru (čas připojení, IP adresa, jméno mountpointu), množství odeslaných dat a další informace. Jakmile se NTRIP server připojí ke Casteru, K152 Caster automaticky vloží záznam do této tabulky. Po odpojení serveru Caster záznam z tabulky vymaže. 57

jméno popis typ id Primární klíč, identifikátor int name Jméno mountpointu. varchar(100) socket Socket deskriptor spojení. int ip IP adresa NTRIP serveru, int který je připojen userpass Heslo použité NTRIP varchar(255) serverem k vytvoření mountpointu. date Datum a čas připojení NTRIP datetime serveru. data Množství odeslaných dat. int Tabulka Mountpoint Stats Mountpoint Stats obsahuje statistiky mountpointů. Do této tabulky se zaznamenává množství odeslaných dat NTRIP Serverem a aktuální počet připojených klientů. Každý mountpoint zaznamenává své statistiky jednou za minutu. Pro každý aktivní mountpoint každou minutu K152 Caster přidá jeden řádek do této tabulky. jméno popis typ id Primární klíč, identifikátor int thread Identifikátor spojení int mountpoint Jméno mountpointu. varchar(100) time Datum a čas. datetime data Množství odeslaných dat double serverem za minutu. receivers count Počet připojených klientů. int Tabulka Users V tabulce Users je seznam uživatelů, kteří mají právo připojit se ke Casteru. Tabulka obsahuje přihlašovací údaje a další informace o uživateli. Administrátor Casteru přidává uživatele do této tabulky přes K152 GUI. 58

jméno popis typ id Primární klíč, identifikátor int username Přihlašovací jméno uživatele. varchar(255) name Jméno uživatele. varchar(255) password Heslo uživatele. varchar(255) credit Kredit uživatele. int active Parametr, zda je uživatel povolen nebo zablokován. bool connections Maximální počet simultánních int připojení uživatele ke Casteru (0 = neomezeně). Tabulka User Stats User Stats tabulka obsahuje statistiky jednotlivých spojení uživatelů ke K152 Casteru. V tabulce jsou uvedeny tyto informace: začátek a konec spojení (čas a datum), množství přijatých dat klientem a pokud klient odeslal NMEA zprávu tak i stav fixace přijímače a informace o poloze uživatele. Do této tabulky automaticky zapisuje K152 Caster vždy při připojení a odpojení klienta od Casteru. Jeden záznam v tabulce představuje jedno spojení. jméno popis typ id Primární klíč, identifikátor int user id Cizí klíč. ID uživatele. int start Datum a čas připojení klienta. datetime end Datum a čas odpojení klienta. datetime mountpoint Jméno mountpointu, ke varchar(100) kterému byl klient připojen. data Množství přenesených dat. int thread Identifikátor spojení. int fix Stav fixace přijímače během int spojení. latitude Zeměpisná šířka. float longtitude Zeměpisná délka. float Tabulka MP User Perm Do tabulky MP User Perm se ukládají práva uživatelů pro připojení k jednotlivým mountpointům. Tabulka MP User Perm realizuje vztah m:n mezi tabulkami Users a Sources. 59

Administrátor Casteru spravuje uživatelská práva k mountpointům přes K152 GUI. jméno popis typ id Primární klíč, identifikátor int user id Cizí klíč. ID uživatele. int name Jméno mountpointu, ke varchar(100) kterému má uživatel právo se připojit. Tabulka Receivers V tabulce Receivers jsou uvedeni aktuálně připojení NTRIP klienti. Do tabulky se zaznamenává IP adresa klienta, mountpoint, ke kterému je připojen a pokud klient poslal NMEA zprávu, tak i informace o jeho poloze, stav fixace atd. Do tabulky Receivers zapisuje aplikace K152 Caster. Jakmile se připojí nový NTRIP Client, Caster vytvoří v této tabulce nový záznam, jakmile se klient odpojí Caster záznam smaže. jméno popis typ id Primární klíč, identifikátor int socket Socket deskriptor spojení. int id mountpoint Cizí klíč. Identifikátor mountpointu. int ip IP adresa NTRIP klienta, int který je připojen longtitude Zeměpisná délka přijímače float klienta. latitude Zeměpisná šířka přijímače float klienta. fix Stav fixace. int satellites Počet satelitů použitých k int měření. altitude Nadmořská výška. float start Datum a čas připojení klienta. datetime data Množství přijatých dat klientem. int user id Cizí klíč. Identifikátor int uživatele. 60

Tabulka STR Sourcetable Jak název napovídá, tabulka STR Sourcetable obsahuje záznamy source-table typu STR (popis datových streamů). Záznam do tabulky STR Sourcetable musí přidat administrátor Casteru přes K152 GUI při založení nového mountpointu. 61

jméno popis typ id Primární klíč, identifikátor. int type Typ záznamu. varchar(3) name mountpoint Název mountpointu. varchar(100) identifier Identifikátor NTRIP Source, text název města. format Formát dat. text format details Dodatečné informace o text formátu dat, frekvence aktualizace ve vteřinách. carrier Informace o měření na vlnách: int 0 = Ne, 1 = L1, 2 = L1+L2 nav system Název používaného GNSS. text network Název sítě referenčních stanic. text country ISO zkratka státu, ve kterém varchar(3) je referenční stanice umístěna. latitude Zeměpisná šířka přijímače. float longtitude Zeměpisná délka přijímače. float nmea 0 = klasický mountpoints, int 1 = VRS mountpoints solution Původ dat: 0 = data z jedné int stanice, 1 = data ze sít ového řešení generator Generátor dat. text compr encryp Algoritmus pro kompresi nebo text kryptování dat. authentification Způsob autentifikace klientů: N = žádná, B = Basic, D = Digest. varchar(1) fee Zpoplatněný mountpoint: 1 znak Y = Ano, N = Ne bitrate Velikost datového toku (b/s). int misc Dodatečné informace. text rewritable Parametr, zda záznam může být změněn NTRIP serverem bool plugin id Cizí klíč. Identifikátor pluginu. int 62

Tabulka NET Sourcetable Tabulka NET Sourcetable, stejně tak jako STR Sourcetable, obsahuje source-table záznamy. V tomto případě jsou to záznamy typu NET. Záznam do tabulky NET Sourcetable může přidat pouze administrátor Casteru přes K152 GUI. Atribut Popis Formát id Primární klíč, identifikátor. int type Typ záznamu. varchar(3) identifier Identifikátor sítě referenčních text stanic. operator Provozovatel sítě referenčních text stanic. authentification Způsob autentifikace klientů: N = žádná, B = Basic, D = Digest, varchar(1) fee Zpoplatněný mountpoint: varchar(1) Y = Ano, N = Ne web net Webové stánky s informacemi text o síti. web str Webové stránky s informacemi text o NTRIP Source. web reg Webové stránky nebo mailová text adresa pro registraci. misc Dodatečné informace text Tabulka CAS Sourcetable V tabulce CAS Sourcetable najdeme poslední typ záznamů v source-table - CAS (záznamy popisující jiné NTRIP Castery). Záznam do tabulky CAS Sourcetable může přidat administrátor Casteru přes K152 GUI. 63

Atribut Popis Formát id Primární klíč, identifikátor. int type Typ záznamu. varchar(3) host IP adresa nebo hostname varchar(128) Casteru. port Číslo portu na kterém Caster int čeká na spojení. identifier Identifikátor Casteru, jméno text provozovatele. operator Provozovatel sítě referenčních text stanic. country ISO zkratka státu, ve kterém stanice leží. varchar(3) latitude Zeměpisná šířka přijímače float (stanice). longtitude Zeměpisná délka přijímače float (stanice). fallback host IP adresa nebo hostname varchar(128) záložního Casteru. fallback port Port záložního Casteru. int misc Dodatečné informace. text Tabulka Virtuals Do tabulky Virtuals se zaznamenávají klienti, kteří se připojili na tzv. mountpoint pro virtuální referenční stanici (VRS mountpoint). VRS mountpoint umožňuje generování dat speciálně pro každého jednotlivého uživatele na základě jeho polohy. V tabulce najdeme zeměpisné souřadnice klienta (odeslané pomocí NMEA zprávy), datum a čas připojení a další parametry umožnující generování dat. K152 Caster automaticky vytvoří záznam v této tabulce po připojení klienta na VRS mountpoint a odeslání NMEA zprávy s polohou přijímače. Více informací o fungování generátoru v sekci 4.4.2. 64

Atribut Popis Formát id Primární klíč, identifikátor. int mountpoint Název mountpointu. varchar(100) virt Identifikátor klienta. int latitude Zeměpisná šířka přijímače. float longtitude Zeměpisná délka přijímače. float altitude Výška přijímače. float start Datum a čas připojení klienta. datetime gpgga Celá NMEA zpráva odeslaná varchar(255) klientem. Tabulka Settings Tabulka Settings obsahuje informace o Casteru. Do tabulky se ukládají informace o IP adrese a portu, na kterém Caster čeká na spojení a datum a čas spuštění Casteru. Tyto záznamy načítá GUI aplikace při startu, a není tak nutné konfigurovat připojení ke Casteru manuálně. K152 Caster automaticky vytvoří záznam v této tabulce po spuštění. Atribut Popis Formát ip Primární klíč, IP adresa, na které Caster int běží. port Číslo G portu - port na kterém K152 int Caster čeká na spojení od K152 GUI. start Datum a čas spuštění Casteru. datetime connections Maximální počet všech simultánních int připojení ke Casteru. Tabulka Log Connections V tabulce Log Connections najdeme různé záznamy. Zaznamenává se například připojení/odpojení NTRIP klienta/ntrip serveru, NTRIP zprávy, které Caster přijme, akce, které provede administrátor Casteru v GUI (přidání uživatele, změna práv atd.). Do této tabulky zapisuje K152 Caster i K152 GUI automaticky při různých výše zmíněných událostech. 65

Atribut Popis Formát id Primární klíč, identifikátor. int thread Identifikátor spojení/aplikace. (0=Caster, int 1=GUI, ostatní=klienti/servery). date Datum a čas zalogování. datetime ip IP adresa, které se záznam týká. int event Popis události. text Plugins Plugins tabulka obsahuje záznamy týkající se pluginů, které je možno použít v Casteru pro konverzi mezi jednotlivými formáty. Poté, co K152 Caster detekuje nový plugin, vytvoří v této tabulce nový záznam s informacemi o pluginu. Více informací o pluginech viz. sekce 4.3. Atribut Popis Formát id Primární klíč, identifikátor. int name Jméno pluginu. varchar(255) active Dostupnost pluginu. bool 66

Obrázek 4.23: Schéma komunikace při připojení klienta na VRS mountpoint. 67

Obrázek 4.24: Schéma databáze. 68