Monitorowanie pojazdów z wykorzystaniem systemów GPS i GPRS ...

Politechnika Poznańska w Poznaniu Wydział Elektroniki i

Telekomunikacji

Praca magisterska

„Monitorowanie pojazdów z wykorzystaniemsystemów GPS i GPRS”

Miłosz Zajonz

Kierownik pracy:dr Krzysztof Lange

Poznań 2009

Dziękuję mojemu ojcu za udzielonewsparcie i cierpliwość.

1

Spis treści

Wprowadzenie – cel i zakres pracy 6

1 Streszczenie 6

2 Budowa pracy 7

3 Abstract 7

I Część teoretyczna 8

1 GPS zmienia świat 81.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2 Struktura systemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3 Zasada działania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.4 Źródła błędów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.5 Protokół NMEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 GPRS-pakietowa transmisja danych w sieci GSM 172.1 Co to jest GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2 GPRS a GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3 Ewolucja metod trasmisji danych w GSM[24] . . . . . . . . . . . . . . 192.4 Przegląd modemów wykorzystujących technologię GPRS . . . . . . . 20

2.4.1 Aplikom 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4.2 Moduł Siemens TC65 . . . . . . . . . . . . . . . . . . . . . . . 222.4.3 Telit GM862-GPS . . . . . . . . . . . . . . . . . . . . . . . . . 232.4.4 Wavecom Q2501B . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Aplikacje Internetowe 253.1 Przełom w budowaniu serwisów internetowych . . . . . . . . . . . . . 253.2 Środowisko Zope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.1 Wybór Frameworka . . . . . . . . . . . . . . . . . . . . . . . . 263.2.2 ZOPE - wprowadzenie . . . . . . . . . . . . . . . . . . . . . . 27

4 Google Maps 29

5 Języki wysokiego poziomu 315.1 JavaMe - programowanie urządzeń mobilnych . . . . . . . . . . . . . 31

5.1.1 J2ME = CLDC + MIDP[17] . . . . . . . . . . . . . . . . . . . 325.1.2 Java w telefonach GSM . . . . . . . . . . . . . . . . . . . . . . 32

2

5.1.3 Java po liftingu[18] . . . . . . . . . . . . . . . . . . . . . . . . 335.1.4 Praca z kodem . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.3 SQL i bazy danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

II Część praktyczna - projekt Ariadna 38

1 Wstęp 38

2 Słownik 38

3 Prowadzenie projektu 39

4 Koncepcja systemu 40

5 Analiza kosztów 42

6 Projekt i wykonanien systemu 436.1 GeoAgent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.1.1 Wybór odbiornika GPS - Navibe GM720 . . . . . . . . . . . . 456.1.2 Wybór modemu GPRS - Aplikom 12 . . . . . . . . . . . . . . 456.1.3 ED77 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.1.4 Zestawienie komunikacji GPS GM720 i modemu ED77 . . . . 476.1.5 Odbiór komunikatów GPS przez moduł Aplicom . . . . . . . . 486.1.6 Wysłanie meldunków do zdalnego serwera . . . . . . . . . . . 486.1.7 Dodatkowa obsługa SMS . . . . . . . . . . . . . . . . . . . . . 50

6.2 GeoListener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.2.1 GeoListener . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.2.2 UDPReceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.2.3 AddressUpdater . . . . . . . . . . . . . . . . . . . . . . . . . . 556.2.4 TraceUpdater . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.3 GeoStorage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.4 GeoBotMaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.4.1 BotSynchronizer . . . . . . . . . . . . . . . . . . . . . . . . . 636.4.2 Bot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.5 GeoZope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.5.1 Zasada działania . . . . . . . . . . . . . . . . . . . . . . . . . 686.5.2 Projekt witryny i lista opcji . . . . . . . . . . . . . . . . . . . 696.5.3 Ekran live (rys. 32) . . . . . . . . . . . . . . . . . . . . . . . . 706.5.4 Ekran playback (rys. 33 ) . . . . . . . . . . . . . . . . . . . . . 70

3

6.5.5 Ekran ślady (rys. 34) . . . . . . . . . . . . . . . . . . . . . . . 726.5.6 Ekran heatmaps (rys. 35) . . . . . . . . . . . . . . . . . . . . . 736.5.7 Ekran strefy (rys. 36) . . . . . . . . . . . . . . . . . . . . . . . 746.5.8 Ekran komunikaty (rys. 37) . . . . . . . . . . . . . . . . . . . 746.5.9 Ekran dodanie bota (rys. 38) . . . . . . . . . . . . . . . . . . . 746.5.10 Ekran lista botów (rys. 39) . . . . . . . . . . . . . . . . . . . . 74

7 Zakończenie 757.1 Perspektywy zastosowania i dalszego rozwoju . . . . . . . . . . . . . 757.2 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767.3 Wykorzystane oprogramowanie . . . . . . . . . . . . . . . . . . . . . 77

A Załączniki cyfrowe 78A.1 Buildout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78A.2 Kody źródłowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Literatura 79

4

Wprowadzenie – cel i zakres pracy

1 Streszczenie

Większość dużych firm i niemal wszystkie korporacje posiadają własną flotę po-jazdów. Firmy te, chcąc zwiększyć swoją efektywność i zredukować koszty chętniedecydują się na różnego rodzaju systemy nawigacji satelitarnej. Zdalne śledzenie po-jazdów pozwala na lepszą koordynacje i planowanie trasy, oraz zapobiega próbomnieautoryzowanego użycia pojazdu przez pracowników. Dodatkowym atutem jestwiększa szansa na odzyskanie pojazdu po kradzieży. Często do modułu nawigacjipodłączana jest sonda paliwowa, firma transportowa może w ten sposób łatwo zi-dentyfikować pracowników, którzy mają "ciężką nogę" i poinstruować ich o sposobieekonomicznej jazdy. Koszty paliwa stanowią obecnie ok. 40% całkowitych kosztówutrzymania firm transportowych [14].

Obecnie na rynku istnieje wiele konkurujących ze sobą firm świadczących usłu-gi śledzenia pojazdów. Zastosowane rozwiązania różnią się szczegółami, ale zasadadziałania jest ta sama. Samochód zostaje wyposażony w urządzenie, którego okre-ślony interwał czasu wysyła swoją pozycje poprzez sieć GSM do centralnego serwera.Klienci łączą się z serwerem poprzez dedykowaną aplikację i w ten sposób mogą śle-dzić oraz zarządzać swoją flotą. Urządzenia oprócz śledzenia pozycji często równieżwyposażone są dodatkowo w czujniki – wspomniana wcześniej sonda paliwowa, jakrównież czujnik zapalania silnika, czy nawet otwierania drzwi. Podstawową zaporąw przypadku chęci skorzystania z tego typu usług jest cena, która często przekraczakwotę 100 zł netto na miesiąc na każdy pojazd.

Celem pracy magisterskiej jest wykonanie i przetestowanie systemu, któregokoszt będzie bardzo niski(mniej niż 300 zł za jedno urządzenie), a funkcjonalnośćzbliżona do komercyjnych rozwiązań. Zaprojektowany system integruje ze sobą wie-le różnych technologii. Aby go wykonać niezbędna okazała się wiedza na tematukładów elektronicznych, systemów operacyjnych, administracji serwerów, tworze-nia aplikacji internetowych, programowania urządzeń mobilnych, w końcu wiedzateoretyczna o systemach GPS i GSM/GPRS. Na bazie systemu uruchomione zostałprojekt Ariadna służący do śledzenia i analizy ruchu floty pojazdów. Ze względuna ograniczenia związane z budżetem całego przedsięwzięcia zbudowano tylko jedenprototyp urządzenia typu Agent(montowanego w pojazdach). System przygotowanyjest jednak na obsłużenie wielu pojazdów i wielu użytkowników. Aby móc sprawdzićdziałanie systemu w takich warunkach, możliwe jest dodanie wirtualnych samocho-dów, ze zdefiniowaną trasą i rozkładem prędkości.

5

2 Budowa pracy

Architektura układu wykorzystana w systemie ma budowę modułową, tzn. składasię z wielu niezależnych, współpracujących ze sobą części. W kolejnych sekcjach czę-ści teoretycznej wyjaśnione zostają technologie użyte w poszczególnych warstwachsystemu. Opisane są dokładnie główne mechanizmy niezbędne do wysyłania danychdo serwera –system GPS odpowiedzialny za wyznaczenie pozycji i GPRS jako plat-forma za pomocą której można bezprzewodowo wysyłać informacje z obszaru całegokraju. W dalszych sekcjach przedstawiono technologe użyte po stronie serwera tj no-woczesny sposób budowania stron WWW(aplikacje internetowe, środowisko ZOPE )oraz usługę Google Maps, za pomocą której można wyświetlać obiekty na mapach.Ostatnia część rozdziału zawiera krótką charakterystykę wykorzystywanych językówprogramowania – JavaME, Python i SQL(wraz z opisem baz danych)

Druga część pracy stanowi przełożenie umówionych wcześniej informacji teore-tycznych na praktykę. W tym celu od podstaw budowany jest system śledzenia traspojazdów nazwany Ariadna. W kolejnych rozdziałach szczegółowo wyjaśniona zo-staje budowa, sposób działania i integracja poszczególnych elementów architekturysystemu, oraz opis najważniejszych i najciekawszych rozwiązań programistycznychi sprzętowych.

3 Abstract

This report studies a low cost hardware platform for Fleet Management Services.The platform manages vehicle data, positioning and wireless communication. Allinformation from the mobile devices are transmitting to the server- the core of thesystem. Server stores data in relational database. Visualization layer is a web serviseintagrated with Google Maps.

6

I

Część teoretyczna

1 GPS zmienia świat

1.1 Historia

Za początek nawigacji satelitarnej należy uznać pracę wykonaną przez naukowcówz Hopkins University w Baltimore, USA. Korzystając z sygnałów radiowych nada-wanych przez radzieckiego satelitę Sputnik I, wykazali możliwość wykorzystania donawigacji sztucznych satelitów Ziemi.

Historycznie pierwszym systemem nawigacji satelitarnej był opracowany na prze-łomie lat pięćdziesiątych i sześćdziesiątych system Transit - SATNAV, który osiągnąłzdolność operacyjną w 1964r. Postawę systemu stanowiło 6 satelit, krążących na ni-skich (1100km) orbitach. Pracowały one na częstotliwości 150MHz i 400 MHz, ado określania pozycji wykorzystywany był efekt Dopplera.[2] Mała liczba satelitównie wystarczała do pokrycia zasięgiem całej kuli ziemskiej. Należy pamiętać, że byłto okres zimnej wojny, więc nie trzeba było długo czekać na odpowiedź ze stronyzwiązku radzieckiego. Bliźniaczy system nazwano Cykada.

Wspomniane platformy działały sprawnie i bezproblemowo, co okazało się dużymsukcesem. Skłoniło to USA do wzmożonych wysiłków mających na celu opracowa-nie nowych, lepszych technologii geo lokalizacji. W ten sposób powstały programyTIMATION Marynarki Wojennej USA oraz 621 B (1968 r).Doświadczenia zebranepodczas tworzenia i użytkowania tych systemów umożliwiły Departamentowi Obro-ny USA stworzenie systemu nawigacji satelitarnej znacznie doskonalszego od po-przedników. Tak narodził się projekt GPS - NAVSTAR. [2]

W przedsięwzięciu brały udział wszystkie rodzaje wojsk USA (armia lądowa, ma-rynarka wojenna, lotnictwo), a także służba kartograficzna DMA (Defense MappingAgency) oraz prywatne firmy i ośrodki badawcze. System był stopniowo udostępnia-ny autoryzowanym użytkownikom (zastosowanie wyłącznie militarne- wersja PPS -Precision Positioning Service). NAVSTAR pozwalał określić pozycję z dokładnościądo 10m. Początkowo odbiorniki były niezwykle drogie(pierwsze odbiorniki koszto-wały 125 tys. USD) i duże, jednak wraz z postępującą miniaturyzacją układówscalonych, niedogodności te systematycznie niwelowano. Wkrótce również cywilniużytkownicy zaczęli się domagać się dostępu do systemu, uruchomiono wobec tegowersję SPS (Standard Positioning Service). SPS posiadał jednak ograniczenie do-kładności do 500m, co skutecznie eliminowało go z wielu funkcji, które mógł pełnićsystem udostępniający pełnie swoich możliwości.

7

Duże zainteresowanie systemem spowodowało poprawę wersji SPS do dokład-ności 100m. Producentom sprzętu udało się jednak udoskonalić odbiorniki cywilnedo tego stopnia, że dokładność pozycji była porównywalna z wersją militarną. Powprowadzeniu na orbity i uruchomieniu wszystkich planowanych satelitów systemu,dnia 27.04.1995 r. oficjalnie ogłoszono system GPS w pełni operacyjnym, to znaczyspełniającym wymagania podane w oficjalnych specyfikacjach systemu.

Z dniem 1 maja 2000 Administracja USA podjęła decyzję o zaprzestaniu wpro-wadzania błędu do sygnału GPS i obecnie dokładność pozycji dla SPS wynosi do 10m. Zmiany te dotyczą całego świata, z wyjątkiem niektórych regionów, na którychtoczy się wojna lub jest niestabilna sytuacja polityczna.

1.2 Struktura systemu

Segment kosmicznyW skład segmentu kosmicznego wchodzą satelity bądź inne urządzenia kosmicz-

ne należące do GPS. Projektanci systemu oryginalnie przewidywali 24 satelity, po8 na każdą orbitę kołową, jednak te plany zostały zmienione i obecnie mamy po 4satelity na krążących po 6 orbitach (rys. 1). Satelity z punktu widzenia obserwatoraznajdującego się na ziemi nie poruszają się względem gwiazd, a więc są geocen-tryczne. W praktyce zmienia się ona co 4 minuty każdego dnia w wyniki różnicypomiędzy długością doby słonecznej i gwiazdowej[5]. Wysokość każdej satelity wy-nosi około 20200 km i jest ona nachylona do ziemi pod kątem 55 stopni. Zapewniająone widoczność co najmniej 5 satelitów z każdego punku na kuli ziemskiej z praw-dopodobieństwem 99.96% [6] Na nielicznych i niewielkich obszarach wyznaczeniepozycji trójwymiarowej jest niemożliwe w okresie nie dłuższym niż około 20 minutw ciągu doby.

Utrzymanie tak dużej liczby nadajników jest bardzo kosztowne. Są to niezwykleskomplikowane i drogie urządzenia, ich żywotność oscyluje zwykle wokół 10 lat [5].Stany Zjednoczone regularnie wymieniają przestarzałe/wadliwe satelity. Ciekawost-ką jest fakt, że satelity mają zainstalowaną aparaturę NUDET (Nuclear Detection), która jest przeznaczona do natychmiastowego wykrywania wybuchów nuklearnychna Ziemi[6].

Generacje satelitów GPS[6]

• Satelity bloku I (SVN1 – SVN11):

– obecnie nie występują

– 3 zegary: 1 cezowy i 2 rubidowe

• Satelity bloku II (SVN13 – SVN21):

8

– silny sygnał

– możliwe działanie przez 14 dni bez kontaktu ze stacją kontrolną

• Satelity bloku IIA (SVN22 – SVN40):

– 4 zegary atomowe: 2 cezowe i 2 rubidowe)

– zdolność transmisji sygnału zdegradowanego przez degradację SA i AS,

– możliwe działanie przez 180 dni bez kontaktu ze stacją kontrolną

– żywotność satelity: 9.6 - 10.23 lat [8]

• Satelity bloku IIR (SVN41 – SVN62):

– działanie przez 14 dni bez kontaktu ze stacjami kontrolnymi( korzystaniez automatycznej nawigacji)

– możliwość łączności między sobą i możliwy pomiar odległości między sa-telitami,

– 3 zegary rubidowe

– zdolność transmisji sygnału zdegradowanego przez degradację SA i AS,

– żywotność satelity: 8.57 - 10.62 lat[8]

• Satelity bloku IIR-M:

– znacznie lepsza jakość sygnału

– wzajemna łączność i wzajemny pomiar odległości,

– lustra laserowe

– żywotność satelity: szacowana na 11.35 lat[8].

Segment nadzoruŚcieżki satelitów są cały czas monitorowane Siły Powietrzne Stanów Zjednoczo-

nych, stacjonujące w Hawaii, Kwajalein, Ascension Island, Diego Garcia, i ColoradoSprings. Informacje na temat położenia satelitów są wysyłane do Centrum Dowodze-nia Sił Powietrznych znajdującym się w Bazie Sił Powietrznych, Colorado Springs[6]. Baza analizuje otrzymywane informacje i na ich podstawie wysyła do poszcze-gólnych satelitów poprawki (rys. 2), mające na celu skorygować ich kurs[9].

Segment użytkowników Segment użytkowników składa się z urządzeń koń-cowych (odbiorczych systemu GPS). Odbiorniki są tak skontruowany, aby odbie-rać, dekodować i przetwarzać sygnału nadawane przez satelity GPS. W czasach,gdy NAVSTAR- GPS ledwo raczkował, odbiorniki ważyły kilkanaście kilogramów i

9

Rysunek 1: Konstelacja satelitów GPSźródło: Opracowanie własne na podstawie [9]

Rysunek 2: Działanie segmentu nadzoruźródło: Opracowanie własne

zajmowały wielkość zbliżoną do bagażnika samochodu typu Kombi. [5]. Gwałtow-ny rozwój techniki mikroprocesorów pozwolił na wykorzystanie cyfrowych technikprzetwarzania sygnału, co pozwoliło ma miniaturyzację całego układu do rozmia-ru monety. Przykładowy moduł GPS jest przedstawiony na rys. 3. Istnieją nawetzegarki z wbudowanymi modułami GPS!

10

We współczesnych odbiornikach układy analogowe wykorzystywane są jedyniew celu wzmocnienia sygnału. Dla potrzeb cyfrowego przetwarzania sygnału wy-korzystuje się specjalizowane mikroukłady próbkujące sygnał z częstotliwością dokilkudziesięciu MHz. Pracę tych mikroukładów nadzorują procesory o bardzo dużejszybkości przetwarzania danych.

Istnieje wiele zastosowań dla odbiorników GPS. Nawigacja (lądowa, morska ipowietrzna), transfer czasu, pomiary geodezyjne i wiele innych. Moduły GPS mogąwystępować jako samodzielne układy, często jednak montowane są jako dodatek doinnych urządzeń, takich jak palmtopy, telefony komórkowe, systemy nawigacyjne,czy jako karty rozszerzeń współpracujące z komputerami.

Poszczególne urządzenie odbiorcze sygnału GPS charakteryzuje szereg parame-trów, z których najważniejsze to:

• Ilość śledzonych satelitów. Do poprawnej analizy odebranego sygnału wystar-czą 4 satelity [9]. W przypadku sygnału odbieranego 3 nadajników możliwe jesttylko wyznaczenie pozycji dwuwymiarowej (bez pomiaru wysokości), ponownaakwizycja sygnału 4 satelity i powrót do nawigacji trójwymiarowej może zająćdo 2 minut [2]. Praktyczne minimum to 5 satelitów, ale większość współcze-snych modułów GPS pozwala na śledzenie wszystkich 12 satelitów[2].

