České vysoké učení technické v Praze. Fakulta elektrotechnická. Diplomová práce Petr Špika

České vysoké učení technické v Praze Fakulta elektrotechnická

Diplomová práce

2010

Petr Špika

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra měření

Monitorování polohy pohybujícího se vozidla

Leden 2010

Autor: Vedoucí:

Bc. Petr Špika doc. Ing. Jaroslav Roztočil, CSc.

i

Čestné prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o dodržování etických principů při přípravě vysokoškolských závěrečných prací. Dále prohlašuji, že nemám námitek proti půjčování nebo zveřejňování mé diplomové práce nebo její části se souhlasem katedry.

V Praze 5.ledna 2010

...................... Petr Špika

ii

iii

Abstrakt První část diplomové práce je rešeršního charakteru. Stručně popisuje principy, výhody a nevýhody jednotlivých současných metod používaných pro sledování polohy pohybujících se vozidel. Druhá část této práce popisuje možnosti, jakými lze zařízení monitorující polohu automobilu realizovat. Diskutovány jsou dva možné modely - zařízení sestavené z jednotlivých částí a zařízení využívající programovatelný GSM modul. Třetí, již praktická a nejobsáhlejší část práce, se zabývá konkrétní realizací ”monitorovacího” systému. Detailně popisuje hardwarové a softwarové řešení založené na využití GSM modulu Siemens XT65. V závěru práce jsou diskutovány dosažené výsledky a je naznačeno možné budoucí vylepšení (rozšíření) navrženého systému.

Summary The master thesis consists of three main parts. The first part provides an overview and description of the methods which are used for monitoring of location of moving vehicles. There are presented the principles, advantages and disadvantages of the most widely used methods. The second part describes the possible ways of the realization of such monitoring systems. There are discussed two possible cases - the devices assembled from individual parts and the devices using a programmable GSM module. The third part is practical and most comprehensive. It deals with the main goal of the thesis, which is a practical realization of a car location monitoring system. It describes in detail hardware and software solutions based on the programmable GSM module Siemens XT65. Finally, the achieved results and the possible improvements of designed system are mentioned at the end of the project.

iv

Poděkování Na tomto místě bych rád poděkoval vedoucímu mé diplomové práce panu doc. Ing. Jaroslavu Roztočilovi, CSc. za vstřícnou a ochotnou spolupráci. Dále panu Ing. Ondřeji Janovskému z firmy Alarex-Group s.r.o. za zapůjčení GSM modulu a pomoc při řešení technických problémů, které během psaní práce vznikaly. Velké poděkování bych rád věnoval také mým rodičům za maximální podporu během celého studia.

Obsah Úvod

1

1 Analýza možností monitorování polohy pohybujícího se vozidla

2

1.1 1.2 1.3

Monitorování polohy pomocí globálních navigačních systémů . . . . . . . . Monitorování polohy pomocí GSM sítě . . . . . . . . . . . . . . . . . . . . Radiové zaměřování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 3 6

2 Návrh systému monitorujícího polohu vozu 2.1 Požadavky na navrhovaný systém . . . . . . . . . . . . . . . . . . . . . . . 2.2 Možnosti realizace systému monitorujícího polohu vozu . . . . . . . . . . . 2.2.1 Poskládání systému z jednotlivých částí . . . . . . . . . . . . . . . .

7 7 8 8

2.2.2

Využití programovatelného GSM modulu . . . . . . . . . . . . . . .

11

3 Praktická realizace systému pro sledování polohy automobilu 3.1 Popis realizovaného řešení . . . . . . . . . . . . . . . . . . . . . . . . . . .

12 12

3.2

3.3

Hardwarová část řešení . . . . . . . . . . . . . 3.2.1 GSM modul Siemens XT65 . . . . . . 3.2.2 M2M universal motherboard 2.0 . . . . 3.2.3 Návrh vstupů a výstupů . . . . . . . . Softwarová část řešení - modul Siemens XT65

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

13 14 16 17 20

3.3.1 3.3.2 3.3.3

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

21 23 26 26

Inicializace . . . . . . . . . . . . . . . . . . . . . . . . . . Stav READY . . . . . . . . . . . . . . . . . . . . . . . . . Stav sledování s UDP protokolem . . . . . . . . . . . . . .

27 28 28

Stručný úvod do MIDletů . . Použité vývojové prostředí . . Popis navržené řídící aplikace 3.3.3.1 Načtení parametrů . 3.3.3.2 3.3.3.3 3.3.3.4

v

. . . .

. . . .

. . . .

. . . .

. . . .

OBSAH

vi

3.3.3.5 3.3.3.6 3.3.3.7 3.3.3.8 3.3.3.9

Stav sledování s TCP protokolem Příprava dat k odeslání . . . . . Zpracování příchozího hovoru . . Zpracování příchozí SMS zprávy Ukončení programu . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

29 30 31 32 32

3.4

Softwarová část řešení - serverová strana 3.4.1 Java UDP server . . . . . . . . . 3.4.2 Java TCP server . . . . . . . . . 3.4.3 Databáze . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

32 32 34 35

3.5

Zpracování uložených dat . . . . . . . . . . . . . . . 3.5.1 Navržené webové rozhraní - vzhled . . . . . 3.5.2 Navržené webové rozhraní - popis . . . . . . 3.5.3 Navržené webové rozhraní - technické řešení 3.5.3.1 Zobrazení nejnovější souřadnice . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

36 36 40 40 41

Zobrazení souřadnic z daného období . . . . . . . . . . . . Generování GPX souboru a jeho zobrazení . . . . . . . . . Odeslání GPX na FTP server a e-mailovou adresu . . . .

42 43 44

4 Praktické otestování systému 4.1 Statické testování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Testování ve vozidle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48 48 51

5 Závěrečné zhodnocení

54

Seznam zkratek

55

Seznam obrázků

57

Seznam tabulek

59

Použitá literatura

60

A Schéma a blokový diagram modulu Siemens XT65

61

B Technické parametry GSM modulu Siemens XT65

63

C Ukázka využití prostředí NetBeans pro vývoj MIDletů

67

3.5.3.2 3.5.3.3 3.5.3.4

. . . .

. . . . .

OBSAH

vii

D Stavový diagram

70

E Zařízení ve vozidle a vygenerované trasy

72

Úvod Tato diplomová práce se zabývá tématem monitorování polohy jedoucího vozidla. Ačkoliv se jedná o téma, jež bylo jistě již mnohokráte rozebíráno, jde o téma stále zajímavé. Důkazem toho je stále rostoucí nabídka zařízení a služeb poskytujících on-line monitoring vozidel. Lze se o tom snadno přesvědčit např. zadáním termínů jako ”monitoring vozidel”, ”elektronická kniha jízd”, ”sledování vozidel” a jim podobných do některého z internetových vyhledávačů. Nabízena jsou řešení od jednoduchých GSM modulů odesílajících pouze informace o poloze automobilu, až po komplexní softwarové systémy nabízející mimo sledování polohy daného vozidla (či skupiny vozidel) i celou škálu doplňkových služeb. Takovýmito službami mohou být např. vedení elektronické knihy jízd, dálkové sledování požadovaných parametrů vozidel (např. teplot v nákladním prostotu, stavu paliva, . . .) atd. Samostatnou kapitolou jsou pak firmy nabízející zabezpečení a vyhledávání vozidel. I v této oblasti je nabídka služeb v České Republice již poměrně široká. Cílem této práce je udělat rešerši popisující metody, jež se dnes pro lokalizaci vozidel používají, zamyslet se nad tím, jakým způsobem lze systémy monitorující polohu vozu realizovat, a na základě toho zkusit navrhnout a realizovat vlastní systém, jenž by byl pro sledování vozu využitelný.

1

1 Analýza možností monitorování polohy pohybujícího se vozidla V době psaní této práce se pro monitorování polohy pohybujících se objektů využívá třech způsobů založených na třech rozdílných principech. První možností, jak určit polohu nějakého objektu (v našem případě vozidla), je využití některého z globálních navigačních systémů. Další možností je využití vhodných funkcí, které jsou poskytovány mobilními telefony a mobilními operátory (tzv. GSM lokalizace), a poslední způsob, jak určit polohu vozidla, je využití radiového vyhledávání.

1.1

Monitorování polohy pomocí globálních navigačních systémů

Globální družicové navigační systémy, anglicky Gobal Navigation Satellite Systems (GNSS), jsou systémy umožňující přesné určování 3D polohy a času s celosvětovým pokrytím. Zjednodušeně lze GNSS popsat jako družicové radiové dálkoměrné systémy1 . Mezi nejznámější GNSS patří zejména americký systém s původním jménem NAVSTAR GPS (jehož vývoj byl zahájen již v roce 1973), ruský GLONASS a evropský projekt s názvem Galileo2 . Cílem této práce však není detailně popsat princip těchto systémů. Případní zájemci mohou nalézt podrobné informace jak o principu, tak o aktuálním stavu vývoje uvedených systémů na oficiálních webových stránkách těchto projektů (např. [10], [11], [12]) a na mnoha dalších webech zabývajících se danou tématikou. Pro účely této práce je podstatné to, že z uživatelského hlediska je pro využití GNSS potřeba pouze adekvátní přijímač. Takový přijímač je pak schopen vypočítat svoji polohu s přesností na desítky až 1

Dálkoměrný družicový - pro určení polohy zaměřovaného objektu se využívá známé vzdálenosti tohoto objektu od kosmických družic, jejichž poloha je známa. 2 Mimo zmíněných celosvětových globálních navigačních satelitních systémů je vyvíjeno nebo již funguje i několik menších regionálních systémů, jako je např. čínský Beidou-1, indický IRNSS nebo japonský QZSS.

2

1.2. MONITOROVÁNÍ POLOHY POMOCÍ GSM SÍTĚ

3

jednotky metrů1 , což je pro určení polohy pohybujícího se vozidla dostačující. Hlavní výhody lokalizace pomocí GNSS • Služba dostupná zdarma 24 hodin denně kdekoliv na světě. • Relativně vysoká přesnost určení polohy. Hlavní nevýhody lokalizace pomocí GNSS • Nutnost přímé viditelnosti oblohy přijímačem. • Relativně dlouhá doba potřebná pro prvotní určení polohy po zapnutí přijímače. Tato doba záleží na mnoha faktorech (viditelnost družic, změna polohy přijímače od jeho posledního zapnutí, . . .). Za ideálních podmínek může být v rozsahu sekund, za nepříznivých okolností může dosahovat až jednotek minut.

1.2

Monitorování polohy pomocí GSM sítě

Lokalizace pomocí GSM sítě je založená na využití znalostí její struktury a monitorování činnosti lokalizovaného mobilního zařízení, které je do ní přihlášeno. Využíváno je několika metod s rozdílnou přesností určení polohy. Základní z metod využívá tzv. Cell ID (Obrázek 1.1). GSM síť je tvořena sítí základnových stanic (tzv. BTS), jež vytváří buňkovou strukturu. Pomocí Cell ID, neboli identifikačního čísla buňky, a známé polohy základnové stanice pak lze určit polohu mobilního zařízení, které je k dané buňce, resp. základnové stanici, přihlášeno. Poloha základnových stanic je známa a velikost buněk se pohybuje v závislosti na lokalitě od cca 100 až 500 metrů čtverečních v městských oblastech až po jednotky či desítky kilometrů čtverečních v odlehlých nezastavěných oblastech. S takovouto přesností může být tedy stanovena i poloha daného mobilního zařízení. S využitím výpočtu průniků buněk (mobilní zařízení přijímá signál z více základnových stanic) lze přesnost lokalizace dle dostupných informací zvýšit na přibližně 300m.

1

Ve speciálních nebo vědeckých aplikacích může být pak přesnost určení polohy v řádu centimetrů až milimetrů.


4

Obrázek 1.1: Lokalizace s využitím metody Cell ID

Pro další zpřesnění určení polohy mobilního zařízení v GSM síti lze využít výpočtu doby šíření průchodu signálu mezi tímto zařízením a sítí pomocí parametru Timing Advance (TA). Ze znalosti parametru TA a rychlosti šíření signálu lze pak určit i vzájemnou vzdálenost mobilního zařízení a základnové stanice. Udávaná přesnost určení této vzdálenosti je přibližně 500 metrů. Přibližnou polohu lokalizovaného zařízení (s přesností na desítky metrů) lze pak určit při znalosti jeho vzdálenosti od tří BTS jednoduchou triangulací.

Obrázek 1.2: Metoda Timing advance

Další možnou metodou pro určení polohy GSM zařízení je metoda Enhanced Observed Time Difference (E-OTD). Ta je založená na sledování časových rozdílů mezi příchody signálů od tří a více základnových stanic. Pozice mobilního zařízení je v tomto případě vypočtena s přesností 30-300m. S přesností určení polohy kolem 300 metrů lze také počítat při použití metody nazývané Angle of Arrival. Tato metoda vyžaduje použití směrových antén a znalosti vyzařovacích


5

charakteristik. Měření úhlu, pod kterým je signál přijímán, se provádí v základnové stanici nebo mobilním zařízením. Výsledkem jsou přímky, které stanicí a mobilním zařízením procházejí. Poloha je poté stanovena jako průnik těchto přímek (Obrázek 1.3).

Obrázek 1.3: Metoda Angle of Arrival

Poslední metoda, která bude v rámci popisu GSM lokalizace zmíněna, je metoda Enhanced Cell Global Identity (E-CGI). Jedná se o vylepšení metod Cell ID a Timing advance o měření úrovní signálů. Dle [5] E-CGI používá pro výpočet vzdálenosti mezi mobilním zařízením a základnovou stanicí model šíření signálů. Podle naměřených úrovní signálů v místě mobilního zařízení a znalosti vysílacích výkonů základnových stanic jsou tak predikovány oblasti s nejpravděpodobnějším výskytem uživatele. Jeho poloha je poté obvykle stanovena jako těžiště této oblasti. Přesnost metody E-CGI je kolem 50-550m pro městské oblasti a 250m-8km pro venkovské oblasti. Více informací o GSM lokalizaci, včetně odkazů na další zdroje zabývající se danou problematikou, lze nalézt v [5]. Hlavní výhody GSM lokalizace • Možnost lokalizace i v oblastech, kde není možný příjem GPS signálu (interiéry budov, garáže atd.). • Možnost zjištění polohy daného mobilního zařízení operátorem. Dnes již standardně nabízená služba (zpoplatněná).

