Miskolci Egyetem Gépészmérnöki és Informatikai Kar Informatikai Intézet és Villamosmérnöki Tanszékcsoport Általános Informatikai Intézeti Tanszék WiFi Alapú Beltéri Pozicionálási Módszerek Vizsgálata Diplomamunka Készítette: Tervezésvezető: Karsai Szabolcs Tóth Zsolt QZO9LA Egyetemi tanársegéd 4400 Nyíregyháza, Kállói út 93. Általános Informatikai Tanszék Miskolc, 2015.
Tartalomjegyzék 1. Bevezetés 1 1.1. Global Positioning System......................... 2 1.1.1. Működés............................... 2 1.1.2. Előnye................................ 3 1.1.3. Hátránya.............................. 3 1.2. Pozíció meghatározás............................ 3 1.2.1. Technológiai lehetőségek...................... 3 1.3. Alkalmazási lehetőségek.......................... 4 2. Felhasznált technológiák 6 2.1. WiFi..................................... 6 2.1.1. Története.............................. 6 2.1.2. Szabványai............................. 7 2.1.3. Csatornakiosztás.......................... 7 2.1.4. Működése.............................. 8 2.1.5. Biztonság.............................. 8 2.2. Android................................... 8 2.2.1. Története.............................. 8 2.2.2. Architektúra............................. 9 2.3. Kliens - Szerver Architektúra....................... 10 2.4. Maven.................................... 11 2.5. MySQL................................... 11 2.6. Liquibase.................................. 12 2.7. MyBatis................................... 12 2.8. Spring MVC................................. 13 I
2.9. Eclipse.................................... 14 2.10. SVN..................................... 14 2.11. Continuous Integration........................... 15 2.12. Tomcat................................... 16 3. Létező megoldások 17 3.1. Távolság mérés............................... 17 3.2. Háromszögelés................................ 17 3.3. Fingerprinting................................ 18 3.4. Magyarországi megoldások......................... 19 3.5. Külföldi megoldások............................ 19 4. Rendszerterv 21 4.1. Adatbázis.................................. 21 4.2. Webalkalmazás............................... 22 4.3. Kliensek................................... 26 5. Vizsgált módszerek 27 5.1. Trilateration................................. 27 5.1.1. Hatótávolság mérés......................... 28 5.1.2. Jel terjedése............................. 28 5.1.3. Működés............................... 29 5.1.4. Hátrány............................... 31 5.1.5. Genetikus algoritmus........................ 31 5.1.6. Szimulált lehűtés.......................... 32 5.2. Fingerprinting................................ 32 5.2.1. Korreláció.............................. 33 5.2.2. Euklideszi távolság......................... 34 5.2.3. Hátrány............................... 34 6. Eredmények 35 6.1. Trilateration................................. 35 6.1.1. Mobil alkalmazás.......................... 36 6.1.2. Trilateration - Első mérés..................... 37 II
6.1.3. Genetikus Algoritmus - Második mérés.............. 37 6.1.4. Szimulált lehűtés - Harmadik mérés................ 37 6.1.5. Összegzés.............................. 39 6.2. Fingerprinting................................ 39 6.2.1. Mobil alkalmazás.......................... 41 6.2.2. Korreláció - Első mérés....................... 41 6.2.3. Korreláció - Második mérés.................... 42 6.2.4. Korreláció - Harmadik mérés.................... 42 6.2.5. Összegzés.............................. 43 6.2.6. Euklideszi távolság - Negyedik mérés............... 44 6.2.7. Összegzés.............................. 44 6.3. Hibák ábrázolása.............................. 45 6.3.1. Trilateration............................. 45 6.3.2. Fingerprinting............................ 47 7. További lehetőségek 49 8. Összefoglalás 51 9. Summary 53 10.Köszönetnyilvánítás 54 A. DVD melléklet 55 B. Használati útmutató 57 III
Ábrák jegyzéke 1.1. ClickSoftware által készített felmérés[12]................. 1 2.1. 2,4 GHz-es tartomány csatorna kiosztása................. 7 2.2. Mobil OS piaci részesedése 2010-től 2013 Q1-ig.............. 9 2.3. Android OS architektúrája [1]....................... 9 2.4. Kliens - szerver architektúra........................ 10 2.5. Spring MVC architektúra......................... 14 2.6. Continuous Integration folyamat...................... 15 2.7. Jenkins főoldal............................... 16 3.1. Háromszögelés ábrázolása......................... 18 4.1. Adatbázis modellje............................. 21 4.2. Adatbázis táblákhoz tartozó osztály diagram............... 23 4.3. Kérés és válassz objektumok osztály diagram............... 23 4.4. Liquibase konfigurációs xml........................ 24 4.5. ResultMap példa.............................. 24 4.6. MyBatis - SQL utasítás minta....................... 24 4.7. Service osztályok UML diagramja..................... 25 4.8. Spring controller.............................. 25 5.1. Egy szoba vázlata.............................. 27 5.2. Trilateration idális eset........................... 30 6.1. Történeti Tárház - Első terem alaprajza................. 35 6.2. Trilateration alkalmazás képernyői..................... 36 6.3. Az Informatika épület referencia pontjai................. 40 6.4. WiFik jelerősség térképei.......................... 40 IV
6.5. Mérő mobil alkalmazás képernyője..................... 41 6.6. Pozíció kereső alkalmazás képernyője................... 41 6.7. Trialteration - Eredmények......................... 45 6.8. Genetikus algoritmus - Eredmények.................... 46 6.9. Szimulált lehűtés - Eredmények...................... 46 6.10. Korreláció 0,7 - Eredmények........................ 47 6.11. Korreláció 0,8 - Eredmények........................ 47 6.12. Korreláció 0,9 - Eredmények........................ 48 6.13. Euklideszi távolság - Eredmények..................... 48 V
Táblázatok jegyzéke 4.1. A Coordinate tábla tulajdonságai..................... 22 4.2. Az Accesspoint tábla tulajdonságai.................... 22 4.3. A Measurement tábla tulajdonságai.................... 22 4.4. WifiInfo objektum tulajdonságai...................... 26 5.1. 2,4 GHz jel csillapítási értékek....................... 28 6.1. A WiFik pozíciója.............................. 36 6.2. Trilateration mérési eredmények...................... 37 6.3. Genetikus Algoritmus mérési eredmények................. 38 6.4. Szimulált lehűtés mérési eredmények................... 38 6.5. Korreláció threshold: 0,7 mérési eredmények............... 42 6.6. Korreláció threshold: 0,8 mérési eredmények............... 43 6.7. Korreláció threshold: 0,9 mérési eredmények............... 43 6.8. Euklideszi távolság mérési eredmények.................. 44 VI
1. fejezet Bevezetés Napjainkban az elterjedt mobilkészülékek által bárhol, bármikor kapcsolatot tudnak az emberek teremteni egymással. Ez alatt nem csak a telefonhívást vagy SMS küldést kell érteni. A mobilkészülékek mára már ennél sokkal szélesebb körben nyújtanak szolgáltatásokat a felhasználók számára úgy, mint fényképek készítése, zene hallgatás, film nézés, internet elérési lehetőség, vagy tájékozódás a beépített GPS által. 2013 áprilisában felmérést végeztek az USA okostelefon felhasználói között[12]. A felmérésben arra voltak kíváncsiak, hogy az emberek melyik alkalmazásokat használják a leggyakrabban. A felmérés összefoglaló adatai az 1.1 ábrán láthatóak. 1.1. ábra. ClickSoftware által készített felmérés[12] A felmérésből kiderül, hogy a megkérdezett férfiak tizenhét, míg a nők tíz százaléka jelölte meg a GPS funkciót mint a három leggyakrabban használt szolgáltatás egyikét. A megkérdezettek több mint ötvenkilenc százaléka pedig azt mondta, hogy sokkal gyorsabban tudta elvégezni a feladatát, mintha térképet használtak volna. 1
1.1. Global Positioning System A Globális Helymeghatározó Rendszer [7], amellyel 3 dimenziós helyzetmeghatározást végezhetünk földön, vízen vagy levegőben. A rendszert kezdetben katonai célokra kezdték fejleszteni, majd később engedélyezték a polgári használatot is. Azóta számos, a mindennapi életben gyakran használt rendszer alapjául szolgál. Ezen rendszerek a következő csoportok valamelyikébe sorolhatóak: közlekedésben navigációként, gépjárművédelemként, földméréseknél, környezeti megfigyeléseknél. A felsorolt szolgáltatások bármelyikének igénybevételéhez évekkel ezelőtt még külön GPS készülékre volt szükség, mostanra azonban a technikai fejlődésnek köszönhetően mindezek könnyen használhatóak az okostelefonok révén. Ezek a készülékek ugyanis már rendelkeznek beépített GPS vevővel. 1.1.1. Működés Ahhoz, hogy megtudjuk határozni pozíciónkat a következő kritériumoknak kell megfelelni a GPS rendszernek: legalább négy műhold láthatósága egy időben, pontosabb méréshez pedig öt darab, rendelkezni kell információkkal a műholdak pályájáról. Ezek ismeretében 4 lépésből végrehajtható a keresett pozíció számítása. Az első lépésben a vevők szinkronizálják órajelüket a műholdaktól kapott PRN jelek segítségével. Második lépésben a háromszögelés segítségével megállapítják 3 műhold alapján a távol ságokat, amelyekből meghatározható 2 lehetséges pozíció. Harmadik lépésben a műhol daktól kapott adatokat frissítik a műholdak helyzetének pontosításához. A negyedik lépésben pedig a felmerülő hibák korrekcióját végzik a rendszerben. Mivel 3 műhold szolgáltatta jelekből 2 lehetséges pozíció adódik, ezért a negyedik által kerül kiválasztásra a megfelelő pozíció. 2
1.1.2. Előnye A GPS-szel történő helymeghatározás előnyei napszaktól független, földfelszín feletti magasságtól független, mozgási sebességtől független. 1.1.3. Hátránya A GPS-szel történő helymeghatározás hátrányai a szükséges adatok vétele viszonylag hosszú időbe telik, csak nyílt, fedetlen területeken alkalmazható, az épületekről visszaverődő jelek zavart okoznak a mérésben, a ritkán előforduló erős napkitörések alatt használhatatlanná válnak. A beltéri használhatatlanság legfőbb oka az épületek szerkezete, az építéskor felhasznált anyagok tulajdonságai melyek leárnyékolják a műholdak jeleit. 1.2. Pozíció meghatározás A beltéri pozíció meghatározása számos napjainkban fejlesztett rendszernél felmerülő részfeladat, egyre nagyobb érdeklődés övezi. Ennek feltétele, hogy találjunk olyan megoldást amivel beltérben meg lehet határozni egy eszköz helyzetét. 1.2.1. Technológiai lehetőségek A beltéri helymeghatározás megvalósítására számos már meglévő és elterjedt eszköz áll rendelkezésre. A listát hatótávolság szerint vizsgálva az első a telefonba épített szenzorok [2]. Ezek együtteséből vagy tetszőleges kombinációjából készíthetünk olyan alkalmazást, amely 3
képes megmondani hol tartózkodik az ember egy épületen belül. Ilyen megoldás lehet például, hogy ha kamerával figyeljük a teret és az ott elhelyezett jelölések felismerésével megállapítjuk hol tartózkodunk. Másik megoldás lehet ha a gyorsulásmérőt használjuk, ehhez azonban szükséges minden készülék esetén egy kalibráció. A szenzor pontos működéséhez az épületben több referencia pont kinevezése is szükséges lehet. A következő lehetőség az NFC (Near Field Communication) [9], amely RFID alapú technológia, rádiós kommunikáció az alapja. Ilyen jeladókat helyezhetünk el az épületben vagy a megjelölni kívánt helyeken amiket a mobiltelefonok képesek érzékelni. A kapott adatokon keresztül tudjuk közölni a mobiltelefonokkal, hogy hol tartózkodnak. A technika hátránya, hogy sok jeladóra van szükség mivel eléggé kicsi a hatótávolságuk. A Bluetooth [5] már egy ennél jóval nagyobb hatótávolságot tud biztosítani attól függően, hogy milyen frekvenciát használ. A készülékek képesek 1-100 méter közötti távolság áthidalására. Ezt a vezeték nélküli kommunikációt 1994-ben az Ericsson távközlési vállalat találta fel rövid távolságon belüli adatcserére különféle eszközök között, beleértve a mobiltelefonokat is. Hátránya, hogy a nagyobb hatótávolságot biztosító eszközök drágák, míg a gyengébb eszközökből több darabra is szükség lehet. A Wifi [10] egy vezeték nélküli mikrohullámú kommunikációs szabvány, amelyet szintén adatcserére használnak. Az ezzel felszerelt eszközök már széles körben elterjedtek mivel gyors és szélessávú kapcsolatot képesek biztosítani. Hálózati eszközökbe építve gyorsan elterjedt. Ebből következően rengeteg épület rendelkezik bizonyos számú ilyen eszközzel, ami kiváló lehetőséget biztosíthat a beltéri pozicionáláshoz. Legfőbb hátránya a kibocsájtott jel fizikai tulajdonságaiból származik. 1.3. Alkalmazási lehetőségek Előzőekben felsorolt megoldások mind alapjául szolgálhatnak olyan alkalmazásoknak mint például egy múzeumi tárlatvezető. Egy ilyen alkalmazás képes a látogatót körbevezetni saját mobilkészülékén keresztül. Több információt is eljuttatva hozzájuk, illetve interaktívabbá és érdekesebbé is téve a kiállítást. 4
Másik alkalmazási lehetőség például kereskedelmi láncok, áruházak számára lehet akár több megoldás is. Például vevőknek lehet egy fajta bevásárló lista mobil alkalmazás. Az üzletben való navigációt biztosítaná megvásárolandó termékhez, közben pedig akár személyre szabott akciós ajánlatokat is kínálhatna. Nagyobb raktárak esetén, amelyek akár áruházak is lehetnek, nagyobb csomagok vagy szállítmányok keresése és nyomon követésére is adhat egyfajta megoldást. Manapság hasonlóan a beltéri pozicionáláshoz a robotikát is egyre nagyobb érdeklődés övezi. A két terület összekapcsolódása révén a robotok egy beltéri alkalmazás segítségével önállóan tudnának navigálni az épületeken belül. De a robotok is segíthetik egy épület belsejének a feltérképezését és szolgáltathatnak mindig friss információt egy beltéri alkalmazás megfelelő és naprakész működéséhez. 5
2. fejezet Felhasznált technológiák A most következő fejezetben az általam választott és felhasznált technológiák ismertetése található. Választásaimhoz a következő szempontokat vettem figyelembe: elterjedt technológia, könnyen kezelhető, gyors rendelkezésre állás, saját tapasztalat. 2.1. WiFi A WiFi az általam választott technológia, ami a helymeghatározás alapja lesz. Azért ezt választottam, mert rengeteg épületben manapság WiFi-s hálózati eszközöket használ nak így sok helyen egy alap infrastruktúra már adott egy ilyen alapú alkalmazáshoz. Egy az ABI Research által közölt cikkben [17] olvasható, hogy a tavalyi 2013-as évben közel 139 millió darab WiFi-s eszközt értékesítettek a világon. 2.1.1. Története A WiFi egy vezeték nélküli mikrohullámú kommunikációs szabvány, amely 2,4 GHz és 5 GHz frekvenciasávot használja. Alapja a 802.11 szabvány, amelyet az Institute of Electrical and Electronics Engineers (IEEE) kezel. A kezdeti 1997-es indulása óta a 6
szabvány több fejlődésen ment keresztül. Hatótávolsága beltérben közel 20 méterről 70 méterre nőtt, jelátviteli sebessége pedig 2 Mbit/s-ról közel 600 Mbit/s-ra emelkedett. A WiFi már nem csak hálózati eszközökben, hanem már hordozható számítógépekben, telefonokban is megtalálható. A hivatalos WiFi tanúsítványok kezeléséről és kiosztásáról pedig 1999 óta a non-profit Wi-Fi Alliance gondoskodik. Több, mint 600 cégből állnak akik ilyen WiFi-s eszközök előállításával és forgalmazásával foglalkoznak. 2.1.2. Szabványai A WiFi-s eszközök az alábbi főbb szabványokat használják. 802.11a - ez a szabvány 5 GHz-es frekvencia tartományt használ és így 54 Mbit/s sebességre képes 802.11b - ez 2,4 GHz-es tartományban közel 11 Mbit/s-os adatátvitelt biztosít 802.11g - hasonlóan a 802.11b szabványhoz szintén a 2,4 GHz-es frekvenciát használja de már gyorsabb közel 54 Mbit/s -os sebességgel 802.11n - napjainkra a leginkább elterjedt szabvány, amely kompatibilis a korábban felsoroltakkal és a 150 Mbit/s-os átviteli sebességet kínál. 2.1.3. Csatornakiosztás A 2,4 GHz-es frekvencia tartományban 14 darab csatornát jelöltek ki ezek mindegyike 22 MHz széles és a 2412-től 2472-ig tart. Európában csak 13-at használnak ebből, a 14. csatorna Japánban használatos. A csatornakiosztást az alábbi 2.1 ábra szemlélteti. 2.1. ábra. 2,4 GHz-es tartomány csatorna kiosztása 7
2.1.4. Működése A legtöbb WiFi-s eszköz bekapcsolás után elkezdi sugározni a gyárilag beállított nevét (SSID). Ez alapján észlelhető az eszköz és lehet hozzá csatlakozni. Az eszközhöz való csatlakozás beállítástól függően lehet nyílt vagy jelszóval védett. A működéséhez nem szükséges hálózati kapcsolat. Az okostelefonok csatlakozás nélkül képesek információt kapni az ilyen eszközök által kibocsájtott jelekről. Ez a tulajdonság is erősítette döntésem a technológia mellett. 2.1.5. Biztonság Mint minden hálózati kapcsolatnál, úgy a WiFi esetén is fontos a biztonság. Ennek érdekében több különböző lehetőség is rendelkezésre áll, az első ilyen módszer a WEP volt. Azonban ennek gyengesége és könnyen feltörhetősége miatt a Wi-Fi Alliance másik megoldást készített. A WPA titkosítás már nehezebben feltörhetőnek bizonyult a 128 bites kulcs használata miatt. Manapság a legbiztonságosabb megoldás a WPA2 használata jelenti, melynek beépí tését kötelezővé tette a Wi-Fi Alliance. 2006-tól magában foglal olyan algoritmusokat mint TKIP, Michael, EAS valamint CCMP ezekkel téve biztonságossá a vezeték nélküli hálózatok használatát. 2.2. Android Az okostelefonok széles körben való elterjedése miatt potenciális platformnak bizonyultak egy beltéri helymeghatározó alkalmazáshoz. Ezért esett a választásom az okostelefonokra, ahogy a következő 2.2 ábrán látható felmérés eredménye is mutatja az Androidos készülékek a legelterjedtebb telefonok. Ezen adatok valamint az ingyenes fejleszthetősége miatt választottam ezt a platformot. 2.2.1. Története 2003-ban kezdték fejleszteni a Linux kernel alapú mobil operációs rendszert. 2005-ben vásárolta meg az addig támogató Google. A kifejezetten érintőképernyős készülékekre tervezett rendszerrel ellátott első telefon 2008 október 22-én jelent meg. A legfrissebb 8
2.2. ábra. Mobil OS piaci részesedése 2010-től 2013 Q1-ig verzió 2013 októberében kiadott 4.4-es rendszer a KitKat. 2.2.2. Architektúra Ahogy már említésre került a rendszer Linux kernel alapú, pontosan azért döntöttek emellett, hogy támogassák a nyílt rendszerek használatát a mobil piacon. Továbbá ezzel egyszerűsítve a mobilokba épített hardverek ( WiFi, Bluetooth, érintőképernyő) kezelését. A rendszer felépítéséről részletes bemutatást az alábbi 2.3 ábra ad. 2.3. ábra. Android OS architektúrája [1] Mint láthatjuk, a platform alapját vörös színnel jelölt Linux kernel adja, amely tartalmazza a hardver által kezelendő eszközök meghajtó programjait. Ezeket azon cégek készítik el, amelyek az Android platformot saját készülékükön használni kívánják, hiszen a gyártónál jobban más nem ismerheti a mobil eszközbe integrált perifériákat. 9
Ez a kis méretű kernel adja a memória kezelését, a folyamatok ütemezését és az alacsony fogyasztást elősegítő teljesítmény-kezelést is. A kernel szolgáltatásait használják a Linux rendszerekben meglévő különféle programkönyvtárak, mint a libc, az SSL vagy az SQLite ezek C/C++ nyelven vannak megvalósítva, és a Linux kernelen futnak közvetlenül. Részben ezekre épül a Dalvik virtuális gép, amely más, mint a Java alatti megszokott virtuális gép, vagyis a Java csak mint nyelv jelenik meg. A kék színnel jelölt részekben már csak Java forrást találunk, amelyet a virtuális gép futtat, s ez adja az Android lényegét a látható és tapintható operációs rendszert, illetve a futó programokat. A virtuális gép akár teljesen elrejti a Linux által használt fájlrendszert, és csak az Android Runtime által biztosított fájlrendszert láthatjuk [http://hu.wikipedia.org/wiki/android (operációs rendszer)]. 2.3. Kliens - Szerver Architektúra Mivel az Android készülékek mindegyikére nem lehet eljuttatni illetve telepíteni a szükséges adatbázist minden adattal ezért kliens - szerver architektúra kiépítése mellett döntöttem. Egy ilyen rendszer felépítést az alábbi 2.4 ábra szemlélteti. 2.4. ábra. Kliens - szerver architektúra A kliensek ebben az architektúrában csak mint megjelenítők szerepelnek, tényleges műveleteket és számításokat nem végeznek, az ilyen feladatok a szerveren hajtódnak végre. A feladatok és azok elvégzéséhez szükséges adatokat a kliensek hálózaton, interneten keresztül küldik a szervernek. A szerver szerepe, hogy a kliensek számára adatokat biztosítsanak, illetve a kért feladatokat elvégezzék annak eredményéről pedig választ küldjenek a kliensek számára. 10
A szerveren található üzleti logika végzi ezen feladatokat illetve az adatbázissal való kapcsolatot és azon való műveleteket is végrehajtja. 2.4. Maven A szerveren futó Java alkalmazás Maven alapú fejlesztésként végeztem. A Maven egy olyan eszköz, amely szoftverprojektek menedzselésére és a buildelési folyamat automatizálására használható. A szoftvertervezési minták terjesztésével egységes program struktúra kialakítására törekszik. A Maven előnye az Ant-al szemben, hogy nem kell leírnunk mi történjen a buildelés során, csak meg kell adnunk a kimenet eredményét ami lehet Jar vagy War fájl. Egy projekt kezelésre és leírására bevezeti a POM ( Project Object Model ) fogalmát, amely egy xml alapú leíró fájl. Ebben megadhatóak a projekt függőségei, ezáltal elkerülve az esetleges verzió eltéréseket, továbbá megadhatóak pluginek és azok szükséges konfigurációja. A pluginek segítségével az alap életciklus folyamatok kiegészíthetőek további műveletekkel. Egy Maven alapú projekt életciklusa az alábbi előredefiniált célokkal rendelkezik, melyek függőségben állnak egymással. compile test package install deploy Minden cél végrehajtásához az azt megelőző cél sikeres lefutása szükségeltetik. Azért választottam ezt a menedzser eszközt, mert a hozzátartozó xml leíró fájl segítségével a projekt könnyen karbantartható és egy másik fejlesztő egyszerűen bevonható. 2.5. MySQL A pozicionáláshoz szükséges adatokat tárolni kell ezért egy adatbázis kezelő rendszert is felhasználtam, amely a MySQL lett. Azért választottam ezt, mert ingyenes, nincs 11
adatbázis szintű korlátozása és a táblánkénti 64TB-os maximális méret elegendő. A MySQL többfelhasználós, többszálú, SQL alapú relációs adatbázis-kezelő rendszer. Rengeteg programozási nyelvhez rendelkezik driverrel amin keresztül kezelhető. Az adatbázisok adminisztrációja megoldható parancssorból vagy grafikus felületen keresztül. Platformok közül pedig támogatja a Windows, Mac, Linux és egyéb rendszereket. Főbb előnyei: Keresztplatformos elérhetőség Tárolt eljárások Adatbázis triggerek Valódi VARCHAR támogatás SSL támogatás Lekérdezés gyorstár (cache) Egymásba ágyazott SELECT -ek ACID megfelelés az InnoDB-vel, BDB-vel és Cluster-rel 2.6. Liquibase A Liquibase egy ingyenes, nyílt forráskódú, adatbázisfüggetlen verziókövető eszköz. A Maven-be beépülő pluginjának segítségével az adatbázishoz tartozó összes SQL karbantartható és kezelhető. A változásokat egy saját changelog táblában tárolja. Minden SQL fájlt egy xml fáljban lehet kezelni ahol id és author tagekkel azonosítja a változásokat. További előnye, hogy a Maven segítségével az adatbázis karbantartása életciklusba köthető, így minden fordításnál ellenőrzi az adatbázis állapotát. 2.7. MyBatis A MyBatis egy Java-s perzisztencia keretrendszer, amely az ORM-től eltérően nem az osztályok - adatbázis táblák közötti leképzést végzi, hanem az SQL utasításoknak Java függvényekkel való összekapcsolását. Így könnyen használhatóvá téve a különböző 12
SQL utasításokat a programban egy függvény hívás segítségével. Az esetleges eredmény halmazokat pedig a megadott formára képezi le. A MyBatis integrálható Spring keretrendszerrel így az üzleti kód függőségeit feloldva. A parancsok leképzését xml fájlok vagy annotációk segítségével végezhetjük el. 2.8. Spring MVC Azért választottam ezt a keretrendszert mert korábban hallgatott tantárgy keretein belül megismerkedtem vele és a webes alkalmazások fejlesztését tapasztalataim szerint is gyorsabbá és kényelmesebbé teszi. Az egyik legelterjedtebb nyílt forrású keretrendszer a Java fejlesztők körében sikeressége az EJB modul helyettesítőjeként érte el. Előnye, hogy moduláris felépítésű így mindig csak azon részeit kell importálni, amelyekre a projektnek szüksége van. Ilyen modulok például az Inversion of Control konténer, adatkezelés és az MVC modul. Az Inversion of Control amelynek célja, hogy az objektumok életciklusát kezelje. Ennek a modulnak alapvető része a dependency injection, amelynek révén az objektumok egy kontextusba kerülnek regisztrálásra és innen válnak elérhetővé. A kontextusba való regisztráció történhet annotáció révén vagy konfigurációs állomány által, így ez könnyen cserélhetővé válik és a tesztelhetőségét is javítja az alkalmazásnak. Az adatkezelési modul támogatást biztosít a legnépszerűbb Java keretrendszerekhez úgy mint JDBC, ibatis/mybatis, Hibernate, JDO, JPA, Oracle TopLink, Apache OJB, és Apache Cayenne. Ezekhez a következő támogatásokat nyújtja: Erőforrás kezelés Kivétel kezelés Tranzakció kezelés Objektum transzformáció Absztrakció Az MVC keret webes alkalmazásokhoz készült kérés alapú megvalósítás, amelynek segítségével az alkalmazásban megkülönböztethetünk Model - View - Controller rétegeket. Ahol is a Model az adatkezelő, a View megjelenítő, Controller pedig az 13
ezeket összekötő réteg így elválasztva egymástól a megjelenítést és üzleti logikát. Az MVC architektúráját az alábbi 2.5 ábra szemlélteti. 2.5. ábra. Spring MVC architektúra 2.9. Eclipse A felsorolt alkalmazások elkészítéséhez az Eclipse IDE-t választottam mert Androidos fejlesztéshez és Spring alapú alkalmazások fejlesztéséhez testreszabható plugin készlettel rendelkezik. Ezek révén saját igényeknek megfelelő fejlesztő környezetet alakíthatunk ki. Összeköthető különböző alkalmazás szerverekkel így az elkészült webes alkalmazás rögtön buildelhető és kipróbálható. Androidos változata pedig a megfelelő SDK telepítése után felület szerkesztőt és telefon emulátort biztosít a fejlesztők számára. A beépülő pluginek révén alkalmas a projektek verziókövetésére, példák generálására, vékony és vastag kliensek készítésére. 2.10. SVN A dolgozathoz tartozó Androidos és webes projektek verziókövetéssel készültek. Erre a tanszék által biztosított SVN (Subversion) repositoryt használtam. Az SVN egy verziókezelő rendszer az Apache License alá tartozik. A CollabNet cég készítette el 2000-ben azzal a céllal, hogy a CVS (Concurrent Versions System) felvegye a versenyt. Ennek segítségével a fejlesztők forráskódokat, dokumentumoknak változását és történetét tudják tárolni és azt visszaállítani. Az SVNre jellemző például, hogy a Commit műveletek atomi szintűek. A törölt, átnevezett, mozgatott fájloknak és 14
könyvtáraknak is megtartja a történetét. A branch (elágaztatás) és taggek (jelölések) erőforrásigénye minimális. A repositoryra elérési út alapú jogosultságok ellenőrzése beállítható. 2.11. Continuous Integration Az elkészült alkalmazások teszteléséhez a tanszék biztosított egy virtuális gépet. Ezen a gépen alakítottam ki egy CI rendszert. Maga a CI egy szoftverfejlesztési gyakorlat, ami egy elterjedt agilis módszer. Egyik fő feladata az elkészült projektek automatizált buildelése és telepítése. Mindezek mellett persze több funkcionalitást is biztosítva a fejlesztőknek. Ilyen például a Unit tesztek futtatása és csak azok sikeressége esetén való telepítés. Verziókövető rendszerrel való integrációja melynek következtében egy előre beállított időközönként megnézi történt-e változás. Az esetleges hibákról értesítést küldhet a fejlesztőknek. Az alábbi 2.6 ábra egy ilyen folyamatot szemléltet. 2.6. ábra. Continuous Integration folyamat Azért döntöttem egy ilyen rendszer kiépítése mellett, mert a tanszéki virtuális gép elérése körülményes lett volna külső hálózatról. Hasonló problémával már egy tantárgy keretein belül találkoztam, ahol szintén egy ilyen rendszer kiépítésével és használatával oldottuk meg a feladatot. Egy ilyen Continuous Integration Serverhez a virtuális gépre egy Jenkinst telepítettem ami egy nyílt forrású Java eszköz. Eredetileg 2004- ben kezdték fejleszteni akkor még Hudson néven. A Jenkins konfigurálás után képes Maven projektek kezelésére és buildelésére. Valamint a megfelelő beépülők telepítésével képes az elkészült War fájlokat telepíteni az alkalmazás szerverre. 15
A Jenkinsben minden projekthez egy jobot kell definiálni amiben azt konfiguráljuk. Itt megadhatjuk, hogy SVNből töltse le a forrást. Beállíthatjuk Maven projekt esetén, hogy a szükséges globális konfigurációkat hol találja. Illetve itt adható meg, hogy az elkészült csomaggal mi történjen. Esetünkben például egy másik alkalmazás szerverre kerül telepítésre. A jobhoz tartozó minden buildelés napló fájlját tárolja így az visszakövethető. Az alábbi 2.7 kép a Jenkins főoldalát ábrázolja. Itt láthatjuk, hogy a jobok mikor futottak utoljára és milyen eredménnyel. 2.7. ábra. Jenkins főoldal 2.12. Tomcat A webes alkalmazás futtatására illetve a Jenkins számára is szükség volt egy - egy alkalmazás szerverre. Azért választottam a Tomcatet mert már három éve használom különböző projektek kapcsán. Gyorsan telepíthető és használatba vehető. Könnyen konfigurálható és integrálható az Eclipsebe is. A Tomcat egy az Apache Software Foundation által készített nyílt forrású webszerver és servlet konténer. A Java Servletek és Java Server Pagesek implementációját tartalmazza. Három fő komponensből áll. A Catalina servlet konténerből, Coyote HTTP konnektroból és a Jasper JSP motorból. 16
3. fejezet Létező megoldások 3.1. Távolság mérés Egyik lehetőség a távolság számítására az úgy nevezett ToA azaz Time of Arrival lenne. Az eljárás a jelek kibocsájtása és fogadása közötti idő alapján határozná meg a keresett távolságot az adók és vevők között. Működéséhez elengedhetetlen, hogy az adókban és a vevőkben lévő órák szinkronban legyenek. Másik alternatíva ha úgynevezett két utas megoldásként használjuk, hogy a vevő választ küld az adónak a vételről. Ezt az alternatívát gyakran használják, ha az órák szinkronizálása nem lehetséges. Az alkalmazásunk szempontjából viszont egyik ToA sem használható. Ennek oka, hogy a WiFi-s eszközökre ebben az esetben saját rendszer készítésére lenne szükség. A különböző típusú eszközök pedig tovább nehezítik egy ilyen rendszer elkészítését. 3.2. Háromszögelés A háromszögelés mint mérési eljárás már régóta használatos az élet különböző területein. Példának okán régen a hajók helyzetének megállapításához is használták ezt a módszert. Az alapja, hogy egy harmadik pont megállapításához legalább két ismert helyzetű pontra van szükség. Az alap eljáráshoz a felhasználó ismeri vagy legalábbis megtudja határozni az ismert pontokkal bezárt szögét. Ezt ábrázolja a 3.1 ábra. Az ábrához az alábbi képletek tartoznak. l = d tgα + d tgβ 17
3.1. ábra. Háromszögelés ábrázolása d = l 1 + 1 tgα tgβ A mi esetünkben azonban ez nem elegendő, mivel a mobilkészülékek nem rendelkeznek megfelelő antennával. a készüléknek. Így adott pontokkal bezárt szögét nem tudjuk meghatározni Ezért egy másik módszer szükséges, amely ezen adatok hiányába is képes a háromszögelést megvalósítani. Ez az úgynevezett trilateration[16][14] egy a geometriában használatos módszer amikor három pontra egy - egy gömbfelületet illesztünk. A gömbök sugarát az egyes pontoktól mért távolság határozza meg. A módszer lényege, hogy az általunk keresett pont a három pontra illesztett gömbfelületek metszéspontja. Ezt használják a GPS rendszerek is. A trilateration részletes leírását és matematikai hátterét az 5. Vizsgált módszerek fejezetben ismertetem. 3.3. Fingerprinting Más néven ujjlenyomat vételezés ez a leginkább elterjedt módszer[15][18][16], amelyet beltéri pozicionálásnál alkalmaznak. A módszer a rádió frekvenciás jelerősségeket használja fel egy fajta térkép elkészítéséhez. A módszer két lépésből áll, az első lépésben ki kell jelölnünk referencia pontokat. A pontokban elvégzett mérésekből egy adatbázist építünk, amely tartalmazza, hogy az egyes pontban melyik Wifi eszköztől milyen erősségű jelet vettünk. A második lépésben pedig az aktuális jelerősségekhez az adatbázisban tárolt adatok alapján kiszámítjuk a pozíciót. A módszer hátránya, hogy ha az adott infrastruktúra megváltozik, akkor a referencia pontokhoz tartozó adatbázist frissíteni kell. Újra el kell végezni az első fázist. Előnye viszont az eddig felsoroltakkal szemben, hogy beltérben a jelek visszaverődése nem befolyásolja az eredményt. 18
3.4. Magyarországi megoldások Magyarországon is találhatunk már elkészült beltéri alkalmazásokat. Az egyik legjelentősebb cég a BLUENION[4] cég, amely fejlesztésekkel és kutatásokkal foglalkozik a mobilalkalmazások területén. A cég több külföldi és hazai rendezvényre is biztosított már az általuk fejlesztett rendszer segítségével beltéri tájékozódást. Az alkalmazási területtől és feladattól függően általános vagy speciálisan fejlesztett eszközöket biztosítanak. A rendszer működéséhez WiFi, RFID és Bluetooth technológiát használnak. Az ANSWARE[3] Kft egy 2005-ben elnyert projekt kapcsán dolgozta ki prototípusait. A kutatás és fejlesztési projektben több egyetem bevonásával készítették el az RFID és WiFi alapú megoldásaikat. A további munkákat az egyetemek folytatták. 3.5. Külföldi megoldások Külföldön már korábban felismerték a beltéri pozicionálás jelentőségét, így olyan nagy vállalatok is bekapcsolódtak mint a Microsoft vagy a Google. Utóbbi még csak az épületek belső térképének nyilvánossá tételét biztosítja. A felhasználók feltölthetik a részletes szintekre bontott térképét egy épületnek. Így a Google térképen ránagyítva az épületre a belső térképe fog megjelenni. A Microsoft RADAR[11] egy fingerprinting alapú rendszer, amely a beltéri alkalmazhatóság lehetőségeit vizsgálta. A felhasználó pozíciójának, orientációjának és nyomonkövetésének feladatát elemezte olyan módszerekkel mint Euklideszi távolság, legközelebbi szomszéd (KNN) és terjedési modell. Az Ekahau[6] cég szintén RFID és WiFi alapú megoldást dolgozott ki. A cég RTLS (valós idejű pozícionáló rendszer) fejlesztett ki. Használatához saját WiFi és RFID eszközöket fejlesztettek ki. Ezek segítségével valósítják meg például kórházakban az életmenő készülékek helymeghatározását. Kidolgoztak egy biztonsági rendszert is iskolák számára, amivel követni tudják az eszközt viselő tanárokat és diákokat. Veszély esetén az eszközök által segítséget tudnak kérni a biztonsági szolgálattól vagy a rendőrségre is eljuttathatják a riasztást. A Navizon[8] WiFi két fajta megoldást dolgozott ki. Létrehozott egy Android és iphone alkalmazást, amellyel már meglévő WiFi infrastruktúrát lehet feltérképezni. A mérési adatokat a cég által biztosított rendszerbe küldik el az alkalmazások. Egy 19
másik alkalmazással pedig a valós idejű pozícionálás szintén a központi rendszeren keresztül történik. A másik megoldáshoz saját WiFi eszközöket készítettek, amelyek az aktív telefonok, laptopok és egyéb WiFi-s kézi eszközöket képes észlelni és behatárolni. Azokat követni épületen belül és a megfelelő alkalmazás megléte esetén kommunikációt is megvalósítanak. 20
4. fejezet Rendszerterv A módszerek kipróbálásához és azokhoz tartozó teszteredményeket kapjunk szükségünk volt egy adatbázisra, egy web szolgáltatásra és több mobilos alkalmazásra is. A most következőkben ezeknek leírását fogom bemutatni. Az alkalmazások készítésénél az alábbi kritériumok szerint jártam el. Modularitás megvalósítása, hogy a rendszer egyes részei könnyen cserélhetőek legyenek és bővíthetőek. Gyors rendelkezésre állás, hogy a rendszer minél gyorsabban használatba állítható legyen. A több felhasználó esetén a zavartalan működés. 4.1. Adatbázis Az adatbázis tárolja az alkalmazások számára szükséges RSSI (Received Signal Strength Indicator) értékeket és pozíció adatokat. Felhasználásukkal a beltéri helymeghatározás elvégezhető. Az adatbázis sémáját az alábbi 4.1 ábra mutatja be. Az adatbázis tábláinak leírása az 4.1-4.2-4.3 táblázatokban látható 4.1. ábra. Adatbázis modellje 21
4.1. táblázat. A Coordinate tábla tulajdonságai COORDINATE A pozícionáláshoz használt koordinátákat tároló tábla. Mezőnév Leírás id Azonosító X A pozíció X koordinátája Y A pozíció Y koordinátája Z A pozíció Z koordinátája 4.2. táblázat. Az Accesspoint tábla tulajdonságai ACCESSPOINT A wifi pontokat tároló tábla. Mezőnév Leírás id Azonosító name A router által közölt SSID macaddress Routerhez tartozó MAC cím coordinate A router pozíciója 4.3. táblázat. A Measurement tábla tulajdonságai MEASUREMENT A referencia pontokat tároló tábla. Mezőnév Leírás id Azonosító signalstrength Referencia pontban mért jelerősség (db) frequency A router által sugárzott jel frekvenciája distancefromcoordinate A jelerősségből és frekvenciából számolt távolság coordinate A referencia pont pozíciója accesspoint A jelet biztosító router 4.2. Webalkalmazás Azért, hogy az adatbázis könnyen kezelhető legyen, illetve hogy a mobil kliensek elérhessék az adatbázisban tárolt adatokat egy webes alkalmazásra van szükség. Ez az alkalmazás egy Maven-es multimodulos Spring-es alkalmazás. A következőkben az egyes modulokat részletezem. Az első modul, amely az alkalmazás működéséhez és az adatbázis objektumokhoz szükséges osztályokat tartalmazza valamint a szolgáltatások interfész leírását. Azon objektumokat, amelyek az adatbázis tábláit reprezentálják xml leírókból generálódnak a JAXB plugin által. Az így kapott osztályokat az alábbi 4.2 UML diagram ábrázolja. 22
4.2. ábra. Adatbázis táblákhoz tartozó osztály diagram Ahogy láthatjuk az osztályok teljes egészében illeszkednek az adatbázis sémához. Az API további osztályokat is tartalmaz, amelyek a web szolgáltatások működéséhez szükséges kérés / válasz objektumoknak felelnek meg. Ezen osztályokat a következő 4.3 UML diagram ábrázolja. 4.3. ábra. Kérés és válassz objektumok osztály diagram A ResponseObject osztály egy általános válasz osztály. Két adattaggal rendelkezik, az első response a kérés sikerességének vagy sikertelenségének értékét tartalmazza. A második message az esetleges válaszban küldendő üzenetet tartalmazza. A RequestF indp osition a pozíció keresésnek a kérés objektuma. A thresholdban tárolja küldi kliens, hogy milyen határértékkel számoljon a kereső metódus. A measurement a kliens által érzékelt WiFi-knek és a hozzájuk tartozó jelerősség értékek nek a listája. Ezen beküldött adatok alapján és az adatbázisban tárolt értékekkel számolva kapja vissza a keresett pozícióját a kliens. A talált pozíciókat az alkalmazás a ResponseP osition válasz objektumban küldi vissza a klienseknek. Ez tartalmazza a kérés sikerességét vagy sikertelenségét. Illetve két koordináta objektumot. Második réteg a Data Access Object más néven adat hozzáférési réteg. Ez tartalmazza az adatbázis kiépítéséhez szükséges SQL scripteket. Ahhoz, hogy a scriptek 23
automatizáltan lefussanak itt található a Liquibase plugin számára a konfigurációs xml. A fájl tartalma az alábbi 4.4 képen látható. 4.4. ábra. Liquibase konfigurációs xml Továbbá ebben a modulban találhatóak az SQL utasításokat leíró xml fájlok, amelyeknek a Java metódusokhoz való kötését a MyBatis végzi el. A fájlokban található resultm apek az összetett SQL lekérdezések eredményének osztályokra való leképzését írja le. Egy ilyenre ad példát az alábbi 4.5 ábra. 4.5. ábra. ResultMap példa Az egyes utasításokat az id attribútumokkal kötődnek a Java metódusokhoz. Az utasítások eredményét pedig a resultm ap határozza meg. Az utasítás bemenőparaméte rét a parametert ypeon keresztül adhatjuk meg. Az utasítások preparedstatementként kerülnek felhasználásra, ebben az esetben a paramétereket #{} formában kell megadni. Egy utasításra példát az alábbi 4.6 ábra mutat. 4.6. ábra. MyBatis - SQL utasítás minta 24
A Service réteg tartalmazza a szolgáltatás implementációkat valamint a MyBatishoz tartozó mapper osztályokat. Ezeken keresztül érhetőek el az SQL utasítások. A mapper osztályokban az SQLben felhasználandó paramétereket az alábbi formában kell megadni (@P aram( coordx )doublex. A service osztályok UML diagramját az alábbi 4.7 ábrán láthatjuk. 4.7. ábra. Service osztályok UML diagramja Ezen metódusok általános esetben az Insert / Delete / Update utasításokat valósítják meg. Ezeken felül a különböző lekérdezéseket megvalósító metódusok kerültek implementálásra. Az utolsó modul valósítja meg az eddigiek kapcsolatát. A kliensektől érkező kéréseket a Springes controller osztályokban annotált metódusok szolgálják ki. Az annotációkkal megadható, hogy milyen URL-en keresztül érhető el az adott metódus. Megadható melyik HTTP kéréseket szolgáljon ki, illetve mi legyen a visszatérési értéke. Egy ilyen metódusra példa az alábbi 4.8 ábra. 4.8. ábra. Spring controller Az alkalmazás JSP (JavaServer Pages) oldalakat is tartalmaz, amelyeken keresztül az egyes szolgáltatások és az adatbázis kapcsolat ellenőrizhető. 25
4.3. Kliensek A szolgáltatások használatához és a beltéri pozicionáláshoz ahogy már említettem Androidos klienseket terveztem. Ahhoz, hogy az alkalmazások a telefonba épített WiFi-t használhassák a Manifest fájlban engedélyezni kell azt. Továbbá minden alkalmazásban regisztrálni kell egy BroadcastReceiver-t amin keresztül a WiFi-s eszközök szkennelése megvalósul. Minden ilyen szkenneléssel egy listát kapunk az aktív hatótávolságon belüli eszközökről. A lista egy eleme az alábbi 4.4 táblázatba foglalt információkat hordozza. Adattag SSID BSSID Frequency Level Capabilites 4.4. táblázat. WifiInfo objektum tulajdonságai WifiInfo WiFi eszközről kapható információk Leírás Hálózat neve Az eszköz MAC címe A csatorna frekvenciája MHz-ben Az érzékelt jel dbm-ben Az eszközhöz tartozó authentikáció kulcs kezelés és encriptálási adatok. Mivel a WiFi jelek szkennelése időben változó hosszúságú így csak szinkronban végezhető a keresés. Mivel a mért jelek nem állandóak hanem ingadozóak, ezért a szerver felé a mérések átlagos értéke kerül elküldésre. Az alkalmazások gyorsabb tesztelése végett futásidőben beállításokon keresztül konfigurálhatóak a főbb paraméterek. 26
5. fejezet Vizsgált módszerek A két fő eljárás amiket implementáltam a beltérben való pozíció meghatározására a Trilateration és Fingerprinting. A következőkben ezen eljárásokhoz tartozó matematikai hátteret és az alternatív megoldásokat ismertetem. 5.1. Trilateration A Trilateration módszerrel, hogy megtaláljuk a keresett pontot meg kell határoznunk a három ponthoz tartozó gömböket és azok sugarait. Kezdeti lépésben az adott termet vagy szobát el kell helyeznünk egy koordináta rendszerben. A WiFi access pontok helyét ezen fix pontokként felvéve megkapjuk azok x, y és z koordinátáját. Ezek majd a végső képletben kerülnek felhasználásra. Erre példa az alábbi 5.1 kép. 5.1. ábra. Egy szoba vázlata 27
A képen is jól látható, hogy a keresett pontot ki tudjuk számolni, szükségünk van a három sugárra. A sugarak kiszámítására viszont korlátolt megoldás áll rendelkezésünkre. Ahogy már említettem a telefonokba épített antennák nem alkalmasak szögmérésre. Továbbá az eszközökkel való szinkronizáció sem megvalósítható. Ezért olyan távolság meghatározó módszereket kerestem, amelyek a rádiós jelek terjedésén alapszanak. 5.1.1. Hatótávolság mérés Az első módszerben az alábbi képletet használjuk a távolság, a sugarak kiszámítására: d i = p(1 m i ) Ahol is d i az i. wifi access pointtól való távolságot, p az adott wifi access point által biztosított lefedettséget méterben, m i pedig az adott wifi access pointról mért jel erősségét jelenti százalékban. Ezen módszer hátránya, hogy használható lehessen minden access pointról pontos hatótávolsági mérést kellene elvégezni. Mivel a gyártók által kiadott adatok a valós esetben eltérőek lehetnek. Ezért legfeljebb becslés szempontjából használható ez a megoldás. A jel hatótávolságát ugyanis befolyásolják az olyan tényezők, mint a jel útjába kerülő akadályok. Ezen akadályok anyagától függően más és más értékű csillapítással hatnak a jelre. Pár ilyen csillapítási értéket az alábbi 5.1 táblázat szemléltet. 5.1. táblázat. 2,4 GHz jel csillapítási értékek Anyag Csillapítás (db) Téglafal 6-12 Vastag vakolat 2-5 Betonfal 10-12 Ember 10-15 5.1.2. Jel terjedése A második módszer az úgynevezett free-space path loss röviden FSPL. Ezt az eljárást a telekommunikációban használják a jelerősségek kiszámítására adott távolság esetén. 28
Az alábbi egyenletet felhasználva: F SP L(dB) = 20 log 10 (d) + 20 log 10 (f) + constant Ahol is F SP L(dB) a kapott jelerősség db-ben, d a távolság, f a vizsgált jel frekvenciája, constant a jel frekvenciájának és a távolság függvényében konstans érték. A constant lehet 92.45 - ha f GHz és d kilométerben adott, 87.55 - ha f KHz és d méterben adott, 27.55 - ha f MHz és d méterben adott, 32.45 - ha f MHz és d kilométerben adott. 5.1.3. Működés Miután az egyik módszerrel meghatároztuk a keresett ponthoz képest a három WiFi távolságát, az alábbi egyenletrendszert kell megoldanunk. r 2 1 = x 2 + y 2 + z 2 r 2 2 = (x d) 2 + y 2 + z 2 r3 2 = (x i) 2 + (y j) 2 + z 2 Ezen három képlet alkotta egyenletrendszerből kell kifejeznünk az x, y és z koordinátákat. Először előszámításokat kell elvégeznünk, ugyanis ideális esetben a három WiFi úgy helyezkedne el, hogy az egyik az origóban lenne. A második az x tengelyen az elsőtől d távolságra, a harmadik pedig az x tengelyen i, az y tengelyen j távolságra. Egy ilyen ideális eset látható az alábbi 5.2 ábrán. 29
5.2. ábra. Trilateration idális eset De ez az eset ritka ezért szükségesek a számítások amikor is kitüntetünk egy pontot jelen esetben a P1-et, amelyhez majd a többi pontot viszonyítjuk. e x = P 2 P 1 P 2 P 1 ez lesz a P1-ből P2-be mutató egység vektor. ez a jelzett nagysága az x komponensnek. i = e x (P 3 P 1) e y = ez az y irányba vett egység vektor. P 3 P 1 i e x P 3 P 1 i e x A harmadik egység vektor pedig előáll az alábbi formában e z = e x e y A P1 és P2 pont távolsága nem lesz más mint d = P 2 P 1 j = e y (P 3 P 1) 30
ez pedig a jelzett nagysága az y komponensnek. Ezen számítások eredményeit behelyettesítve az alábbi megoldó képletbe megkapjuk a keresett koordinátákat. x = r2 1 r 2 2 + d 2 2d y = r2 1 r 2 3 + i 2 + j 2 2j i j x z = + r 2 1 x 2 y 2 Az így kapott koordináták viszont még nem az eredeti rendszerből valók. Ezért az alábbi számítást kell elvégezni rajtuk ahol is a három egység vektorral szorozva őket majd a P1 ponthoz hozzáadva megkapjuk az eredeti rendszerbe vissza transzformált koordinátáit a keresett pontunknak. p 1,2 = P 1 + x e x + y e y + z e z Így máris hozzájutottunk a mobilkészülék helyéhez. 5.1.4. Hátrány A módszer mindenkori hátránya, hogy a WiFi eszközöktől való pontos távolságot nem lehet megmondani. Nincs jelenleg olyan módszer, amelynek ne lenne egy bizonyos pontatlansága. Ez fakad a beltéri rádiós jelek terjedéséből és csillapításából. További hátránya ennek a módszernek, hogy működéséhez mindig három WiFi szükséges. Külön ben a számítások nem végezhetőek el. Ugyanakkor több mint három WiFi-vel sem képes számolni. Ezért olyan alternatívákat kerestem, melyek a WiFi-k számától függetlenül is működnek. 5.1.5. Genetikus algoritmus A genetikus algoritmus segítségével egy optimalizálási feladatot oldottam meg. A feladat során az aktuális pozícióhoz tartozó és a mért távolságok különbségét minimalizálom. Ezt az alábbi képlettel írhatom le: 31
[(d(a, D) 2 ) ((X a X D ) 2 + (Y a Y D ) 2 + (Z a Z D ) 2 )] min! a AP A függvény a WiFi pontonkénti mért távolságok négyzetének és a generált pontoknak jeladóktól számított Euklideszi távolságának a különbség összegét számítja ki. Az algoritmus minimum távolság elérésére törekszik a megadott létszámú populáció generálásával. A genetikus algoritmusnál konfigurálható, hogy mekkora létszámú populációt hány iterációban készítsen el. További paraméterei az elitek száma valamint a mutáció mértéke. 5.1.6. Szimulált lehűtés A genetikus algoritmus számítás igénye a populáció méretétől és az iterációk számától függően elég nagy is lehet. Ezzel lassulna a keresés is, ezért a szimulált hűtés módszerét választottam másik optimalizálási eljárásnak. A genetikushoz hasonlóan itt is ugyan azt a fitness függvényt használjuk. De itt egyszerre csak egy pont koordinátáival számolva, nem egy egész populációval. Az eljárás kezdetben generált ponttal vizsgálja a függvény értékét, majd a pontot mutáció segítségével elmozdítja és újra vizsgálja a függvény értéket. Annak jobb vagy rosszabb értéke alapján folytatja működését. Az eljárás paraméterei a kezdeti hőmérséklet és a lehűlés mértéke ezek határozzák meg, hogy hány darab vizsgálatot végezzen. 5.2. Fingerprinting Az eddig felsorolt módszereknél a WiFi-k helyét mindig pontosan kellett tudni, hogy számolhassunk velük. Továbbá a jelek csillapítása és visszaverődése a számolt eredmé nyeket erősen befolyásolta. Ezért egy olyan módszert is kipróbáltam, amelyiket ezek nem befolyásolják. Ez pedig a fingerprinting. Az eljárás megvalósításához először is a trilaterationhoz hasonlóan fel kell térképezni az épületet vagy szobát és referencia pontokat jelölünk ki. Ezután ezeken a pontokon méréseket végzünk, amelyek során rögzítjük, hogy adott pontban melyik WiFi-t látjuk. A rögzítéshez a mért jelerősségek átlagát minden szükséges adattal együtt tároljuk. Ezen adatokból felépített adatbázis 32
segítségével számítjuk ki a keresett pozíciókat. módszereket próbáltam ki. A pozíció kiszámításához az alábbi 5.2.1. Korreláció A korreláció két adatsor közötti lineáris kapcsolat nagyságát és irányát adja meg. A korreláció értéke -1 és +1 között változik. A képlete, amelyet felhasználtunk az alkalmazásban pedig az alábbi: r xy = n i=1 (x i x)(y i ȳ) (n 1)s x s y A képletben a x és a y az átlagokat jelölik. Az n az összehasonlítandó adatok darabszámát. A nevezőben pedig a két minta szórása található, melyeket az alábbi módon számoltunk ki: s x = n i=1 (x i x) 2 (n 1) A fenti képleteket felhasználva az adatbázisban letárolt mérési pontokra és a beérkező mérésekre kiszámoljuk a korrelációt. Azokat a korrelációkat vesszük figyelembe, amelyek egy bizonyos küszöbértéknél jobb eredménnyel rendelkeznek. Majd ezen mérésekhez tartozó koordinátákból kiszámítjuk a keresett pozíció koordinátáit. Ehhez az alábbi képleteket használtuk fel: x = corr(mi, a)(m ix ) corr(mi, a) y = corr(mi, a)(m iy ) corr(mi, a) Azaz vettük a küszöbértéknél nagyobb minták x és y koordinátáinak a korrelációjuk kal való szorzatának az összegét, melyet a korrelációk összegével osztunk. Ahol m i a tárolt méréseket míg az a a keresett pontban pillanatnyilag vett mérési értékeket jelöli. A küszöbértéken keresztül az eredmények finomíthatóak. További pontosítás az eredményekben a minták számának növelésével érhető el. 33
5.2.2. Euklideszi távolság A korreláció mellett a másik gyakran használt megoldás a fingerprinting[13][14][19] esetén, amikor a tárolt minták és az aktuálisan kapott jelek között kiszámoljuk a távolságot. Az így létrejött listából kiválaszthatjuk azt a pontot, amelyre legkisebb a távolság. Ennek kiszámítására az alábbi képletet használtuk fel: d = n (m isignal a signal ) 2 i=1 A képletben vesszük a tárolt mintákhoz tartozó jelerősséget és a keresett pontban mért jelerősségek különbségének négyzetösszegéből vont négyzetgyököt. A távolság értékek a tárolt átlagos minták miatt nem feltétlen a pontos pozícióban lesz a legkisebb. Ezért az n darab legkisebb távolságú mintából számítottuk a koordinátákat átlagolással. 5.2.3. Hátrány A fingerprinting legnagyobb hátránya az időigényesség. Ugyanis egy teljes épület felmérése rengeteg időt vehet igénybe. Attól függően, hogy milyen sűrűn szeretnénk mérési pontokat. További hátránya, hogy ha egy WiFi eszköz cserére vagy áthelyezésre kerül, akkor a teljes adatbázist frissíteni kell. Ugyanakkor ha nagyobb átrendezések történnek az épületen belül akkor is ajánlott az adatbázis frissítése. 34
6. fejezet Eredmények Az elkészült alkalmazások segítségével mind a Trilateration mind pedig a Fingerpinting módszer kipróbálhatóvá vált. A tesztelések során kapott eredményeket az alábbiakban fejtem ki. 6.1. Trilateration Az első módszer amihez elkészült a mobil alkalmazás. A módszer kipróbálásához egy nagy teremre volt szükség, ahol a tesztkörnyezetet ki tudtam építeni. Az Egri Történeti Tárház főtermében került erre sor, amely 17,05 méter hosszú és 5,14 méter széles. A terem alaprajza az alábbi 6.1 ábrán látható. 6.1. ábra. Történeti Tárház - Első terem alaprajza A mérések során az alábbi készülékeket használtam fel: Mérést végző készülék: Vodafone Smart III AP1 - TP-Link WR740N AP2 - TP-Link WR720N 35
WiFi alapu belte ri poziciona la si Mo dszerek Vizsga lata AP3 - TP-Link WR841ND A ha rom elhelyezett WiFi-t a ke k pontok jelo lik. A terem felme re se uta n meghata roztam a hozza juk ta rsı thato koordina ta kat, ezeket a 6.1 ta bla zat tartalmazza. A koordina ta k centime terben e rtendo k. 6.1. ta bla zat. A WiFik pozı cio ja WiFi Koordina ta AP1 (70,340,100) AP2 (37,1625,210) AP3 (477, 1450,210) A me re st a teremben tı z darab kijelo lt ponton ve geztem el, amelyeket a piros pontok jelo lnek a ke pen. 6.1.1. Mobil alkalmaza s A mo dszerhez elke szı tett mobil alkalmaza s maga ban foglalja a Trilateration, Genetikus Algoritmus e s a Szimula lt lehu te shez szu kse ges implementa cio kat. Az alkalmaza s futa sido ben konfigura lhato. Megadhatjuk, hogy mely mo dszerrel hata rozza meg a pozı cio t. Tova bba a genetikus algoritmushoz megadhatjuk a popula cio me rete t, itera cio k sza ma t, elitek sza ma t, muta cio me rte ke t. A szimula lt lehu te s re sze ro l bea llı t hato a kezdeti ho me rse klet e s a lehu le s me rte ke. Az alkalmaza sban elhelyeze sre keru lt egy te rke pes mo d. Ebben az esetben a kiva lasztott mo dszerrel az alkalmaza s folyamatosan me r. A kapott eredme nyt a WiFi-kel egyu tt megjelenı ti a kijelzo n. Az alkalmaza s fo bb ke pernyo it az ala bbi 6.2 ke p mutatja be sorban. 6.2. a bra. Trilateration alkalmaza s ke pernyo i 36
6.1.2. Trilateration - Első mérés Az első mérés eredményeit az eredeti trilateration módszerrel számoltattam ki. Ezen mérési eredményeket az alábbi 6.2 táblázatból olvashatjuk le. Az adatok centiméterben vannak megadva. 6.2. táblázat. Trilateration mérési eredmények Referencia pont Számított pont Hibák Távolság X Y X Y X Y 330 646-61 973 391 327 509,71 186 884 522 863 336 21 336,65 254 1156 138 965 116 191 223,4 50 1156 103 968 53 188 195,32 186 1292 170 1223 16 69 70,83 390 1394 119 1184 271 210 342,84 186 1530 37 988 149 542 562,10 322 1530 82 1066 240 464 522,39 412 1700 54 1099 358 601 699,54 356 201-487 755 843 554 1008,74 Min: 16 21 70,83 Max: 843 601 1008,74 Disp: 274,88 Avg: 447,16 Az eredményekből megállapítható, hogy a terem közepe felé haladva az eredmények pontosabbak. Míg a terem szélén a falaknál a mérések sokkal pontatlanabbak. Az átlagos eltérés valamivel több mint 4 méter (447,16 cm). 6.1.3. Genetikus Algoritmus - Második mérés A második mérést a Genetikus Algoritmussal végeztem el. A mérési eredményeket az alábbi 6.3 táblázat tartalmazza. Az adatok centiméterben vannak megadva. A táblázatból kitűnik, hogy a mérési eredmények rosszabb értékeket mutatnak. A mérési pontokban az átlagos eltérés közel 5 méter (504,36 cm). 6.1.4. Szimulált lehűtés - Harmadik mérés Ehhez a módszerhez tartozó méréseket az alábbi 6.4 táblázat foglalja össze. Az adatok centiméterben vannak megadva. 37
6.3. táblázat. Genetikus Algoritmus mérési eredmények Referencia pont Számított pont Hibák Távolság X Y X Y X Y 330 646 148 882 182 236 298,02 186 884 31 367 155 517 539,73 254 1156 145 1118 109 38 115,43 50 1156 110 1082 60 74 95,26 186 1292 142 913 44 379 381,54 390 1394 157 1081 233 313 390,20 186 1530-14 1354 200 176 266,41 322 1530 164 746 158 784 799,76 412 1700 86 838 326 862 921,58 356 201 180 1424 176 1223 1235,59 Min: 44 38 Max: 326 1223 Disp: 371,66 Avg: 504,36 6.4. táblázat. Szimulált lehűtés mérési eredmények Referencia pont Számított pont Hibák Távolság X Y X Y X Y 330 646 135 1011 195 365 413,82 186 884 274 944 88 60 106,50 254 1156 173 1019 81 137 159,15 50 1156 166 1017 116 139 181,04 186 1292 190 1208 4 84 84,09 390 1394 175 1169 215 225 311,20 186 1530 158 1032 28 498 498,78 322 1530 167 1081 155 449 475,00 412 1700 160 1101 252 599 649,84 356 201-123 767 479 566 741,48 Min: 4 60 84,09 Max: 479 599 741,48 Disp: 230,94 Avg: 362,10 A táblázatot megvizsgálva láthatjuk, hogy az eredmények a második méréshez képest jobbak. De az eredeti trilateration módszernél is pontosabbak. Ezzel a módszer rel az átlagos eltérés már csak 3,5 méter (362,10 cm) volt a referencia pontonként. 38
6.1.5. Összegzés A trilateration alapú mérések elvégzése során bebizonyosodott, hogy a módszert erősen befolyásolják a jelre gyakorolt külső tényezők. A csillapításokból és a visszaverődésből adódó eltérések több méteres pontatlanságot okoznak. A mérések során próbáltam a tesztkörnyezetet változtatni a jobb eredmények elérése végett. Ezért próbáltam a WiFi-k áthelyezésével javítani az eredményeket, de ez nem hozott érdembeli javulást. Továbbiakban próbálkoztam még a WiFi-k különféle konfigurációjával is, de ez szintén nem változtatott az eredményeken. 6.2. Fingerprinting A fingerprintinghez tartozó méréseket már egy másik helyszínen az Informatika épület első emeletén végeztem el. A tesztkörnyezethez az alábbi eszközöket használtam fel. IITAP1 IITAP2 D-link-measure - D-Link Dir825 Ciscob-measure Az épület felmérésében és az eljárás tesztelésében a Vodafone Smart III telefont használtam. Az első emeleten méterenként jelöltünk ki mérési pontokat. Ezekben a pontokban végeztük el a referencia méréseket. Az így kapott referencia pont térképet az alábbi 6.3 ábrán láthatjuk. A pontokban végzett mérések során az alkalmazás 50 darab mintavételezést hajtott végre. Az 50 minták átlagát pedig a web servicen keresztül kerültek mentésre. A service ezen adatok közül kiválasztotta azon WiFi-khez tartozó mintákat amiket menteni kell. Ezek a fent felsorolt 4 eszközök voltak. Így állt elő az adatbázis. Továbbá a pozíció keresésen felül az adatbázisban tárolt adatokból generálhatunk az egyes eszközökhöz jelerősség térképet. A négy WiFihez tartozó jelerősség térképek az alábbi 6.4 ábrán láthatóak. Az ábra segítségével megállapíthatjuk, hogy az IITAP2 az előtérben már nem biztosít láthatóságot. Ugyanakkor látható, hogy néha érzékeltünk jelet az IITAP2-től. Ez 39
WiFi alapu belte ri poziciona la si Mo dszerek Vizsga lata 6.3. a bra. Az Informatika e pu let referencia pontjai 6.4. a bra. WiFik jelero sse g te rke pei a folyoso ajtaja nak nyita sa nak tudhato be. Viszont ez az ingadoza s a poziciona la st befolya solhatja majd. A te rke pro l mega llapı thato me g, hogy a ma sik ilyen gyenge re sz az e pu letben az az o sszeko to folyoso. Itt pe lda ul ma r a ke t elo te rben elhelyezett WiFi jelei voltak alig me rheto ek. Itt is a ke t ajto ami a jelek csillapı ta sa t okozta e s okozhatja. A ne gy WiFi-ro l kapott jelte rke peket egybevetve mega llapı thatjuk, hogy a tantermek felo li folyoso illetve az elo te r lefedettse ge ko zel folytonos. Ez pedig egy rendkı vu l fontos te nyezo a belte ri poziciona la s esete ben. Egy e pu let elo zetes felme re se, illetve a WiFi-k 40