• Czas akwizycji - czas od włączenia do pierwszego wyznaczenia pozycji.

• Czas reakwizycji -czas wznowienia pomiarów po chwilowym zaniku sygnału zsatelity

• Maksymalne przyśpieszenia jakie może odnieść urządzenie bez zerwania sy-gnału.

• Czułość odbiornika - prawie wszystkie konstrukcje charakteryzują się wystar-czającą czułością, ale warto pamiętać, że im niższa wartość minimalnego sy-gnału, tym lepszy odbiornik.

• Stosunek SNR - minimalny stosunek sygnału do szumu, przy którym urządze-nie jest w stanie poprawnie zinterpretować sygnał satelitarny.

• Odporność na warunki środowiskowe

• Odporność na sygnały zakłócające - konstrukcja anteny powinna zmniejszaćwpływ sygnałów odbitych. Poza tym uczciwsi producenci podają natężeniezakłóceń elektromagnetycznych, przy których odbiornik jeszcze pracuje po-prawnie.

11

Rysunek 3: Wielkość współczesnego modułu GPSźródło: [6]

1.3 Zasada działania

GPS czyli Globalny System Pozycjonowania (Global Positioning System) jest syste-mem satelitarnym zapewniającym precyzyjne wyznaczanie pozycji, prędkości i cza-su. Dwadzieścia cztery satelity NAVSTAR obiegające Ziemię zapewniają nieprze-rwaną dostawę sygnału radiowego który, po odebraniu przez specjalny odbiornikumożliwia wyliczenie bieżącej pozycji. Sygnał ten jest dostępny na całym globie,korzystanie z niego jest bezpłatne. Dokładność pomiaru waha się od centymetra(odbiorniki geodezyjne, pomiar różnicowy - Differential GPS) do stu metrów (pro-ste odbiorniki nawigacyjne bez korekcji różnicowej). Satelity obiegają Ziemię dwarazy dziennie i rozmieszczone na sześciu orbitach na wysokości około 20 000 km nadZiemią.

Zasada działania systemu opiera się na pomiarze odległości pomiędzy satelitą,który porusza się po ściśle wyznaczonej orbicie a odbiornikiem. Znana odległość odsatelity lokuje odbiornik na sferze o promieniu równym zmierzonej odległości. Znanaodległość od dwóch satelitów lokuje odbiornik na okręgu będącym przecięciem dwusfer. Kiedy odbiornik zmierzy odległość od trzech satelitów, istnieją tylko dwa punk-ty, w których może się on znajdować. Jeden z tych punktów można wykluczyć jakoznajdujący się zbyt wysoko lub poruszający się zbyt szybko i w ten sposób wyzna-czyć swoją pozycję. Należy tylko poznać odległość od satelitów emitujących bardzosłabe sygnały (o mocy zbliżonej do szumu tła), i to z centymetrową dokładnością.Dokonuje się tego poprzez pomiar czasu. Każdy z satelitów posiada cztery zegaryatomowe, którymi synchronizuje wysyłany sygnał. Jedyne, co pozostaje zmierzyćodbiornikowi, to opóźnienie sygnału odebranego z poszczególnych satelitów.

Niestety, odbiornik GPS nie dysponuje własnym zegarem atomowym a tylko do-kładnym zegarem kwarcowym, więc staje przed na pozór nierozwiązywalnym zada-niem: ma stwierdzić, która jest godzina (z dokładnością do nanosekundy) dysponując

12

tylko sygnałem otrzymanym z satelitów, z których każdy podaje inny czas. Dokonu-je się tego odbierając sygnał nie od trzech, a od czterech satelitów. Można wówczaswyliczyć zarówno rzeczywisty czas, jak i położenie (klasyczny układ czterech równańz czterema niewiadomymi).

Opisana metoda pomiaru daje błąd poniżej 10 metrów. Do niedawna, dokładnośćtaką mogły uzyskać tylko amerykańskie odbiorniki wojskowe. Odbiorniki cywilnemusiały się zadowolić kodem C/A, w którym sygnał czasu był umyślnie zakłócanypoprzez Departament Obrony USA. Stąd też występował spadek dokładności do ok.50-100 metrów. Zakłócenia wprowadzone sztucznie do systemu nazywały się SA (Se-lective Availability) i sprawiały, że każdy samodzielny odbiornik GPS, pozostawionyw bezruchu, stopniowo wykazywał zmiany pozycji. Dokładność taka jest wystarcza-jąca tylko do nawigacji; dlatego wymyślono metodę obejścia problemu zakłócaniasygnału. Metodą tą jest pomiar względny (DGPS - Differential GPS) Zasada jestprosta: jeżeli ustawi się GPS w ustalonym punkcie, to na skutek zakłócenia sygnałupozycja przez niego wyznaczona będzie się ciągle zmieniać. Jeżeli obliczymy różnicępomiędzy zmierzoną przez odbiornik pozycją, a pozycją rzeczywistą odbiornika tootrzymamy tzw. wektor błędu.

Wyłączenie SADecyzją władz Stanów Zjednoczonych 1 maja 2000 roku o północy czasu EDT

zagłuszanie sygnału z satelitów GPS zwane ograniczonym dostępem (Selective Ava-ilability - SA) zostało wyłączone. SA (ograniczony dostęp) było to celowe zmniejsza-nie dokładności systemu GPS w celu zapobiegnięcia wykorzystaniu go przez wrogiearmie w celach taktycznych. Stany Zjednoczone zdecydowały wyłączyć SA od 1maja 2000 roku. Wcześniej jednak zdarzało się, że chwilowo rezygnowano z jegostosowania np. podczas wojny w Zatoce Perskiej i podczas inwazji na Haiti, po-nieważ wówczas armia nie posiadała dostatecznej liczby odbiorników wojskowych ikorzystano również z odbiorników cywilnych. Odbiorniki wojskowe mogą korzystaćz odszyfrowanego kodu P i uzyskiwać dokładność około 20 m.

Usunięcie SA jest bardzo korzystne dla obecnych i przyszłych użytkownikówodbiorników GPS. Przede wszystkim spowodowało ono zdecydowane polepszeniedokładności wyznaczania pozycji ze 100 do 10-20 metrów, czyli prawie dziesięcio-krotnie. Zauważalna jest również poprawa dokładności określania prędkości. Lepszadokładność (rzędu 1-5 metrów) może być nadal osiągnięta poprzez zastosowanie ko-rekcji różnicowej (DGPS), która pozwala wyeliminować inne błędy systemu takie,jak błędy zegarów i orbit satelitów, błędy spowodowane opóźnieniem jonosferycznymi troposferycznym, szumem odbiornika i odbiciem. Odbiorniki GPS automatycznieprzystosowują się do wyznaczania pozycji w nowych warunkach po usunięciu SA, azatem żaden upgrade ani też zmiany w sprzęcie nie są konieczne. W swoim orzeczeniudotyczącym decyzji Stanów Zjednoczonych o zaprzestaniu zmniejszania dokładności

13

Globalnego Systemu Pozycjonowania prezydent Bill Clinton powiedział, że posu-nięcie to jest konsekwencją jego prezydenckiej dyrektywy decyzyjnej z marca 1996roku. Dyrektywa ta zawierała wytyczne dla systemu GPS. Było to między innymi:rozszerzenie cywilnych, handlowych i naukowych zastosowań systemu GPS na ca-łym świecie i zachęcenie prywatnego sektora do inwestowania w system, jak równieżużytkowania tej technologii również, że Stany Zjednoczone nadal będą kontynuowaćudostępnienie możliwości systemu użytkownikom na całym świecie bezpłatnie, coutwierdzi jego status światowego standardu w dziedzinie nawigacji. W orzeczeniuporuszony został również temat obronności Stanów Zjednoczonych. Postanowienieo rozszerzeniu zastosowań systemu dla pokojowych celów, nie spowoduje usunięciajego cech militarnych. Nowe technologie, będące w posiadaniu armii umożliwiająStanom Zjednoczonym zagłuszenie sygnału GPS na danym obszarze. W ten spo-sób użytkownicy systemu na całym świecie nie muszą przejmować się regionalnym,powodowanym względami bezpieczeństwa, zagłuszaniem sygnału, a gałęzie biznesustosujące system GPS mogą spokojnie działać otrzymując dobrą dokładność.

System GPS jest technologią znajdującą obecnie coraz szersze zastosowanie. Naświecie jest teraz ponad 4 miliony użytkowników GPS, a oczekuje się, że rynekzastosowań GPS podwoi się w najbliższych trzech latach z 8 bilionów dolarów doponad 16 bilionów dolarów. Niektóre z wspomnianych zastosowań to: komunikacjalotnicza, drogowa, kolejowa, nawigacja morska, precyzyjne rolnictwo i kopalnictwo,eksploatacja ropy naftowej, badania i zarządzanie środowiskiem, telekomunikacja,elektroniczny transfer danych, konstrukcje, rekreacja i ratownictwo.

1.4 Źródła błędów

• Kilka czynników, które wpływają na spadek dokładności działania systemuGPS:

• Opóźnienia powodowane przez jonosferę i troposferę - sygnał transmitowanyprzez satelitę zostaje spowolniony, dlatego system GPS zawiera zaimplemento-wany model, który pozwala na określenie średniej wartości opóźnień i pozwalana segmentacyjne usuwanie tych błędów,

• Wielodrogowość sygnałów radiowych - sygnał GPS zostaję odbity przez Róź-ne obiekty jak np. wysokie budynki, lub góry zanim dociera do odbiornika.Powoduje to wydłużanie czasu przesyłania sygnału, co uniemożliwia dokładnypomiar.

• Błędy zegara w odbiorniku - zegar w odbiorniku cechuje mniejsza dokładnośćniż zegary atomowe stosowane w satelitach. Z tego powodu możemy się spo-dziewać zmiennej dokładności pomiaru.

14

• Błędna orbita - rzeczywista lokalizacja satelity różni się od zadeklarowanej

• Liczba widzianych satelitów - im większa jest liczba "widzianych" satelitówtym większa dokładność pomiaru.

• Położenie satelitów - najdokładniejszy pomiar uzyskujemy gdy satelity roz-mieszczone są równomiernie pod jak najszerszym kątem. Jeżeli są one bliskosiebie, lub są umieszczone w linii powoduje iż dokładność pomiaru położeniaspada.

• Międzynarodowa degradacja sygnału GPS - (ang, Selective Avaliability - SA)wprowadzona przez Departament Obrony USA. SA była stosowana do maja2000 roku, pozwalała na uniemożliwianiu bardzo dokładnych przy zastosowa-niu cywilnych odbiorników GPS. Rezygnacja ze stosowania SA pozwoliła nabardzo znaczącą poprawę jakości działania urządzeń.

1.5 Protokół NMEA

NMEA (National Marine Electronics Association) stworzyła jednoznaczną specy-fikację interfejsu komunikacyjnego i opis protokołu, który umożliwia komunikacjęmiędzy różnego rodzaju urządzeniami pomiarowymi i prostą integrację zakupione-go modułu GPS z innymi urządzeniami. Standard jest standardem otwartym alenie darmowym. Pełną specyfikację standardu NMEA można kupić bezpośrednio zestrony WWW organizacji.

Standard cały czas ewoluuje, gdyż tworzone są coraz to nowe urządzenia. Aktu-alnie obowiązującym numerem standardu jest 3.01. Jednakże wszystkie późniejszezmiany są jedynie dodatkami do wyjściowego (i najpowszechniej stosowanego obec-nie) standardu 0183 (wersja 2.0) (NMEA-0183). Każdy odbiornik GPS obsługującynowszy standard musi być również zgodny ze standardem NMEA-0183.

Ideą standardu NMEA jest wysyłanie linii danych, w których każda linia zaczynasię od określonego nagłówka i zawiera jakieś informacje wysyłane przez urządzenie.Każda linia tekstu musi spełniać następujące wymagania:

• linia zaczyna się od znaku $ i kończyć znakiem nowej linii (r),

• ilość linii nie może przekraczać 80 znaków (plus znak początku linii i znaknowej linii)

• dane wysyłane przez odbiornik GPS są w danej linii podzielone znakami prze-cinka

• dane liczbowe mogą posiadać miejsca ułamkowe(po kropce)

15

• liczby znaków po kropce zależy od precyzji pomiaru urządzenia

• na końcu linii może znajdować się suma kontrolna w postaci (gwiazdka + 2znaki HEX), jednak nie musi ona być sprawdzana przez odbiornik

• każda linia posiada nagłówek (od znaku $ do pierwszego znaku przecinka)

Powyższe ustalenia sprawiają, iż jest to standard bardzo uniwersalny. Interpre-tując dane wysyłane nam przez odbiornik GPS nie musimy się wiec martwić, iżomijając jakąś linie stracimy możliwość odczytania danych dotyczących naszej po-zycji z następnych linii, gdyż każda linia jest od siebie niezależna. Nie ma równieżproblemów z interpretacją późniejszych standardów, gdyż jeżeli dany nagłówek niejest interpretowany przez naszą aplikację, daną linie możemy po prostu pominąć,bez skutków negatywnych dla działania naszej aplikacji.

Dla pewności dane wysyłane przez odbiornik GPS mogą (ale nie muszą) byćuzupełnione o sumę kontrolną, która pozwala sprawdzić czy podczas przesyłania nieuległy przekłamaniu i odrzucić daną linię.

2 GPRS-pakietowa transmisja danych w sieci GSM

2.1 Co to jest GPRS

GPRS (general packet radio service) jest usługą pakietowej transmisji danych w sie-ciach GSM, CDMA i TDMA[24]. GPRS umożliwia na efektywny, bezprzewodowytransfer danych pomiędzy mobilnymi urządzeniami GSM a zewnętrznymi pakietowy-mi sieciami. Mówimy o pakietach, jeżeli dane są dzielone na odrębne paczki, któresą niezależnie transmitowane w sieci i składane z powrotem w całość u żądanegoodbiorcy[29]. GPRS wspiera najpopularniejsze na świecie protokoły Internetowe -IP (Internet Protocol) oraz X.25, protokół, który używany jest głównie w Europie.GPRS umożliwia na komunikacje z każdym urządzeniem opartym na IP bądź X.25poprzez sieć telefonii komórkowej[28]. Sieci komórkowe, w których uruchomiony jestGPRS stanowią zatem rozszerzenie Internetu i sieci X.25[24].

GPRS umożliwia niemal natychmiastowe i ciągłe zestawienie połączenia z In-ternetem. Niezwykle istotny jest fakt, że niepotrzebne jest sztywne połączenie typupunkt-punkt, gdyż zasoby sieci i pasmo są wykorzystywano tylko podczas transmi-sji danych[24]. System GPRS zajmuje kanały komunikacyjne tylko na czas transmi-sji poszczególnych pakietów, a użytkownicy płacą za transmitowaną ilość danych,niezależnie od czasu jaki to zajęło[28]. Jest to zatem rozwiązanie o wiele bardziejkorzystne niż drogi i nieefektywny sposób transmisji opart na komutacji kanałów.

Prędkość przesyłania danych w GPRS mieści się w granicach od 14.4 kbit/s (uży-wając tylko jednej szczeliny czasowej) do 115kbit/s (zwiększając odpowiednio liczbę

16

szczelin)[24]. Średnia prędkość połączenia z Internetem wynosi około 56kbit, czylityle ile można było kiedyś uzyskać łącząc się przez połączenie modemowe z sieciątelefonii analogowej[28]. Jak na dzisiejsze standardy nie jest to dużo, jednak takiepasmo pozwala np. na przeglądanie witryn internetowych bądź rozmowy VoIP1.

2.2 GPRS a GSM

System GSM drugiej generacji został zaprojektowany i zbudowany pod kątem trans-misji głosu. Na skutek gwałtownego rozwoju sieci Internet operatorzy telefonii ko-mórkowych wprowadzili do swoich ofert usługę transmisji danych i połączenie zInternetem. Podczas transmisji danych w systemie GSM zajmowana, podobnie jakw transmisji głosowej cała szczelina czasowa (ang. time slot)[24]. Pojedyncza szcze-lina czasowa pozwala osiągnąć prędkość 14,4 kbit(technika CSD -Circuit SwitchedData) , co jest niewystarczające nawet do podstawowych usług oferowanych przezglobalną sieć. Aby zwiększyć pasmo, należy zając większą liczbę szczelin czasowych- technika High Speed Circuit Switched Data (HSCSD). Obydwa sposoby połącze-nia z Internetem mają zasadniczą wadę- za każdą zajętą szczelinę klient płaci takąsamą stawkę, jak za rozmowę głosową[24]. Dla większości abonentów jest to sytu-acja nie do zaakceptowania, dlatego wprowadzono system GPRS, który umożliwiłwykorzystanie istniejących łączy radiowych do komutacji pakietów, co umożliwiłorozliczanie na podstawie ilości danych a nie czasu.

Zasadniczo system GPRS tworzy odrębną sieć od GSM. Stacja bazowa wymagadość sporych modyfikacji, aby mieć możliwość obsługi GPRS[28]. Pomimo tego za-sięg GPRS jest w Polsce porównywalny do zasięgu GSM. Oznacza to, że praktyczniena terytorium całego kraju można skorzystać z możliwości jakie oferuje pakietowatransmisja danych. Obecnie 3 generacja GSM oferuje znacznie szybsze metody trans-misji danych od GPRS, jednak ich zasięg jest jeszcze mocno ograniczony, dlategow wielu rozwiązaniach - między innymi w tytułowym projekcie, wybór GPRS jestbardziej korzystny.

System ma nieco inną architekturę w porównaniu z systemem GSM. Jest tosieć szkieletowa (ang. Core Network), składająca się z elementów SGSN, GGSN iwewnętrznej sieci IP. Przykładowa budowa sieci GPRS przedstawiona jest na rys.4[24].

Elementy dodane podczas implementacji GPRS:

• SGSN – (Serving GPRS Support Node) jest elementem sieci GPRS odpowie-dzialnym za zarządzanie terminalami będącymi na kontrolowanym przez siebie

1VoIP (ang. Voice over Internet Protocol) - technologia cyfrowa umożliwiająca przesyłaniedźwięków mowy za pomocą łączy internetowych lub dedykowanych sieci wykorzystujących pro-tokół IP, popularnie nazywana "telefonią internetową"

17

Rysunek 4: Schemat sieci GPRS

terenie[29]. Teren ten podzielony jest na Routing Area. Jeśli terminal zmienipołożenie i znajdzie się w innym Routing Area, fakt ten zostanie odnotowanyw SGSN[28]. Element ten jest też odpowiedzialny za uwierzytelnianie termi-nala włączającego się do sieci. Podczas transmisji uczestniczy w przesyłaniupakietów (w obie strony) pomiędzy terminalem a siecią GPRS. Liczba SGSNw sieci zależy od ruchu pakietowego generowanego przez abonentów[29].