1.3. RADIOVÉ ZAMĚŘOVÁNÍ

6

Hlavní nevýhody GSM lokalizace • Menší přesnost v porovnání s lokalizací pomocí GNSS. • Náročnější implementace (málo dokumentace, složité výpočty, . . .).

1.3

Radiové zaměřování

Radiové vyhledávání pracuje na principu radiolokačního zaměření miniaturního zdroje signálu. Pro zaměření se používá síť radiových zaměřovačů pokrývajících požadovanou oblast. Tato metoda je používána zejména velkými firmami nabízejícími zabezpečení vozidel1 . Pro přesné zaměření jsou v takových případech používána vyhledávací vozidla a letadla. Tato metoda dle dostupných informací umožňuje dobře lokalizovat požadované objekty i v podzemních a krytých prostorách. Hlavní výhody radiového zaměřování • Možnost lokalizace i v případech, kde není k dispozici GPS signál a signál GSM je také nedostupný, či záměrně rušený. Hlavní nevýhody radiového zaměřování • Nutné speciální technické vybavení (pro plošné monitorování prostoru nutné vybudování sítě monitorovacích stanic, pro dohledání nutnost speciálně vybavených vozidel či letadel).

1

Příkladem může být firma SECAR BOHEMIA, a. s. a její systém vyhledávání vozidel SHERLOG.

2 Návrh systému monitorujícího polohu vozu Cílem této práce je navrhnout systém, který bude monitorovat polohu vozidla a zjištěné souřadnice bude schopný v reálném čase posílat prostřednictvím GSM sítě na určené cílové zařízení. Takovýmto zařízením má být GSM modem nebo mobilní telefon či FTP server zapojený v síti Internet. V následující části budou probrány základní možnosti realizace systému monitorujícího polohu vozu a v další části pak bude takovýto systém konkrétně navržen a realizován.

2.1

Požadavky na navrhovaný systém

Jak již bylo uvedeno výše, navrhovaný systém musí být schopný zejména zjistit svoji polohu a tu odeslat na požadované cílové zařízení. Pro tento účel musí disponovat vhodnými prostředky. Mimo to by měl být také snadno ovladatelný, stabilní a dobře implementovatelný do elektrické instalace automobilu. Z toho vyplývají i další požadavky, které je třeba brát při návrhu zařízení v potaz. Mezi hlavní takové požadavky patří:

• Možnost zařízení dálkově ovládat Mělo by být možné dálkově, tj. prostřednictvím GSM sítě, zapnout/vypnout odesílání souřadnic na přednastavené cílové zařízení a zjišťovat, např. pomocí SMS zpráv, aktuální stav zařízení. • Možnost ovládat základní funkce zařízení také lokálně Pomocí tlačítek či přepínačů by mělo být možné zapnout zařízení do pohotovostního režimu, aktivovat/deaktivovat odesílaní dat a bezpečně vypnout zařízení. • Stabilita V zařízení by mělo být zajištěno ošetření maxima možných chyb, které mohou během

7

2.2. MOŽNOSTI REALIZACE SYSTÉMU MONITORUJÍCÍHO POLOHU VOZU

8

provozu nastat, a ty řádně ošetřit. V úvahu připadá například také použití softwarového či hardwarového watchdogu. • Rozumný formát odesílaných dat Odesílaná data by měla být v takovém formátu, aby bylo možné jejich další snadné využití. V úvahu přichází navrhnout jiný formát výstupních dat pro jejich odesílání ve formě SMS zpráv na mobilní telefon a jiný např. pro jejich odesílání na server. • Možnost modifikace Zařízení by mělo disponovat dostatkem vstupů/výstupů tak, aby v případě dodatečných požadavků na činnost systému1 , toto mohlo být provedeno co nejjednodušeji, ideálně jen úpravou softwaru.

2.2

Možnosti realizace systému monitorujícího polohu vozu

Požadované zařízení je samozřejmě možné navrhnout a konstruovat mnoha způsoby. Zařízení však vždy bude muset obsahovat část schopnou zjistit polohu (tj. GPS přijímač), část schopnou komunikovat se sítí mobilního operátora (tj. mobilní telefon či GSM modul) a část, která se postará o řízení činnosti celého zařízení a zpracovávání dat.

2.2.1

Poskládání systému z jednotlivých částí

Jedním z možných řešení, jak zařízení realizovat, je ”poskládat” jej z jednotlivých výše uvedených částí (viz Obrázek 2.1).

Obrázek 2.1: Orientační schéma monitorovacího systému poskládaného z jednotlivých částí

1

Může se jednat např. o požadavek moci na dálku vypnout motor, odposlouchávat interiér vozu atd.


9