• GGSN – (GPRS Gateway Support Node) jest elementem sieci działającymjak router łączący sieć GPRS i zewnętrzną sieć (np. Internet lub sieć LANużytkownika)[29]. Gdy użytkownik terminala chce skorzystać z zasobów ze-wnętrznej sieci, GGSN przydziela mu numer IP (z własnej puli numerów lubdostarczony przez serwer z zewnętrznej sieci)[24], dodatkowo na czas sesji ak-tywuje tzw. PDP context, który zawiera numer IMSI terminala, przydzielonymu numer IP oraz adres IP SGSN, które kontroluje obszar, na którym znajdujesię użytkownik. PDP context będzie przydatny podczas routowania pakietówprzychodzących z zewnętrznej sieci[29].

• PCU – (Packet Control Unit) jest odpowiedzialny za prawidłową obsługę ru-chu pakietowego w radiowej części sieci[28]. Przydziela terminalom GPRS ka-nały radiowe (zobacz rozdział Interfejs radiowy), buforuje dane przesłane przezSGSN, forwarduje je do odpowiedniej stacji bazowej dodając informację, któraumożliwi terminalowi zidentyfikowanie ’swoich’ danych[29]. PCU może być (wzależności od dostawcy) zaimplementowany jako dodatkowy hardware w BSCbądź jako niezależny element sieci obsługujący jedno lub więcej BSC[24].

2.3 Ewolucja metod trasmisji danych w GSM[24]

• GSM (Global System For Mobile)- jest znana jako 2G (druga generacja- cy-frowa) telefonii komórkowej. GSM przesyła dane z maksymalną prędkościa

18

9,6kbit przy użyciu komutacji kanałów (circuit switching).

• HSCSD (High Speed Circuit Switched Data) - komutacja kanałów ze zwięk-szona prędkością. Pierwszy krok w kierunku zwiększenia prędkości transmisjidanych w GSM. HSCSD umożliwia zajęcie 4 szczelin czasowych przez jednegoużytkownika, co pozwala na osiągnięcie prędkości do 64 kbit/s. Standard tenbył mało popularny ze względu na wysoką opłatę, jako klient musiał zapłacićza zajęcie większej liczby szczelin czasowych.

• GPRS (General Pocker Radio Service) - wprowadzenie tego systemu stano-wi pierwszy krok na drodze ewolucji do standardu 3G, dlatego GPRS częstonazywane jest technologią 2.5 G.

• EDGE (Enhanced Data rates for GSM Evolution) rozszerzenie dla technolo-gii GPRS (oprócz nazwy EDGE używa się też terminu EGPRS - EnhancedGPRS), poprawiony został w niej interfejs radiowy, dzięki czemu uzyskanookoło trzykrotne polepszenie przepływności (w większości obecnych systemówteoretycznie do 236.8 kbit/s) oraz możliwość dynamicznej zmiany szybkościnadawania pakietów w zależności od warunków transmisji.

• 3G (telefonia komórkowa trzeciej generacji )- rozszerzenie istniejącej sieci tele-fonii komórkowej o zaawansowane usługi transmisji danych. W odróżnieniu od2G w trzeciej generacji GSM w 3G cała transmisja odbywa się za pośrednic-twem komutacji pakietów. Przejście na system telefonii 3G wymaga zmoderni-zowania wszystkich elementów architektury sieci. Bardzo wysokie ceny licen-cji dla operatorów oraz duży nakład inwestycyjny potrzebny na przebudowęspowodowały, że wdrożenie standardu znacznie sie opóźniło. Obecnie najpo-pularniejszym systemem 3G jest standard UMTS, który umożliwia transferz pasmem 2mbit/s. W specyfikacjach 3GPP w wersji R5 zaproponowano no-wą technologię transmisji sygnału do abonenta - HSDPA, która umożliwiałamaksymalną szybkość transmisji 14.4 Mbit/s (obecnie w Polsce maksymalnaprędkość do 7,2 Mbit/s).

2.4 Przegląd modemów wykorzystujących technologię GPRS

2.4.1 Aplikom 12

Aplikom jest firmą pochodna od Nokii, która specjalizuje się w urządzeniach stoso-wanych do pomiarów telemetrycznych[35]. Opisywany moduł został zaprojektowanyprzez Nokie i jako Nokia 12i, jednak Aplikom wykupił prawa do tego urządzenia izmienił nazwę na Aplikom A12[35].

19

Rysunek 5: Siemensźródło:

Tabela 1: specyfikacja sprzętowa[35]Język programowania J2ME IMPpamięć dostępna dla oprogramowania: 1 Mbyte (Aplikacja jest ograniczona do

128 KB.sDostępna pamięć RAM: 256 KbWspierane protokoły TCP, UDP, CORBA, NMEAInterfejsy 3x RS232, 17* GPIOZakres temperatur [C] +15 :+35, normal -25 : +55 extremeZasilanie 3.6 : 4.0Pasmo GSM 900/1800klasa GPRS 10

A12 ma zintegrowana wirtualną maszynę Javy 2 Micro Edition[35]. Aplikom do-dał swoje metody, np obsługujące interfejs GPS. Silnik Javy uruchamiany jest naprocesorze ARM7. Wspierana jest wielowątkość - ograniczona jedynie możliwościa-mi pamięci RAM modułu. Wydajność modułu jest uzależniona od ilości i częstościtransmitowanych danych. Wszystkie porty i połączenia bezprzewodowe mogą byćkonfigurowana zarówno za pośrednictwem oprogramowania zainstalowanego na PC,jak i za pomocą samych programów wgrywanych do modułu[35]. Istotną zaletą urzą-dzenia jest możliwość aktualizacji programów bezprzewodowo. Do modułu napisanyzostał specjalny SDK wraz z emulatorem urządzenia. Emulator uruchamiany nakomputerze pozwala przetestowanie programów bez konieczności wgrywania ich domodułu. Głównym celem projektu jest przesyłanie pozycji GPS[35]. A12 zawierawbudowaną obsługę protokołu NMEA. Po ustawieniu danego portu jako GPS, mo-

20

że w bardzo łatwy sposób uzyskiwać dane, stosowana jest składnia typu[35]:

S t r ing l a t t i t u d e = gpsData . p o s i t i o n . l a t . degree s ; 4 . 2 Siemens TC65

2.4.2 Moduł Siemens TC65


Niemiecki gigant przemysłowy Siemens ma także oddział specjalizujący się wbezprzewodowej komunikacji urządzeń typu m2m[25]. TC65 6 jest modułem, którypodobnie jak Aplikom ma zagnieżdżoną obsługę Javy. Jest to już druga generacjamodułów radiowych Siemensa, poprzednia, której flagowym modelem był TC45 ko-munikowała się z otoczeniem za pomocą komend AT[25]. Siemens opracował takżemoduły ze zintegrowanym odbiornikiem GPS, np XT55, jednak autorowi nie udałosię dotrzeć do dokumentacji tych urządzeń, dlatego opracowany będzie moduł bezGPS, TC65[25].

Tabela 2: specyfikacja sprzętowa[25]Język programowania J2ME IMPpamięć dostępna dla oprogramowania 1.7 MBDostępna pamięć RAM 400 KBWspierane protokoły TCP, UDP, HTTPSInterfejsy 2x RS232, 10x IO, I C, SPI, USB 2.017*

GPIOTemperatura pracy [C] -30 : +70 normal / -40 : 85 storageZasilanie 3.2 : 4.5 Vpasmo GSM 900/1800klasa GPRS 12

Zagnieżdżona Wirtualna Maszyna Javy działa na procesorze ARM7[25]. Systemplików jest typu flash i może być przeglądany, gdy podłączymy urządzenie do PC.

21

GPIO, SPI i I2C są kontrolowane przez komendy AT[25]. Pozostałe funkcje są kon-trolowane przez metody Javy. Przepływ danych w uruchamianych programów Javajest przedstawiony na rys. 9


Wydajność modułu wynosi 45000 jPS (zdań Javy ba sekundę)[25]. Siemens okre-ślił maksymalną przepływność RS232 -> GPRS na 20Kbit/s, przy użyciu 3 kana-łów równoległych (maksymalna teoretyczna przepływność w takim wypadku to 36Kbit/s)[25].

TC65 nie posiada specjalnych sprzętowych ułatwień dla zastosowania systemuGPS. Aby móc korzystać z pozycjonowania, należy podłączyć zewnętrzny odbiornikGPS to portu RS-232 i zaimplementować w Javie interpreter protokołu NMEA[25].

2.4.3 Telit GM862-GPS

Forma Telit opracowuje systemy komórkowe począwszy od lat osiemdziesiątych[26].Obecnie produkują telefony i moduły GSM. Ich najbardziej odpowiednim produk-tem rozważanym do zastosowania w projekcie jest moduł GSM862-GPS[26]. Urzą-dzenia ma zaimplementowany interpreter języka Python, oraz wbudowany odbiornikGPS[26].

Moduł Telita jest w stanie uruchomić jeden wątek[26]. Jest go główny mankamenturządzenia, gdyż znacznie ogranicza to jego możliwości. Ponadto urządzenie posiadatylko jeden port RS232, bez kontroli przepływu. Moduł zawiera wbudowany czytnikkart SIM. Produkt łączy się z PCB przez 50 pinowe złącze[26].

GSM862-GPS wspiera skrypty napisane w Pythonie. Producent wybrał ten język

22


Tabela 3: Specyfikacja sprzętowa Telit GM862-GPS[26]Język programowania: Python, wersja 1.5.2+pamięc dostępna dla oprogramowania: 3 MBDostępna pamięć RAM 1.5 MB (współdzielona wraz z interpre-

terem Pythona)Wspierane protokoły TCP, UDP, FTPInterfejsy RS232, 13x IO, SPI, I CZasięg temperatury pracy [C] -10 : +55, normal / -30 : +80, extremeZasialanie [V] 3.4 : 4.2pasmo GSM 850/900/1800/1900klasa GPRS 10

ze względu na fakt, że jest on typu open source, oraz zabiera mniej zasobów niżWirtualna Maszyna Javy.

2.4.4 Wavecom Q2501B

Firma Wavecom mająca swą siedzibę blisko Paryża[27], produkuje bezprzewodowemoduły transmisji danych począwszy od 1993. Jej produkty charakteryzują się niskąceną i dużą wydajnością. Producent ma bogatą ofertę produktów, opisany zostałmodel Q2501B z wbudowanym odbiornikiem GPS[27].

Moduł uruchamia programy skompilowany w języku C++[27]. Takie rozwiązaniezapewnia większa wydajność, niż odpowiedniki napisane na Wirtualną Maszynę Ja-vy. Zgodnie z danymi producenta, urządzenia zapewnia wykonanie 1,5 MIPS (MegaInstrukcji Na Sekundę). Procesor może być spowolniony do 32 kHz, oszczędzając wten sposób energię[27].

23


Tabela 4: Specyfikacja sprzętowa Wavecom Q2501B[27]Język programowania: C++pamięc dostępna dla oprogramowania: 512 KBDostępna pamięć RAM 128 KBWspierane protokoły TCP, UDPInterfejsy 2xRs232, 2xSPI, 6 GP IOZasięg temperatury pracy [C] -35: 85, operacyjna / -30 : +80, extremeZasialanie [V] 3.6pasmo GSM 900/1800klasa GPRS 10

3 Aplikacje Internetowe

3.1 Przełom w budowaniu serwisów internetowych

Bardzo często kluczową rzeczą na stronach internetowych jest to, aby przegląda-jący je użytkonicy widzieli zawsze informacje, które są najbardziej aktualne. Treśćwitryny, której zawartość jest w jakis sposób zależna od czasu musi zmieniać sięnieustannie, w sposób ciągły. Aby bardziej zobrazować ten problem wyobraźmy so-bie komercyjny serwis WWW, który pozwala użytkownikom sprzedawać i kupowaćużywane samochody. Intuicyjnie wiadomo, że taka strona musi pokazywać tylko tesamochody, które jeszcze nie zostały sprzedane. Ponadto nowe samochody musząbyć dodawane tak szybko, jak tylko sprzedawca umieści ogłoszenie. Jeśli te warunkinie zostały by spełnione serwis z pewnością by się długo nie utrzymał

Wygląd strony - rozmieszczenie i treść tekstu, obrazki, i inne elementy składającesię na wygląd witryny najczęsciej definiowane są za pomocą prostego języka zwane-go HTML(Hyper Text Markup Language)[30]. Kiedy użytkownik odwiedza typowąstrone internetową, pola tekstu są oznaczane specjalnymi tagami języka HTML inastępnie transmitowane pomiędzy serwerem strony internetowej, a przeglądarką

24

użytkownika[31]. Przeglądarka interpretuje otrzymywane kawałki i zwraca na ekranich zawartość.

Niektóre strony internetowy są statyczne. Statyczne strony wymagają osoby,która ma odpowiednią wiedzę i uprawnienia (zwykle taką osobę nazywamy webma-sterem) aby ręcznie "odświeżyć" zawartość strony. Uaktualnienie serisu wymagaręcznego zmodyfikowania każdej strony, którą ma być zmodyfikowana[32]. Zwykle,odbywa się to poprzez edycję zestawu plików na serwerze internetowym, gdzie każdyplik reprezentuje pojedynczą stronę.

Duże zmiany na statycznych stronach wymagają, aby webmaster zmienił zawar-tość każdego pliku wchodzącego w skład witryny internetowej. Serwisy internetowerozrastają się nieraz to tysięcy plików, wiec zadanie staje się bardzo uciążliwe. Jeśliodniesiemy się do przykładu serwisu z używanymi samochodami, webmaster mu-siałby na bieżąco sprawdzać ważność poszczególnych ogłoszeń, i nieustannie usuwać,edytować i dodawać nowe strony. Szybko okazało by się, że samo dbanie o aktual-ność danych było by zajęciem na cały etat. Ponadto człowiek może się pomylić i np.zapomnieć zmodyfikować jakiejś ważnej podstrony.

W celu eliminacji uciążliwego ręcznego modyfikowania zawartości strony naro-dziła się koncepcja aplikacji internetowej[30]. Aplikacja internetowa jest programemdziałającym na serwerze, uruchamiany w momencie, kiedy użytkownik wpisze woknie przeglądarki adres rządanej strony[31]. Przeglądarka i użytkownicy nie są świa-domi, czy aktualnie przeglądana witryna jest statyczna bądź aplikacją internetową.Aplikacja internetowa, w przeciwieństwie to statycznej witryny tworzy własne "stro-ny" dynamicznie[32]. Program działający na serwerze, może być napisany w dowol-nym, ulubionym języku, a efektem jego działania jest wygenerowanie kodu HTML,który serwer zwraca do przeglądarkiajax1.

W dynamicznie tworzonych serwisach nie jest wymagane, aby webmaster prze-glądał witrynę strona po stronie w celu aktualizacji zawartości. Zamiast tego jest wstanie zaprogramować wygląd i sposób zachowania podstron serwisu, aby aktualiza-cje wykonywały się automatycznie (dynamicznie).

3.2 Środowisko Zope

3.2.1 Wybór Frameworka

Obecnie na rynku istnieje wiele frameworków2 wspomagających proces tworzeniaaplikacji internetowych. Wywodzą się one z różnych języków programistycznych. Nachwile obecną najpopularniejsze języki webowe to[12]:

2Framework (rama projektowa, szkielet) to w programowaniu struktura wspomagająca two-rzenie, rozwój i testowanie powstającej aplikacji. Z reguły na framework składają się programywspomagające, biblioteki kodu źródłowego i inne podobne narzędzia.[7]

25

• PHP

• Python

• Java

• ASP.NET

• Ruby

Autor projektu osobiście lubi programować w języku Python, dlatego zdecydowałsię na wybór któregoś z frameworków wspierających ten język. Ostatecznie wybranośrodowisko Zope, głownie ze względu na ustabilizowaną pozycję w spełeczności py-thonowej, bogatą dokumentację i dużą ilość dodatkowych modułów (rozszerzeń)[33].

3.2.2 ZOPE - wprowadzenie

Zope jest rozbudowanym systemem, pozwlającym na tworzenie portali społeczno-ściowych, sklepów internetowych, systemów typu intranet/extranet. Zbudowany jestz kilku komponentów, w których każdy ma inne, specyficzne zadanie[33]. Rys. 10przedstawia poszczególne elementy architektury ZOPE, oraz ich wzajemne relacje.Poszczególne moduły są niezależne i mogą być użyte poza środowiskiem ZOPE, wniezależnych aplikacjach Python[12].

Rysunek 10: Modułowa architektura ZOPEźródło: [1]

26

ZServer ZServer odpowiedzialny jest za odbieranie żądań kierowanych do ser-wera poprzez różne protokoły oraz odpowiednie reagowanie na nie[12]. Wspiera ta-kie protokoły, jak: http, FTP, XML-RPC, FastCGI, PCGI, WebDAV. ZPublisherModuł opowiedzialny za dostarczanie do ZServer żądanych obiektów[34]. Pełni ta-ką samą funkcję w Zope jak ORB (Object Request Broker).ZPublisher weryfiku-je również prawa oraz rozpoczyna i kończy transakcje a w przypadku problemówwywołuje rollback[33]. Transaction manager śledzi zmiany wszystkich obiektów wczasie trwanie żądanie i na zakończenie obsługi żądania, po tym jak ZServer wysłałodpowiedź do klienta, wykonuje zatwierdzenie transakcji (ang. commit) lub w przy-padku niepowodzenie – wycofanie (ang. abort)[12]. ZODB Obiektowa baza danychodpowiedzialna za trwałe przechowywanie obiektów Zope[12]. Każda zmian obiektupowoduje zapisanie nowej jego wersji, dzięki czemu uzyskujemy możliwość wyco-fania wprowadzonych przez nas zmian[33]. ZEO Zope Enterprise Option pozwalana współdzielenie obiektowej bazy danych (ZODB) poprzez instancje Zope dzia-łające na różnych maszynach[12]. Dzięki temu możemy w prosty sposób skalowaćnasze aplikacje. ZRDBM Zope Relational Database Management definiuje interfa-ce pozwalający na integrację Zope z zewnętrznymi, relacyjnymi bazami danych[33].Dostępne są adaptery dla najbardziej popularnych produktów, jak: Oracle, Syba-se, MySql, Postgresql, ODBC Drivers[34]. Zope Products Produkty pozwalające norozszerzanie podstawowej funkcjonalności Zope. Napisane w Pythonie dodają nowetypy oraz funkcje do standardowo oferowanych przez Zope[12].

Kilka podstawowych faktów na temat frameworka Zope[12, 33, 34]

• Zope jest framworkiem, który pozwala na programistom o różnym stopniuzaawansowania na budowanie aplikacji internetowych. Warto użyć Zope’a zkilku powodów:

• Zope jest darmowy, rozpowszechniany jako wolne oprogramowanie. Istenie wie-le komercyjnych serverów aplikacyjnych, których koszt jest relatywnie wysoki.

• Zope posiada wiele dodatków i bibliotek. Nie potrzeba płacić za rozszerzeniaprogramu, brak ukrytych kosztów.

• Zope umożliwia i zachęca międzynarodową społeczność do rozwijania i roz-powszechniania dodatkowych modułów. Zope posiada bogatą kolekcję kom-ponentów napisach przez pasjonatów z całego świata. Wszystkie tego typuprodukty są dostępne od ręki, i gotowe do działania. Duża popularność Zope’aspowodowała, że jego społeczność jest duża i aktywna. Oznacza bwardzo dobrewsparcie i pomoc dla początkujących jak i zaawansowanych użytkowników.

• Aplikacje stworzone w Zopie mogą być liniowo skalowane z użyciem klastro-wanie ZEO Zope Enterprise Objects. Dzieki ZEO możliwe jest rozdzielenie

27

projektu na wiele fizycznych serwerów bez znaczących zmian w kodzie. Jestto niezwykle istotne w zastosowaniach, gdzie wielkość i popularność serwisumoże szybko wzrosnąć.

• Zope umożliwia tworzenie aplikacji za pomocą zwykłej przeglądarki interne-towej. Wiodące na rynku przeglądarki są w stanie wyświetlać i modyfikowaćśrodowisko Zope (ZMI - Zope Management Interface). Oczywiście możliwe jestrównież rozwijanie aplikacji przy pomocy standardowych narzędzi takich jakedytor Eclipse.

• Zope można uruchomić na większości platformach sprzętowych, takich jak :Linux, Windows, Solaris, FreeBSD, NetBSD, OpenBSD i Mac OS X.

• Możliwości Zope’a można rozszerzyć za używając interpretowanego językaskryptowego Python. Python jest popularny i łatawy do nauki, jego kod jestkrótki i przejrzysty.

4 Google Maps

Najłatwiej jest prezentować informację o pozycji geograficznej, wyświetlając je namapie. Programiści rozwijający komercyjne produkty z dziedziny, zwykle kupujemapy w postaci cyfrowej i sami tworzą odpowiednie oprogramowanie. Istnieją tutajdwa podejścia. Pierwszy z nich polega na napisaniu "tradycyjnego" programu(plikwykonywalny), który klient instaluje na swoim komputerze domowym. Program ko-munikuje się z serwerem centralnym poprzez socket3 i ściąga wszystkie niezbędnedane. Wadą tego typu rozwiązania jest konieczność instalacji specjalnego oprogra-mowania na każdym komputerze, z którego klient chce skorzystać z usługi. Dodat-kowym problemem mogą być aktualiacje aplikacji, gdyż każdorazowo niezbędne jestpobranie odpowiedniej łatki przez klientów. Innym sposobem zapewnienia dostepudo serwisu jest stworzenie aplikacji internetowej. W takim wypadku użytowdnik niemusi ściagąć żadnego specjalnego oprogramowania - wystarczy zwykła przeglądar-ka internetowa. Dobrze zaprojektowana i napisana aplikacja WWW może być taksamo wygodna w obsłudze, jak tradycyjny program komputerowy. Taka możliwośćpojawiła się stosunkowow nie dawno, na skutek pojawienia sie nowych technologiidostępnych przy budowaniu web serwisów. Mowa ty głównie o technice AJAX[30],która będzie szczegółowo omówiona w dalszych rozdziałach pracy.UsługaGoogle maps[22] jest usługą oferowaną przez korporacje Google. Sercem serwisu

3Adres sieciowy składakający się z numeru IP oraz portu

28

stanowi olbrzymia baza cyfrowych zdjęć satelitarnych, obejmujących swym zakre-sem obszar całego świata, a nawet więcej, gdyż dostępne są rownież mapy Marsai Księżyca[15]. Nie wszystkie obszary kuli ziemskiej dostępne są z wystarczającympoziomem szczegółów, jednak zdjęcia cyfrowe w wysokiej rozdzielczośći systema-tycznie uzupełniają te braki. 6 września 2008 r. Google odpaliło swojego własne-go satelitę[21], który wkrótce będzie wykonywał fotografię z dokładnościa do 41cm.Zdjęcia powierzchni Ziemi będą wykonywane z wysokości 681 km, a satelitabędzie się przemieszczać względem jej powierzchni z prędkością ok. 7 km/sek[23].Świadczy o rozmachu całego przedsięwzięcia i o niesamowotych możliwościach roz-woju usługi.MożliwościOprócz samych zdjęć satelitarnbych Google zgromadziło imponująco liczbę dodat-kowych informacji. W wiekszości krajów świata mapy uzupełnione są nazwami ulici obiektów[23]. Umożliwiło to progamistom firmy stworzenie algorytmów wyszu-kiwania najlepszej drogi pomiędzy punktami geograficznymi. Oprócz tego serwisudostepnia wiele innych usług takich jak wstawienie własnych zdjęć z podpisaniami,rysowanie po mapie, geocoding4, czy nawet widok ulic z perspektywy osoby po niechprzechodzącej[22]. Dostępne są 3 podstawowe tryby przeglądania - widok satelitar-ny, widok mapy, oraz hybrydowy (połącznie dwóch pierwszych). Dostęp do GoogleMaps możliwy jest również na urządzenia mobilne[22].IntegracjaProgramiści Google w celu popularyzacji serwisu stworzyli do niego specjalne API[21]5.Oznacza to, że każdy web developer może skorzystać ze wszytskich możliwości ofe-rowanych przez ten produkt. Integracja odbywa się poprzez wykorzystanie funkcjiJavaScript, które Google dokładnie opisuje na swojej stronie[22]. Najciekawsze funk-cje, które zostały zastosowane w projekcie to [22]

• tworzenie własnych markerów. Markery są to znaki graficzne, za pomocąktórych oznaczamy punkt o danych współrzędnych geograficznych. Markerymożna ukrywać, przesuwać, animować, oraz dodawać do nich zdarzenia i in-formacje.

• rysowanie linii

• geocoding Jest to usługa polegająca na znajdywaniu współrzędnych geo-graficznych dla określonego adresu geograficznego.Dla Polski jak i większości

4Translacja adresów na odpowiednie współrzędne geograficzne5API (Application Programming Interfaces) jest ot zestaw procedur, protokołów i narzędzi dla

tworzenia zestawu oprogramowania aplikacyjnego przedsiębiorstwa oraz dla komunikacji z progra-mami z innego systemu.

29

krajów europejskich adres dostępny jest z poziomem szczegółów do nazw po-sczególnych ulic.

• reverse geocoding Jest to odwrotny proces do geocodingu. Podajemy adres,a otrzymujemy współrzędne geograficzne. Należy przy tym zaznaczyć, że Go-ogle oficjalnie wspiera tylko tą usługę dla Stanów Zjednoczonych. W Europiemożliwe jest tylko dekodowanie adresów do poziomu nazwy miasta. Możliwejest jednak wyciągnięcie pełnego adresu poprzez napisanie specjlanego skryp-tu, który wszystkie niezbędne dane pobiera z usługi Google directions [stopka]

• infotipy Są to pola z informacją, które mozna zainicjować poszczególnymizdarzeniami, np poprzez kliknięcie na marker.

• wsparcie dla AJAX Umożliwia modyfikacje widoku mapy bez niecznościprzeładowywania całej strony, umożliwiając w ten sposób dynamiczną zmianęposzczególnych elementów naniesionych na mapę. Warto dodać, że cała stronaGoogle Maps jest zbudowana w oparciu o tą technologię.

5 Języki wysokiego poziomu

5.1 JavaMe - programowanie urządzeń mobilnych

Technologiczny rozwój telefonów GSM sprawił, że pojawiły się w nich dodatkowefunkcje: zegarki, notesy czy dyktafony. Jednak nadal użytkownicy mogą korzystaćjedynie z tych aplikacji, które udostępnił producent. Aby temu zaradzić, opraco-wano standard pozwalający użytkownikowi na uruchamianie własnych aplikacji wtelefonie[17].

W wyniku pierwszych prób opracowania takiego standardu powstał system ope-racyjny Symbian, pozwalający na tworzenie aplikacji dla telefonów komórkowych wjęzyku C++[19]. Jedną z pierwszych serii telefonów działających pod kontrolą Sym-biana była Nokia Communicator, która miała arkusz kalkulacyjny, edytor tekstów irozbudowany program klienta poczty e-mail. Nowe modele telefonów działające podkontrolą Symbiana (np. Nokia 7650) przy użyciu odpowiednich aplikacji pozwalająnp. na odtwarzanie sekwencji filmowych[18]. Na przeszkodzie upowszechnienia sięSymbiana stanęła konieczność kompilacji kodu dla każdej nowej serii telefonów iograniczona wydajność telefonów.

Pojawienie się nowych telefonów, o większej pamięci operacyjnej i szybszychprocesorach pozwoliło myśleć o wprowadzeniu nowej technologii, pozwalającej nadziałanie tej samej aplikacji na urządzeniach różnych producentów bez konieczno-ści rekompilacji kodu źródłowego programu. Aby spełnić warunek kompatybilnościsprzętowej, Sun Microsystems stworzył specjalny rodzaj środowiska Java - J2ME[17].

30

5.1.1 J2ME = CLDC + MIDP[17]

Java 2 Micro Edition to zoptymalizowane środowisko platformy Java, przeznaczonedla małych urządzeń, takich jak telefony komórkowe, palmtopy, odbiorniki telewi-zyjne czy pagery. Środowisko to zawiera własną maszynę wirtualną (KVM) oraz- ograniczony w porównaniu do Javy działającej na komputerach PC - zbiór klasstanowiących rdzeń środowiska uruchomieniowego[18]. Klasy te noszą nazwę konfi-guracji (configuration) i ich zbiór zależy od urządzenia, na którym działają. Róż-norodność urządzeń okazała się dość spora, konieczne stało się więc zdefiniowanienastępnej warstwy klas opisujących funkcje możliwe do wykonywania na konkret-nych urządzeniach, czyli profili (profile). Rodzaje platform Java

W przypadku J2ME najczęściej stosowaną kombinacją konfiguracji i profilu jestCLDC i MIDP. CLDC (Connected Limited Device Configuration) to konfiguracjaużywana z maszyną KVM i pracująca na urządzeniach 16-, 32-bitowych, zapewniających[19]:

• 160-512 KB pamięci dostępnych dla Javy i napisanej aplikacji (128 KB jestprzeznaczone na wirtualną maszynę Javy i biblioteki CLDC)

• bateryjne źródło zasilania

• połączenie z siecią, zwykle bezprzewodowe, o niewielkiej prędkości

• ograniczony interfejs użytkownika (niewielki wyświetlacz z małą liczbą kolo-rów, sterowanie przy użyciu kilku klawiszy)

Profil MIDP (Mobile Information Device Profile) jest rozwijany przez Java Com-munity Process. Zainicjowała go grupa ekspertów, składająca się z pracowników firmprodukujących urządzenia elektroniczne i telekomunikacyjne, m.in. Motorola, Nokia,Siemens, Palm. MIDP specyfikuje[18]:

• klasy i metody dla interfejsu użytkownika

• trwałą bazę danych - Record Manager Store (RMS)

• połączenie sieciowe dla urządzeń bezprzewodowych

MIDP przeznaczono dla urządzeń mających około 200 KB wolnej pamięci.

5.1.2 Java w telefonach GSM

Aplikacje Java tworzone z wykorzystaniem technologii J2ME noszą nazwę midletów- mogą mieć charakter biznesowy lub użytkowy. Aplikacje biznesowe to najczęściejaplikacje typu klient-serwer, gdzie midlet w sposób ciągły komunikuje się z serwerem(zazwyczaj za pomocą połączenia GPRS)[19]. Aplikacje służą do prezentowania np.

31

kursów walut, notowań czy przebiegów licytacji. Mogą również obsługiwać łączeniesię z zasobami firmy - np. z bazą klientów, korporacyjną książką adresową, komuni-katorem internetowym. Telefon komórkowy pełni tu rolę tzw. cienkiego klienta.

Aplikacje użytkowe natomiast wspomagają codzienną pracę i obowiązki. Są to:organizery (PIM), notesy, słowniki, konwertery miar. Aplikacje te nie wymagajązazwyczaj łączenia z internetem oraz nie mają specjalnych wymagań wobec telefonu,w którym pracują[18].

Największa grupa midletów to aplikacje rozrywkowe, obejmujące nie tylko prostegry w stylu Kółko i krzyżyk czy Ping-pong, ale także takie projekty jak gra wzoro-wana na Wolfstain3D. Ich odbiorcą jest głównie młodzież. Komfort gry podniosłykolorowe wyświetlacze, pokazujące nawet kilka tysięcy kolorów.

5.1.3 Java po liftingu[18]

Wydajność aplikacji napisanych w języku Java silnie zależy od możliwości sprzęto-wych. Ceną za wieloplatformowość kodu jest konieczność kompilowania kodu pośred-niego na język danego procesora przez Wirtualną Maszynę Javy (JVM). Aby zadaniutemu mogły sprostać również telefony komórkowe, konieczne było odchudzenie J2MEw stosunku do klas zawartych w edycjach J2SE i J2EE. Zbiór klas MIDP składa sięz 4 pakietów specjalnie przygotowanych dla obsługi urządzeń mobilnych[17]:

• javax.microedition.io - obsługa protokołu HTTP,

• javax.microedition.lcdui - obsługa interfejsu użytkownika,

• javax.microedition.midlet - sterowanie pracą midletu,

• javax.microedition.rms - obsługa pamięci danych.

Do dyspozycji programisty pozostawiono część metod zawartych w pakietachjava.io, java.lang, java.util, jednak ich liczba jest bardzo ograniczona w stosunkudo J2SE[17]. W efekcie nie można korzystać z portów szeregowych (IrDA czy Blu-etooth) ani inicjować połączeń telefonicznych czy wysyłać SMS-ów. Dostępny jestwyłącznie protokół HTTP, zaś aplikacje nie mają możliwości współdzielenia obszarudanych z innymi aplikacjami, wykonywania operacji na danych zmiennoprzecinko-wych i posługiwania się zaawansowanymi funkcjami operującymi na grafice[19].

W grudniu 2002 roku Sun Microsystems ogłosił wersję 2.0 specyfikacji MIDP.Rozszerzono w niej wsparcie dla obsługi strumieni audio i wideo, dodano możliwośćkorzystania z protokołów SSL i WTLS, zapewniono obsługę portu szeregowego, atakże dostępność innych protokołów niż HTTP[17]. Wprowadzono możliwość usta-lania uprawnień dostępu oraz rozróżnienie kodu na zaufany i niezaufany[18]. Nie-zaufany kod nie może sam tworzyć połączeń, wymaga nadania odpowiednich praw

32

przez użytkownika. Zaufany kod podpisany jest cyfrowo, a jego autentyczność musipotwierdzić urządzenie. Telefony obsługujące standard MIDP 2.0 mają pojawić sięw drugim kwartale 2003 roku[18].

5.1.4 Praca z kodem

Na stronach producentów telefonów komórkowych lub serwisów przeznaczonych dlaprogramistów J2ME dostępne są stosowne emulatory, pozwalające na proste uru-chamianie i testowanie aplikacji. Większość z nich łatwo integruje się bądź z samymIDE, bądź z J2ME Wireless Toolkit[19].

Programując aplikacje dla telefonów komórkowych należy mieć na względzie, żemimo wprowadzenia oficjalnego standardu dla warstwy MIDP, poszczególni produ-cenci komórek mogą dostarczać klasy, które będą wykorzystywać specyficzne wła-ściwości telefonów. W przypadku telefonów Siemens możliwy jest dostęp do książkiadresowej czy inicjowanie połączeń lub wysyłanie SMS-ów; Nokia w niektórych mo-delach pozwala na sterowanie wibracją telefonu czy jasnością wyświetlacza[18].

Kolejną przeszkodą w tworzeniu uniwersalnego kodu okazuje się maksymalnawielkość midletu, który może zostać zainstalowany w telefonie. W większości mo-deli jest to 64 KB, niemniej jednak warto przetestować midlet na kilku dostępnychemulatorach[17].

5.2 Python

Python jest językiem programowania, który można opisać za pomocą następującychokreśleń[3]:

• darmowy, powszechnie dostępny

• przenośny

• zgodny z innymi językami programowania

• prosty

• interpretowany

• obiektowy

• spierany przez ogromną społeczność oraz korporacje

• nazwany na cześć brytyjskich komików

33

Cechy pythona

• Darmowość i swobodny dostęp.Python jest oprogramowaniem typu open-source 6. Można go pobrać za darmoz oficjalnej witryny internetowej www.python.org. Jest to duża zaleta w porów-naniu do płatnych produktów konkurencyjnych, np. Java, czy ASP.NET [3].

• Pewność działania i dobre wspomaganiePython jest dojrzałym językiem - powstał prawie 20 lat temu [3]. Obecnie jestto produkt, którego kod źródłowy był tworzony, modyfikowany, testowany ipoprawiany przez wiele osób. Podstawowy zespół autorów Pythona jest kiero-wany przez jego głównego twórcę - Guido Van Rossuma, który w regularnychodstępach wprowadza poprawki i modyfikację. Python jest rozpowszechnianywraz z kompletem dokumentacji, która zawiera samouczek, opis dokumentacji,oraz biblioteki

• PrzenośnośćPython został napisany w przenośnym języki ANSI C[3]. Można go skompi-lować i uruchamiać właściwie każdej ważniejszej współczesnej platformie sys-temowej. Działa on między innymi w systemach, takich jak Unix, Windows,MaxOS i PalmOS. 7 Rdzeń języka Python i biblioteki działają w taki sam spo-sób na wszystkich platformach, a więc programy można tworzyć w mieszanychśrodowiskach[3]. Można na przykład napisać program w środowisku Windowsi załadować go na serwer produkcyjny działający pod kontrolą systemu Li-nux. Trzeba jednak pamiętać, że niektóre rozszerzenia Pythona są zależne odsystemu operacyjnego[3].

• Zgodność z innymi językamiPython pozwala się łatwo “sklejać” z istniejącymi bibliotekami napisanymi w C,C++, Fortran, Java lub Visual Basic (za pomocą pakietu COM) oraz innymijęzykami. Można zatem opracować w języki C wymagającej dużej wydajnościczęść programu a następnie osadzić go w kodzie języka Python[3].

• Prostota Pythona można bardzo łatwo zainstalować, opanować jego reguły ikorzystać z niego jak z innym języków programowania. Jego kod można łatwoodczytać dzięki kilku wyróżniającym go cechom, takim jak[3]:

– struktura wierszowa wymuszająca jednolite stosowania wcięć.6Otwarte źródła - oprogramowanie tego typu posiada licencję pozwalającą na kopiowanie, mo-

dyfikację, rozpowszechnianie, rozszerzanie i odsprzedaż bez konieczności opłat lub podpisywaniaumów licencyjnych [16]

7Pełna lista systemów dostępna jest pod adresem www.python.org/download/

34

– składnia i semantyka ułatwiająca stosowanie go zarówno w prostych, jaki dużych programach

– elastyczne struktury danych i dynamiczne typy umożliwiające zaprogra-mowanie wielu czynności w kilku wierszach

• Język interpretowanyInterpreter Pythona uruchamia programy natychmiast po ich wpisaniu lubzaładowaniu. Jeśli zostanie stwierdzony błąd, interpreter wywoła wyjątek iprzedstawi komunikat o błędzie[3]. Można zatem szybko testować kod i usuwaćbłędy, ponieważ nie występują tu etapy kompilacji i konsolidacji. Interpretermoże uruchamiać programy programy napisane we wcześniejszych wersji ję-zyka. Python posługuje się tzw. kompilacją bajtową, podczas której programźródłowy jest zamieniany ma przenośny kod, który można uruchomiać na każ-dym z zainstalowanym interpreterem Pythona[3].

• ObiektowośćZ Pythona można korzystać tak samo jak z języka proceduralnego, ale należygo traktować jako język programowania obiektowego. Python zawiera wszyst-kie potrzebne elementy tego programowania, takie jak[3]:

– klasy

– wyjątki

– egzemplarze

– metody

– automatyczne zarządzanie pamięcią (odśmiecanie)

– dziedziczenie

– przeciążenie

5.3 SQL i bazy danych

Funkcjonowanie współczesnych systemów relacyjnych baz danych oparte jest głów-nie na języku SQL (Structured Query Language, strukturalny język zapytań). SQLjest językiem czwartej generacji, który został w ciągu wielu lat opracowany przezgrupę badawcza IBM[10]. Stał się międzynarodowym standardem dla języków bazdanych i występuje obecnie w produktach większości liczących się firm, zajmującychsię sprzedażą oprogramowania dla baz danych. Ponieważ SQL jest językiem standa-ryzowanym, dostęp do danych jest możliwy przez wiele różnych platform sprzęto-wych, w tym komputery osobiste, mikrokomputery i duże komputery. Inna korzyśćzwiązana z SQL polega na tym, że takie oprogramowanie jak arkusze kalkulacyjne

35

czy procesory tekstów może importować dane z baz danych opartych na SQL[11].Polecenia SQL maja postać zbliżoną do zdań w języku angielskim i są stosowane wcelu uzyskania dostępu do danych i sterowania operacjami w bazie danych. Użyt-kownik mający małe doświadczenie w przetwarzaniu danych lub niemający go wcale,może szybko nauczyć się podstawowych konstrukcji SQL, a ekspert od przetwarza-nia danych może znaleźć w tym języku pełny zestaw potrzebnych mu narzędzi[10].Zatem jest to język, którego używają zarówno zwykli użytkownicy, jak i fachowcyod przetwarzania danych.

SQL jest językiem strukturalnym, zdefiniowanym za pomocą reguł składniowych.Występują w nim trzy rodzaje poleceń[11]. Pierwszy to polecenia języka definiowa-nia danych, które umożliwiają tworzenie obiektów bazy danych, takie jak tabela iperspektywy. Drugi rodzaj to polecenia języka operowania danymi, które są używa-ne do wydobywania informacji z bazy danych, usuwania informacji z bazy danych idodawania ich do niej. Trzeci rodzaj to polecenia języka administrowania danymi,które służą do przyznawania i odwoływania uprawnienia dostępu do bazy danych.Użytkownik może korzystać z poleceń SQL w sposób interakcyjny bądź za pomocątakiego interfejsu jak zapytanie przez przykład ( QBE )[10].

36

II

Część praktyczna - projekt Ariadna

1 Wstęp

Nazwa Ariadna nawiązuje do mitu o Tezeuszu, który w labiryncie dzięki nici poda-rowanej przez Ariadnę odnajduje drogę do domu.Cel i zastosowanieAriadna jest to system, który pozwala na monitorowanie floty pojazdów. Pojazdymają zamontowane urządzenia nadawcze typu Agent. W momencie, jeśli zostaniewykryty ruch pojazdu, urządzenie wysyła komunikaty (meldunki nawigacyjne) zapośrednictwem sieci GPRS. Wszystkie meldunki trafiają do centralnego serwera,gdzie są gromadzone w bazie danych. Baza danych jest podłączona do aplikacjiinternetowej, dzięki czemu za pomocą odpowiednich zapytań SQL możliwe jest wy-świetlenie na mapie pozycji aktualnych bądź historycznych żądanych pojazdów.Wybór technologiiAutor pracy wybrał i użył następujących technologii w projekcie:

• PostgreSQL - jako platforma bazodanowa

• Zope - jako framework do stworzenia aplikacji webowej

• Python - jako język do stworzenia skryptów pomocniczych

• JavaME - jako język do zaprogramowania urządzenia mobilnego

2 Słownik

W celu zapewnienia poprawnej komunikacji między użytkownikami systemu, a je-go twórcą, został przygotowany słownik terminów. Zawiera on wszystkie terminy ispecyficzne słownictwo używane podczas opisu realizacji projektu.

Słownik terminów (terminów, akronimów, skrótów):

• Ariadna (system) System do monitorowania pozycji pojazdów.

• (Aplikacja WWW (aplikacja)Interfejs do systemu zaimplementowany wpostaci aplikacji WWW dostępny z poziomu przeglądarki internetowej.

• Klient(użytkownik) Instytucja lub osoba, która korzysta z systemu Ariadna.

• GeoSerwer (serwer) Komputer z dostępem do Internetu, na którym działająmoduły GeoBotMaker, GeoListener, GeoZope i GeoStorage.

37

• GeoAgent (Agent) Urządzenie mobilne zawierające moduł GPS i wysyła-jące komunikaty do serwera.

• GeoStorage Baza danych systemu Ariadna.

• GeoBotMaker (bot) Program symulujący działanie moduły GeoAgent.

• GeoListener Program odbierający meldunki GPS od GeoAgentów. zasilającnimi bazę danych.

• GeoZope Moduł w systemie Ariadna odpowiedzialny za interakcję z użyt-kownikiem za pomocą aplikacji internetowej.

3 Prowadzenie projektu

Stworzenie od podstaw w pełni funkcjonalnego technicznego systemu informatycz-nego nie jest prostym zadaniem. W firmach zajmujących się komercyjnym wykony-waniem systemów informatycznych, poszczególne etapy realizowaną są przez różneosoby / zespoły osób. Oprócz tego po drugiej stronie istnieje klient - osoba, któraczęsto nie posiada rozległej wiedzy technicznej z zakresu obejmującego projekt.

Kluczowe jest to, aby wszystkie osoby zajmujące się projektem, zarówno od stro-ny klienta, jak i developara osiągnęły porozumienie i satysfakcję. Aby tego dokonaćniezbędne jest dostosowanie metody tworzenia projektu do obecnie panujących stan-dardów.

Typowy proces rozwijania projektu podzielić na kilka etapów[4]:

• analiza wymagań

• projektowanie

• kodowanie/wykonanie

• testowanie

• wdrożenie

• eksploatacja

W celu ułatwienia wymiany informacji i obrazowania pewnych obiektów/zjawiskwprowadzono standard UML 8. Jest to graficzny system wizualizacji, specyfikowaniaoraz dokumentowania składników systemów informatycznych. Opis systemu wyko-nany za pomocą języka UML jest jednoznaczny, co bardzo ułatwia napisanie kodu

38

Rysunek 11: Iteracyjny proces kodowania

źródłowego w oparciu o modele. Powstała w ten sposób dokumentacja projektowajest zrozumiała nie tylko dla twórców systemu, ale również dla klienta.

Projekt Ariadna w całości został wykonany tylko przez jedną osobę(autora pra-cy). Pomimo tego faktu, jego realizacja przeprowadzona została zgodnie z zakreślo-nymi wyżej standardami. Usystematyzowanie realizacji Ariadny znacznie ułatwiacały proces, oraz pozwala na lepsze zrozumienie z odbiorcami niniejszej pracy.

Do realizacji systemu Ariadna został wybrany iteracyjny model wytwarzaniaoprogramowania, przedstawiony na rys. 11. Podejście iteracyjne (inaczej przyrosto-we) wymusza na projektancie/programiście gruntowne przemyślenie architekturyoprogramowania. Powinna być ona elastyczna i dawać możliwość dołączania kolej-nych funkcjonalności. Poza tym, technika ta pozwala na wczesne wykrycie zagrożeń(min. przekroczenie terminów i budżetu, źle zaprojektowane interfejsy modułów)oraz uzyskanie lepszej kontroli nad budową systemu.

4 Koncepcja systemu

Ariadna jest systemem typu serwer-agent. Zarys architektury jest przedstawiony narys. 12. Taka architektura oznacza, że obydwie części działają niezależnie i komuni-kują się za pośrednictwem wspólnego protokołu.

Użytkownik loguję się do serwisu za pośrednictwem sieci Internet. Dzięki dostar-czonemu Interfejsowi w postaci dynamicznego serwisu WWW ma dostęp do całejfunkcjonalności oferowanej przez system.

8ang. Unified Modeling Language czyli Ujednolicony Język Modelowania

39

Agentem jest urządzenie mobilne, zawierające moduł GPS i modem GPRS.Agent odpowiedzialny jest za zbieranie informacji uzyskanych z odbiornika GPSi wysłanie ich przez internet (za pośrednictwem GPRS) na określony adres w sie-ci, zdefiniowany przez IP i port. Ramki danych wysyłane są co określony interwałczasu (typowo 3 sekundy) za pośrednictwem protokołu UDP. Warto zaznaczyć, żeurządzeń typu Agent może być wiele i wszystkie mogą nadawać jednocześnie.

Serwer stanowi oś centralną systemu. Jest to komputer klasy PC, na który napisa-no dedykowane oprogramowanie, służące do odbierania, gromadzenia, przetwarzaniai wyświetlania danych nadsyłanych przez urządzenia typu Agent.

Rysunek 12: Model koncepcyjny systemu Ariadna

Poglądowy algorytm systemy jest narysowany na rys. 13. W momencie, gdypojazd zaczyna się poruszać, urządzenie nadawcze zainstalowane w samochodzierozpoczyna cykliczne nadawanie meldunków nawigacyjnych do centralnego serwera.Częstotliwość nadawania komunikatów jest zaprogramowana w Agencie i może byćmodyfikowana za pomocą specjalnych sms-ów konfiguracyjnych. Komunikat trafiado bazy danych, gdzie jest zapamiętywany. Odczyt wartości konkretnych komunika-tów następuje dopiero na żądanie użytkownika, tzn. aplikacja internetowa odwolujesię do bazy danych i eksportuje z niej np. aktualne pozycje wszystkich urządzeń. Ko-munikacja między urządzeniami nadawczymi, a serwerem jest jednostronna. Agenciwysyłają dane niezależnie, bez żądań i potwierdzeń ze strony serwera, dzięki cze-

40

mu zminimalizowana została objętość transferowanych danych, co znacznie obniżakoszty.

Rysunek 13: Algorytm systemu Ariadna

5 Analiza kosztów

Ważny aspektem jest rozważenie całkowitych kosztów, wymaganych aby wdrożyćsystem Ariadna. Koszty możemy podzielić na dwie podstawowe kategorie:

41

• jednorazowe

• miesięczne

Koszty jednorazowe

SerwerW tej kategorii należy zawrzeć wszelkie koszty sprzętowe. Aby uruchomić System,należy posiadać Serwer i conajmniej jednego Agenta. Jako serwer możemy użyć zwy-kłego komputera PC, który powinien bez problemu obsłużyć aplikację webową, orazsilnik bazodanowy. Oczywiście wraz ze znacznym wzrostem liczby Agentów i uzyt-kowników systemu, należało by monitorować poziom utylizacji Serwera i rozważyćkupno wydajnej, wielordzeniowej maszyny. Do prototypu zwykły domowej kompu-ter w zupełności wystarczy, dlatego nie uwzględniono ceny serwera w kosztorysieprojektu.

AgentAgent, czyli mobilne urządzenie instalowane w pojazdach składa się z dwóch pod-zespołów - modułu GPS i modemu GPRS. Odniornik GPS z interfejsem USB mo-żemy kupić za ok 70 zł, modemy GPRS dostępne są na internetowych aukcjach zaok. 130 zł. Podsumowując, koszt całego urządzenia typu agent wynosi ok 200 PLN.

Koszty miesięczneKoszty miesięczne wiążą się z opłatami za transmisję pozycji Agentów przez siećGPRS. W sieci Orange, w pakiecie Orange Free[20] każde 100kB transmisji kosztuje3 grosze. Pojedynczy meldunek ma objętość ok 30 kB. Jest to związne z wielkościąnagłówka pakietu UDP (8 bajtów) i rozmiarem meldunku (20 bajtów). Wynika ztego, że przybliżony koszt jednego meldunku to 1 grosz. Zakładając, że Agent będzieczynny przez 8h dziennie (w przypadku braku ruchu pojazdu nie są wysyłane żadnedane), przy częstotliwości nadawnia meldunków co minutę, całkowity miesięcznykoszt na transmisję GPRS nie powinien przekroczyć 10 PLN.

6 Projekt i wykonanien systemu

Model architektury zilustrowany na rys. 14 stanowi rozwinięcie modelu koncepcyj-nego zaprezentowanego na wstępie części praktycznej niniejszej pracy. Na schemaciezaznaczone są wszystkie moduły wchodzące w skład systemu, oraz przepływ in-formacji pomiędzy nimi. Ikony na poszczególnych modułach określają technologię,jaką wykorzystano w celu ich realizacji. W dalszych podrozdziałach tej sekcji kolejnobędą omawiane i wyjaśniane wszystkie komponenty wchodzące w skład systemu.

42

Rysunek 14: Architektura systemu Ariadna

6.1 GeoAgent

GeoAgent jest to nazwa skonstruowanego dla potrzeb projektu urządzenia mobilne-go. Urządzenie to składa się z dwóch podstawowych części - modułu GPS i modemuGPRS, pokazanego na rys. 15. Moduły te współpracują ze sobą, dzięki czemu możli-we jest przesyłanie wszelkich informacji z odbiornika GPS bezprzewodowo, poprzezsieć GPRS. Punktu widzenia serwera (a konkretnie modułu GeoListener) przycho-dzące pakiety pochodzą wprost z Internetu.

Rysunek 15: Komunikacja modułu GeoAgent

W celu realizacji prototypu GeoListenera użyto następującego sprzętu:

43

• odbiornik GPS Navibe GM720

• modem GPRS ED77 (z modułem Aplikom 12)

6.1.1 Wybór odbiornika GPS - Navibe GM720

Jest to jeden z tańszych odbiorników GPS 16 dostępnych na rynku. Oparty jestna dobrym i sprawdzonym chipsecie SiRFstar III, który cechuje się następującącharakterystyką[13]:

Rysunek 16: Odbiornik GPS Navibe GM720

• 20 kanałowy odbiornik, który potrafi przetwarzać sygnały ze wszystkich wi-docznych satelit jednocześnie

• pobór mocy 62 mW w czasie pracy

• czułość rzędu -159 dBm podczas śledzenia

Oprócz chipsetu, na płytce modułu znajduje się konwerter interfejsu USB.

6.1.2 Wybór modemu GPRS - Aplikom 12

Jako platforma sprzętową wybrano moduł Aplicom 12 (rys. 17). Jest to progra-mowalny moduł GSM umożliwiający transmisję w systemach GPRS i EDGE. Jegoniewątpliwą zaletą jest sprzętowe wspieranie protokołu NMEA, przyjazne środowi-sko Java, oraz dostępność i niska cena urządzenia. Najlepszym sposobem na zdoby-cie urządzenia jest kupno gotowego modemu GPRS. Orange i Plus swoje modemy

44

GPRS(odpowienio- Ed77 i iPlus Commander). Dodatkową zaletą kupna gotowegomodemu jest to, że oprócz samego modułu radiowego zawiera w komplecie antenę,płytkę PCB na której wyprowadzony jest PORT1 przekonwertowany na USB, orazzasilacz.

Rysunek 17: Moduł Aplicom 12i

Z urządzeniem można się komunikować za komputera poprzez specjalny softwa-re dostarczony przez producenta (Aplicom 12 Configurator). Za pomocą tego opro-gramowania, można ustawić podstawowe parametry pracy modułu- takie jak PIN,numer centrum SMS, bramki łączności, ustawienia portów itp. Za pomocą konfigu-ratora wgrywane są również IMLety, czyli napisane oprogramowanie. Niewątpliwązaletą jest niska cena wspomnianych modemów GPRS. Na aukcjach internetowychmożna je kupić poniżej 200zł.

Z punktu widzenia projektu niezwykle istotne jest to, że Aplikom 12 posiada wir-tualną maszynę Javy wraz z wbudowany wsparciem protokołów TCP/IP i UDP/IP.Dzięki temu programowanie modułu w całości odbywa się w wysokopoziomowymjęzyku JavaMe.

6.1.3 ED77

Modem GPRS, zilustrowany na rys.18 sprzedawany był przez operatora komórkowe-go Orange jako urządzenie umożliwiające dostęp do Internetu z sieci GSM. Modemzostał wyparty przez nowsze urządzenia, obsługujące standardy UMTS i HSDPA. Wchwili obecnej można go dostać za niewielkie pieniądze na aukcjach internetowych.

Modem ten został wybrany przez autora projektu, gdyż jest oparty na moduleAplikom 12. Oprócz tego modem ma układ stabilizujący zasilanie, antenę, diodysygnalizacyjne. Jeden w portów we/wy został przekonwertowany na interfejs USB,za pomocą którego modem komunikuje się z komputerem PC.

Najbardziej interesujący i użyteczny jest fakt, że za pośrednictwem dołączonegokabla USB , po zainstalowaniu sterownika ściągniętego ze strony internetowej Apli-

45

Rysunek 18: Modem GPRS ED77

kom można bezpośrednio komunikować się z samym modułem GSM. Dzięki temumamy możliwość wygrywania własnego oprogramowania w postaci IMletów, zmie-niając tym funkcjonalność i przeznaczenie modemu ED77.

6.1.4 Zestawienie komunikacji GPS GM720 i modemu ED77

Pierwszym krokiem w celu poprawnego zestawienia komunikacji pomiędzy tymi dwo-ma urządzeniami jest poprawne ustawienie parametrów odbiornika GPS.

GM720 komunikuje się za pomocą interfejsu USB, przy jego pomocy jest równieżzasilane. Po podłączeniu GPS do komputera PC za pomocą sterownika zmieniamypodstawowe parametry pracy:

• Prędkość transmisji danych - jest to bardzo istotne, gdyż urządzenie podłą-czone do odbiornika GPS musi mieć ustawioną taką samą prędkość odbiorudanych

• Rodzaj transmisji danych - mamy do wyboru transmisję binarna i ASCII(trybtekstowy). Należy wybrać ASCII.

• Częstotliwość odświeżania. Co jaki interwał czasu urządzenia ma odświeżaćdane z satelitów. Optymalną wartością będzie 1-2 sekundy.

• Wysyłane komunikaty NMEA. Należy wybrać jaki zestaw danych generowa-nych przez odbiornik jest dla nas interesujący.

– GPRMC - pozycja, prędkość i kierunek

– GPWPL - przesyłanie Waypoints

Urządzenie GPS zaczyna nadawać sygnał o ustalonych wcześniej parametrachod razu po załączeniu zasilania, nie jest wymagana żadna sekwencja startowa.

Jak wcześniej zostało wspomniane, Aplikom posiada 3 złącza I/O, z czego jednozostało przekonwertowane na USB i jest wykorzystywane do komunikacji modemuz PC. Do wykorzystania pozostają zatem 2 złącza szeregowe. GPS Navibe GM720z kolei posiada tylko jeden interfejs USB do połączenia z PC. Aby zestawić ko-munikację między tymi dwoma urządzeniami należy z odbiornika GPS wyprowadzić

46

bezpośrednio sygnał TTL(z pominięciem konwertera USB) na wejście szeregowe mo-dułu Aplikoma. W tym celu zainstalowano w odbiorniku GPS specjalny przełącznik,umożliwiający wybór dwóch trybów:

Rysunek 19: Układ modułu GeoAgent - połączenie odbiornika GPS(Navibe 720) imodemu GPRS(Aplikom 12)

• TTL - tryb uzyskiwany przez ominięcie układu konwertującego na sygnał USB.Tryb służy do połączenia GM720 z modułem Aplikomu

• USB - załączenie układu konwertera USB, tryb służy do komunikacji odbior-nika z PC i zmiany parametrów nadawanego sygnału

Komunikacja pomiędzy modułami jest jednostronna, gdzie modem GPRS jestodbiornikiem, a moduł GPS nadajnikiem.

6.1.5 Odbiór komunikatów GPS przez moduł Aplicom

Moduł GPS wysyła na wybrany port tekstowe komunikaty NMEA. Głównym zada-niem programu (w postaci IMLetu Java) napisanego na moduł Aplikoma jest odbiórtych komunikatów, przetworzenie i wysłanie ich do zdalnego serwera poprzez siećGPRS. Meldunki NMEA mają ściśle określoną strukturę, co pozwala do swobodnydostęp do poszczególnych danych takich jak, współrzędne geograficzne, prędkość,wysokość idp. Do otrzymanych danych z odbiornika GPS dodawany jest unikalnyID urządzenia.

6.1.6 Wysłanie meldunków do zdalnego serwera

Na wstępie należy rozpatrzyć protokół komunikacji pomiędzy GeoAgentem a Geo-Listenerem. Moduł Aplikom 12 ma wbudowaną obsługę zarówno TCP jak i UDP.Obydwa protokoły są oparte na IP, jednak znacznie się od siebie różnią.

47

TCP jest protokołem niezawodnym, bezstratnym, gdzie tworzony jest strumieńdanych. Niewątpliwą zaletą jest 100% pewność dostarczenia danych. Wadą z ko-lei duża redundacja danych i powolność transmisji. TCP jest bardzo powszechniestosowany w Internecie, do komunikacji HTTP, przesyłania plików, rozmów itp.

UDP z kolei operuje na datagramach - paczki są wysyłane niezależnie od siebie,bez potwierdzenia. UDP jest protokołem zawodnym - nie mamy gwarancji, że danezostaną dostarczone do adresata. W zamian otrzymujemy małe opóźnienie transmisjii małą redundancję danych.

W projekcie wykorzystano(pomimo zastrzeżeń) protokół UDP. Ze względu naspecyfikę projektu, UDP jest dużo lepszym wyborem. Dopuszczalna jest strata pew-nej ilości meldunków (są to niewielkie wartości, rzędu części promila) na korzyśćszybkiej i taniej transmisji (mniejsza nadmiarowość transmisji to mniejszy kosztwysłania danych).

Meldunki nawigacyjne są wysyłane co ściśle określony przedział czasu T. Wcelach testowych T został ustawiony jako zmienna losowa z równomiernego przedział(3;5) sekund. W rzeczywistych zastosowaniach z reguły nie jest potrzebne tak częsteodświeżanie danych z odbiornika GPS.

Ramka meldunku nawigacyjnego przesyłana jest jako Plain Text 9. W komer-cyjnych systemach komunikaty powinny być szyfrowane, w celu ułatwienia testówautor zdecydował się na razie nie stosować żadnego kodowania. Poszczególne daneotrzymane z odbiornika GPS są rozdzialne przecinkiem. Kolejność występowaniakolejnych danych jest stała. Poniżej przedstawiony jest przykładowych kilka komu-nikatów otrzymywanych przez serwer10.

Dane po kolei: id urządzenia, data meldunku, długość geograficzna, szerokośćgeograficzna, prędkość, wysokość n.p.m, kurs

4,2009−01−24 22 : 25 : 10 , 52 . 397473 , 16 . 903201 , 63 . 1 , 233 , 106 . 82,2009−01−24 22 : 25 : 12 , 52 . 411294 , 17 . 027252 , 33 . 6 , 94 , 122 . 86,2009−01−24 22 : 25 : 15 , 52 . 399633 , 16 . 907481 , 49 . 4 , 227 , 91 . 67,2009−01−24 22 : 25 : 16 , 52 . 399311 , 16 . 991993 , 54 . 9 , 181 , 105 . 53,2009−01−24 22 : 25 : 16 , 52 . 392532 , 16 . 895809 , 0 . 0 , 2 22 , 97 . 75,2009−01−24 22 : 25 : 16 , 52 . 391565 , 16 . 996069 , 53 . 4 , 181 , 105 . 04,2009−01−24 22 : 25 : 17 , 52 . 397126 , 16 . 903857 , 50 . 9 , 234 , 88 . 71,2009−01−24 22 : 25 : 17 , 52 . 425185 , 16 . 990695 , 63 . 0 , 113 , 99 . 02,2009−01−24 22 : 25 : 18 , 52 . 410746 , 17 . 027412 , 43 . 4 , 94 , 106 . 7

9zwykły tekst, niezaszyfrowany10Jest to faktyczny wyciąg z logów serwera

48

6.1.7 Dodatkowa obsługa SMS

GeoAgent oprócz głownego kanału GPRS posiada dodatkowo obsługę SMS. Użyt-kownicy mogą wysyłać smsy na numer karty SIM zainstalowanej w Agencie, a wodpowiedzi modem wyśle wiadomość zwrotną, w którym znajdują się współrzędnegeograficzne oraz przybliżony adres. Translacja współrzędnych na postać adresowąodbywa się po stronie serwera. Pełna sekwencja zdarzeń jest następująca:

1. Użytkownik wysyła sms.

2. GeoAgent rozpoznaje żądanie i wysyła do Serwera po protokole UDP swojeaktualne współrzędne.

3. Serwer tłumaczy współrzędne geograficzne na przybliżony adres i wysyła godo urządzenia mobilnego

4. GeoAgent przesyła sms zwrotny z odpowiedzią do użytkownika.

Fragment listingu kodu źródłowego programu zainstalowanego na moduleAplikomu

Program odpowiada za odczyt i analizę komunikatów NMEA z odbiornika GPS,oraz formowanie datagramów z meldunkami nawigacyjnymi i wysłanie ich na zdalnyserwer.

protected void startApp() //start aplikacji{

try{

do //proboj do skutku połączyć się z serwerem UDP{

//ip serweraUdpConn = (DatagramConnection) Connector.open("datagram://85.221.210.247:5656");

//parametry polączeniaserialConn =(StreamConnection) Connector.open("comm:3;baudrate=9600", Connector.READ);

is = serialConn.openInputStream(); //czytanie danych z portuThread.sleep(100);//pauza przed kolejna próba połączenia

}while(UdpConn==null || serialConn==null || is==null);} catch (Exception e) { }

new Thread(new SmsListener()).start(); //uruchomienie procesu pomocniczego- transmisja SMSnew Thread(new GPRSSender()).start(); //uruchomienie procesu głównego- transmisja GPRS

}public void sendUdp(String msg) //wysłanie wiadomości msg do serwera zdalnego{