Při výběru jednotlivých částí máme následující možnosti: Výběr GPS části Co se výběru GPS přijímačů týká, je na dnešním trhu výběr skutečně široký. Vybírat lze z příjímačů osazených různě výkonnými chipsety1 , vybavených různými druhy komunikačních rozhraní2 , podporujících různé GPS protokoly3 , různé typy napájení atd. Dobře si lze představit např. využití průmyslových OEM GPS přijímačů firmy Leadtek. Ukázka takového přijímače určeného pro SMD montáž je na Obrázku 2.2 (více například přímo na http://www.leadtek.com/eng/).

Obrázek 2.2: GPS přijímač LR9805ST firmy Leadtek

Výběr GSM části Tato část může být v nejjednodušším případě tvořena obyčejným mobilním telefonem ovládaným AT příkazy prostřednictvím sériového rozhraní. Mnohem sofistikovanější řešení však přináší využití GSM modulů. Ty jsou mnohem lépe přizpůsobeny pro dané použití (konstrukce, připojení externí antény, způsob napájení, absence displeje, klávesnice a hla1

Dnes asi nejpoužívanější jsou GPS chipsety založené na SiRF StarIII architektuře (http://www.sirf. com/products/gps_chip.html). Z dalších jmenujme např. chipsety NEMERIX (http://www.nemerix. com), MTK, SONY atd. 2 Nejčastěji jsou GPS přijímače vybaveny rozhraním RS232, ale existují i moduly vybaveny např. rozhraním bluetooth či CompactFlash. 3 Pojmem GPS protokoly jsou zde myšleny jak podporované formáty výstupních dat GPS přijímače (NMEA-0183, SiRF Binary,. . . ), tak přijímačem podporované GPS systémy jako takové (v dnešní době jen GPS a Glonass).


10

sové části, . . .). I v této oblasti je paleta dostupných produktů již dostatečně široká. Asi nejznámější jsou výrobky firmy Siemens (moduly TC35i, MC39i, TC63, . . .) nebo dále pak např. firem Motorola (G24) či SonyEricsson (GR47, GR48, . . .). Mimo zmíněné prověřené kvalitní moduly renomovaných firem lze však samozřejmě sehnat i levnější moduly od ”noname” výrobců. Výběr řídící části Hardware řídící části by měl obsahovat alespoň následující komponenty:

• Paměť pro uložení řídícího programu a dat. • Digitální výstupy pro spínání diagnostických signálů (např. LED diod) a pro ovládání pomocných obvodů zařízení. • Digitální vstupy pro snímání řídících vstupů a stavových hlášení pomocných obvodů systému. Mimo to musí být řídící jednotka schopná:

• Komunikovat s GPS přijímačem prostřednictvím některého z GPS protokolů. • Komunikovat s GSM modulem prostřednictvím AT příkazů. • Zpracovávat data (převod dat z GPS přijímače do požadovaného formátu pro odeslání, . . .). Je patrné, že výše uvedené funkce může plnit např. celá řada mikroprocesorů. Ať už některý z velkého množství jednodušších mikroprocesorů pro všeobecné použití (příkladem může být např. Atmel řady 8052) nebo některý ze složitějších, např. DSP, mikroprocesorů, které nabízejí větší výpočetní výkon (24bitové procesory Motorola DSP56000, . . .). Výhody systému poskládaného z jednotlivých částí • Možnost postavit si zařízení skutečně ”na míru”. • Možnost levného řešení.


11

Nevýhody systému poskládaného z jednotlivých částí • Složitější návrh.

2.2.2

Využití programovatelného GSM modulu

Další možnost jak monitorovat polohu vozu je využít programovatelného GSM modulu. Takovéto moduly jsou přímo určeny pro vzdálenou komunikaci, monitoring nebo řízení. Obsahují v sobě již většinu prostředků potřebných pro daný účel. Zjednodušeně si je lze představit jako spojení GSM a řídící části z řešení diskutovaného výše (Obrázek 2.3).

Obrázek 2.3: Využití programovatelného GSM modulu

Mezi nejznámější výrobce programovatelných GSM modulů patří firma Siemens1 . Moduly této firmy jsou založeny na JavaT M technologii a po jejich doplnění o pomocné obvody (obvody napájení, spouštění, . . .) a naprogramování a nahrání příslušné Java aplikace představují moderní řešení pro návrh M2M aplikací. Výhody programovatelných GSM modulů • Zjednodušení výsledného řešení (menší pravděpodobnost poruch). • Zmíněné moduly jsou osvědčené a vyzkoušené mnoha uživateli. • Lze využít doplňkových služeb (update softwaru prostřednictvím GSM sítě, . . .). Nevýhody programovatelných modulů • Do jisté míry omezený výběr modulů. • Vyšší cena. 1

Z dalších výrobců lze uvést např. firmu Motorola a její GSM moduly G24.

3 Praktická realizace systému pro sledování polohy automobilu V následujících částech bude popsána konkrétní realizace systému umožňujícího dálkově sledovat polohu vozu. Nejdříve bude čtenáři navržený systém popsán a vysvětleno jeho fungování, dále pak budou detailněji popsány jednotlivé části realizovaného řešení.

3.1

Popis realizovaného řešení

Jako stavební kámen požadovaného zařízení byl zvolen programovatelný GSM modul XT65 firmy Siemens (Obrázek 3.1). Tento modul byl zvolen s ohledem na vlastnosti, které vývojáři nabízí a které jsou pro daný účel ideálně vyhovující. Výhodou tohoto modulu je integrovaný citlivý GPS chip a za jistou výhodu se dá považovat i možnost ovládat tento modul aplikací psanou v jazyce JavaT M MicroEdition (JavaMET M ). V našem případě je řídící aplikace navržena tak, že modul umožňuje odesílání GPS souřadnic prostřednictvím UDP či TCP protokolu na cílové zařízení či po vyžádání (prozvonění) ve formě SMS zprávy na číslo volajícího. Jako cílová zařízení pro UDP resp. TCP přenos byl zvolen UDP resp. TCP server běžící na vzdáleném osobním počítači zapojeném v síti internet. Obě serverové aplikace byly naprogramovány v programovacím jazyku Java a pro přenos dat v rámci GSM sítě byla zvolena datová služba GPRS. Maximální možná frekvence vyčítání dat z GPS přijímače je 1 sekunda. S takovouto minimální periodou lze také data z modulu na server odesílat. Implementována byla také funkce postupného odesílání, kdy se neposílají souřadnice jednotlivě, ale ukládají se do dočasného bufferu a odesláno je až několik souřadnic najednou. To dává GSM modulu dostatek času na přijetí hovoru či SMS zprávy v době mezi odesíláním dat. V případě postupného odesílání jsou data odesílána jednou za 15 až 24 sekund a počet v paketu odesílaných souřadnic je závislý na nastavené periodě vyčítání dat z GPS přijímače. V případě maximální frekvence vyčítání dat (tj. jednou za sekundu) je v paketu odesíláno

12

3.2. HARDWAROVÁ ČÁST ŘEŠENÍ

13

15 souřadnic, v případě, že jsou GPS data vyčítána jednou za tři sekundy, je odesíláno 5 souřadnic atd. Překročí-li perioda vyčítání dat hranici čtrnácti sekund, je odesílána pouze jedna souřadnice a perioda odesílání dat je rovna nastavené periodě vyčítání dat z GPS přijímače. Ovládat modul je možné jak lokálně, tak vzdáleně. Lokální ovládání je řešeno dvěma přepínači a dvěma tlačítky. Jeden přepínač slouží k aktivaci/deaktivaci odesílání dat na server, druhý pak k vypnutí modulu. Zapnutí modulu a spuštění řídícího programu je automatické (po přivedení napájení). Tlačítka slouží k restartování modulu. Vzdáleně lze ovládat pouze aktivaci resp. deaktivaci odesílání dat na server, a to prostřednictvím SMS zprávy s textem SLEDOVANI resp. READY. Po pouhém prozvonění SIM karty modulu je na číslo volajícího odeslána SMS zpráva informující o aktuálním stavu modulu, o počtu souřadnic, které již byly od zapnutí modulu na server odeslány, a zejména pak o aktuální pozici modulu. Souřadnice jsou odeslány ve formě odkazu na http://maps.google.com/, což umožňuje si v mobilu, pokud ten to podporuje, okamžitě v internetovém prohlížeči aktuální pozici modulu, resp. automobilu, zobrazit. Na straně serverů jsou přijatá data zkontrolována a uložena do MySQL databáze. Toto řešení rozšiřuje možnosti dalšího zpracování přijatých souřadnic a jedná se zcela jistě o lepší způsob řešení, než by bylo odesílání dat ve formě souborů na FTP server či ve formě přílohy jako součást e-mailů. Nicméně i tyto funkce byly implementovány. Díky navrženému webovému rozhraní je možné vyčítat data z databáze, vizualizovat je, či z nich generovat datové soubory se strukturou založenou na datovém formátu GPX a tyto soubory pak odesílat na FTP server či jako přílohy e-mailových zpráv. Vizualizace dat ve webovém rozhraní je opět založena na využití serveru http://maps.google.com/ a stejné mapy jsou použity také pro zobrazení trasy uložené ve vygenerovaných GPX souborech.

3.2

Hardwarová část řešení

Ačkoliv by bylo možné požadované zařízení poskládat z několika částí tak, jak bylo naznačeno v druhé kapitole, bylo po zvážení všech pro a proti rozhodnuto využít pro daný účel již zmiňovaný GSM modul Siemens XT65. Následující podkapitoly obsahují základní popis tohoto modulu a popis vývojové desky M2M universal motherboard 2.0, která byla v práci také použita. Dále je pak popsána technická realizace vstupů/výstupů sloužících pro řízení činnosti modulu.


3.2.1

14

GSM modul Siemens XT65

XT65 spojuje Quad-band GSM/GPRS modul s GPS přijímačem a programováním v jazyce JavaMET M . Reklamní slogany doslova píší: „Siemens XT65 je vůbec první modul, který integruje GSM a GPS v naprostém souladu, nejde jen o pouhou kombinaci. Výrobci fleetmanagementu nebo navigace založené na GPS mohou svoje produkty vyvinout podstatně dříve a za nižší náklady hlavně díky platformě JavaMET M . Čtyřpásmová podpora umožňuje sledování nákladů osob, vozidel a dalších objektů v jakékoliv síti GSM. O pravdivosti a váze takovýchto tvrzení lze samozřejmě polemizovat. Jde samozřejmě především o reklamu. Pravdou však zůstává, že technické parametry toho modulu jej skutečně předurčují pro použití v oblasti transportu, logistiky, zabezpečovací techniky, nebo jako je tomu v našem případě, v oblasti on-line sledování polohy. Základní parametry GSM modulu Siemens XT65: GSM pásma 850/900/1800/1900 MHz GPRS třídy 12, podpora kódovacích schémat CS1 až CS4 J2ME profil IMP-NG, CLDC 1.1 HI Provozní teplota -30◦ C až +65◦ C Napájecí napětí 3.3V až 4.5V Rozměry 34x59x3,5mm

Obrázek 3.1: GSM modul Siemens XT65


15

Některé z dalších parametrů modulu Siemens XT65: GPS přijímač - Architektura: SiRF, 16 kanálů, L1 1575.42 MHz -

Podporované protokoly: NMEA-0183, RTCM 2.2 a UBX binární protokol Podporované módy: GPS, AGPS, DGPS, SBAS Přesnost určení polohy: 2.5m CEP, 5.0m SEP Přesnost s využitím DGPS/SBAS: 2.0m CEP, 3.0m SEP

- Doba startu (průměrné hodnoty): Hot start < 3.5s, Warm start 33s, Cold start 34s Sériové rozhraní - Osmivodičové rozhraní (ITU-T V.24 protokol) - Přenosová rychlost: 300 bps až 460 800 bps - RTS0/CTS0 a XON/XOFF flow control - Multiplex vyhovující GSM 07.10 Multiplexer protokolu Deset vstupně/výstupních programovatelných pinů (GPIO) - jeden z pinů lze využít jako čítač pulsů o frekvenci až 1KHz USB 2.0 Full Speed (12Mbit/s) I2C sběrnice s přenosovou rychlostí až 400kbps SPI sběrnice s přenosovou rychlostí až do 6.5Mbps

1

Dvě analogová audio rozhraní (2 mikrofonní vstupy a 2 výstupy na sluchátka) SIM rozhraní podporující 3V a 1.8V SIM karty Z výše uvedených parametrů je patrné, že modul disponuje dostatečným množstvím funkcí. Ty umožňují nejenom plnit požadovaný úkol, tedy moci určovat polohu a tuto bezdrátově posílat na nějaké cílové zařízení, ale lze jich využít i pro případné rozšíření aplikace 1

Když je aktivní SPI sběrnice nelze využívat rozhraní I2C


16

o další funkcionality (viz závěr práce). Blokové schéma modulu lze nalézt v příloze A, kompletní technickou specifikaci v příloze B a celkový podrobný popis hardwaru modulu pak v [1].

3.2.2

M2M universal motherboard 2.0

Modul XT65 jako základ požadované aplikace je třeba doplnit dalšími podpůrnými částmi. Je třeba zpřístupnit požadovaná rozhraní a vstupně/výstupní piny1 , navrhnout obvody napájení, spouštění atd. Ačkoli by návrh výše uvedených částí neměl být extrémně složitý2 , lze využít některého z již hotových řešení. Zajímavou variantou bylo použití univerzální desky M2M universal motherboard 2.0, kterou vyrábí firma Alarex-Group s.r.o. Tato vývojová deska (Obrázek 3.2) byla navržena pro maximální využití GSM modulů podporující JavaMET M technologii3 a pro usnadnění vývoje M2M aplikací, ve kterých se tyto moduly využívají. Její hlavní výhodou je, že obsahuje všechny podpůrné obvody potřebné pro činnost modulu a že veškerá rozhraní použitého modulu jsou z Board-To-Board konektoru vyvedena na ”standardní” konektory umístěné po obvodu desky.

Obrázek 3.2: M2M universal motherboard 2.0

1

Samotný modul je vybaven pouze 80ti pinovým Board-To-Board konektorem. Při návrhu by bylo možné vycházet z ukázkových zapojení podpůrných obvodů uvedených v [1] či ostatních PDF dokumentech dodávaných k modulu. 3 Jedná se o moduly TC65, AC75, XT 65/75, ale kompatibilita je zaručena i s TC63, MC75 a při použití konektorové redukce i s moduly HC15/25. 2


17

Základní parametry vývojové desky: - Rozměry 89x107x21mm - Napájecí napětí 7V - 60V - Oboustranná deska plošného spoje - Kompletní osazení z jedné strany - RoHS Dále tato deska obsahuje: - Dva kanály rozhraní RS232 přepínatelné do 3V TTL úrovní - Spínané zdroje pro napájení modulu - Obvody pro dobíjení připojeného akumulátoru (kterým lze desku s modulem napájet) - Výklopný držák SIM karty - Konfigurovatelný watchdog1 - Externí konektor pro stavovou LED diodu GSM modulu - SYNC LED Kompletní technickou specifikaci použité vývojové desky lze nalézt v [4].

3.2.3

Návrh vstupů a výstupů

Jak již bylo uvedeno výše, navržená aplikace využívá dvou tlačítek a dvou přepínačů. Tlačítka pro resetování modulu jsou již součástí vývojové desky. Pro připojení přepínače aktivujícího/deaktivujícího odesílání dat a přepínače vypínajícího modul byly využity dva z deseti digitálních vstupů/výstupů (označované GPIO), které GSM modul nabízí. Další dva z těchto univerzálních vstupů/výstupů byly využity pro signalizaci pomocí LED diod. Jedna dioda je aktivována po úspěšné inicializaci modulu a bliká s periodou rovnou periodě vyčítání dat z GPS přijímače. Druhá LED dioda svítí při aktivovaném odesílání dat. Za další signalizační diodu lze považovat SMD LED diodu, která je součástí vývojové desky. Tato dioda svítí v případě aktivní komunikace v rámci GSM sítě a lze tak podle ní detekovat např. aktivní GPRS přenos dat.

1

Pro oživování watchdogu lze použít GPIO pin 9 nebo 10, čas watchdogu lze volit v rozsahu 10 - 150 s nebo 1 - 15 min (vyřazení watchdogu z činnosti je také možné).


18

Připojení přepínačů Při připojování přepínačů bylo vycházeno z parametrů GPIO rozhraní modulu (viz Obrázek 3.3 převzatý z technické specifikace modulu [1]). Toto rozhraní je na vývojové desce přístupné na konektoru J12. Mimo pinů GPIO1 - GPIO10 je na tomto konektoru vyvedeno deset dalších pinů (GND, +3V, . . . ). Rozmístění všech těchto pinů spolu s jejich funkcí lze nalézt v [4].

Obrázek 3.3: Parametry GPIO rozhraní modulu

Zapojení přepínačů bylo realizováno dle doporučení výrobce pomocí pull-up rezistorů (R1 a R2). Přepínač P1 aktivující/deaktivující odesílání dat je připojen na pin GPIO1, přepínač P2 vypínající GSM modul je zapojen na pin GPIO2. Výsledné zapojení je zobrazeno na Obrázku 3.4. Zapojení signalizačních LED diod Zapojení signalizačních LED diod vychází opět z technických parametrů GPIO rozhraní modulu (Obrázek 3.3). Přímé zapojení LED diod by znamenalo velké proudové zatížení GPIO výstupu. Signalizační LED diody jsou proto spínány pomocnými NPN tranzistory. Výsledné zapojení viz Obrázek 3.5.


19

Obrázek 3.4: Zapojení přepínačů

Obrázek 3.5: Zapojení signalizačních LED diod

Napájecí napětí LED diod +3V a zem GND byly vyvedeny z vývojové desky, resp. z jejího konektoru J11 určeného pro audio rozhraní. Jako spínací tranzistory byly použity NPN tranzistory C547B. Velikost rezistorů R1 a R2 (omezující velikost proudů protékajících LED diodami) byla určena na základě parametrů uvedených v Tabulce 3.1. Výpočet hodnot těchto rezistorů je uvedený v rovnici 3.1

R1 = R2 =

3 − 2, 6 − 0, 08 Ucc − Ud − UCEsat = 16Ω = Id 0, 02

(3.1)

Velikost skutečně použitého rezistoru R1 (R2): 13,8Ω (sériové spojení dvou rezistorů 6,8Ω)

3.3. SOFTWAROVÁ ČÁST ŘEŠENÍ - MODUL SIEMENS XT65 Napájecí napětí LED diod Požadovaný proudu LED diodami Saturační napětí kolektor-emitor použitých tranzistorů Úbytek napětí na LED diodách

20

Ucc =3V Id =20mA UCEsat =80mV při požadovaném proudu kolektorem Ic =Id =20mA Ud =2,6V pro použité zelené diody při proudu 20mA

Tabulka 3.1: Parametry použité pro výpočet hodnot rezistorů R1 a R2

Velikost bázových rezistorů RB1 a RB2 byla stanovena vzhledem k velikosti výstupního napětí GPIO výstupu VOHM ax , velikosti jím procházejícího proudu Ib = 500μA a úbytku napětí na přechodu báze-emitor použitého tranzistoru Ube. Výpočet viz rovnice 3.2.

RB1 = RB2 =

VOHM ax − Ube 3, 05 − 0, 7 = = 4700Ω Ib 0, 0005

(3.2)

Vzhledem k tomu, že jsou již mezi GPIO piny Board-To-Board konektoru modulu a příslušnými piny konektoru J12 vývojové desky zapojeny ochranné rezistory hodnoty 1kΩ, byla hodnota skutečně použitého rezistoru RB1 (RB2) snížena na 3770Ω (sériové spojení rezistorů o hodnotách 3300Ω a 470Ω ).

3.3

Softwarová část řešení - modul Siemens XT65

Jak již bylo uvedeno výše, použitý GSM modul se dá nejpohodlněji ovládat prostřednictvím Java aplikace1 . Toho bylo využito a následující části této podkapitoly se pokusí navržené softwarové řešení na straně GSM modulu dostatečně popsat.

1

Kromě Java aplikace může být modul ovládán také AT příkazy prostřednictvím sériového (případně USB) rozhraní.

3.3. SOFTWAROVÁ ČÁST ŘEŠENÍ - MODUL SIEMENS XT65

3.3.1

21

Stručný úvod do MIDletů

Softwarová architektura modulu Základem softwarové architektury v použitém modulu je JavaT M MicroEdition. Ta je poskytována firmou SUN Microsystems (http://java.sun.com/javame/) a je navržená speciálně pro použití v embedded systémech. Modul XT65 využívá konkrétně konfiguraci CLDC 1.1 HI a profil IMP-NG, jenž je téměř identický s MIDP 2.0 (nepodporuje LCDUI1 ). MIDlet a jeho životní cyklus Řídící aplikace tedy není klasickou Java aplikací, ale jedná se o tzv. MIDlet, aplikaci vyhovující MID profilu. Ten se svými vlastnostmi spíše podobá apletu. Základní třída MIDletu musí rozšiřovat abstraktní třídu javax.microedition.midlet.MIDlet. Při spouštění aplikace je pak daná třída vytvořena zavoláním svého veřejného konstruktoru bez parametrů. MIDlet se může nacházet střídavě v několika stavech (viz Obrázek 3.6). Po zavolání konstruktoru se aplikace nachází v pasivním stavu. Pro přechod z pasivního stavu do aktivního stavu (hlavní činnost programu) je zavolána metoda startApp(). Při přechodu zpět do pasivního stavu je volána metoda pauseApp(). K ukončení MIDletu dojde voláním metody destroyApp() resp. metody notifyDestroyed(). Více informací o MIDletech a jejich životních cyklech lze nalézt například v [3] či nejlépe přímo v API dokumentaci k výše uvedené abstraktní třídě javax.microedition.midlet.MIDlet.

Obrázek 3.6: Stavy MIDletu

1

Vysvětlení a bližší popis jednotlivých konfigurací a profilů lze nalézt např. na Wikipedii (http://cs. wikipedia.org/wiki/Java_ME).


22

Uložení MIDletu v paměti modulu MIDlet je uložen ve FLASH paměti modulu ve formě dvou datových souborů jejichž struktura je daná specifikací MIDP. Jsou to deskriptor aplikace JAD a archiv JAR. Archiv JAR a MANIFEST.MF MIDlet je ukládán do paměti modulu ve formě archivu s příponou JAR. Mimo jednotlivých Java tříd tvořících MIDlet tento archiv ještě běžně obsahuje ostatní zdroje, jež MIDlet využívá (obrázky, zvuky, . . . ) spolu s tzv. souborem manifestu. Manifest soubor se v archivu nachází v adresáři META-INF a je pojmenován MANIFEST.MF. Jedná se o textový soubor udávající, stejně jako JAD deskriptor aplikace (viz níže), důležité parametry nesoucí informace o uloženém MIDletu. Ukázka možné podoby manifest souboru je uvedena na Obrázku 3.7.

Obrázek 3.7: Možný obsah souboru MANIFEST.MF

Deskriptor aplikace Deskriptor aplikace je textový soubor, který má stejný formát jako soubor manifestu1 . Deskriptor je uložen ve stejném adresáři jako archiv JAR (v případě GSM modulu typicky v kořenovém). Možný obsah JAD deskriptoru je zobrazen na Obrázku 3.8. 1

Přípona souboru je JAD a MIME typ tohoto souboru je text/vnd.sun.j2me.app-descriptor.


23

Obrázek 3.8: Možný obsah JAD deskriptoru

Kromě parametrů uvedených v ukázkách mohou JAD deskriptory a soubory manifestu obsahovat ještě mnoho dalších parametrů. To, které parametry musí jednotlivé soubory obsahovat a které jsou volitelné spolu s jejich významem, je přesně specifikováno. Informace lze získat např. v API dokumentaci k balíčku javax.microedition.midlet. Z hlediska programování je podstatné to, že kromě standardních parametrů začínajících MIDlet- a MicroEdition- lze do JAD deskriptoru umístit i vlastní pomocné parametry. Tyto parametry jsou pak ve zdrojovém kódu aplikace přístupné prostřednictvím metody MIDlet.getAppProperty(String Key). Tato metoda vrátí řetězec obsahující hodnotu parametru Key uvedeného v deskriptoru. Vezmeme-li za příklad výše uvedený ukázkový obsah souboru JAD a za parametr Key dosadíme např. PROTOKOL, vrátí metoda textový řetězec ”UDP”. Toto je zvláště výhodné, je-li třeba často měnit určité parametry programu. Nemusí se vždy upravovat zdrojový kód programu, znova kompilovat, komprimovat do nového JAR archivu, stačí jen přepsat hodnotu parametru v textovém souboru. Možnost uvedení vlastních parametrů v JAD souboru je využita i v navržené aplikaci. Detaily budou uvedeny níže.

3.3.2

Použité vývojové prostředí

Než bude navržená aplikace popsána, stojí za uvedení i stručný popis vývojového prostředí, jež bylo při programování použito. Pro Java GSM moduly Siemens je k dispozici instalační CD nazvané ”Cinterion Mobi-


24

lity Toolkit Installation CD”. Mimo jiné toto CD zahrnuje :

• MES - Module Exchange Suite • WTK - Wireless ToolKit (obsahuje nástroje pro vývoj a ladění aplikací, HTML Java dokumentaci k API, potřebné Java třídy a ukázkové kódy) • Java SDK (jdk-1 5 0 15-windows-i586-p.exe) • NetBeans IDE 6.0.1 obsahující Mobility pack (netbeans-6.0.1-ml-mobility-windows.exe) • Eclipse 3.2.2 (eclipse-SDK-3.2.2-win32.zip) • Eclipse 3.3.1.1 (eclipse-SDK-3.3.1.1-win32.zip) • EclipseME plugin 1.6.8 (eclipseme.feature 1.6.8 site.zip) • EclipseME plugin 1.7.7 (eclipseme.feature 1.7.7 site.zip) • Integrated Documentation Suite (zpřehledněná HTML dokumentace k modulu a API) • PDF datasheety (např. popis hardwaru modulu, AT příkazů, Java příručka, . . .) Uvedené CD tedy obsahuje vše, co je třeba k úspěšnému psaní a ladění aplikací pro použitý modul. Po jeho kompletní instalaci je k dispozici kromě jiného i zvolené vývojové prostředí (v našem případě NetBeans), v němž jsou obsaženy již všechny potřebné knihovny/API i emulátor. Lze tedy přímo v prostředí NetBeans programovat MIDlety, kompilovat je a následně v modulu spouštět1 . K dispozici je také možnost klasického ladění (debugu) aplikace bez stálého nahrávání a přepisování JAR a JAD souborů ve FLASH paměti modulu. Pro tyto účely lze také přesměrovat standardní výstupní stream MIDletu (system.out) do výstupního okna (output window) prostředí NetBeans, což ladění aplikace ještě usnadňuje2 . Obrázky demonstrující použití prostředí NetBeans pro programování MIDletů jsou uvedeny na Obrázkách C.1 a C.2 v příloze C.

1

Samozřejmě pouze v případě, že je modul k počítači připojen. K tomuto lze využít jak sériového, tak USB rozhraní modulu. Více v [3]. 2 Při standardním běhu aplikace v modulu je system.out možno směrovat na sériové či USB rozhraní modulu, do UDP soketu, do souboru ve FLASH paměti, či ho potlačit. Více viz [2].


25

Druhou důležitou aplikací, jež je součástí instalace a o které je dobré se zmínit, je Module Exchange Suite (MES). Jedná se o software, jenž - jednoduše řečeno - na počítači doplní ”složku” Tento počítač o odkaz na FLASH paměť modulu (Obrázek 3.9 a 3.10). Tak lze například do modulu manuálně nahrávat MIDlety či jiné soubory, soubory či celé adresářové struktury z FLASH paměti modulu mazat atd1 .

Obrázek 3.9: Přístup do FLASH paměti modulu

Obrázek 3.10: Obsah FLASH paměti modulu

1

Instalace MES kromě výše uvedeného zpřístupní také FLASH paměť modulu prostřednictvím speciální sady příkazů příkazové řádky. Lze tak vytvářet například dávkové .BAT soubory zpracovávající zdrojové Java soubory do výsledných JAR a JAD souborů a ty hned ukládající do modulu.


3.3.3

26

Popis navržené řídící aplikace

Jak již bylo uvedeno výše, je aplikace ovládající modul navržena ve formě MIDletu. Aplikace využívá standardní Java IM profil doplněný o API dodávaná firmou Siemens1 , která obsahují třídy a rozhraní pro práci s GSM moduly Siemens. Celý zdrojový kód programu je možné najít na přiloženém CD v adresáři Zdrojové kódy. Soubor je uložen pod názvem GpsLkator.java. Základní stavový diagram programu je uveden v příloze D. 3.3.3.1

Načtení parametrů

Po spuštění programu jsou (v rámci konstruktoru uvedené třídy) z JAD deskriptoru (viz kapitola 3.3.1) načteny následující parametry:

Parametr

Význam a rozsah hodnot (v závorce uvedena přednastavená hodnota) PERIODA Perioda vyčítání GPS dat z GPS přjímače (v sekundách). Možné hodnoty jsou 0 - 255 (5). PROTOKOL Protokol, jakým se budou odesílat data na server. Možné hodnoty jsou TCP a UDP (UDP). BUFFER Udává, zda se budou souřadnice odesílat jednotlivě nebo se budou nejdříve ukládat do dočasného bufferu a posílat po skupinách. Možné hodnoty jsou true a false (true). UDP KONTROLA PO V případě, že je zvolen UDP protokol, udává tento parametr, po kolika odeslaných datagramech se modul táže na stav serveru, na který jsou data odesílána (20). PIN V případě, že je třeba při GSM autentizaci vložit PIN SIM karty, je použito číslo z tohoto parametru. Možné hodnoty 0000-9999 (1234). Tabulka 3.2: Načítané parametry Tyto parametry slouží pro řízení dalšího běhu programu. Hodnoty parametrů jsou při jejich načítání kontrolovány, pokud obsahují nepovolené hodnoty, je použita přednastavená defaultní hodnota.

1

Jedná se o balíčky com.siemens.icm.io, com.siemens.icm.io.file a com.siemens.icm.misc.

3.3. SOFTWAROVÁ ČÁST ŘEŠENÍ - MODUL SIEMENS XT65 3.3.3.2

27

Inicializace

Po následném zavolání metody startApp() je spuštěna hlavní část programu. V úvodní části programu je nejdříve provedena inicializace potřebných prostředků. V rámci inicializace je nejdříve získána instance třídy ATCommand. Prostřednictvím této třídy (resp. její metody send(String ATcmd)) lze zasílat modulu AT příkazy stejným způsobem, jakým by se jinak posílaly přes USB či sériové rozhraní. Získaný objekt (nazývejme ho ATCommand) tedy slouží pro veškerou komunikaci s GSM modulem. Dále je vytvořen objekt vlastní třídy ATList a tento zaregistrován u ATCommnadu jako tzv. posluchač. Třída ATList představuje vlastní implementaci rozhraní ATCommandListener. Toto rozhraní poskytuje možnost zpracovat nevyžádaná, tzv. URC, hlášení. URC hlášení se mohou vyskytnout například v případě příchozího hovoru, příchozí SMS zprávy, nových dat z GPS přijímače atd. Důležité je, aby vlastní implementace tohoto rozhraní obsahovala metodu ATEvent(String arg0) s kódem obsluhujícím jednotlivé události, jež mohou nastat a jež mají být v programu ošetřeny. Události jsou této metodě předávány prostřednictvím parametru arg0. Více bude uvedeno níže. Dále program provede kontrolu zalogování do GSM sítě, resp. kontrolu stavu SIMkarty. V této části je zadáván, pokud je to třeba, PIN kód. Poté je provedena inicializace již zmiňovaných vstupů a výstupů sloužících pro ovládání programu a optickou signalizaci jeho stavu. Aby nebylo třeba stav řídících vstupů v průběhu programu neustále kontrolovat, jsou oběma vstupům přiděleni opět posluchači. Tentokráte se jedná o instance tříd PinKonecList a PinSledovaniList, jež vycházejí z rozhraní InPortListener. Při změně stavu na příslušném pinu GPIO rozhraní modulu je volána funkce portValueChanged(int port) 1 těchto tříd. V našem případě, je-li změněna hodnota vstupu aktivujícícho/deaktivujícícho odesílaní dat, je změněna hodnota globální proměnné stav, která udává okamžitý stav, ve kterém se program nachází. Pokud její hodnota byla SLEDOVANI, je změněna na READY, jinak je změněna na SLEDOVANI. Stejně se chová metoda portValueChanged(int port) také u vstupu ukončující běh aplikace. Zde navíc dochází k nastavení globální proměnné aplikaceBezi na hodnotu false. Více viz zdrojový kód. V další části inicializace je provedeno základní nastavení modulu. Je povoleno zobrazování CLIP URC hlášení (potřebné pro možnost identifikovat volajícího). Je nastavena forma URC hlášení pro příchozí SMS zprávy, je nastaven textový mód SMS zpráv, je nastavena použitá paměť pro SMS zprávy a zprávy v ní uložené jsou vymazány. 1

Parametr port udává hodnotu aktuálního stavu příslušného vstupu.


28

Posledním krokem inicializace je spuštění GPS ovladače a zahájení vyčítání dat z GPS přijímače s přednastavenou periodou. GPS data jsou z přijímače odesílána prostřednictvím URC hlášení. Po úspěšné inicializaci začne hned blikat signalizační LED dioda v rytmu vyčítání dat z GPS přijímače. Pokud se některá z částí inicializace nepovede1 , je běh programu ukončen. Jedná se možná o nestandardní řešení, ale každá z částí inicializace je potřebná pro další běh aplikace a případný reset modulu a znovuspuštění programu problém jistě vyřeší. Nutno podotknout, že během testování aplikace inicializace proběhla vždy v pořádku.

3.3.3.3

Stav READY

Po úspěšné inicializaci se modul nachází ve stavu označeném jako READY. V tomto stavu jsou pouze přijímána data z GPS přijímače a toto je indikováno blikající LED diodou. Přechod do některého z následujících stavů je možný buďto již několikrát zmíněným přepínačem nebo přijmutím SMS zprávy obsahující text SLEDOVANI. Umožněno je v tomto stavu také zpracování příchozích hovorů. O tom, stejně jako o zpracování příchozích SMS zpráv, pojedná jedna z níže uvedených částí této kapitoly.

3.3.3.4

Stav sledování s UDP protokolem

Jedním ze dvou stavů, do kterých může modul vstoupit ze stavu READY, je stav SLEDOVANI s UDP protokolem. V tomto stavu, obsluhovaném metodou UdpOdesilani(), jsou přijímaná data z GPS přijímače odesílána na vzdálený UDP server (viz oddíl 3.4.1). Pro tyto účely je otevřeno datagramové spojení (DatagramConnection). V prvním datagramu je na statickou IP adresu serveru odeslán paket obsahující dotaz na stav serveru. V případě, že ten je v pořádku, odpoví zprávou UDPOK . V případě, že přijatý datagram obsahuje jinou odpověď, je UDP spojení zavřeno a po přednastavené pauze se metoda UdpOdesilani() ukončí. Modul však zůstává v uvedeném stavu, a tak okamžitě dojde k novému volání této metody a tedy i navázání nového spojení a odeslání dalšího dotazu na stav serveru. Pro případ, že by byl UDP server nedostupný, je doba čekání na jeho odpověď omezena využitím objektu třídy Timer. Před voláním metody receive() pro příjem datagramu2 je 1 2

Některé části inicializace jsou v případě chyby opakovány 2x. Jedná se o blokující metodu. Vykonávání programu se zastaví a čeká se na příchod dat.


29

Timerem naplánováno spuštění metody run() přidruženého objektu vlastní třídy MyTimerTask 1 . Spuštění je naplánováno s přednastaveným zpožděním (defaultně 10 sekund). Nedojde-li do této doby od serveru odpověď, je metoda run() spuštěna. V této metodě se zkontroluje, zda odpověď skutečně nepřišla, a když ne, je ukončeno datagramové spojení, což metodu receive() přeruší2 a následně dojde k ukončení i celé metody UdpOdesilani(). Nepřijetí odpovědi od serveru v daném čase má tedy stejné následky jako přijmutí špatné odpovědi. V případě, že je odpověď přijata, je naplánované spuštění metody run() zrušeno, a pokud odpověď obsahuje zprávu UDPOK, započne odesílání aktuálních GPS souřadnic na server. Dokud není změněn stav modulu zpět na READY, jsou periodicky kontrolována data k odeslání. Pokud jsou zjištěné neodeslané souřadnice připravené k odeslání, jsou tyto odeslány. Po každých x3 odeslaných datagramech je serveru opět odeslán dotaz na stav. Lze tak předejít zbytečnému odesílání dat v případě, že serverem nemůžou být přijímána (např. pád serveru). Odpověď serveru je kontrolována stejným způsobem jako u prvotního dotazu. Po přepnutí do stavu READY je odesílání ukončeno, datagramové spojení zavřeno a metoda UdpOdesilani() ukončena. Program se opět nachází ve stavu READY.

3.3.3.5

Stav sledování s TCP protokolem

Druhým ze stavů, do kterých může modul přejít ze stavu READY, je stav, kdy jsou souřadnice na server odesílány protokolem TCP. K tomuto slouží metoda TcpOdesilani(). Po vstupu do této metody je otevřeno soketové spojení se vzdáleným TCP serverem (viz kapitola 3.4.2) a v případě úspěšného spojení je zahájeno odesílání souřadnic. Dokud trvá stav SLEDOVANI, jsou, stejně jako je tomu v případě odesílání UDP protokolem, kontrolována data k odeslání, a pokud jsou zjištěna nová připravená a neodeslaná data, jsou tato odeslána. Odesílání je realizováno metodou write(byte[] data) příslušného output streamu. K ukončení periodického odesílání dojde změnou stavu SLEDOVANI zpět na stav READY. U obou způsobů odesílání dat (UDP/TCP) byla snaha zajistit ošetření všech možných chyb, které mohou během komunikace nastat. Toto bylo řešeno, ostatně jako i v ostatních částech programu, uzavřením nebezpečných částí kódu do tzv. try-catch bloků. Chyby vzniklé v takovýchto blocích jsou zachyceny a ošetřeny. Nedojde tak (nemělo by dojít) k pádu aplikace. 1

Třída MyTimerTask je rozšířením abstraktní třídy TimerTask. Ve skutečnosti tak dojde k záměrnému vyvolání výjimky, jež je v programu patřičně ošetřena. 3 Konkrétní počet je dán parametrem UDP KONTROLA PO v deskriptoru. 2


3.3.3.6

30

Příprava dat k odeslání

O přípravu dat k odeslání se stará již zmíněná metoda ATEvent(String arg0) třídy ATlist. Ta v případě, že jsou přijata nová GPS data (tj. vyvolání této metody s parametrem obsahujícím GPS data), tato data upraví z tvaru: ˆSGPSP:2006/07/12,08:37:09,48.5921692,N,032.2702400,W,18,0,152.75,0 na tvar: 2006/07/12,08:37:09,48.5921692,N,032.2702400,W,18,0,152.75,0 a takto zkrácená je uloží do globální proměnné aktualniPozice. Obsah proměnné aktualniPozice je dále uložen do proměnné gpsBuffer. Tato proměnná je typu String a slouží pro uchovávání GPS dat, jež jsou odesílána, jak je uvedeno výše, na vzdálený server. Souřadnice jsou do gpsBufferu ukládány postupně tak, jak přicházejí z GPS přijímače, oddělené znakem \n. Velikost bufferu (odpovídá počtu najednou odesílaných souřadnic) je stanovena na základě parametrů BUFFER a PERIODA uvedených v deskriptoru. Má-li parametr BUFFER hodnotu false, posílají se souřadnice jednotlivě. Do gpsBufferu se tedy v tomto případě ukládá souřadnice jen jedna. Je-li parametr BUFFER nastaven na true, odvíjí se počet odesílaných souřadnic na nastavené periodě vyčítání dat z GPS přijímače tak, jak je uvedeno v Tabulce 3.3. Po zaplnění gpsBufferu je nastaven příznak připravenosti dat k odeslání. Děje se tak nastavením globální proměnné dataZpracovana na false. Po detekci tohoto příznaku funkce UdpOdesilani() (případně TcpOdesilani()) převezme z gpsBufferu data, vynuluje jeho obsah a nastaví příznak dataZpracovana na true. Dokud toto není provedeno, metoda ATEvent(String arg0) obsah gpsBufferu nepřepisuje. Případné nově přijaté souřadnice pouze ukládá do proměnné aktualniPozice. Tato proměnná tedy obsahuje vždy nejaktuálnější souřadnice. O jejím využití je psáno hned v následující části.


31

Perioda vyčítání GPS dat [s] Počet odesílaných souřadnic 1 15 2 8 3 5 4 4 5 3 6 3 7 3 8 2 9 2 10 2 11 2 12 2 >12 1 Tabulka 3.3: Počet odesílaných souřadnic v závislosti na periodě vyčítání dat z GPS přijímače

3.3.3.7

Zpracování příchozího hovoru

Kdykoliv během běhu programu se může stát, že na telefonní číslo modulu někdo zavolá. Ať již omylem nebo záměrně. Příchozí telefonní hovory jsou Java aplikaci signalizovány stejně jako nová GPS data formou URC hlášení. O jejich zpracování se tedy opět stará metoda ATEvent(String arg0). Parametr této funkce obsahuje v případě příchozího hovoru řetězec RING, případně řetězec CLIP následovaný číslem volajícího. Je-li metoda ATEvent zavolána 3x pouze s parametrem RING, tedy bez informace o volajícím, je hovor modulem odmítnut. Pokud informace o volajícím k dispozici je, je hovor modulem také odmítnut, ale následně je zavolána metoda posliSMSzadateli(String cislo). Parametrem, se kterým je tato metoda volána, je telefonní číslo volajícího. Metoda posliSMSzadateli(String cislo) zkontroluje, zda-li číslo volajícího patří mezi povolená čísla (prvních deset čísel uložených na SIM kartě) a pokud ano, odešle na dané číslo informační SMS zprávu. Ta obsahuje informaci o stavu, ve kterém se modul zrovna nachází, počet souřadnic, jenž byl od spuštění programu již odeslán a především aktuální GPS souřadnice. Ty jsou, jak již bylo výše uvedeno, odesílány ve formě odkazu na web http://maps.google.com/.

3.4. SOFTWAROVÁ ČÁST ŘEŠENÍ - SERVEROVÁ STRANA 3.3.3.8

32

Zpracování příchozí SMS zprávy

Během běhu programu může také na telefonní číslo modulu přijít SMS zpráva. Informace o tom je MIDletu předána opět prostřednictvím URC hlášení a o zpracování se tedy stará opět metoda ATEvent(String arg0). Její parametr v tomto případě obsahuje řetězec +CMTI: a krom jiného i pozici příchozí zprávy v paměti. Tato pozice je parametrem, se kterým se následně volá metoda zpracujSMS(int pozice). Tato metoda zkontroluje odesílatele příchozí SMS zprávy uložené na dané pozici, a pokud tento spadá do již výše zmíněných povolených čísel, SMS zprávu zpracuje. Pokud text zprávy obsahuje řetězec READY ”přepne” modul do tohoto stavu. Pokud zpráva obsahuje text SLEDOVANI, dojde ke změně stavu modulu na tento. Zbylý či jiný text zprávy je ignorován. Stejně tak jsou ignorovány i zprávy, které přišly z nepovolených čísel. 3.3.3.9

Ukončení programu

Aplikace může být standardně ukončena jen jedním způsobem. Změnou stavu přepínače připojeného na pin GPIO2. Změnou log. úrovně na tomto pinu se vyvolá funkce portValueChanged(int port) příslušného posluchače. Ta se mimo jiné postará o změnu hodnoty globální proměnné aplikaceBezi na false. Tato změna je programem detekována a dojde k ukončení MIDletu.

3.4

Softwarová část řešení - serverová strana

V této podkapitole bude popsáno softwarové řešení na straně serveru. To v sobě zahrnuje UDP a TCP server. Následující text se pokusí vysvětlit nejdůležitější části jednotlivých programů. Kompletní zdrojové kódy jsou k dispozici na přiloženém CD v adresáři Zdrojové kódy (soubory ServerUDP.JAVA a ServerTCP.JAVA). Kromě serverů je součástí softwarového řešení i databáze MySQL. Její využití je popsáno v závěru této podkapitoly.

3.4.1

Java UDP server

UDP server již není ve formě MIDletu. Je to klasická Java aplikace běžící na osobním počítači zapojeném v síti internet. Výchozí část aplikace tvoří třída ServerUDP. Po spuštění aplikace je hlavním vláknem aplikace vytvořeno a spuštěno druhé paralelní vlákno. To

3.4. SOFTWAROVÁ ČÁST ŘEŠENÍ - SERVEROVÁ STRANA

33

se stará o samotný příjem dat. Hlavní vlákno se, jak bude níže vysvětleno, poté již postará pouze o ukončení programu. Inicializační část vlákna čtení Po spuštění vlákna čtení (spuštění jeho metody run()) je nejdříve provedena nezbytná inicializace. Je otevřeno datagramové soketové spojení na požadovaném portu a je vytvořena instance třídy Logger. Zároveň je vytvořen objekt třídy FileHandler a ten je jako handler loggeru přidán. Inicializační část nám tak zpřístupní příjem dat z daného UDP portu, objekt loggeru pak umožní snadné logování přijatých dat do textového souboru v případě, že není k dispozici databáze, do níž se data ukládají přednostně. Celá inicializace je uzavřena v try-catch bloku a pokud během ní dojde k nějaké chybě, je aplikace ukončena. Opět se jedná možná o drastické řešení, ale uživatel je o typu vzniklé chyby informován (například obsazený port), může ji odstranit a po znovuspuštění aplikace by mělo být vše v pořádku. Po úspěšné inicializaci se aplikace pokusí připojit k MySQL databázi běžící na stejném počítači. V případě, že se spojení nezdaří, je toto ignorováno. Přijatá data budou loggerem ukládána do souboru a pokusy o navázání spojení s databází budou průběžně opakovány. Stejně je postupováno i v případě, že se spojení s databází naváže, ale v dalším průběhu programu se přeruší. Vlastní příjem dat O vlastní příjem dat se stará metoda receive(DatagramPacket p) datagramového spojení. Čtení dat a jejich zpracování se periodicky opakuje tak dlouho, dokud je nastavena globální příznaková proměnná beh na hodnotu true. Zpracování přijatých dat Pokud přijatá data obsahují dotaz na stav, je na IP adresu a UDP port odesílatele odeslán datagram se zprávou UDPOK. Pokud data neobsahují dotaz na stav, jsou považována za souřadnice. Jak již bylo uvedeno výše, jsou souřadnice z modulu odesílány buď jednotlivě nebo v paketech ve formě textového řetězce, v němž jsou jednotlivé souřadnice odděleny znakem \n. Na straně serveru jsou data nejdříve zpětně rozdělena na jednotlivé souřadnice a ty jsou poté jednotlivě ukládány do databáze. Před uložením do databáze je u každé souřadnice


34

zkontrolováno, zda-li obsahuje validní data. Pokud souřadnice neodpovídá požadavkům, je loggerem uložena do souboru. Tam jsou uložena i případně přijatá jiná data. Tak je zabezpečeno, že v databázi budou skutečně jen platné souřadnice. Ukončení programu Standardní ukončení programu je možné jen jedním způsobem. Stiskem libovolné klávesy odeslané enterem. Detekce odeslání znaku je ošetřena v hlavním vlákně. To po odeslání znaku z klávesnice zavolá metodu interrupt() čtecího vlákna. V rámci této metody je nastaven globální příznak beh na false, čímž je čtecí vlákno při další kontrole tohoto příznaku ukončeno. V případě, že se čtecí vlákno v čase volání metody interrupt() nachází v zablokovaném stavu, tj. je zrovna aktivní blokující metoda receive(DatagramPacket p) a zrovna žádná data nepřicházejí, nemuselo by ke kontrole stavu příznaku beh vůbec dojít. Program by tak zůstal ”viset” v příjmu dat. Z tohoto důvodu metoda interrupt() také uzavře soketové spojení voláním jeho metody close(). Dojde-li k tomuto v době, kdy je aktivní metoda receive(DatagramPacket p), dojde samozřejmě k jejímu přerušení a vyvolání výjimky. Ta je ošetřena, běh čtecího vlákna je ukončen a stejně tak následně celá aplikace.

3.4.2

Java TCP server

Koncepce TCP serveru je velmi podobná UDP serveru. Opět se jedná o klasickou Java aplikaci tvořenou dvěma vlákny. Jedno se opět stará o příjem a zpracování dat, druhé hlídá požadavek na ukončení programu. To je řešeno podobně jako u UDP serveru voláním metody interrupt() čtecího vlákna, jež uzavře TCP spojení a nastaví flag serverBezi na false. Tím dojde k ukončení čtecího vlákna a následně i celého programu. Za zmínku stojí, že pro příjem dat je využita metoda readLine(). Znamená to, že i v případě, kdy nejsou souřadnice modulem odesílány jednotlivě, ale hromadně, přijatá a zpracovaná je vždy jen jedna souřadnice. Na rozdíl od UDP serveru, kdy byl celý blok souřadnic přijat a zpracován najednou. Pro tento účel jsou jednotlivé souřadnice odděleny právě znakem \n. Kontrola přijatých dat, jejich ukládání do databáze či případné loggování do souboru probíhá stejným způsobem, jako je tomu u UDP serveru. Více informací viz zdrojové kódy.


3.4.3

35

Databáze

Jak již bylo uvedeno, jsou serverem přijaté souřadnice ukládány do lokální MySQL databáze. Pro její instalaci bylo využito freeware instalačního balíčku VertrigoServ dostupného z http://vertrigo.sourceforge.net/. Instalace tohoto balíčku obsahuje mimo MySQL databáze a nástroje PhpAdmin pro její administraci i HTTP webový server Apache, programovací jazyk PHP a mnoho dalších webových nástrojů. Využití zmíněných komponent bude popsáno v podkapitole 3.5. Souřadnice jsou ukládány do tabulky data v databázi pojmenované gpsdata. Struktura této tabulky je uvedena na Obrázku 3.11 (několik uložených záznamů pak na Obrázku 3.12).

Obrázek 3.11: Struktura tabulky data Jak je patrné, jsou jednotlivé části souřadnic (datum a čas, zeměpisná šířka, délka, rychlost, kurz, . . .) ukládány do odpovídajících sloupců. Jako primární klíč byl zvolen údaj obsahující datum a čas pořízení souřadnice. Poslední sloupec v tabulce, označený fix, obsahuje údaj o zafixování GPS přijímače (2 = 2D přesnost určení polohy, 3 = 3D určení polohy). Toto řešení ulehčuje další zpracování přijatých dat. Ukázka takového možného zpracování je uvedena hned v následující podkapitole.

3.5. ZPRACOVÁNÍ ULOŽENÝCH DAT

36

Obrázek 3.12: Záznamy uložené v tabulce data

3.5

Zpracování uložených dat

Uložení dat do databáze umožňuje další zpracování získaných souřadnic mnoha způsoby. V rámci této práce bylo navrženo jednoduché webové rozhraní určené pro lokální použití, jež umožňuje uložená data prohlížet a odesílat na FTP server či ve formě přílohy na danou e-mailovou adresu. Popis tohoto rozhraní bude uveden v následujících částech.

3.5.1

Navržené webové rozhraní - vzhled

Vzhled navrženého webového rozhraní představují následující obrázky. Popsány a vysvětleny budou níže.


Obrázek 3.13: Základní vzhled webového rozhraní

Obrázek 3.14: Zobrazení nejnovějšího záznamu uloženého v databázi

37


Obrázek 3.15: Zobrazení souřadnic z daného časového období

Obrázek 3.16: Zobrazení souřadnic z daného období s vygenerováním GPX souboru

38


Obrázek 3.17: Obsah vygenerovaného GPX souboru

Obrázek 3.18: Trasa z vygenerovaného GPX souboru

39


3.5.2

40

Navržené webové rozhraní - popis

Jak je z obrázků patrné, je navržené webové rozhraní poměrně jednoduché. Jeho účelem není špičkově zpracovat uložená data, to by mohlo být tématem samostatné diplomové práce. Cílem je spíše demonstrovat možnosti, jak by takové zpracování mohlo vypadat a ukázat, že uložení získaných GPS souřadnic do databáze má svoje opodstatnění. Web umožňuje vybraná naměřená data vizualizovat, či jednoduchým způsobem odeslat ve formě datového souboru na FTP server či e-mailovou adresu. Díky navrženému webu lze také do jisté míry zhodnotit kvalitu navrženého systému pro sledování vozidla (například si na mapových podkladech ověřit přesnost určení polohy atd.). První obrázek (Obrázek 3.13) ukazuje základní stránku webu. Ta uživateli nabízí tři možnosti. První možností je vyhledat nejnovější v databázi uloženou souřadnici. Po volbě této možnosti se zobrazí stránka (Obrázek 3.14), jež podává informaci o nejnovější souřadnici uložené v databázi, a tato souřadnice je zároveň na stránce zobrazena na mapě. Druhou možností (tlačítko Zobrazit GPS data přijata od-do) je vyhledání souřadnic z daného časového období. Po zadání období v příslušných kolonkách a stisku uvedeného tlačítka je zobrazen seznam nalezených GPS souřadnic (viz Obrázek 3.15). Souřadnice jsou zobrazeny v tabulce, kde každý řádek podává informace o dané souřadnici. Součástí každého řádku je i odkaz zobrazující danou souřadnici na mapě. Třetí možností je zobrazení souřadnic z daného období a současného vygenerování GPX souboru. Toto se děje stejným způsobem, který byl uveden o pár řádků výše, jen je navíc zaškrtnuta volba Generovat GPX soubor z výsledků (viz Obrázek 3.16). Po odeslání žádosti je tabulka s odpovídajícími GPS souřadnicemi doplněna o odkaz na GPX soubor. Tento soubor je vygenerován z nalezených souřadnic a prostřednictvím webové stránky si jej lze hned stáhnout či zobrazit. Struktura tohoto souboru je uvedena na Obrázku 3.17, který zachycuje část jeho obsahu. Vizualizace takového souboru je pak uvedena na Obrázku 3.18. Poslední možnost také umožňuje odeslat vygenerovaný soubor na FTP server či ve formě přílohy na danou e-mailovou adresu. K tomuto účelu slouží příslušná tlačítka (viz Obrázek 3.16).

3.5.3

Navržené webové rozhraní - technické řešení

Webové stránky jsou uloženy na serveru Apache, jenž je součástí (jak již bylo zmíněno v kapitole 3.4.3) nainstalovaného softwarového balíčku Vertrigo. Server tedy běží na


41

stejném počítači jako samotná databáze. Pro programování webu byl zvolen programovací jazyk PHP. K tomuto kroku vedlo jednak to, že podpora PHP je již součástí instalace balíčku Vertrigo1 , ale hlavně to, že použití PHP umožňuje relativně snadným způsobem přistupovat k databázi, komunikovat s FTP serverem a odesílat e-maily SMTP protokolem. Zdrojové kódy jednotlivých stránek jsou obsaženy na přiloženém CD v adresáři Zdrojove kody/web/. Následující podkapitoly se pokusí důležité části kódů navrženého webového rozhraní popsat.

3.5.3.1

Zobrazení nejnovější souřadnice

Základem webu je skript GpsData.php. Ten v případě, že je zavolán bez parametrů, vygeneruje html stránku uvedenou na Obrázku 3.13. Součástí této stránky je pouze formulář obsahující tlačítka Zobrazit nejnovější záznam GPS dat a Zobrazit GPS data přijatá od-do (čas v UTC) 2 . Kromě těchto tlačítek stránka již obsahuje pouze nadpis a vstupní pole pro případné zadání časového rozpětí. Je-li formulář odeslán tlačítkem Zobrazit nejnovější záznam GPS dat 3 , je zavolán tentýž skript, jenž kromě opětovného vygenerování stejného formuláře, kód stránky doplní informacemi o nejnovější GPS souřadnici nalezené v databázi. Mimo to je do stránky vložen také iframe, obsahující mapu, na níž je daná souřadnice zvýrazněna (viz Obrázek 3.14). Pro připojení k databázovému serveru je použita PHP funkce MySQL Connect() 4 . Pro výběr konkrétní databáze je volána PHP funkce mysql select db(). Pokud se připojení k serveru či výběr databáze nezdaří (jedna z uvedených metod vrátí FALSE), dojde k vypsání chybové hlášky a vykonání skriptu se ukončí zavoláním funkce die(). Tato funkce před tím, než ukončí vykonávání skriptu, ještě vypíše do výsledného html kódu řetězec, jenž jí je předán jako parametr při jejím volání. Toho je využito pro vypsání příslušné 1

Není tak nutné doplňkově instalovat a nastavovat další softwarové komponenty. Poznámka (čas v UTC) je uvedena z toho důvodu, že čas pořízení souřadnic není ukládán v čase lokálního časového pásma, ale právě v čase UTC. Na toto je třeba při zadávání časového rozpětí myslet. Ukládání časového údaje v UTC sice trochu znepřehledňuje orientaci ve skutečném (lokálním) čase pořízení jednotlivých souřadnic, ale tento čas je standardně používán a jeho používání je např. vyžadováno i v GPX souborech. 3 O tom, jakým tlačítkem byl formulář odeslán, je ve skriptu rozhodnuto funkcí isset(). Více viz zdrojový kód a [8]. 4 Pro přehlednost práce budou PHP funkce uváděny bez parametrů, s nimiž se volají, a typů jejich návratových hodnot. Přesné deklarace těchto funkcí, včetně jejich popisu a významu parametrů, lze nalézt v on-line PHP manuálu [8]. 2


42

chybové hlášky1 . Této tzv. or die() konstrukce je v práci využito několikrát. Výběr nejnovější souřadnice z databáze zajišťuje SQL příkaz SELECT * FROM data ORDER BY DatumCas DESC LIMIT 1. Tento příkaz vybere z tabulky data všechny záznamy, seřazené sestupně dle sloupce DatumCas, a vrátí první z výsledků. Tedy nejnovější souřadnici uloženou v tabulce. O vykonání tohoto příkazu a o následné uložení výsledku do proměnné $vysledek se stará PHP funkce mysql query(). Poté je volána funkce mysql num rows(). Tato funkce slouží pro zjištění počtu řádků výsledku SQL dotazu, tedy počtu nalezených záznamů. Pokud nebyl nalezen žádný záznam (tabulka může být např. prázdná), je o tom vypsána informační hláška a skript, tedy i html výstup, je ukončen. Byl-li nejnovější záznam nalezen, je záznam funkcí mysql fetch array() uložen do proměnné $row. Ta představuje pole a k jednotlivým částem záznamu se tedy přistupuje prostřednictvím indexů (jmen jednotlivých sloupců dané tabulky). Např. v $row[Sirka] je uložena zeměpisná šířka nalezeného záznamu. Následně jsou informace o nalezené souřadnici vypsány do html kódu stránky. Zároveň je do těla stránky vložen plovoucí rám obsahující mapu Google, na níž je nalezená souřadnice zvýrazněna. K tomuto je využit tag iframe. Obsah, jenž bude iframe obsahovat, je určen jeho parametrem src. V tomto případě src=”http://maps.google.com/maps?q=$NS$row[Sirka],$WE$row[Delka]”. Význam parametrů $row[Sirka] a $row[Delka] je zřejmý. Parametry $NS a $WE obsahují buďto znak + nebo - v závislosti na tom, jedná-li se o souřadnice jižní či severní zeměpisné šířky a západní či východní zeměpisné délky. Po doplnění kódu stránky o rám je skript ukončen. 3.5.3.2

Zobrazení souřadnic z daného období

Je-li formulář odeslán tlačítkem Zobrazit GPS data přijata od-do, je nejdříve volána vlastní funkce kontrolaCasu(). Tato funkce zkontroluje hodnoty zadané ve vstupních polích určených pro volbu časového období2 . Kontrolován je datový typ u polí hh, mm, ss (musí být INT), kontrolována je hodnota v těchto polích (0-23 pro hodiny, 0-59 pro minuty a sekundy) a jako poslední je provedena kontrola zadaných dat. Pro tyto základní kontroly je využito PHP funkcí ereg() a checkdate(). Je-li zjištěna chyba, je o tomto do generovaného html kódu vypsána zpráva a skript je ukončen. Je-li období zadáno správně, jsou požadované souřadnice z databáze získány příkazem Select * From data Where DatumCas Be1

Pro pořádek je chybová hláška doplněna ještě html kódem obsahujícím pomocné html tagy rozumně ukončující rozepsané bloky (řádné ukončení html tabulek atd.) 2 Tyto parametry, stejně jako všechny ostatní, jsou skriptu předávány metodou GET a do jednotlivých proměnných ($rokdo, $mesicdo, $dendo, $hodinado, $minutado, $sekundado,. . . ) jsou ve skriptu ukládány prostřednictvím funkce $ GET.


43

tween ’$rokod-$mesicod-$denod $hodinaod:$minutaod:$sekundaod’ And ’$rokdo-$mesicdo$dendo $hodinado:$minutado:$sekundado’ order by DatumCas DESC. V případě, že zadanému dotazu v databázi žádná data neodpovídají, je o tomto uživatel informován a skript ukončen. V opačném případě jsou nalezené souřadnice vypsány do html kódu stránky. Zobrazeny jsou v tabulce umístěné do samostatného bloku DIV s pevnou velikostí. Jedná se o ”dekorativní” opatření. I v případě, že je nalezeno např. několik set záznamů, je tak stále vidět levé menu a v tabulce se posouvá vertikálním scroll-bar posuvníkem umístěným v pravé části DIVu. U každé souřadnice je v tabulce vygenerován odkaz na Gooogle mapy s vyznačenou souřadncí. 3.5.3.3

Generování GPX souboru a jeho zobrazení

K vygenerováni GPX souboru dochází zaškrtnutím check boxu Generovat GPX data z výsledků a následným odesláním formuláře tlačítkem Zobrazit GPS data přijata od-do. V tomto případě je mimo zobrazení souřadnic z daného období html kód stránky doplněn o odkaz na vygenerovaný GPX soubor, o odkaz na html stránku, kde je vygenerovaný GPX soubor vizualizován, a o dvě tlačítka, jimiž lze tento soubor odeslat na FTP server či E-mail (viz 3.16). Je-li vygenerování GPX souboru vyžadováno, je nejdříve funkcí fopen() na serveru vytvořen soubor GpsData.gpx. Do tohoto souboru je následně PHP funkcí fwrite() zapsána hlavička GPS souboru (viz prvních 7 řádků souboru zobrazeného na Obrázku 3.17). Dále jsou pak do tohoto souboru generovány segmenty popisující jednotlivé GPS záznamy (viz segmenty . . . . na stejném obrázku). Po uložení posledního záznamu je vygenerována část ukončující GPX soubor, ta do souboru vložena a soubor PHP funkcí fclose() uzavřen. Z nalezených GPS záznamů je tak v souboru GpsData.gpx vytvořena trasa, která může být vizualizována mnoha on-line GPX prohlížeči1 . Pro demonstraci této možnosti byla v rámci této práce vytvořena html stránka gpxview.html (také obsažena na přiloženém CD). Odkaz na tuto stránku je zpřístupněn po vygenerování souboru (zároveň je vygenerován odkaz na tento soubor, který tak lze okamžitě stáhnout). Kód této stránky, včetně JavaScript kódu (loadgpx.4.js) nutného pro jeho fungování, byl převzat z http://notions.okuda.ca/geotagging/projects-im-working-on/gpx-viewer/. Na tomto webu je uveden popis použitých kódů spolu s odkazy na další internetové stránky 1

Zde stojí za zmínku, že formát vygenerovaného souboru plně nesplňuje GPX specifikaci ([9]), ale pro účely této práce toto není na závadu.


44

zabývající se zpracováním GPX a XML souborů v prostředí Google map. Na tomto místě stačí uvést, že toto řešení nabízí možnost prohlédnout si trasu uloženou v GPS souboru na mapách Google, přičemž lze nastavit např. šířku a barvu čáry tvořící trasu, lze nastavit minimální vzdálenost mezi body tvořícími trasu, v případě, že GPX soubor obsahuje také waypointy, lze i tyto v trase zvýraznit atd. Zobrazování trasy tímto způsobem funguje bez problémů (viz např. Obrázek 3.18). Jedinou nevýhodou převzatého řešení bylo, že pro správné zpracování dat, bylo vyžadováno přejmenování koncovky vstupního souboru z GPX na XML. Toto bylo odstraněno přidáním direktiv AddType text/xml .xml a AddType text/xml .gpx do konfiguračního souboru HTTP serveru (soubor .htaccess). Po této úpravě již přejmenování není nutné a trasu lze generovat přímo z vytvořeného GPX souboru. 3.5.3.4

Odeslání GPX na FTP server a e-mailovou adresu

Jak již bylo výše naznačeno, lze vygenerovaný GPX soubor odeslat také na FTP server či ve formě přílohy na e-mailovou adresu. K tomuto slouží tlačítka Odeslat vygenerovaný GPX soubor na FTP server a Odeslat vygenerovaný GPX soubor na E-mail. Při stisku těchto tlačítek je volán skript odeslat.php. Tento skript, zjednodušeně řečeno, odešle soubor na e-mail či FTP server a o výsledku informuje uživatele. Odeslání na E-mail Je-li skript zavolán příslušným tlačítkem, dojde k odeslání vygenerovaného GPX souboru na E-mail. Nejdříve je PHP skriptem e-mailová zpráva sestavena. Skládá se klasicky z tzv. obálky a těla. Obálka je vytvořena nejjednodušším způsobem. Nastaveny jsou parametry FROM a TO, udávající, od koho zpráva pochází a komu je určena. V tomto konkrétním případě je odesílatelem [email protected] a příjemcem vždy [email protected] (skript tedy soubor vždy odešle na tuto adresu.)1 . Tělo zprávy je ve skriptu poskládáno ze tří částí. V první části je uveden typ a podtyp zprávy (TYPEMULTIPART, mixed). Druhá část těla tvoří textový obsah odesílané zprávy, tedy text e-mailu. Typ této části je TYPETEXT a podtyp plain. Samotný odesílaný text je vždy ”GPX trasa z GpsData.php.. .”. Třetí část zprávy je typu TYPEAPPLICATION a obsahuje odesílaný soubor. Důležitými parametry nastavenými u této části jsou podtyp (octet-stream), encoding (ENCBINARY) a disposition.type (attachment). Samotný GPX soubor je nejdříve otevřen PHP funkcí fo1

Samozřejmě by šlo stránku doplnit o vstupní pole, kam by uživatel zadal adresu, kam má být soubor odeslán, ale pro účel práce toto není nutné.


45

pen() 1 a poté funkcí fread() načten do proměnné $obsah. Tato proměnná je poté předána poslednímu parametru třetí části těla, parametru contents.data. Jednotlivé části těla jsou poté uloženy do proměnné $body. Tak je připravena obálka a tělo odesílané zprávy. Tyto části se následně předají PHP funkci imap mail compose(). Tato funkce se postará o finální naformátování odesílané zprávy (např. přidání tzv. boundary bloků pro oddělení jednotlivých částí těla atd.). Finální zpráva je uložena do proměnné $zprava. Z této proměnné jsou vyjmuty hotová obálka a tělo2 , a ty uloženy do zvláštních proměnných. Tyto proměnné jsou předány závěrečné PHP funkci mail() 3 , která se postará o skutečné odeslání e-mailu. Před ukončením PHP skriptu je do html kódu generované stránky vypsána informace o úspěšném (v případě nějaké chyby neúspěšném) odeslání. Vzhledem k tomu, že nebyl nalezen žádný vyhovující anonymní (tj. bez autorizace) smtp server, jejž by bylo možné pro odesílání zpráv využít, bylo pro odesílání využito stávajícího uživatelského účtu [email protected], tedy serveru smtp.seznam.cz (port 25). Funkce mail() odesílá zprávu na IP adresu a port uvedené v konfiguračním souboru php.ini a zde by tedy uvedený server a port měly být nastaveny. Jelikož však žádná ze standardních PHP funkcí (funkce mail() není výjimkou) odesílání zpráv na smtp server s autorizací nepodporuje, nebylo takovéto přímé řešení možné. Byla proto využita freeware aplikace SMTPAuth (http://www.bisswanger.com/en/index.php?seite=smtp). Tato aplikace poslouchá na přednastaveném portu počítače, na kterém je spuštěna, a elektronickou poštu, která je na tento port odesílána, přeposílá na zvolený smtp server (v případě serveru s vyžadovanou autorizací pod přednastaveným uživatelským jménem a heslem). V konfiguraci PHP je tedy jako smtp server nastaven localhost a jako port stejný port, na kterém poslouchá aplikace SMTPAuth (konkrétně standardní smtp port 25). Za zmínku stojí, že uvedená aplikace veškerou svoji činnost loguje a tak lze např. prohlížet uskutečněnou komunikaci smtp protokolem. Do jisté míry si tak lze např. ověřit činnost uvedených funkcí imap mail compose() a mail(). Viz Obrázek 3.19.

1

Nepodaří-li se soubor otevřít, je o tomto vygenerováno do html kódu chybové hlášení, tvorba e-mailové zprávy je zrušena a skript ukončen. 2 V proměnné odděleny znakovou sekvencí \r\n\r\n. 3 Dalšímy parametry této funkce jsou příjemce zprávy a subject (název) e-mailu.


46

Obrázek 3.19: Část SMTP komunikace zachycené programem SMTPAuth

Odeslání na FTP server Je-li skript zavolán příslušným tlačítkem, dojde k odeslání vygenerovaného GPX souboru na FTP server. K tomuto jsou v kódu skriptu použity tři standardní PHP funkce. První z nich, ftp connect(), zajistí připojení k FTP serveru. Parametry, se kterými se tato funkce volá, jsou adresa a port příslušného serveru. V konkrétním případě této práce běží FTP server (FileZilla Server) na stejném počítači jako HTTP server s PHP, adresa je tedy localhost. Portem, na kterém FTP server běží, je standardní port 21. Druhá z funkcí, ftp login(), se postará o zalogování na FTP server. Parametry této funkce jsou uživatelské jméno a heslo. Samotné odeslání GPX souboru zajišťuje funkce ftp put().


47

Parametry této funkce jsou, kromě dalších, cesta k souboru, jenž má být odeslán, jméno, pod kterým bude soubor na serveru uložen1 , a způsob, jakým bude soubor na server přenesen (FTP ASCII). Nepodaří-li se v úvodní části připojit či zalogovat na server, je o tomto vypsána chybová hláška a skript se ukončí. V opačném případě dojde k ukončení skriptu po odeslání souboru následovaného vypsáním informace o tom, jestli se odeslání zdařilo či nikoliv.

1

Jméno, pod kterým je soubor na FTP server uložen, (příklad: GpsData2009-11-23 21h49m19s.GPX ) v sobě obsahuje informace o čase odeslání souboru (ty jsou pro účely pojmenování souboru získány PHP funkcí getDate().

4 Praktické otestování systému Navržený systém byl otestován v mobilní síti Vodafone. Použita byla předplacená SIM karta a pro účtování datových přenosů byl zvolen tarif Vodafone Internet v mobilu na den (17Kč / den, max. objem přenesených dat 5MB ), jenž pro daný účel vyhovoval1 . Systém byl testován jednak staticky (modul byl v budově, nepohybovalo se s ním), a poté i prakticky ve vozidle.

4.1

Statické testování

Toto testování probíhalo mimo vozidlo. Modul byl připojen ke stolnímu počítači, jeho systémový výstup (system.out), a tedy všechny debugovací hlášky byly přesměrovány na sériové rozhraní ASC0 a zobrazovány na připojeném počítači. Tak bylo možné kontrolovat činnost modulu. Aplikace byla spuštěna tak, jak by byla spuštěna v automobilu. Zapnuty byly i TCP a UDP server a databáze pro ukládání dat. Během testování byly uměle vyvolávány všemožné situace, jež mohou během provozu zařízení nastat (opakované zapínání / vypínání odesílání dat, pád UDP (TCP) serveru, opakovaný pád databáze, vyčerpání kreditu na SIM kartě, ztráta GPS signálu, . . .). Testováno bylo odesílání dat oběma druhy protokolů, odesílání dat s bufferováním i bez něj, odesílání dat s různými periodami vyčítání souřadnic z GPS přijímače. . . Stručné shrnutí tohoto testování uvádí následující tabulky.

1

V případě větších a častějších datových přenosů by bylo výhodné využít některý z měsíčních tarifů bez omezení velikosti přenesených dat. Naopak pro málo časté a krátké přenosy by bylo výhodnější např. Připojení Vodafone karta, kde se platí jen za skutečně přenesená data (0,060 Kč/kB).

48

4.1. STATICKÉ TESTOVÁNÍ

49

Testovaná událost

Výsledek S buffrováním Bez Bufferování Přepínání stavů (READY a SLEDOVANI) Ok Ok tlačítkem Přepínání stavů SMS zprávou Ok Chyba Přepínání stavů SMS zprávou Ok Chyba z nepovoleného čísla Prozvonění modulu ve stavu READY Ok Ok Prozvonění ve stavu READY Ok Ok z nepovoleného čísla Prozvonění ve stavu SLEDOVANI Ok Chyba Prozvonění ve stavu SLEDOVANI Ok Chyba z nepovoleného čísla Vypnutí aplikace ve stavu READY Ok Ok Vypnutí aplikace ve stavu SLEDOVANI Ok Ok Detekce pádu UDP serveru Chyba Chyba + znovu připojení Odeslání 210 souřadnic Ok Ok (kontrola počtu přijatých) Dotazování na stav serveru po 10 odeslaných souřadnicích v případě neaktivního bufferování a po dvou odeslaných datagramech v případě Ok Ok aktivního bufferování (tedy po odeslání 30 souřadnic ve dvou datagramech). Kontrolována byla detekce pádu serveru, tedy nepřijmutí odpovědi od něj. Tabulka 4.1: Test odesílání UDP protokolem, perioda vyčítání dat z GPS přijímače 1 sekunda.

4.1. STATICKÉ TESTOVÁNÍ

50

Testovaná událost

Výsledek S buffrováním Bez Bufferování Přepínání stavů (READY a SLEDOVANI) Ok Ok tlačítkem Přepínání stavů SMS zprávou Ok Chyba Přepínání stavů SMS zprávou Ok Chyba z nepovoleného čísla Prozvonění modulu ve stavu READY Ok Ok Prozvonění ve stavu READY Ok Ok z nepovoleného čísla Prozvonění ve stavu SLEDOVANI Ok Chyba Prozvonění ve stavu SLEDOVANI Ok Chyba z nepovoleného čísla Vypnutí aplikace ve stavu READY Ok Ok Vypnutí aplikace ve stavu SLEDOVANI Ok Ok Detekce pádu TCP serveru Ok Ok + znovu připojení Odeslání 210 souřadnic Ok Ok (kontrola počtu přijatých) Tabulka 4.2: Test odesílání TCP protokolem, perioda vyčítání dat z GPS přijímače 1 sekunda. Kromě výše uvedeného byl proveden i test správného bufferování. Byly nastavovány periody vyčítání dat z GPS přijímače v rozmezí 1-16 sekund a přitom byl kontrolován počet najednou odesílaných souřadnic. I toto fungovalo dle požadavků. Situace, v nichž systém neobstál (označeny Chyba), nastaly vždy v případě, kdy byly souřadnice odesílány bez bufferovaní, tedy v případech, kdy se souřadnice odesílaly jednotlivě s periodou jedné vteřiny. V tomto případě selhal jakýkoliv pokus o vzdálenou komunikaci s modulem. V případě vytočení telefonního čísla modulu byl operátorem modul prohlášen za nedostupný, v případě odeslání SMS zprávy tato byla doručena až po ukončení odesílání. Toto je způsobeno zřejmě tím, že operátor používá pro doručování SMS zpráv GPRS kanál, jenž je obsazen odesíláním dat. V případě bufferovaného přenosu, tedy přenosu, kdy se souřadnice neposílají jednotlivě, ale jednou za čas (typicky po 15 sekundách) po skupinách, vznikají mezi odesíláním dostatečné časové mezery na spojení případného hovoru či doručení SMS zprávy. A to jak v případě UDP, tak i TCP protokolu.

4.2. TESTOVÁNÍ VE VOZIDLE

4.2

51

Testování ve vozidle

Bylo provedeno několik testovacích jízd, během nichž bylo otestováno odesílání GPS souřadnic jak protokolem TCP, tak protokolem UDP. Otestováno bylo bufferované i nebafferované odesílání a vyzkoušeno bylo i přerušení a opětovné spuštění odesílání dat během testovací jízdy. K testování byl použit vůz Ford Galaxy, modul byl umístěn i s GPS anténou pod předním sklem a napájen byl palubním napětím vozu. Viz Obrázek E.1 v příloze E. Testovací jízdy probíhaly v okolí Zdíkova na Šumavě, pro vyzkoušení zařízení v oblasti s větším zatížením GSM sítě byla jedna z testovacích jízd udělána i v Českých Budějovicích. Ze záznamů GPS souřadnic získaných během testování byly vygenerovány projeté trasy. Zde budou uvedeny pro ilustraci některé z nich.

Trasa

Zdíkov - Nový Dvůr - Albrechtec Jirkalov - Stachy - Zdíkov Start 28.11.2009 13:10:34 Konec 28.11.2009 13:35:34 Protokol TCP Buffrování NE Perioda odesílání souřadnic 1s Počet přijatých souřadnic v trase 1440 Tabulka 4.3: Trasa č.1 (viz Obrázek E.2 přílohy E)

Trasa

Zdíkov - Stachy - Michalov - Kůsov Zadov - Nový Dvůr - Zdíkov Start 27.11.2009 12:12:09 Konec 27.11.2009 12:36:35 Protokol UDP Buffrování NE Perioda odesílání souřadnic 1s Počet přijatých souřadnic v trase 1100 Tabulka 4.4: Trasa č.2 (viz Obrázek E.3 přílohy E) Pozn. během této trasy bylo vyzkoušeno vypnutí a následné opětovné zapnutí odesílání dat. Okamžiky vypnutí a zapnutí jsou na obrázku označeny červeně.


52

Trasa

Část trasy Zdíkov - Račov Putkov - Račov - Zdíkov Start 29.11.2009 9:54:00 Konec 29.11.2009 9:59:32 Protokol UDP Buffrování NE Perioda odesílání souřadnic 1s Počet přijatých souřadnic v trase 315 Tabulka 4.5: Trasa č.3 (viz Obrázek E.4 přílohy E) Z vygenerovaných tras je patrné, že navržený systém je schopný sledovat polohu vozu. Vypočítá-li se počet souřadnic, jenž by měl být v rámci jednotlivých tras na server odeslán, je vidět, že počet skutečně přijatých souřadnic je o něco málo nižší. Nechybí souvislé bloky souřadnic, ale občas jedna či dvě za minutu. A to jak v případě odesílání dat protokolem UDP (zde by se to dalo předpokládat), tak i v případě, kdy je pro odesílání použit protokol TCP. V rámci výše uvedeného statického testování toto nenastalo. Souřadnice vždy byly doručeny všechny. Lze tedy předpokládat, že na vině je činnost prováděná v rámci GSM sítě (přehlašování mezi BTS stanicemi, s tím spojené možné krátkodobé rozpadání GPRS spojení atd.). Nicméně rychlost pohybujících se vozidel není vysoká a občasná ztráta jedné ze souřadnic se na vygenerované trase téměř ztratí. Z vygenerovaných map je vidět, že určení polohy GPS přijímačem v modulu je velmi přesné. A to i v případě, kdy bylo projížděno například lesem. Tato přesnost je srovnatelná s přesností určení polohy komerčními GPS navigacemi1 . Jelikož jsou serverem přijatá data okamžitě ukládána do databáze, lze toho využít a průběžně polohu vozu během jízdy kontrolovat. Pro tyto účely byl napsán jednoduchý PHP skript, uložen na CD v adresáři Zdrojove kody/web pod názvem sledovani.php, jenž pouze vybírá z databáze nejnovější souřadnici a tu na mapě zobrazuje ve webovém prohlížeči. Tento skript opět využívá mapy Google. V kódu výsledné stránky je nastaven automatický refresh a stránka (a tedy i mapa s vyznačenou polohou vozu) je tak automaticky po přednastavené době aktualizována. Součástí přiloženého CD je také videozáznam ukazující využití této stránky. Jedná se o záznam pořízený během jedné z testovacích jízd, kdy byla poloha vozu touto stránkou prů1

Podíváme-li se občas během jízdy na komerční GPS navigaci, tak je často skutečná poloha vozu (v některých navigacích zobrazena malinkou tečkou) zcela mimo vozovku. To, že hlavní šipka zobrazující řidiči polohu je zobrazena na silnici, je výsledkem práce softwaru, jenž předpokládá, že řidič při rychlosti 100km/hod nejede po poli vedle silnice, ale po silnici.


53

běžně sledována (konkrétně se jedná o zachycení části trasy zobrazené na Obrázku E.4). Video je uloženo pod názvem trasa1.AVI.

5 Závěrečné zhodnocení Navržený systém, jak je vidět z výsledků uvedených výše, funguje dle požadavků. Umožňuje sledovat polohu pohybujícího se vozidla a informaci o poloze odesílat po vyžádání ve formě SMS zpráv na mobilní telefon, či vybraným protokolem periodicky na vzdálený server. Na straně serveru jsou data ukládána do databáze a díky navrženému webovému rozhraní mohou být průběžně odesílána ve formě datových souborů na FTP server či na danou e-mailovou adresu. Do budoucna si lze představit, že by bylo možné navržený systém na straně GSM modulu doplnit o logování dat do souboru (např. pro případ, kdy není k dispozici GSM signál nebo server na než se mají data odesílat). Bylo by také možné na dálku prostřednictvím modulu ovládat zařízení uvnitř vozu (např. odpojení autobaterie), zajímavé by také bylo modul doplnit miniaturní kamerkou a na vyžádání na server odesílat snímek např. kabiny vozu. Na straně serveru by bylo možné zpřehlednit ukládání dat do databáze. Např. jednotlivé trasy ukládat do samostatných tabulek. A samozřejmě i webové rozhraní určené pro prohlížení záznamů a odesílání dat by bylo možné vylepšit. V práci používané mapy umožňují jen zlomek toho, čeho by šlo dosáhnout s využitím profesionálních mapových API1 ve spojení s technologií AJAX. Vzorem, jak by takové skutečně pěkně navržené on-line sledování polohy s využitím internetu mohlo vypadat, je např web http://radar.zhaw.ch/radar.html monitorující letový provoz. Uvedená vylepšení by si však žádala dlouhodobější práci na projektu, a to ne jednotlivce, ale nejlépe celé skupiny lidí. I přes uvedená možná vylepšení (na každém projektu je vždy co vylepšovat) si však myslím, že systém byl navržen tak, že je v praxi použitelný.

1

Ať už od firmy Google nebo třeba české firmy Seznam.cz, a.s.

54

Seznam použitých zkratek 2D 3D AGPS API BTS CD CEP CLDC 1.1 HI

-

CLIP CS1 CS4 DGPS DSP FTP GNSS GPIO GPRS GPS GPX GSM HTML HTTP I2C IDE ITU IM IMP-NG IP

-

Two Dimensional Three Dimensional Assisted GPS Application Programming Interface Base Transceiver Station Compact Disc Circular Error Probable Connected Limited Device Configuration Hot spot Implementation Calling Line Identification Presentation Coding Scheme 1 Coding Scheme 4 Differential GPS Digital Signal Processor File Transfer Protocol Global Navigation Satellite Systems General Purpose IO General Packet Radio Service Global Positioning System GPS eXchange format Global Standard for Mobile Communications HyperText Markup Language HyperText Transfer Protocol Inter-Integrated Circuit Integrated Development Environment International Telecommunication Union Information Module Information Module Profile - Next Generation Internet Protocol

55

56 JAD - Java Application Descriptor JAR - JavaT M Archive LED - Light Emitting Diode M2M - Machine To Machine MIDP - Mobile Information Device Profile MIME - Multipurpose Internet Mail Extensions OEM - Original Equipment Manufacturer PDF - Portable Document Format PHP - PHP: Hypertext Preprocessor PIN - Personal Identification Number RoHS - Restriction of Specific Hazardous Substances in Eletrical and Electronic Equipment RS232 - Recommended Standard 232 SBAS - Satellite Based Augmentation System SDK - Standard Development Kit SEP - Spherical Error Probable SIM - Subscriber Identification Module SMD - Surface Mount Device SMS - Short Message Service SMTP - Simple Mail Transfer Protocol SPI - Serial Peripheral Interface SQL - Structured Query Language TCP - Transmission Control Protocol UDP - User Datagram Protocol URC - Unsolicited Result Code USB - Universal Serial Bus UTC - Coordinated Universal Time XML - Extensible Markup Language

Seznam obrázků 1.1 1.2 1.3

Lokalizace s využitím metody Cell ID . . . . . . . . . . . . . . . . . . . . . Metoda Timing advance . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metoda Angle of Arrival . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 4 5

2.1

Poskládání systému z jednotlivých částí . . . . . . . . . . . . . . . . . . . .

8

2.2 2.3

GPS přijímač LR9805ST firmy Leadtek . . . . . . . . . . . . . . . . . . . . Využití programovatelného GSM modulu . . . . . . . . . . . . . . . . . . .

9 11

3.1 3.2 3.3

GSM modul Siemens XT65 . . . . . . . . . . . . . . . . . . . . . . . . . . M2M universal motherboard 2.0 . . . . . . . . . . . . . . . . . . . . . . . . Parametry GPIO rozhraní modulu . . . . . . . . . . . . . . . . . . . . . .

14 16 18

3.4 3.5 3.6 3.7

Zapojení přepínačů . . . . . . . . . . . Zapojení signalizačních LED diod . . . Stavy MIDletu . . . . . . . . . . . . . Možný obsah souboru MANIFEST.MF

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

19 19 21 22

3.8 3.9 3.10 3.11

Možný obsah JAD deskriptoru . . . Přístup do FLASH paměti modulu Obsah FLASH paměti modulu . . . Struktura tabulky data . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

23 25 25 35

3.12 3.13 3.14 3.15 3.16

Záznamy uložené v tabulce data . . . . . . . . . . . . . . . . . . . . . Základní vzhled webového rozhraní . . . . . . . . . . . . . . . . . . . Zobrazení nejnovějšího záznamu uloženého v databázi . . . . . . . . . Zobrazení souřadnic z daného časového období . . . . . . . . . . . . . Zobrazení souřadnic z daného období s vygenerováním GPX souboru

. . . . .

. . . . .

. . . . .

36 37 37 38 38

3.17 Obsah vygenerovaného GPX souboru . . . . . . . . . . . . . . . . . . . . . 3.18 Trasa z vygenerovaného GPX souboru . . . . . . . . . . . . . . . . . . . . 3.19 Část SMTP komunikace zachycené programem SMTPAuth . . . . . . . .

39 39 46

. . . .

57

. . . .

SEZNAM OBRÁZKŮ

58

A.1 Orientační schéma modulu XT65 . . . . . . . . . . . . . . . . . . . . . . . A.2 Blokový diagram modulu XT65 . . . . . . . . . . . . . . . . . . . . . . . .

61 62

B.1 Parametry modulu Siemens XT65 - část 1 . . . . . . . . . . . . . . . . . . B.2 Parametry modulu Siemens XT65 - část 2 . . . . . . . . . . . . . . . . . . B.3 Parametry modulu Siemens XT65 - část 3 . . . . . . . . . . . . . . . . . .

63 64 65

B.4 Parametry modulu Siemens XT65 - část 4 . . . . . . . . . . . . . . . . . .

66

C.1 Nastavení obsahu deskriptoru a MANIFEST.MF v NetBeans . . . . . . . . C.2 Spuštění MIDletu z prostředí NetBeans . . . . . . . . . . . . . . . . . . . .

68 69

D.1 Stavový diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

E.1 E.2 E.3 E.4

73 74 75 76

Test zařízení Trasa č.1 . . Trasa č.2 . . Trasa č.3 . .

ve vozidle . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Seznam tabulek 3.1 3.2 3.3

Parametry použité pro výpočet hodnot rezistorů R1 a R2 . . . . . . . . . . Načítané parametry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Počet odesílaných souřadnic . . . . . . . . . . . . . . . . . . . . . . . . . .

20 26 31

4.1

Test odesílání UDP protokolem . . . . . . . . . . . . . . . . . . . . . . . .

49

4.2 4.3 4.4 4.5

Test odesílání TCP protokolem Trasa č.1 . . . . . . . . . . . . . Trasa č.2 . . . . . . . . . . . . . Trasa č.3 . . . . . . . . . . . . .

50 51 51 52

. . . .

. . . .

. . . .

59

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Použitá literatura [1] Siemens AG, XT65/XT75 Hardware Interface Description verze 01.001, 2007-1-8 [2] Siemens AG, XT75 AT Command Set verze 01.001, 2007-1-9 [3] Cinterion Wireless Modules GmbH, Java User’s Guide verze 13, 2008-07-24 [4] Alarex Group s. r. o., Technická dokumentace k M2M universal motherboard 2.0, 2009 [5] ORLICH M., Základní lokalizační metody v GSM, 2006 URL: http://access.feld.cvut.cz/view.php?cisloclanku=2006022801 [6] Sun Microsystems, Inc., JavaT M 2 Platform Standard Edition 5.0 API Specification, 2004 [7] Sun Microsystems, Inc., JSR 195: Information Module Profile 1.0 specification, 2005 [8] PHP Documentation Group, PHP manual [online], URL: http://www.php.net/manual/en/manual.php [9] GPX 1.1 Schema Documentation [on-line], URL: http://www.topografix.com/GPX/1/1/ [10] National Space-Based Positioning, Navigation, and Timing Coordination Office, Global Positioning System [online], URL: http://www.gps.gov/ [11] Russian Space Agency, The Information-Analytical Centre [online], URL: http://www.glonass-ianc.rsa.ru/ [12] Česká kosmická kancelář, o.p.s., Národní kontaktní bod Galileo [online], URL: http://www.czechspace.cz/cs/galileo [13] European Space Agency, EGNOS Homepage [online], URL: http://www.esa.int/esaNA/egnos.html

60

A Orientační schéma a blokový diagram GSM modulu Siemens XT65 (převzato z [1])

Obrázek A.1: Orientační schéma modulu XT65

61

62

Obrázek A.2: Blokový diagram modulu XT65

B Technické parametry GSM modulu Siemens XT65 (převzato z [1])

Obrázek B.1: Parametry modulu Siemens XT65 - část 1

63

64


65


66


C Ukázka využití prostředí NetBeans pro vývoj MIDletů

67

68

Obrázek C.1: Nastavení obsahu deskriptoru a MANIFEST.MF v NetBeans

69

Obrázek C.2: Spuštění MIDletu z prostředí NetBeans

D Základní stavový diagram navržené aplikace pro modul Siemens XT65

70

71

Obrázek D.1: Stavový diagram

E Zařízení ve vozidle a trasy vygenerované z uložených GPS souřadnic

72

73

Obrázek E.1: Test zařízení ve vozidle: 1-Vypínač aktivující/deaktivující odesílání dat 2Napájení 12V 3-Vypínač ukončující běh programu 4-LED dioda signalizující stav SLEDOVANI 5-LED dioda signalizující vyčítání dat z GPS přijímače 6-Sériové rozhraní pro připojení PC 7-GPS anténa 8-GSM anténa 9-Pull Up rezistory vypínačů

74

Obrázek E.2: Trasa č.1

75


76


České vysoké učení technické v Praze. Fakulta elektrotechnická. Diplomová práce Petr Špika

Recommend Documents