try{

byte[] data = msg.getBytes(); //zamiana string na postać bajtowąDatagram d = UdpConn.newDatagram(data, data.length); //utworzenie datagramu

49

UdpConn.send(d); //wysłanie datagramu}catch(Exception e){}

}

private boolean Parse(String nmeaString) //analiza i rozkład meldunku NMEA{

int nmea1=nmeaString.indexOf("$"); //szukanie począdku wiadomościint nmea2=nmeaString.indexOf("\n"); //szukanie końca wiadomości//wyzerowanie danych GPSLat="";Lng="";Time=""; HDOP="" ; Speed=""; NoSatVisible=""; Altitude="";Course="";

while(nmea2!=-1) //jeślie znaleziono koniec wiadomości{

String nmea = nmeaString.substring(nmea1,nmea2); //ekstracja wiadomości NMEA

int data1=0, data2=0;for(int i=0; data2 != -1; i++) //umieszczenie poszczególnych danych gps w tablicy{

data1=data2+1;data2 = nmea.indexOf(’,’,data1);try{DataTab[i] = nmea.substring(data1,data2);}catch(Exception ignored){}

}String NmeaTag = DataTab[0]; //analiza tagu (rodzaju wiadomości) NMEASpeed = DataTab[0];if(NmeaTag.equals("GPGGA")) //odczyt poszczególnych danych GPS{

Lat = DataTab[2] + DataTab[3];Lng = DataTab[4].substring(1) + DataTab[5];Time = DataTab[1].substring(0,6);NoSatVisible = DataTab[7];HDOP = DataTab[8];Altitude = DataTab[9];

}if (NmeaTag.equals("GPVTG")) //odczyt poszczególnych danych GPS{

Course =DataTab[1];Speed = DataTab[7];

}nmea1=nmea2;nmea2=nmeaString.indexOf("\n",nmea1);

}return false;

}

6.2 GeoListener

6.2.1 GeoListener

Moduł GeoListener odpowiedzialny jest za odczytywanie odbieranie, interpretacjęi przetwarzanie danych pochodzących z GeoAgentów, oraz zasilanie nimi bazy da-nych GeoStorage. Aplikacja, której schemat przestawiony jest na rys. 20 działa jakodemon 11, który po otwarciu portu rozpoczyna nasłuchiwanie i czeka na komunikaty

11proces, który pracuje w tle bez konieczności interakcji z użytkownikiem.

50

nadsyłane przez Agentów za pośrednictwem protokołu UDP. Po odebraniu komu-nikatu, analizuje jego zawartość po czym generuje odpowiednie komendy językaSQL i za pomocą adaptera PyGreSQL 12 uaktualnia bazę GeoStorage. Komunikacjamiędzy Agentami a serwerami jest jednostronna, Serwer (a konkretnie GeoListe-ner) tylko odbiera dane, tak więc zbieranie meldunków nie odbywa się na zasadziekolejnych odpytywań, tylko każdy Agent po włączeniu od razy zaczyna cyklicznienadawać meldunki nawigacyjne. Wszytskie meldunki trafiają do bazy danych, skądkażdorazowo ekstraktowane są potrzebne informacje.

Rysunek 20: Komunikacja modułu GeoListener

Moduł GeoLister składa się z 3 niezależnych procesów:

• UDPReceiver - odpowiedzialny za odbiór datagramów z meldunkami GPSod posczególnych GeoAgentów.

• AddressUpdater - co określony interwał czasu aktualizuje przybliżone adre-sy urządzeń (proces zamieniający pozycję geograficzną na odpowiadający jejadres nosi nazwę Reverse Geocoding)

• TraceUpdater - zapamiętuje pojedyncze podróże pojazdów- od momenturuszenia pojazdu do zatrzymania.

6.2.2 UDPReceiver

Jest to główny proces modułu GeoListener. Działa zawsze w tle i jest odpowiedzialnyza odbiór meldunków nawigacyjnych (jako datagramy UDP), analizę i rozkład tychmeldunków oraz zasilenie nimi bazy danych. Algorytm zilustrowany rys. 21 działaw sposób następujący.

1. Start procesu Proces jest demonem, więc działa w tle cały czas. Zakończonymoże być tylko poprzez zatrzymanie programu przez system operacyjny.

2. Wczytaj dane z portu Funkcja wczytująca dane z portu blokuje działanieprocesu, dopóki dane faktycznie nie napłyną do portu. W przypadku, gdyby wtym samym momencie do portu dotrą dwa lub więcej datagramów, uruchamia-ne są kolejne kopie procesu, które czekają w kolejce na zwolnienie portu. W ten

12moduł Pythona zawierający interfejs do bazy danych PostgreSql

51

Rysunek 21: Algorytm procesu UDPReceiver

sposób mamy możliwość obsługi praktycznie nieograniczonej ilości urządzeń napojedynczym porcie komputera.

3. Przetwarzanie danych Poszczególne datagramy są dzielone na części od-powiadające pojedynczym jednostkom danych (np. wysokość, lub szerokośćgeograficzna). Dane te są zapamiętywane w pamięci.

4. Zapisanie danych do GeoStorage - stworzone i uruchomione zostają za-pytania języka SQL, baza danych jest aktualizowana.

Listing kodu źródłowego procesu UDPReceiver

class Handler(SocketServer.DatagramRequestHandler):

def handle(self):c=db.cursor()

report = self.rfile.read(200) #odczyt meldunku nawigacyjnego z portudata = report.split(’,’) #podzial danych i wrzucenie do tablicy

id_device = data[0] #zapis poszczególnych danych gpslast_update = data[1]lat = data[2]lng = data[3]speed = data[4]course = data[5]elevation = data[6]

52

#zapytanie SQL, które zapisuje meldunek do bazy danychquery = "BEGIN;"query+= "INSERT INTO reports " \

"VALUES ("+report+");"

query+="UPDATE devices" \" SET last_update="+last_update+ \

", lat="+lat+ \", lng="+lng+ \", speed="+speed+ \", course="+course+ \", elevation="+elevation+ \

" WHERE id_device="+id_device+";"

query+="COMMIT"

c.execute(query) #wykonaj zapytaniw SQL

# zapytanie SQL do sprawdzenia statusow alarmówquery = " SELECT * "\

" FROM status "\" WHERE id_device = "+id_device+""\

c.execute(query) #wykonanie zapytaniazone_status = c.fetchone()

if zone_status == None: #brak zdefiniwanej strefy alarmuquery = "INSERT INTO status(id_device, alarmzone) "\

"VALUES ("+id_device+", ’nie zdefiniowana’);"

c.execute(query)else:

query = "SELECT id_point, lat, lng from alarm_zones WHERE id_device="+id_device;c.execute(query)rows = c.fetchall()desc = "nie zdefiniowana"

isInside = Falsepolypoints = []for row in rows: #sprawdzenie, czy pojazd znajduje się w strefie alarmu

id_point = row[0]if id_point==0 and len(polypoints) > 0: #new polygon

isInside = isInside or pointInsidePolygon(lat, lng, polypoints)polypoints=[]

polypoints.append([ float(row[1]) , float(row[2]) ])

if len(polypoints) > 0:isInside = isInside or pointInsidePolygon(float(lat), float(lng), polypoints)

if isInside:desc = "w strefie"

else:desc = "poza strefa"

query = "BEGIN;"

53

#update stref alarmowc.execute("SELECT alarmzone FROM status WHERE id_device="+id_device)rows = c.fetchall()old = rows[0][0]

if old =="w strefie" and desc=="poza strefa":query+="INSERT INTO logs VALUES ("+id_device+", "+last_update+\

", ’wyjechal poza strefe’, "+lat+", "+lat+");"elif old =="poza strefa" and desc=="w strefie":

query+="INSERT INTO logs VALUES ("+id_device+", "+last_update+\", ’wjechal w strefe’, "+lat+", "+lat+");"

query += "UPDATE status SET alarmzone=’"+desc+"’ WHERE id_device="+id_device+";"

query += " COMMIT"c.execute(query)

6.2.3 AddressUpdater

Jest to pomocniczy proces, który jest odpowiedzialny za szukanie najbliższych adre-sów dla aktualnych pozycji geograficznych, w jakich znajdują się pojazdy. Algorytmdziałania jest przedstawiony na rysnku 22

1. Pobierz aktualne współrzędne Wykonuje zapytanie do bazy danych otrzy-mując listę wszystkich urządzeń (GeoAgent) wraz z aktualną pozycją.

2. Znajdź przybliżony adres Translacja współrzędnych geograficznych na ad-resy odbywa się za pomocą usługi Google Directions w serwise Google Maps.Proces (algorytm przedstawiony na rys. 22) wykonuje odpowiednia zapyta-nia HTTP i parsuje13 odpowiedź. Jeżeli dany punkt nie leży bezpośrednio nażadnej ulicy, skrypt sprawdza kolejne punkty poruszając się po Spirali Archi-medesa14

3. Zapis do GeoStorage Zapis odbywa się w jednej sesji (jedno zapytanie SQL)

4. Pauza 5 sekund

Listing kodu źródłowego procesu AddressUpdater

class AddressUpdaterDeamon(Thread):def __init__(self, timestep): #timestep - co ile ma sprawdzać aktualizacje adresów

self.timestep = timestepThread.__init__(self)Thread.setDaemon(self, True)self.c=db.cursor()

13Analizowanie składni kodu źródłowego i jego reguł gramatycznych.14Spirala Archimedesa to krzywa w o równaniu we współrzędnych biegunowych:r = α ∗ ϕ

54

Rysunek 22: Algorytm procesu AddressUpdater

def run(self):while True:

#wczytaj wszystkie aktualne dane z urządzeń GPSquery= "SELECT *" \

"FROM devices"

self.c.execute(query) #wykonaj zapytanie SQLrows = self.c.fetchall() #zapisz wynik zapytania

for row in rows: #dla każdego urządzenia odczytaj dane GPStry:

id_device = row[0]last_update = row[10]lat = float(row[4])lng = float(row[5])

#jeslie czas osttaniego updatu wiekszy od 30if (str(last_update) == ’None’ or (datetime.datetime.now() - last_update).seconds > 30):

#aktualizacja adresuquery = "UPDATE devices " \

"SET address=’"+reverseGeocoder(str(lat), str(lng))+"’ ," \"address_update=now()"+ \" WHERE id_device="+‘id_device‘+";"

self.c.execute(query)#zapis do bazy danychexcept:

pass

time.sleep(self.timestep) #pauza

55

6.2.4 TraceUpdater

Proces ten ma za zadanie wykrywać moment w którym samochód zaczyna się poru-szać, oraz kiedy kończy podróż. Jest to potrzebne, aby poprawnie wyświetlać historiępodróży. Zasada działania jest prosta i jest zdefiniowana algorytmem, który ilustrujerys. 23

Rysunek 23: Algorytm procesu TraceUpdater

Listing kodu źródłowego procesu TraceUpdater

class TraceUpdaterDeamon(Thread):"""Watek co dany interwal czasu uaktualnia do bazy danych slady urzadzen

"""

def __init__(self, timestep=5, stop_limit=600):

56

#timestep - czas (w sek) co ile sprawdzana jest baza danych#stop_limit - czas (w sek), który mówi jaki czas nieaktywności powoduje zakończenie trasy

self.c=db.cursor()self.timestep = timestepself.stop_limit = stop_limitThread.__init__(self)Thread.setDaemon(self, True)

def run(self):

while True:#zapytanie SQL, które zwraca listę tras dla danego pojazduquery_read= " SELECT id_trace, d.id_device, last_update, start, finish "\

" FROM devices d "\" LEFT JOIN ( "\" SELECT * "\" FROM traces "\" WHERE id_trace in ( "\" SELECT max(id_trace) "\" FROM traces "\" GROUP BY id_device "\" ) "\" ) AS traces "\" ON d.id_device = traces.id_device "

self.c.execute(query_read) #wykonanie zapytania SQLdevices = self.c.fetchall() #zapis zapytania pod zmienną devices

query_write = "BEGIN;"

for dev_data in devices: #zapis poszczególnych zmiennych z tablicy

id_trace= ‘dev_data[0]‘id_device= ‘dev_data[1]‘last_update= dev_data[2];if last_update == None:

last_update = datetime.datetime.now()start= dev_data[3]finish= dev_data[4]

#czas od ostatniego raportudelta_time = (datetime.datetime.now() - last_update).seconds

#rozpoczęcie nowej trasyif delta_time < self.stop_limit and (start== None or finish != None):

query_write+= " INSERT INTO traces(id_device,start) "\" VALUES ("+id_device+",now());"

#zakończenie nowej trasyelif finish == None and delta_time > self.stop_limit:

query_write+= " UPDATE traces "+ \" SET finish=now()"+ \" WHERE id_trace="+id_trace+";"

query_write += "COMMIT"if query_write != "BEGIN;COMMIT":

57

print query_writeself.c.execute(query_write)

time.sleep(self.timestep)

6.3 GeoStorage

Rysunek 24: Komunikacja modułu GeoStorage

GeoStorage jest centralnym miejscem, gdzie przechowane są wszystkie dane po-chodzące z modułów GeoAgent.Najważniejsze są oczywiście aktualne pozycje po-szczególnych modułów GeoAgent, za pomocą przemyślanej konstrukcji bazy i odpo-wiednich zapytań języka SQL możliwe jest uzyskanie bardziej szczegółowych danych,takich jak np. który pojazd przebył największy dystans tydzień temu.

Baza danych została zaprojektowana za pomocą narzędzia DBDesigner 15 Pro-jekt bazy przedstawia rys. 25.

Projekt bazy definiuje następujące tabele.

• devices Jest to główna tabela, przechowująca unikalne id (nazwy) oraz aktu-alne GPS ze wszystkich modułów GeoAgent. Wszystkie pozostałe tabele łącząsię z devices za pomocą klucza id.

• reports Przechowuje wszystkie meldunku nadsyłane przez urządzenia mobil-ne. Przy dużej licznie urządzeń tabela może zajmować znaczą objętość. Ko-rzysta się z niej, gdy chcemy wyodrębnić jakieś dane historyczne.

• traces Zapisywanie są w niej czasy, w których dany pojazd zaczyna i kończytrasę.

15DBDesigner jest narzędziem służącym do modelowania struktur bazy danych. Potrafi on in-tegrować się z różnymi bazami danych (MySQL, Oracle) i dzięki intuicyjnemu interfejsowi użyt-kownika może być wykorzystywany nie tylko przez profesjonalistów, ale również przez osoby nieznające składni języka SQL.

58

Rysunek 25: Projekt bazy danych GeoStorage

• alarm zones Definiuje strefy alarmów, czyli obszary w formie wielokątów wktórych poruszanie się pojazdu jest dozwolone i nie powoduje alarmu.

• bots Przechowuje wszystkie informacje niezbędne, aby na bieżąco generowaćmeldunki należące do poszczególnych botów.

• status Związana jest ściśle z tabelą alarm zones, zapisana jest w niej infor-macja, czy pojazdy są w strefie alarmów.

• logs Przechowuje historię alarmów.

Dzięki takiemu zaprojektowaniu struktury bazy danych, możliwe jest uzyskanieprzeróżnych danych historycznych i statycznych. Poniżej zostanie zaprezentowanychkilka przykładowych zapytań, użytych w projekcie.Dane GPS urządzeń w ściśle określonym momencie w przeszlości

Jako parametr podajemy dokładną datę (dzień i godzina). Zapytanie przeszukujespośród wszystkich rekordów u zwraca te, które mają datę najbliższą w stosunkudo żądanej.

59

query= " SELECT id_device, time::time, lat, lng, speed, course, elevation "\" FROM reports "\" WHERE (id_device, time) "\" IN ( "\" SELECT r.id_device, max(time) "\" FROM reports r JOIN devices d ON r.id_device = d.id_device "\" WHERE time < ’"+par[’date’]+"’ "\" GROUP BY r.id_device "\" ); "\

Przykładowa odpowiedź:

id_device | time | lat | lng | speed | course | elevation-----------+----------+-----------+-----------+-------+--------+-----------

6 | 04:31:33 | 52.425516 | 16.915518 | 91.9 | 271 | 1192 | 04:31:34 | 52.386616 | 16.973983 | 86.5 | 271 | 90.64 | 04:31:35 | 52.391331 | 16.922911 | 159 | 181 | 96.33 | 04:31:37 | 52.428764 | 16.985058 | 111 | 1 | 101.25 | 04:31:37 | 52.393220 | 16.942179 | 0 | 271 | 117.17 | 04:31:39 | 52.397064 | 16.915951 | 94.5 | 181 | 95.5

Wyznaczenie tras określonego urządzenia w określonym przedziale czasuJako parametr podajemy zakres dat i nazwę urządzenia. Baza danych zwraca prze-działy czasów identyfikujace poszczególne trasy.

query = " SELECT u.id_device,name,start::timestamp(0), "+\" finish::timestamp(0), road "+\" FROM traces o "+\" JOIN devices u on u.id_device = u.id_device "+\" WHERE ( start > ’"+par[’date1’]+"’ "+\" AND finish < ’"+par[’date2’]+"’ "+\" AND name = ’"+par[’name’]+"’ "+\" ) "+\" LIMIT "+par[’rows’] +\" OFFSET "+‘offset‘+";


id_device | name | start | finish | road-----------+--------+---------------------+---------------------+------

5 | Milosz | 2009-01-25 00:03:27 | 2009-01-25 00:36:22 | 3.235 | Milosz | 2009-01-25 00:03:17 | 2009-01-25 00:41:42 | 4.235 | Milosz | 2009-01-25 00:04:47 | 2009-01-25 00:45:17 | 2.235 | Milosz | 2009-01-25 00:09:42 | 2009-01-25 01:02:23 | 6.215 | Milosz | 2009-01-25 00:11:27 | 2009-01-25 01:04:23 | 1.235 | Milosz | 2009-01-25 00:11:17 | 2009-01-25 01:04:38 | 2.315 | Milosz | 2009-01-25 00:14:37 | 2009-01-25 01:15:13 | 2.435 | Milosz | 2009-01-25 00:59:53 | 2009-01-25 01:32:58 | 7.235 | Milosz | 2009-01-25 01:05:08 | 2009-01-25 01:42:53 | 10.235 | Milosz | 2009-01-25 01:08:38 | 2009-01-25 01:49:13 | 4.315 | Milosz | 2009-01-25 01:25:58 | 2009-01-25 02:15:23 | 6.325 | Milosz | 2009-01-25 01:27:53 | 2009-01-25 02:21:43 | 12.125 | Milosz | 2009-01-25 01:27:58 | 2009-01-25 02:21:53 | 9.325 | Milosz | 2009-01-25 01:56:28 | 2009-01-25 02:29:14 | 9.225 | Milosz | 2009-01-25 01:38:38 | 2009-01-25 02:38:34 | 7.23

60

Wyznaczenie punktów określonej trasyPosiadając dane w postaci daty rozpoczęcia i zakończenia trasy, możliwe jest uzy-skanie wszystkich meldunków nawigacyjnych, które kolejno napływały podczas po-konywania trasy przez pojazd.

query= "SELECT r.id_device, r.time::time, r.name,"+\r.lat, r.lng, r.speed, r.course, r.elevation "+\"from reports r "+\"JOIN devices d ON r.id_device = d.id_device "+\"WHERE (r.time between ’"+par[’date1’]+ "’ "+\" AND ’"+par[’date2’]+"’ "+\" ) "+\" AND d.name = ’"+par[’name’]+"’ "+\


id_device | time | name | lat | lng | speed | course | elevation-----------+----------+--------+-----------+-----------+-------+--------+-----------

5 | 01:05:05 | Milosz | 52.421999 | 16.994647 | 103.8 | 181 | 111.25 | 01:05:14 | Milosz | 52.420909 | 16.992374 | 127 | 181 | 1115 | 01:05:23 | Milosz | 52.420089 | 16.990665 | 96.6 | 181 | 81.95 | 01:05:31 | Milosz | 52.419155 | 16.988717 | 127.9 | 181 | 121.15 | 01:05:39 | Milosz | 52.418257 | 16.986844 | 115.8 | 181 | 1075 | 01:05:46 | Milosz | 52.417507 | 16.985282 | 111.7 | 181 | 104.15 | 01:05:55 | Milosz | 52.416999 | 16.984221 | 63.7 | 181 | 113.75 | 01:06:01 | Milosz | 52.416534 | 16.983252 | 80 | 181 | 109.95 | 01:06:10 | Milosz | 52.415562 | 16.981226 | 113.6 | 181 | 101.65 | 01:06:17 | Milosz | 52.415025 | 16.980107 | 84.9 | 181 | 885 | 01:06:25 | Milosz | 52.414384 | 16.978770 | 85.7 | 181 | 1025 | 01:06:31 | Milosz | 52.413727 | 16.977399 | 117.7 | 181 | 96.25 | 01:06:39 | Milosz | 52.413519 | 16.976966 | 91.6 | 181 | 110.95 | 01:06:45 | Milosz | 52.413397 | 16.975748 | 85.9 | 181 | 97.45 | 01:06:53 | Milosz | 52.413264 | 16.974415 | 77.6 | 181 | 77.4

Wyznaczenie strefy alarmu dla określonego urządzeniaJako argument podajemy nazwę urządzenia, zapytanie zwraca listę punktów (współ-rzędnych geograficznych) identyfikujących strefę alarmu.

query= " SELECT s.id_poly, s.id_point, s.lat, s.lng "\" FROM alarm_zones s JOIN devices u ON s.id_device = u.id_device "\" WHERE u.name =’"+self.request.form[’name’]+"’ "\


id_poly | id_point | lat | lng---------+----------+-----------+-----------

0 | 0 | 52.414042 | 17.0109550 | 1 | 52.413100 | 17.0181650 | 2 | 52.409854 | 17.0181650 | 3 | 52.410168 | 17.0107840 | 4 | 52.412576 | 17.0054620 | 5 | 52.414356 | 17.0076940 | 6 | 52.414042 | 17.010955

61

6.4 GeoBotMaker

System Ariadna został zaprojektowany i wykonany z myślą o obsłudze wielu urzą-dzeń typu GeoAgent. Jako, że fizycznie został wykonany tylko jeden moduł urzą-dzenia mobilnego, został stworzony specjalny system, który jest w stanie symulowaćmoduł GeoAgenta. Ważne jest to, że bot zachowuje się tak dokładnie tak samo,jak rzeczywisty moduł Agenta. Wynikiem jego działania jest wysyłanie meldunkówkomunikacyjnych bezpośrednio na port serwera, dlatego z punktu widzenia modułuGeoListener nie ma różnicy, czy dane pochodzą z prawdziwego, czy symulowanegoGeoAgenta. Schemat komunikacji jest pokazany na rysnku 26.

Rysunek 26: Komunikacja modułu GeoBotmaker

Klient może dodać Bota w za pomocą wygodnego interfejsu na stronie WWW,gdzie zakreśla wielokąt, po którym bot będzie się poruszał. Dokładne informacje oobsłudze tego mechanizmu będą podane przy opisie modułu GeoZope.

6.4.1 BotSynchronizer

Skrypt BotSynchronizer jest odpowiedzialny na obsługę botów - czyli wirtualnychpojazdów. BotSychronizer działa zawsze w tle i jego zadaniem dodawanie oraz usu-wanie botów z bazy danych. Dzieje się to jeśli użytkownik zarząda takiej akcji zapośrednictwem interfejsu WWW. Pełny algorytm działania skryptu przedstawionyjest na schemacie 27.

Ciekawsze momenty algorytmu:

• 2. Skrypt w celu sprawdzenia aktualnego statusu botów komunikuje się z baządanych, gdyż do GeoStorage zapisywane są dane botów wprowadzane przezKlientów za pośrednictwem WWW.

• 5. Do konstruktora bota przekazywany jest jego unikalny ID. Konstruktor zapomocą ID odwołuje się do bazy danych i pobiera wszystkie wartości botazdefiniowane przez Klienta.

• 7. Warto dodać, że rozsądnym ograniczeniem jest liczba kilkuset botów. Wyni-ka to z budowy systemów operacyjnych, które nie radzą sobie dobrze z większąilością wątków.

62

Rysunek 27: Algorytm procesy BotSynchronizer

Listing kodu źródłowego procesu BotSynchronizer

class Synchronizer(threading.Thread):def __init__(self): #inicjalizacja wątku

threading.Thread.__init__(self)pass

def run(self): #metoda wątkuwhile(True):

query = "SELECT id_device from bots group by id_device;" #zapytanie sqlc.execute(query) #wykonanie zapytania sqlbots_db = c.fetchall() #zapis wyniku zapytaniaactive_bots = []

#zapisz boty z wyciągnięte z nazy danych jako tablica active_botsfor bot_db in bots_db:

active_bots.append(bot_db[0])

#usuniecie botow, ktore zostaly usuniete przez uzytkownikafor running_bot in running_bots:

63

if running_bot not in active_bots:threads[‘running_bot‘].join() #zabicie wątka bota, który ma być usunięty

#dodanie nowych botowfor active_bot in active_bots:

if active_bot not in running_bots:running_bots.append(active_bot)threads[‘active_bot‘] = bot(active_bot)threads[‘active_bot‘].start(); #uruchominie wątka bota, który został dodany

time.sleep(1)

synchronizer = Synchronizer().start() #start procesu

6.4.2 Bot

Każdy Bot jest pojedynczym, niezależnym wątkiem programu i stanowi jeden wirtu-alny pojazd. Jego zadaniem jest cykliczne pobieranie z bazy danych swoich definicji,tworzenie meldunku nawigacyjnego i przesłanie go na port serwera.

Algorytm procesu jest przedstawiony na rys. 28 Ciekawsze momenty algorytmu:

• 2. Z bazy danych wczytywana są dane bota. Definiujemy go za pomocą na-stępujących wartości: lista współrzędnych geograficznych (tworzą zamkniętąfigurę - wielokąt), średnia prędkość poruszania się, rozkład prędkości (typowoGauss), prawdopodobieństwo postoju i częstość nadawania meldunków.

• 3. Sygnał zakończenia jest przekazywany z procesu BotSynchronizer

• 4. Wszystkie wartości przekazywane w meldunku są generowane losowa, przypomocy wartości pobieranych z bazy w punkcie 2. Każdy bot ma zdefiniowanątrasę poruszania się -tzw duże punkty wprowadzane przez Klienta. Programlosuje za ich pomocą, małe punkty - czyli współrzędne, które zmieniają się wposzczególnych meldunkach. Zależą one od prędkości poruszania się symulo-wanego pojazdu oraz częstotliwości nadawania meldunków.

• 5. Meldunek ma taki sam format, jak oryginalnie przekazywany przez Geo-Agenta.

• 7. Pauza jest losowa o średniej podawanej jako parametr. W tym miejscumoże też nastąpić zatrzymanie się/start pojazdu, co objawi się zakończeniemlub początkiem nowej trasy.

Listing kodu źródłowego procesu Bot

class bot(threading.Thread):def __init__(self, id_device, ts=3):

self._stopevent = threading.Event() #zdarzenie powodujące zabicię wątku

64

Rysunek 28: Algorytm procesu bot

self._sleepperiod = 1.0

threading.Thread.__init__(self, name="bot_"+‘id_device‘)#wyzerowanie zmiennych lokalnych

self.course = 0.0 #aktualny kurs pojazduself.id_device = id_device #id pojazduself.speed = 0.0 #aktualna prędkośc pojazduself.current_pos =[0.0,0.0] #aktualna pozycja pojazduself.direction = 1 #aktualny kierunekself.points = [] #punkty na podsatawie których pojazd się poruszaself.next_p=1 #index następnego punktuself.timestep = ts #pauza pomiędzy punktami

query= "SELECT lat, lng FROM bots WHERE id_device="+‘id_device‘+""; #zapytanie sqlc.execute(query)self.points = c.fetchall() #zapis wyniku zapytania SQL

#przypisz jako punkty startowe pierwsze z listyself.current_pos[0] = float(self.points[0][0])self.current_pos[1] = float(self.points[0][1])self.countCourse()

def countCourse(self): #ustala kurs na podstawie pozycji aktualnej i następnejif float(self.points[self.next_p][0]) > self.current_pos[0] and

float(self.points[self.next_p][1]) > self.current_pos[1]:self.course = 0

if float(self.points[self.next_p][0]) > self.current_pos[0] andfloat(self.points[self.next_p][1]) < self.current_pos[1]:

self.course = 90

65

if float(self.points[self.next_p][0]) < self.current_pos[0] andfloat(self.points[self.next_p][1]) < self.current_pos[1]:

self.course = 180

if float(self.points[self.next_p][0]) > self.current_pos[0] andfloat(self.points[self.next_p][1]) < self.current_pos[1]:

self.course = 270

odcX = abs(float(self.points[self.next_p][0]) - float(self.current_pos[0]))odcY = abs(float(self.points[self.next_p][1]) - float(self.current_pos[1]))self.course+=math.atan2(odcY,odcX)

def countDistanceToNextBigPoint(self):#zwraca dystans w km pomiędzy aktualnymi wsp. geogr a następnego punktu

dGeoX = float(self.current_pos[0])-float(self.points[self.next_p][0])dGeoY = float(self.current_pos[1])-float(self.points[self.next_p][1])distGeo = 111196.672 * math.sqrt( dGeoX*dGeoX + dGeoY*dGeoY)return distGeo

def randDistanceTraveled(self): #losuje przebyty dystans pomiędzy punktami

if random.random() > 0.05: #5% szans na dłuższy postójself.speed = random.gauss(100,20) #losuj prędkość z rozkładu gaussa

else:self.speed = 0.0

d = self.speed * 0.277777778 * self.timestep #przebyta droga w metrach w danym odcinku czasureturn d

def run(self): #główna metoda wątku

while not self._stopevent.isSet(): #dopóki proces jest aktywny#czy przebyty dystans jest większy od następnego punktu kontrolnego

gain = float(self.randDistanceTraveled() / self.countDistanceToNextBigPoint())if gain < 1: #jeśli nie to losuj następny mały punkt

delta_x = float(self.points[self.next_p][0])-float(self.current_pos[0])delta_y = float(self.points[self.next_p][1])-float(self.current_pos[1])self.current_pos[0]+=float(gain)*float(delta_x)self.current_pos[1]+=float(gain)*float(delta_y)

else: #jeśli tak to jako następny punkt przyjmij najbliższy punkt kontrolnyself.current_pos[0]=float(self.points[self.next_p][0])self.current_pos[1]=float(self.points[self.next_p][1])

if self.next_p == self.points.__len__()-1: #czy zmienić kierunektime.sleep(random.gauss(self.stop_time,3)) #pauzaself.direction = -1

if self.next_p == 1:self.direction = 1

self.next_p+=self.direction

self.countCourse()

#tworzenie meldunku nawigacyjnego dla botadata = ‘self.id_device‘+’,’+\

"’"+time.strftime("%Y-%m-%d %H:%M:%S", time.localtime(time.time()))+\"’,"+str(round(self.current_pos[0],6))+’,’+\str(round(self.current_pos[1],6))+\

66

’,’+str(round(self.speed,1))+\’,’+str(int(self.course))+\’,’+str(round(random.gauss(100,10),1))

done = Falsewhile(done==False):

try:#wysłanie meldunku jako datagram na portclisocket.sendto(data, ("127.0.0.1", 8667))done=True

except:pass

self.timestep = 5+random.random()*3;time.sleep(self.timestep)self._stopevent.wait(self._sleepperiod)

print "%s ends" % (self.getName(),)

def join(self,timeout=None):"""Stop the thread"""self._stopevent.set()threading.Thread.join(self, timeout)

6.5 GeoZope

Moduł GeoZope (rys. 29) stanowi aplikacja internetowa umożliwiająca wizualizacjędanych zgromadzonych w GeoStorage. GeoZope korzysta z map dostarczanych przezsystem Google Maps. Za pomocą specjalnego API, na mapy nanoszone są różneobiekty, takie jak markery, wielokąty itp.

Działanie aplikacji przetestowano pod następującymi przeglądarkami:

• Microsoft Internet Explorer w wersji: 6.x oraz 7.x,

• Mozilla Firefox w wersji: 3.x,

• Opera w wersji: 9.5,

• Google Chrome w wersji: 0.3.154.9

• Safari 3.x

Wersja developerska witryny znajduje się pod adresem http://gis.stxnext.pl

6.5.1 Zasada działania

Instancja GeoZope połączona jest z bazą danych. Schemat połaczenia ilustruje rys.29. Głównym zadaniem aplikacji internetowej jest pobieranie z GeoStorage danych

67

Rysunek 29: Komunikacja modułu GeoZope

i przekształcanie ich na postać “rozumianą” przez serwis Google Maps. Dzieje się tow kilku krokach:

1. GeoZope łączy się z bazą danych za pomocą adaptera PyGreSQL16 i wysy-ła do bazy zapytanie SQL ( lista aktualnych współrzędnych geograficznychwszystkich urządzeń).

2. Baza danych zwraca wynik zapytania w formie obiektów Pythonowych(tablicestringów).

3. GeoZope przekształca obiekty pythonowe na postać XML17, za pomocą syste-mu szablonów ZPT 18.

4. Format XML jest wczytywany przez funkcję języka JavaScript i zamienianyna obiekt tego języka.

5. Obiekt z danymi(aktualne pozycje pojazdów) jest przekazywany do serwisuGoogle Maps, który aktualizuje widok mapy.

Opisany przykład (aktualizacja pozycji pojazdów) jest automatycznie wykony-wany przez skrypt co 1 sekundę. Inne akcje mogą być inicjowany np. przez kliknięciew określony obiekt na stronie.

Wszystkie aktualizacje danych odbywają się za pomocą techniki AJAX, dlategonie jest konieczne (a wręcz niewskazane) odświeżanie strony.

6.5.2 Projekt witryny i lista opcji

Projekt wyglądu witryny (przestawiony na rys. 30 ) zakłada dwie główne sekcje:16Jest to specjalny moduł Pythona służący do komunikacji z bazą danych PostGreSQL.17uniwersalny język formalny przeznaczony do reprezentowania różnych danych w ustrukturali-

zowany sposób18szablony używane przez serwer aplikacji Zope. Tworzą dynamiczny kod HTML/XML za po-

mocą funkcji języka Python

68

Rysunek 30: Projekt witryny - interfejs użytkownika

• mapaWidok mapy udostępnionej przez Google Maps wraz z naniesionymi obiek-tami. Ekran ten posiada kilka trybów, w zależności od wybranej funkcji zmenu.

• menuSekcja menu jest dwupoziomowa, oparta na dwóch rodzajach zakładek: głównych-uszeregowanych poziomo i wewnętrznych, uszeregowanych pionowo. Listę wszyst-kich dostępnych opcji z menu przedstawia mapa witryny 31

Mapa witryny przedstawia wszystkie ekrany dostępne dla użytkownika. Każdy zekranów, umożliwa inny tryb renderowania mapy. Poszczególne ekrany będą kolejnoomawiane.

6.5.3 Ekran live (rys. 32)

Jest to główny widok aplikacji. Umożliwia podgląd bieżących pozycji aktywnychpojazdów. Na tym ekranie znajduje się filtr, za pomocą którego możliwe jest filtro-wanie urządzeń po nazwie. Działa to w ten sposób, że modyfikowane jest zapytaniegenerowane do bazy danych. Po kliknięcie na wybrany pojazd pojawia się okien-ko ze szczegółowymi informacjami GPS. Po prawej stronie w menu wyświetlanajest tabelka ze spisem urządzeń, datą ostatniej aktualizacji z odbiornika GPS, orazprzybliżonym adresem miejsca, w którym znajduje się pojazd.

6.5.4 Ekran playback (rys. 33 )

Tryb umożliwia odtworzenie ruchu pojazdów począwszy od określonego momentuw przeszłości. Z menu należy wybrać datę i godzinę rozpoczęcia. Aplikacja będziepobierać kolejne historyczne meldunki z bazy danych, aktualizować dane na ekra-nie mapy,. Ze względu na skomplikowane zapytania, które zostały zastosowane aby

69

Rysunek 31: Mapa witryny

Rysunek 32: Ekran live

wyodrębnić dane z GeoStorage tryb nie działa płynnie w przypadku, gdy zgroma-

70

Rysunek 33: Ekran historia->playback

dzonych meldunków jest bardzo dużo (powyżej 100 tysięcy).

6.5.5 Ekran ślady (rys. 34)

Rysunek 34: Ekran historia->ślady

Za pomocą tego ekranu możliwe jest wyodrębnienie poszczególnych kursów zro-bionych przez pojazdy. Przez kurs rozumie się odcinek trasy, gdzie czas postoju jestmniejszy niż 30 minut. Z menu należy wybrać określony pojazd, wtedy w tabelcepojawi się lista jego kursów. Wybrany odcinek pojawi się na mapie.

71

6.5.6 Ekran heatmaps (rys. 35)

Tryb umożliwiający pokazanie, które miejsca na mapie są najczęściej odwiedzane.Na oryginalną warstwę mapy zostaje naniesiona warstwa termiczna; im kolor bar-dziej czerwony, tym dany obszar był częściej odwiedzany. Z menu należy wybraćzakres z którego będzie obliczana warstwa termiczna. Tryb HeatMaps jest czaso-chłonny obliczeniowo, dlatego został nałożony limit– maksymalnie do obliczeń jestpobieranych 2000 punktów.

Rysunek 35: Ekran historia->Heat Maps

Rysunek 36: Ekran alarmy->strefy

72

6.5.7 Ekran strefy (rys. 36)

Strefy alarmów są to zdefiniowane obszary w formie wielokątów. Każdy pojzad mo-że mieć zdefiniowanych kilka takich stref. Jeżeli samochód przekroczy obszar strefyalarmu, zostaje podany odpowiedni komunikat. Tryb ten może być przydatny dozabezpieczania samochód przed kradzieżami. Aby dodać strefę alarmu należy w ta-beli zaznaczyć odpowiedni pojazd i zakreślić myszką pożądany obszar. Strefa zostajeusunięta po naciśnięciu na niej prawego klawisza myszy.

6.5.8 Ekran komunikaty (rys. 37)

Wyświetlone zostają zdarzenia związane z przekraczaniem strefy alarmów przez po-jazdy. Zdarzenie zawiera nazwę pojazdu, czas i współrzędne w którym strefa zostałaprzekroczona.

Rysunek 37: Ekran alarmy->komunikaty

6.5.9 Ekran dodanie bota (rys. 38)

W tej sekcji możliwe jest dodanie bota, czyli symulatora modułu GeoAgent. Abyzdefiniować bota należy zakreślić za pomocą myszy wielokąt, po którym będzie sięporuszał. Po zdefiniowaniu trasy i kliknięciu submit bot zostanie dodany do bazydanych, po czym będzie wykryty przez proces BotSynchronizer modułu GeoBotma-ker

6.5.10 Ekran lista botów (rys. 39)

Sekcja wyświetlająca wszystkie aktywne boty wraz z parametrami. Prawym przyci-skiem myszy można usunąć bota.

73

Rysunek 38: Ekran boty->dodaj bota

Rysunek 39: Ekran boty->lista botów

7 Zakończenie

7.1 Perspektywy zastosowania i dalszego rozwoju

Przygotowany projekt, po etapie dokładnej analizy, został zaimplementowany i jestgotowy do wdrożenia. System Ariadna mógłby być wykorzystany zarówno przez fir-my transportowe, komunikacyjne (MPK), usługowe(taxi, pogotowie, straż pożarna,policja) jak i indywidualnych użytkowników. Dzięki temu, że system Ariadna opartyjest o sieć Internet, jego instalacja odbywa się na jednym komputerze-serwerze. Jestto bardzo wygodne rozwiązanie które pozwala na łatwe zarządzanie i utrzymaniesystemu.

Autor projektu przewidział kilka usprawnień, których implementacja była bypożądana w systemie.

• Kodowanie i kompresja meldunków nawigacyjnych Kodowanie ma na

74

celu uniemożliwienie odczytania meldunków przez niepowołane osoby. Należypamiętać, że pakiety z komunikatami wysyłane są przez publiczną sieć Internet,a więc osoby, które dzielą wspólną podsieć z użytkownikami systemu mogłybyza pomocą specjalnego oprogramowania podsłuchiwać nadawane datagramy.Dodatkową opcją wartą rozpatrzenia jest kompresja meldunków. Ramka ko-munikatu może zawierać niewiele ponad 10 różnych znaków, tak więc symbolmożemy zapisać na 4 bitach. Tymczasem standardowe kodowanie ASCII używa8 bitów. Ponadto kolejne dane przesyłane do serwera różnią się w niewielkimstopniu. Wszystkie te cechy powodują, że zysk uzyskany z kodowania byłbybardzo duży, co mocno ograniczyło by opłaty za transmisje GPRS.

• Moduł danych statystycznych Baza danych GeoStorage gromadzi wszyst-kie historyczne meldunki nawigacyjne poszczególnych urządzeń, dzięki czemumożliwe jest wyodrębnienie wielu ciekawych danych statystycznych. Niestetyz braku czasu, autor projektu pominął ten ważny aspekt.

• Konfiguracja GeoAgenta przez interfejs WWW Aby cokolwiek zmienićw konfiguracji urządzenia mobilnego, należy wgrać nową wersje oprogramo-wania przez kabel USB. Przy większej liczbie urządzeń takie rozwiązanie niesprawdziło by się. Dobrym rozwiązaniem tego problemu była by możliwośćzdalnej konfiguracji urządzenia, można by do tego wykorzystać przeglądarkęWWW i kanał UDP, który obecnie wykorzystywany jest praktycznie tylko doprzesyłania meldunków nawigacyjnych.

• Implementacja modułu GeoAgent na innych urządzeniach mobil-nych Obecnie występujące na rynku telefony komórkowe i palmtopy mająwbudowane odbiorniki GPS oraz obsługę GPRS. Po odpowiednim oprogra-mowaniu można by je zintegrować z systemem Ariadna.

• Transmisja głosu przez GPRS Prędkość kanału GRPS jest wystarczającaaby transmitować zakodowany sygnał dźwiękowy. Wykorzystanie tej możliwo-ści było by bardzo ciekawe, kierowcy mogliby bezpośrednio porozumiewać sięz osobami zdalnie nadzorującymi trasę.

7.2 Podsumowanie

System informatyczny zrealizowany w ramach tej pracy magisterskiej jest projek-tem integrujących ze sobą wiele różnych technologii. Do jego wykonania niezbędnaokazała się wiedza zarówno z dziedziny elektroniki jak i szeroko pojętej informatyki.Otrzymany produkt jest rozwinięty zwłaszcza w części serwerowej. Dziesiątki go-dzin zostały poświęcone, aby dane otrzymywane z odbiornika GPS przechowywać i

75

przetwarzać na wiele różnych sposobów, w celu zwiększenia funkcjonalności całegosystemu.

Projekt Ariadna swoimi możliwościami jest zbliżony do komercyjnych produk-tów obecnych na rynku, a ponadto ma kilka innowacyjnych, niespotykanych funk-cji(HeatMaps, translacja współrzędnych na adresy, obsługa botów).

Ważnym aspektem całego systemu jest jego niski koszt budowy. Całe wykorzy-stane oprogramowanie jest darmowe, a budżet na cały zakupiony sprzęt zmieścił sięw kwocie 250 zł.

7.3 Wykorzystane oprogramowanie

Przy tworzeniu projektu Ariadna niniejszej pracy dyplomowej autor korzystał zróżnego rodzaju narzędzi programistycznych. Wszystkie wykorzystane programy sąpowszechnie dostępne, darmowe, mające otwarte źródła.

• Python - język programowania wykorzystany do napisania aplikacji dla mo-dułów GeoZope, GeoListener, GeoBotMaker

• PostgreSQL - relacyjny serwer bazodanowy, wykorzystany do stworzenia mo-dułu GeoStorage

• Linux Ubuntu 8.10 - system operacyjny pod kontrolą którego działa Geo-Serwer.

• LaTeX - język znaczników, służący do formatowania dokumentów tekstowychi tekstowo-graficznych. Wykorzystany do składu niniejszej pracy.

• Eclipse - zintegrowane środowisko programistyczne, wykorzystane je do napi-sania wszystkich aplikacji wykorzystanych w projekcie. Eclipse posłużył takżejako edytor LaTeX.

• Gimp - edytor grafiki wektorowej.

• Dia, Kivio - edytory schematów, układów blokowych i diagramów UML

• Java ME - uproszczona wersja platformy Java wykorzystana do oprogramo-wania urządzenia Aplikom12, w module GeoAgent

76

A Załączniki cyfrowe

A.1 Buildout

Buildout jest to zestaw specjalnych skryptów, za pomocą których możliwe jest utwo-rzenie w pelni funkcjonalnej instancji aplikacji Zope (GeoZope).

A.2 Kody źródłowe

• aplikacja integernowa GeoZope (python)

• skrypt pythonowy modulu GeoBotMaker(python)

• skrypty tworzące bazę danych GeoStorage(shell systemu linux)

• Imlet na moduł Aplikom 12i (JavaMe)

• skrypt modułu GeoBotListener (python)

77

Literatura

Książki i publikacje

[1] Dziergwa M., Mleczko A., Zope - darmowy serwer aplikacji„Software 2.0 Extra!”,09/2004.

[2] Cezary Speecht, System GPS, Pelplin: Wydawawnictwo Bernardinum, 2007

[3] Mark Lutz & David Ascher, Learning Python, Wydawawnictwo OREILLY, 2004

[4] Dick Hamlet i Joe Maybee. 83-204-2844-0. WNT. 2003. Podstawy techniczneinżynierii oprogramowania.

[5] Jacek Lamparski, Navstar GPS Od teorii do praktyki, Olsztyn: WydawawnictwoUniwersytetu Warmińsko-Mazurskiego, 2001

[6] Wikipedia Wolna encyklopedia, hasło GPS, dostępność w internecie sierpień2008 r.http://pl.wikipedia.org/wiki/Global_Positioning_System

[7] Wikipedia Wolna encyklopedia, hasło Framework, dostępność w internecie sier-pień 2008 r.http://pl.wikipedia.org/wiki/Global_Positioning_System

[8] Rządowa strona internetowa systemu GPS, dostępność w internecie czerwiec2008 r.http://www.gps.dov

[9] Jacek Januszewski, Systemy Satelitarne GPS Gallileo i inne, Warszawa: Wyda-wawnictwo Naukowe PWN, 2007

[10] Chapple, Mike. "SQL Fundamentals" (HTML). About.com: Databases.

[11] Retrieved on 2007-06-10. "Structured Query Language (SQL)" (HTML). Inter-national Business Machines (October 27, 2006). Retrieved on 2007-06-10.

[12] “Zope Book” v.2.7 Jest to praca zbiorowa stanowią-ca dokumentację środowika Zope. Dostępna ppod adresem:http://www.zope.org/Documentation/Books/ZopeBook/

[13] SiRFstarIII Product Overview. SIRF.com. February 2007, Rev. 1.2http://www.sirf.com/products/GSC3LPProductInsert.pdf

[14] Trailer magazine, issue 7/8 2006, page 11, ISSN 0349-9790

78

Źródła internetowe

[15] Beazley D., Python, Warszawa: Wydawawnictwo RM, 2002.

[16] http://www.opensource.ite.pl

[17] http://java.sun.com/javame/technology/index.jsp

[18] www.java-tips.org/java-me-tips/midp/

[19] www.blueboard.com/javame/

[20] http://www.orange.pl

[21] http://googleblog.blogspot.com

[22] http://code.google.com/apis/maps/

[23] Oficjalny blog usługi Google Maps, dostępny pod adrsemhttp://googlemapsapi.blogspot.com/

[24] pl.wikipedia.org/wiki/GPRS

Aplicom 12i GMS Module Data sheetJava IMlet programming guide rev. 1.12 Programming

guideProduct Specification rev 2.1 Product

description

[25] www.siemens.com/wm

Aplicom 12i GMS Module Data sheetJava IMlet programming guide rev. 1.12 System de-

scription

[26] http://www.telit.com/

GM862-GPS Data sheetProduct description rev. 2 Product

descriptionHardware User Guide rev. 0 HardwareSoftware User Guide rev. 0 Software

[27] http://www.wavecom.com/

[28] www.it.iitb.ac.in/ satyajit/seminar/node15.html

79

Wismo Quick Q2501 Data sheetOpen AT ADL User Guide for Open AT 3.02 rev. 6 Programming guideWavecom Wireless Modules Overview Product line overviewOpen AT 3.02 Tutorial rev. 6 Develop and debug environment

[29] www.it.iitb.ac.in/ satyajit/seminar/node15.html

[30] http:// www.asp.net/ajax/

[31] http://en.wikipedia.org/wiki/Ajax_(programming)

[32] http://www.w3schools.com/Ajax/Default.Asp

[33] http://www.zope.org/

[34] http://en.wikipedia.org/wiki/Zope

[35] http://www.aplicom.com/

80

Monitorowanie pojazdów z wykorzystaniem systemów GPS i GPRS ...

Documents

Transcript of Monitorowanie pojazdów z wykorzystaniem systemów GPS i GPRS ...