Budapesti Műszaki és Gazdaságtudományi Egyetem, Villamosmérnöki és Informatikai Kar
TDK dolgozat
Objektumok beltéri követését végző ZigBee hálózat telepítő eszközzel Lengyel Zoltán VI. villamosmérnök hallgató Egyetemi konzulensek: Bánky Tamás és Csörnyei Márk Szélessávú Hírközlés és Villamosságtan Tanszék Ipari konzulens: Fejes Péter - Cason Mérnöki Zrt. 2008. október
1. Bevezetés 2. Igények beltéri követő rendszerekre 3. A szenzorhálózat 3.1. Mozgó eszközök 3.1.1. Azonosító hirdetése 3.1.2. Elemes működés, alacsony fogyasztás 3.1.3. Szenzor
3.2. Koordinátorok és routerek
2 4 5 5 5 5 6
7
3.2.1. Hálózati szerepek 3.2.2. Kommunikáció a szerverrel 3.2.3. A routerek üzenetei 3.2.4. Referencia egységek sűrűsége, hálózati forgalom, költség 3.2.5. A koordinátorok cirkuláris buffere
3.3. A telepítés kérdése
7 7 8 8 8
9
3.3.1. Referencia koordináták 3.3.2. A követés területének lefedése
3.4. Megfontolások a hálózat működésével kapcsolatban 3.4.1. Centralizált feldolgozás és centralizált hálózat 3.4.2. A centralizált hálózat felosztása 3.4.3. Elosztott feldolgozás és centralizált hálózat 3.4.4. Kooperativ lokalizációs hálózat
4. SQL adatbázis 5. Lokalizáció, objektumok követése 5.1. A lokalizáció eszköze – LQI 5.2. A számítás helye 5.3. Kiszolgált kérések 5.4. Lehetséges algoritmusok 5.4.1. Signpost 5.4.2. ML algoritmus 54.3. RF mintával való összevetés 5.4.4. A Signpost algoritmus tovább fejlesztése
6. Az eredmények megjelenítése webes felhasználói felületen 7. Telepítő eszköz 7.1. A telepíthetőség igénye és feladatai 7.2. A telepítés munkafolyamatának kérdései 7.3. Követelmények a telepítő eszközzel szemben 7.4. Telepítő üzemmód és ZigBee hálózat üzemmód 7.5. A telepítés munkafolyamata 7.6. A telepítő eszköz hardvere 7.7. A telepítő eszköz szoftvere és protokollja 7.8. Telepítő eszköz grafikus felülete PDA-n
8. Összegzés, értékelés, kitekintés 9. Irodalomjegyzék
9 9 10 10 11 11 13 13 16 16 17 17 18 18 20 20 20 21 23 23 24 24 25 26 29 30 33 42 44
1
1. Bevezetés Vagyontárgyak és személyek követését végző rendszerek egyre szélesebb köre kerül alkalmazásra. A Cason Mérnöki Zrt. [8] flottakövető rendszerének célja mozgó objektumok (járművek, ipari vagy veszélyes környezetben munkát végző személyek) nagy felbontású, valós idejű megfigyelése. A GPRS kommunikáció a valós idejű megfigyelést, a GPS pedig a nagy felbontású helymeghatározást biztosítja. Felmerül azonban az igény olyan beltéri alkalmazásokra is, ahol a GPS helymeghatározás és a GPRS kommunikáció nem lehetséges, illetve magas fogyasztása miatt nem megengedhető a mozgó objektumok számára. Alacsony fogyasztású mozgó eszközök követésére nyújt lehetőséget egy olyan ZigBee, illetve IEEE 802.15.4-es szabványnak megfelelő szenzorhálózat alkalmazása, mely az alábbi két részre osztható: 1. Statikus hálózat: Helyhez kötött, ismert pozíciójú ZigBee routerek és koordinátorok, melyek a 2007-es ZigBee szabvány (stack profile 1) szerint működnek és hálózati tápellátást igényelnek. 2. Mozgó eszközök: Mozgó, ismeretlen helyzetű, egyedi azonosítójukat hirdető, alacsony fogyasztású, elemes eszközök, melyek a 802.15.4-es IEEE szabványnak megfelelően kommunikálnak. Az álló hálózati routerek és koordinátorok a mozgó csomópontok hirdetett azonosítóit és a hozzájuk tartozó RSSI / LQI (Received Signal Strength Indicator / Link Quality Indicator) ([1], 6.9.8.) értékeket regisztrálják. Csak a koordinátorok rendelkeznek egy GPRS GPRS
Fogadó Program
GPRS GPRS
ZigBee hálózat
SQL DB Telepítő eszköz
Silverlight alkalmazás Web szervíz
Demo szerver internet
ZigBee koordinátorok Routerek Mozgó eszközök Épületek
Felhasználói interfész
1. ábra – A megvalósított teljes rendszer
2
GPRS – ZigBee átjáró funkcionalitásával, a routerek a mért értékeket a koordinátor irányába továbbítják a hálózaton át. A mért adatok SQL adatbázisba kerülnek és szerver oldalon futó algoritmusok segítségével értékelődnek ki, majd az eredmények webes felhasználói felületen jelennek meg.
A követő rendszerben a következő komponenseket valósítottam meg: 1. Mozgó eszközök teljes szoftverének megvalósítása. (lásd 3.) 2. Routereken levő alkalmazás, mely a ZigBee protokoll stack felett fut. (lásd 3.) 3. Koordinátoron levő alkalmazás, mely a ZigBee protokoll stack felett fut. (lásd 3.) A koordinátoron levő GPRS átjáróként a Cason Zrt. kész modulját használtam. A firmware-eket a Cason kész hardver eszközeire és a Freescale Semiconductor demo paneljeire készítettem el. 4. SQL adatbázis építés, tárolt eljárások létrehozása az adatbázisban. (lásd 4-5.) 5. Web szervízek megírása. A 4-5. implementálja a lokalizációs algoritmust. (lásd 5.) 6. Webes felhasználói felület megalkotása Silverlight platformra. (lásd 6.) 7. Telepítő eszköz megvalósítása bármilyen ZigBee hálózat telepítésére. (lásd 7.) Dolgozatom fókuszában a hálózat, illetve annak telepítése áll, emellett röviden bemutatásra kerül a rendszer valamennyi komponense. Törekedtem arra, hogy a legtöbb megvalósított komponenst összehasonlítsam más megoldásokkal is.
3
2. Igények beltéri követő rendszerekre Az alábbi fejezetben példákon keresztül mutatom be, hogy milyen esetekben lehet igény beltéri követő rendszerek alkalmazására, illetve mikor célszerű alkalmazni őket. 2.1. példa – targoncák követése ipari területen Körülmények: Egy gyár területén 30 targonca dolgozik. A gyár több épületből és egy parkból áll, a teljes terület zónákra osztható. A zónák között a targoncák megadott útvonalon közlekedhetnek. A követő rendszer nyújtotta lehetőségek: A követő rendszernek meg kell tudnia állapítani, hogy az egyes targoncák milyen zónában tartózkodnak. Szeretnénk tudni az egyes targoncák kihasználtságát és azt, hogy a töltést igénylő járművek mennyi időt töltenek a targonca töltőben. Gyakran fordul elő, hogy egy tetszőleges, nem használt targoncára van szükség – egy jól működő követő rendszer képes megmondani azt is, hogy hol van szabadon felhasználható jármű. Ha egy targonca meghibásodik vagy lemerül képes a ZigBee hálózaton keresztül értesíteni a központot, ami tudja azt, hogy melyik zónában tartózkodik az adott jármű. Ha a targoncákat össze tudjuk valamilyen módon párosítani a dolgozókkal dinamikus módon, akkor kiderül az is, hogy az egyes munkások éppen hol tartózkodnak. 2.2. példa – pénzes dobozok követése Körülmények: A pénzszállító autó megáll a bank előtt. Az autóból kipakolt pénzes dobozoknak el kell jutnia a parkolóból a széfekig. A követő rendszer nyújtotta lehetőségek: A pénzes dobozok követése a parkolótól a széfekig, az egyes széfekig elért dobozok felvétele a nyilvántartásba. A pénzszállító autó útvonalát egy GPS-en alapuló pozicionáló rendszer követhette a bankig. A bank épületében elhelyezett ZigBee hálózaton alapuló rendszer végig követheti a dobozok útját a széfekig. 2.3. példa – biztonsági emberek követése Körülmények: A biztonsági őrök feladata egy adott épület együttes területén előírt útvonalon való őrjárat. A követő rendszer nyújtotta lehetőségek: Az őrök bejárt útvonala rögzítésre kerül. Az őrök riaszthatják a ZigBee hálózaton keresztül a központot, ha rendellenes jelenséget észlelnek. Ez utóbbi esetben nemcsak a riasztás kerül fel a központba, hanem a riasztás helye is.
4
3. A szenzorhálózat 3.1. Mozgó eszközök 3.1.1. Azonosító hirdetése A mozgó eszközök azonosítóikat (64 bites IEEE cím) hirdetik meghatározott időközönként az IEEE 802.15.4-es szabványnak megfelelően ([1], 5.3.) A követő ZigBee hálózat routerei és koordinátorai ezeket az azonosítókat és a hozzá tartozó RSSI / LQI értékeket regisztrálják. LQI: A vett jel térerősségével van összefüggésben az LQI (Link Quality Indicator), melyet a ZigBee chip modeme számít ki vételkor. 36 és 190 közötti értéket vesznek fel, a vett jel erőssége dBm-ben durván: - LQI / 2. Az LQI felhasználásának megfontolásait az 5.1. rész tartalmazza. Az IEEE 802.15.4-es szabványnak megfelelő üzenetek beltérben kb. 10 méteren belül hallhatóak, de a 10 méter csak egy tájékoztató jellegű adat, a hatótávolság erősen függ a környezettől és magától az adótól és a vevőtől is (lásd 5.) Küldési gyakoriság: Minél gyakrabban hirdeti egy mozgó eszköz az azonosítóját, annál pontosabb képünk lehet a bejárt útvonaláról, azonban annál nagyobb hálózati és GPRS forgalmat generál és annál magasabb az átlagfogyasztása is. Egy kompromisszumos megoldást kell hoznunk tehát a pontosságot, az árat és a fogyasztást figyelembe véve. Gyorsabban mozgó eszközök adott pontosságú követéséhez nagyobb küldési gyakoriságra van szükség, mint lassabban mozgó eszközök ugyanolyan pontosságú követéséhez. Küldési gyakoriság Fogyasztás Hálózati forgalom GPRS - költség Pontosság ++ ++ ++ ++ ++ 1. táblázat – A küldési gyakoriság növelésének hatása A mobil egységek adóteljesítményének csökkentésével szintén pontosabb eredményre juthatunk, mert így kevesebb referencia router hallja egyszerre a hirdetett üzeneteket. Így viszont az alkalmazás területének lefedéséhez nagyobb számú routerre lesz szükség. Fontos hangsúlyozni, hogy egy mobil egység körülbelüli helyét már akkor meghatározhatjuk, ha tudjuk, hogy egy adott pillanatban milyen referencia csomópontok hallották. A térerősség mérések felhasználása csak ezt az eredményt igyekszik pontosítani. 3.1.2. Elemes működés, alacsony fogyasztás A legtöbb ipari alkalmazás során a mozgó eszközök töltésére ill. gyakori elemcserére nincs lehetőség. Ideális esetben a rendszer bevezetésekor a mozgó eszközök aktiválásra kerülnek és csak évek múltán van igény elemcserére. Ez idő alatt a mozgó eszközök hordozói (a követett objektumok) tetszőleges időközönként változhatnak. A mikrokontrollerre olyan szoftvert írtam, melynek átlagfogyasztása 5 másodpercenkénti 5
azonosító hirdetés esetén 35 uA. Alvó állapotában 1 uA-es fogyasztással számolhatunk. Ez az egyik olyan tulajdonság, ami biztosítja a rendszer előnyét ipari célú alkalmazásoknál a több 10 mA-t fogyasztó GPS modulokkal szemben. 3.1.3. Szenzor A mozgó egységeken rezgésszenzor található, mely mozgás esetén impulzusokat generál a mikrokontroller bemenetén, statikus esetben a bemenetet a földre húzza. A szenzor mért jellemzője (mozgás vagy statikus eset) az azonosítóval és a hirdetett üzenet szekvencia számával együtt kerül hirdetésre. Amennyiben a node mozog, adhatja az azonosítóját gyakrabban a pontosabb követés érdekében. Amennyiben statikus állapotban van, hirdetheti azonosítóját ritkábban, ezzel kedvezőbb energia felhasználást 2. ábra – ZigBee Core modul – érhetünk el anélkül, hogy a bejárt a mozgó eszköz hardvere útvonalról pontatlanabb képet kapnánk. 2 fajta firmware verziót valósítottam meg: 1. Mozgás esetén 3 másodperces, statikus esetben 5 másodperces küldés (bal oldali ábra) 2. Kifejlesztettem egy olyan verziót is, amikor a mozgó node csak akkor hirdeti azonosítóját, ha mozgásban van (jobb oldali ábra).
3 másodperces nem megszakítható alvás, 1 uA
2 másodperces mozgás által megszakítható alvás
Szenzor által megszakítható (végtelen) alvás, 1 uA
I Szenzor Interrupt
10 ciklus vége?
N Interrupt
Üzenet küldés (ébrenlét), 6.5 mA + 30 mA
Szekvencia szám ++ (ébrenlét), 6.5 mA
1 másodperces nem megszakítható alvás, 1 uA
Üzenet küldés (ébrenlét), 6.5 mA + 30 mA
3. ábra – Megvalósított firmware tervek áramfelvétel adatokkal
6
A hirdetett üzenetekben tehát egy 64 bites MAC cím, egy 16 bites szekvencia szám és a szenzor mért jellemzője található, melyre 8 bitet allokáltam. Ez utóbbi mező tartalmazhat más információt is, pl.: ha a mozgó entitás riasztást adott le a központba. Hardware: A Cason Mérnöki Zrt. ZigBee Core (2. ábra) és ZiBee CC eszközei, melyek a Freescale Semiconductor MC13213-as ZigBee Chipjeit tartalmazzák. A MC13213-as SiP (system in package) chip egy HCS08-as 8 bites mikrokontrollert és egy MC13192-es rádiós modult tartalmaz. [7] Firmware: A ZigBee Core (2. ábra) és a ZigBee CC panelekre saját fejlesztésű firmware került. (3. ábra)
3.2. Koordinátorok és routerek 3.2.1. Hálózati szerepek A ZigBee koordinátor felelős a PAN (Personal Area Network) létrehozásáért, az eszközök nyilvántartásáért, a hálózat fontos paramétereinek meghatározásáért. A hálózat méretét routerek terjesztik ki, melyek az üzenetek továbbítását végzik hierarchikus fa vagy mesh routing szerint. ([2], 1.1.4) A követő alkalmazás routerei ismert helyzetű referencia egységek. A 2007-es ZigBee szabványnak megfelelően hálózati tápellátást igényelnek és alvásra nincsen lehetőségük. 3.2.2. Kommunikáció a szerverrel A routerek feladata a mozgó eszközöktől elkapott üzenetek továbbítása a koordinátorok (a hálózat 0x00-s című node-ja) irányába, ez a továbbított csomag tartalmazza a mozgó egység címét, a router címét és a vételhez tartozó LQI értéket. ZigBee koordinátorok Routerek Mozgó eszközök Hirdetett azonosító 4. ábra – Kommunikáció a követő hálózatban
Azonosító pár LQI-vel
A routerek meghatározott időközönként egy-egy “alive” üzenetet is küldenek a koordinátornak, melyet diagnosztikai célokra lehet felhasználni. A GPRS átjárót a koordinátorok valósítják meg. A szerveren futó fogadó programmal való kommunikáció UDP szállítási protokoll szerint zajlik. 3.2.3. A routerek üzenetei A routerek ZigBee csomagjainak APS (Appcliation Support Sublayer) keretébe ([2], 2.2.5.2 ) kerülnek az alkalmazás szintű üzenetek. Az alábbi üzenet kerül kiküldésre egy routertől, ha elkapta egy mozgó objektum hirdetett üzenetét: Üzenet típusa: Mozgó node Router LQI (vett Vett üzenet Szenzor 0x00 címe címe üzeneté) szekvencia száma 1 byte 8 byte 8 byte 1 byte 2 byte 1 byte 2. táblázat – A router követési üzenetének mezői az APS szintű keretben
7
Adatbázisban letárolt tracking üzeneteket a 14. ábra mutat. Alive üzenet: 70 másodpercenként küldenek a routerek alive üzenetet, melynek felépítése a következő: Üzenet típusa: 0x01 Router címe 1 byte 8 byte 3. táblázat – A router alive üzenetének mezői az APS szintű keretben Adatbázisban letárolt üzeneteket a 15. ábra mutat. 3.2.4. Referencia egységek sűrűsége, hálózati forgalom, költség A mozgó egységek küldési gyakoriságához hasonlóan kompromisszumos megoldáshoz kell jutnunk a referencia routerek sűrűségét illetően. Minél sűrűbben helyezzük el a referenciákat, annál nagyobb az esélyünk arra, hogy pontosabb képünk lesz a mobil eszközök bejárt útvonaláról. Ezzel együtt a hálózati forgalom is nagyobb, és magasabb kommunikációs költséggel kell számolnunk. Háromszögelésen alapuló algoritmus esetén elvárható, hogy mindig legalább 3 referencia hallja az egyes mobil egységeket. [6] Pontosság Hálózati forgalom GPRS - költség ++ ++ ++ ++ 4. táblázat – A referencia egységek sűrűségének növelése
Referencia node-ok sűrűsége
3.2.5. Koordinátorok cirkuláris buffere A koordinátorok egy cirkuláris buffert tartanak fenn, melybe a routerek és koordinátorok elkapott üzenetei kerülnek. Innen kerülnek ki soros vonalon a Diwicon 3x00 áramkörön levő átjáróba, amely a szerverrel tartja a kapcsolatot. A buffer 40 üzenet átmeneti tárolására alkalmas. Hardware: A routereket és a koordinátorokat a Cason Mérnöki Zrt. Diwicon 3x00 eszközei valósítják meg, melyek a Freescale Semiconductor MC13213-as ZigBee Chipjeit tartalmazzák. A koordinátorok áramköre GPRS átjárót is integrál. A HCS08-as mikrokontroller és az átjáró között soros kommunikáció valósul meg. Firmware: A hálózati eszközökön a Freescale ZigBee stackje (BeeStack 2.0, stack profile 1) található [13]. A BeeStack alkalmazási rétegébe saját fejlesztésű alkalmazás került.
5. ábra – ZigBee koordinátor és GPRS átjáró
8
6. ábra – Egy mozgó objektum jeleinek csillapítása átlagos irodai környezetben [5] A 6.ábrán látható, hogy a zöld mozgó egység hirdetett üzenete irodai környezetben mekkora csillapítással jut el az épület különböző szektoraiba. Az MC13192-es ZigBee modem vevőjének érzékenysége -95 dBm, így ha az adóteljesímény 0 dBm, akkor a sötétkék és lila helyeken levő hálózati elemek biztos, hogy nem is hallják a mobil egységet. Ha az adó teljesítmény -20dBm, akkor pedig csak a zöld és piros színnel festett zónákkal kell számolnunk. A legnagyobb LQI értékeket figyelembe véve egy lokalizációs algoritmussal meghatározható, hogy a node a piros színnel jelzett zónában van.
3.3. A telepítés kérdése 3.3.1. Referencia koordináták A szerveren tehát elérhető számunkra az, hogy az egyes mozgó egységek azonosítóit milyen routerek és koordinátorok hallották és milyen erősséggel. Ahhoz azonban, hogy ebből az információ halmazból megállapítsuk, hogy a mobil eszközök milyen útvonalon haladnak, azt is tudnunk kell, hogy a routerek és a koordinátorok fizikailag hol helyezkednek el. Ehhez egy tudatos, jól definiált protokollal rendelkező telepítési folyamatra van szükség, mely során a telepített hálózati eszközök (a referencia routerek) helye felkerül az adatbázisba. 3.3.2. A követés területének lefedése Egy telepítő eszköz használatát egy további fontos szempont is megköveteli. A követés területe az a terület, amelyen belül mozgó eszközeinket a hálózati routerek és koordinátorok megfelelő minőséggel hallják. Telepítéskor a hálózati eszközöket úgy kell elhelyezni, hogy a követési területen belül tartózkodó mobil eszközök valóban hallhatóak legyenek a statikus hálózat számára. Ebben segít egy olyan telepítő eszköz használata, mely alkalmas térerősség mérések elvégzésére. A telepítés általános kérdéseivel és a fejlesztett telepítő eszközzel dolgozatom 7. fejezete foglalkozik.
9
3.4. Megfontolások a hálózat működésével kapcsolatban 3.4.1. Centralizált feldolgozás és centralizált hálózat A megvalósított hálózatban az üzenetek a koordinátor felé áramlanak, a feldolgozás a szerveren történik. Koordinátorok és routerek (referencia) Mozgó eszközök Szerver 7. ábra – Üzenetek áramlása a centralizált hálózatban [3]
3.4.1.1. Előnyök a.) A mozgó eszközök fogyasztása: Alacsony fogyasztású mozgó node-ok megvalósítása érhető el. A megvalósított elrendezés szerint a mobil eszközök meghatározott időközönként ébrednek fel és adnak egy-egy azonosítót, csak az adás idejére vannak ébren. Nincs szükség arra, hogy rádiójukat vételi üzemmódba állítsák, ez nagy előnyt jelent fogyasztás szempontjából, mert a ZigBee chipek rádiói vételi üzemmódban fogyasztanak a legtöbbet (37 mA) ([7], 3.11.5). b.) Az algoritmus helye: A szerverre kerülnek a router és mozgó node azonosító párok, vett jel térerősséggel ellátva. (Adatbázisban letárolt tracking üzeneteket a 14. ábra mutat.) A nagy számítási kapacitással rendelkező szerver feladata, hogy ezekből az adatokból kiszámítsa a mozgó eszköz helyét. Ha az algoritmus a szerveren – az adatbázisban levő tárolt eljárásokban ill. a szerveren levő web szervízekben – van implementálva, rugalmasan változtatható és fejleszthető anélkül, hogy a hálózati eszközök firmware-jét frissíteni kellene. Akár 2 különböző algoritmus is futhat egyszerre, melynek eredményeit két különböző webes felületen jelenítjük meg, ezzel az algoritmusok hatékony összehasonlítására van lehetőség. Különböző alkalmazási helyeken különböző algoritmusra lehet szükség. c.) Diagnosztika: Mivel a szerveren rendelkezésünkre áll az, hogy pontosan milyen routerek hallották az egyes mozgó node-okat, hálózati diagnózisra is lehetőség van. d.) A fizikai koordináták helye: Az elrendezésben a referencia csomópontoknak (routereknek) nem szükséges tudni saját koordinátáikat, elég ha azokat a szerver tudja. Így helyük rugalmasan változtatható, elég ha a szerveren frissítjük a koordinátákat. Erre a telepítő eszköz alkalmas. e.) Lokalizációs üzenetek gyakorisága: Függ a mobil eszköz mozgásának intenzitásától, hiszen a küldési gyakoriság a rezgés szenzor mért jellemzőjétől függ. 10
3.4.1.2. Korlátok a.) Az átjáró korlátjai: A gateway sávszélessége szűk keresztmetszetet jelent az alkalmazás számára. Ez a referencia node-ok sűrűségét ill. a mozgó eszközök számát korlátozza, mert a ezzel a két tényezővel az átjáró irányába történő hálózati forgalom nő. A koordinátoroknak és az átjáróknak jelentős RAM méretet elfoglaló buffert kell fenntartani az üzenetek bufferelésére, ez a szűk erőforrás készlettel rendelkező (4kB RAM) MC13213-as chip használata miatt ütközik korlátokba. b.) Költség: GPRS kommunikációs költség ebben az elrendezésben a legmagasabb. c.) Szűk keresztmetszetet jelentő csomópontok a hálózatban: Az 1-es mélységű routerek szűk keresztmetszetet jelentenek (“bottleneck hatás” [3]).
3.4.2. A centralizált hálózat felosztása Az a.) és a c.) korlátok miatt a ZigBee hálózatot érdemes több alhálózatra bontani (SN1, SN2 és SN3). Az 8. ábrán látható rendszer 3 PAN-ből áll, 3 centrummal (koordinátorral és átjáróval) rendelkezik. Ekkor lehetséges a rendszer által lefedett terület méretének növelése is.
8. ábra – Több ZigBee hálózat (alhálózatokra való osztás) [3] (piros: koordinátorok, kék: routerek, zöld: mozgó eszközök) Az a.) és c.) korlátok hatása tovább csökkenthető, ha nemcsak a koordinátorokat, hanem egyes routereket is felruháznánk egy ZigBee - GPRS átjáró funkcionalitásával.
11
3.4.3. Elosztott feldolgozás és centralizált hálózat A következő elrendezést valósítja meg a Texas Instruments CC2431 SoC ZigBee chipekkel megvalósított lokalizációs hálózata [4], melyet összehasonlítás képpen mutatok be. A Texas rendszerében a referencia csomópontok hirdetik azonosítóikat és koordinátáikat a mozgó eszközök számára. A mozgó eszközön futó lokalizációs algoritmus számolja ki a pozíciót és küldi el a koordinátoron levő átjáró számára.
9. ábra – Üzenetek áramlása az elosztott feldolgozású lokalizációs hálózatban [3]
3.4.3.1. Előnyök a.) Az átjáró korlátjai: Az átjáró szűk keresztmetszetet jelent, de a kisebb forgalom miatt ez kevésbé meghatározó, nagyobb sűrűségű hálózat építésére van lehetőség. b.) Költség: Kisebb GPRS kommunikációs költség.
3.4.3.2. Korlátok a.) A mozgó eszközök fogyasztása: A mobil eszköz magasabb fogyasztásával számolnunk kell. Az algoritmus a nagy számítási kapacitással rendelkező szerverről, a 8 MHz-es busz frekvenciával működő mikrokontrollerre tevődött át. A mobil eszköz rádióját vételi üzemmódba kell kapcsolni, amikor a hirdetett azonosítókat begyűjti. Ez hosszabb ébrenléti ciklust és kevesebb alvást tesz lehetővé, az elemek élettartama tehát csökkent az előző megoldáshoz képest. b.) Az algoritmus helye: Az algoritmus a mozgó eszközön van, változtatásra, hangolásra, csak firmware frissítéssel vagy az eszköz újra konfigurálásával van lehetőség. c.) Diagnosztika: A szerverre csak a végeredmény kerül, így nincs képünk arról, hogy mely eszközök vettek részt a lokalizációban. d.) A fizikai koordináták helye: A referencia node-ok számára ismert kell legyen a saját koordinátájuk. Ez kevésbé rugalmas elrendezést jelent.
12
e.) Lokalizációs üzenetek gyakorisága: A referencia csomópontok hirdetett üzeneteinek gyakorisága független a mobil egységek mozgásának intenzitásától.
3.4.4. Kooperatív lokalizációs hálózat Ha engedélyezzük, hogy a mozgó eszközök is hallgassanak bele a csatornába adott időre, akkor a más mobil entitásoktól kapott azonosítókat és a hozzájuk tartozó LQI értékeket is felhasználhatják a lokalizációhoz [3]. A megoldás nagy hátránya, hogy a mobil eszközök ébrenléti és vételi üzemmódban töltött ideje nő, tehát magasabb fogyasztással kell számolnunk [6].
4. SQL adatbázis Az alábbi fejezetben az SQL adatbázis legfontosabb tábláit tekintem át a teljesség igénye nélkül. Az adatbázis adatait egy webes felületen jelenítettem meg, a táblákat ezen keresztül mutatom be. Ezen a felületen keresztül új entitások, zónák, hálózati eszközök is vehetőek fel/törölhetők az adatbázisból. 4.1. Entitások táblája – tblEntities A mozgó eszközöket hordozó entitások (emberek, járművek) táblája. Azonosítót (ID), nevet (Name), paramétereket és a hozzá tartozó mozgó eszközt (MobileNodeID) tartalmazza. A MobileNodeID idegen kulcs a táblában. A táblába 4 targonca (ForkLift1 – ForkLift4) van felvéve, melyhez 4 különböző azonosítójú mozgó eszköz van hozzárendelve. (10. ábra)
10. ábra – tblEntities 4.2. Mobil eszközök táblája - tblMobileNodes A mozgó eszközök táblája 64 bites azonosítóikkal. Ezek vannak hozzá rendelve a mozgó objektumokhoz a tblEntities táblában. (11. ábra)
13
11. ábra – tblMobileNodes 4.3. Zónák és épületek táblája – tblBuildings Ez a tábla tartalmazza az épületeket és a zónákat, amikre az épületeket bontjuk. Amennyiben nem történik meg a követés során a mozgó eszközök pontos koordinátáinak meghatározása, a követés területét zónákra oszthatjuk és a cél annak a meghatározása lesz, hogy melyik mozgó eszköz melyik zónában tartózkodik. A zónákhoz koordinátákat is rendelhetünk. A koordináták hozzárendelése későbbi fejlesztés része lesz. (13. ábra) 4.4. Referencia node-ok táblája –tblStandingNodes A tblStandingNodes tábla tartalmazza a routerek és koordinátorok 64 bites azonosítóit, fizikai koordinátáit, illetve azt, hogy az egyes routerek és koordinátorok milyen zónákban helyezkednek el. (12. ábra)
12. ábra – tblStandingNodes tábla részlete
13. ábra – tblBuildings tábla részlete
14
4.5. Tracking üzenetek hisztorikus táblája – tblTrackingMessages
14. ábra – tblTrackingMessages tábla részlete A tblTrackingMessages tábla tartalmazza a szerverre kerülő követési üzeneteket (lásd 3.2.3.). A MessageID és az ArrivalDate a fogadó programban kerül hozzáadásra, a Timestamp az átjáró időbélyege, a CoordinatorID pedig az átjárót azonosítja. A fenti táblázat részletből az látszik, hogy a 3-as számú entitás (aminek neve “ForkLift1”) 2219 szekvencia számú üzenetét 2 hálózati egység hallotta, a 22732135572029889 számú erősebb jelet vett. A 6-os számú entitás (aminek neve “ForkLift4”) 1468 szekvencia számú üzenetét ketten hallották, a 22732135572029889 számú erősebb jelet vett. 4.6. Alive üzenetek hisztorikus táblája – tblAliveStandingNode
15. ábra – tblAliveStandingNode tábla részlete Ez a tábla tartalmazza a hálózati eszközök alive üzeneteit (lásd 3.2.3.) A tábla részletében 2 hálózati eszköz alive üzenete látszik.
15
5. Lokalizáció, objektumok követése Ebben a fejezetben egy rövid elméleti áttekintést végzek a lehetséges lokalizációs algoritmusokról. Munkám során még nem hasonlítottam össze gyakorlatban algoritmusokat, de egy olyan rendszert valósítottam meg, amivel ez a későbbiekben hatékonyan megtehető lesz. Egy Signpost nevű algoritmust került implementálásra, melyet a későbbiekben ismertetni fogok. Bonyolultabb algoritmusok elkészítésére és értékelése jelenlegi munkám része.
5.1. A lokalizáció eszköze - LQI (Link Quality Indicator) / RSSI (Received Signal Strength Indicator) Az irodalomban található ZigBee hálózaton alapuló lokalizációs/követő alkalmazások nagyrészt LQI / RSSI méréseken alapulnak. Előnyei: 1. Minden IEEE 802.15.4-es szabványnak megfelelő chip képes erre, így speciális periféria nincs szükség. Az RSSI mérés a rádiós vétellel automatikusan megvalósul, az értékét a modem egy regiszterből kell kiolvasni. ([1], 6.9.8.) 2. A mérés nem igényel többlet fogyasztást, hiszen a szabvány miatt automatikusan megvalósul. Pontatlanságának forrásai: 1. Nagyon sok környezeti körülmény befolyásolja a rádiós jelek terjedését (reflexió, adszorbció, többutas terjedés, interferencia), az egyes modellek (pl. a Friis formula [5] és ennek általánosított változata) használatának pontossága csak igen erős megszorításokkal lehetne centiméteres tartományban. (A Texas Instruments lokalizációs hálózata maximum 0.25 méteres pontosságot ígér, 16. ábra – Csillapítás irodai környezetben [5] de csak erős megszorításokkal [4]). 2. A nyomtatott áramkörökön megvalósított antennák (dipól, BIFA, IFA) erősen irányított karakterisztikával rendelkeznek. Ez azt jelenti, hogy a routerek által vett jelek térerőssége már attól is függ, hogy a mozgó eszköz milyen irányban állt az üzenet adásakor. Az alkalmazás optimális működéséhez izotróp antennára lenne szükség. 3. Az RSSI mérés nemlineáris tulajdonságával számolni kell. 4. Méréseket csak adott időközönként hajtunk végre. 5. A rádiós csatornában tárgyak, emberek mozognak és ezzel befolyásolják a terjedési körülményeket.
16
A fentiek alapján megállapítható, hogy az RSSI méréseken alapuló lokalizáció olcsó, alacsony fogyasztású módszerrel egy durva becslést képes adni a mozgó eszközök helyére vonatkozóan. A követő alkalmazásnál a mozgó egységekről azt szeretnénk tudni, hogy milyen zónában (teremben/ szobában/ műhelyben/ gyár helyiségben, stb.) vannak – így körülbelül 3-10 méteres pontosságot várunk el. Ez a követelmény a térerősség mérésen alapuló lokalizációs algoritmusok pontosságával összhangban van. Fontos hangsúlyozni, hogy a mobil 17. ábra – A vett jelszint ingadozása, amit az eszközök körülbelüli helyét már irodai környezetben mozgó emberek árnyékoló akkor meghatározhatjuk, ha tudjuk, hatása idéz elő [5] hogy azt adott pillanatban milyen referencia csomópontok hallották. A térerősség mérések felhasználása csak ezt az eredményt igyekszik pontosítani. A pontosság egy kompromisszumos döntés eredménye lesz, melyről a 3.2. fejezetben írtam.
5.2. A számítás helye 1. Elosztott (lásd 3.4.2.): például a Texas Instruments CC2431 SoC ZigBee chipekkel megvalósított lokalizációs hálózata [4]. 2. Centralizált (lásd 3.4.1.): a saját fejlesztésű hálózat.
SQL adatbázis Tárolt eljárások
Web szervízek
5.3. A kiszolgált kérések Célkitűzés, hogy a webes kliens oldali alkalmazás az adatbázishoz tudjon fordulni a következő jellegű kérdésekkel számítási algoritmustól függetlenül: 1. Milyen mozgó entitások vannak jelen az adatbázisban? (GetEntities nevű tárolt eljárást, lásd 5.4.1.1.) 2. Milyen referencia eszközök vannak és hol vannak ezek (koordináták és zónák)? 17
3. Az egyes mobil egységek hol helyezkednek el és mozgásban vannak e a lekérdezés pillanatában? (Signpost és IsMoving nevű tárolt eljárások, lásd 5.4.1.1.) 4. Adott időpontban hol tartózkodtak az egyes node-ok és mozogtak e?
5.4. Lehetséges algoritmusok 5.4.1. A megvalósított Signpost (útjelző) algoritmus (SP) Egyelőre ez az egyetlen algoritmus, amit szerver oldalon megvalósítottam. A jelenleg működő webes felület a Signpost algoritmust hívja meg. A követési területet zónákra osztjuk, az elhelyezés alapján a referencia eszközökhöz zónákat rendelünk. A felhasználói oldalról így olyan jellegű kérdést tehetünk fel, hogy egy adott mobil entitás melyik zónában tartózkodik egy adott pillatatban, illetve mozgásban van e. Az algoritmus: 1. Vegyük egy kérdéses mobil egységtől származó legfrissebb, adott számú üzenetet. Ez az adott szám függ attól, hogy az elmúlt adott időben (pl. 15 másodperc) hány referencia routertől kaptunk adatot a mobil eszközzel kapcsolatban. 2. Rendezzük ezeket az üzeneteket referenciánként. 3. Referenciánként átlagoljuk az adott mozgó entitástól kapott üzenetek LQI-ját (ez az átlagolás jelenthet súlyozott átlagolást is). 4. Vizsgáljuk meg, hogy melyik referenciához tartozik a legalacsonyabb átlag LQI (tehát a legmagasabb vett jelszint). 5. A 4. pontban kiválasztott referencia eszközhöz rendelt zóna lesz az eredmény. A Signpost algoritmus durva becslésnek tűnik első ránézésre, de meg kell jegyezzem, hogy mivel a terület, amit a mozgó egységek bejárnak, igen nagy is lehet, már az nagy jelentőségű információ, hogy egyáltalán milyen routerek hallják éppen az egyes mozgó eszközök azonosítóit. Kommunikációs timeout: Ha már egy perce nem jött adat egy mozgó egységtől, akkor a helyét bizonytalannak tekintem (ez az érték adatbázisban állítható). Ez lehet amiatt, hogy a mozgó entitás kikerült a követés területéről vagy használaton kívülre helyezték. 5.4.1.1. A Signpost algoritmus tárolt eljárásai GetEntities Leírás: Lekérdezi az adatbázisba felvett mozgó entitások adatait (ID és név), v.ö. 10.ábra. Kód: SELECT tblEntities.Name AS EntityName, tblEntities.ID AS EntityID ROM tblEntities
18
Eredmény:
Signpost Leírás: Bemenete a mozgó entitást azonosító EntityID. Az eredmény a Signpost algoritmussal kiszámolt zóna neve (lásd az algoritmus 1-5. pontját) Kód: SELECT TOP(1) BuildingName, EntityID FROM (SELECT AVG(LQI) AS AVGLQI, BuildingName, EntityID FROM (SELECT TOP (2*(SELECT COUNT(DISTINCT StandingNodeID) FROM vwJoinedTable)) * FROM vwJoinedTable WHERE (EntityID = @EntityID) ORDER BY Timestamp DESC, LQI DESC) AS TMPTBL GROUP BY BuildingName, EntityID) AS AVERAGES ORDER BY AVGLQI ASC
Eredmény:
IsMoving Leírás: Bemenete a mozgó entitást azonosító EntityID. Az eredmény 0, ha az egység nincs mozgásban, 1-es értéket vesz fel, ha mozog. Kód: SELECT TOP(1) Movement, EntityID FROM vwJoinedTable WHERE (EntityID = @EntityID) ORDER BY Timestamp DESC
Eredmény:
5.4.1.2. A Signpost algoritmus web szervíze Leírás: A felhasználói felület az adatbázist web szervízeken keresztül éri el. Bemenete a mozgó entitást azonosító EntityID. A Signpost, az IsMoving és a LastSight tárolt eljárásokat hívja meg és összegzi az eredményt. Az eredmény xml fájl tartalmazza az entitás azonosítóját, tartózkodási helyét, mozgását és azt az időpontot, amikor a rendszer legutóbb látta az adott mozgó egységet. URL: http://demo.diwicon.com/ZigBeeTrackingSilverlight2/SignpostFULL.asmx
19
5.4.2. Legnagyobb valószínűség módszere (ML) Az algoritmus már nem zónák szerint próbálja megállapítani a mobil eszközök helyét, hanem egy 2 dimenziós koordináta rendszerben helyezi el őket. Adott egy terjedési modell, melynek paramétereit kell beállítanunk az alkalmazás helyén. Pl.: Szakaszcsillapítás exponens becsléssel: d L p (d ) = Lo (d o ) + 10 ⋅ n ⋅ log , ahol L p (d ) a csillapítás d távolságban, Lo (d o ) a do csillapítás a referencia d o távolságban, n az exponens becslő. Ha tehát ismert a szakaszcsillapítás a referencia d o távolságban és mért az RSSI ismeretlen d távolságban, akkor ebből adott n értékre adódik a d távolság. Ilyen modellt használ a Texas Instruments lokalizációs motorja [4]. Az Lo (d o ) és n értéket a helyszínen végzett mérések alapján kell beállítani. A számított d távolságokból kell származtatni a mozgó eszköz pontos pozícióját. A módszer a Signpost algoritmushoz képest számítás igényes és helyszínen elvégzett méréseket és konfigurációt igényel, ezzel együtt kevésbé rugalmas.
5.4.3. RF mintával való összevetés (RF fingerprinting) A felhasználási helyen telepítéskor “RF mintát” veszünk: adatbázisba visszük a követési terület egyes pontjainak LQI profilját. Az alkalmazás során a szerverre érkező üzenetekben levő LQI értékeket ezekkel a mintákkal vetjük össze és megkeressük azt a mintát, amelyik a legjobban hasonlít a mért értékekre. Az eredmény a minta helye lesz. Nagy mennyiségű mérést kell végezni tehát a felhasználás helyén. Az RF minta halmaz addig használható csak, amíg a hálózati elemek fizikai helyzete állandó és a környezetben sem történik jelentősebb fizikai változás. [3] 5.4.4. A Signpost tovább fejlesztése - térerősség arányokkal dolgozó algoritmusok Egyszerű algoritmusokat implementálhatunk, ha térerősség arányokkal kívánjuk meghatározni az egyes mobil objektumok helyét pl. egy szakaszon belül. 1. Vegyük egy kérdéses mobil eszköztől származó legfrissebb adott számú üzenetet. Ez az adott szám függ attól, hogy az elmúlt adott időben (pl. 15 másodperc) hány referencia routertől kaptunk adatot a mobil eszközzel kapcsolatban. 2. Rendezzük ezeket az üzeneteket referenciánként. 3. Referenciánként átlagoljuk az adott mozgó entitástól kapott üzenetek LQI-ját. 4. Vizsgáljuk meg, hogy melyik 2 referenciához tartozik a 2 legalacsonyabb LQI (tehát a legmagasabb vett jelszint). 5. A 2 átlag arányából vonjunk le következtetést azzal kapcsolatban, hogy a mobil egység a 2 referencia által meghatározott szakaszon hol helyezkedik el. A módszert bővíthetjük több referenciával dolgozó megoldásra. A 3 referenciát használó eszköz esetén háromszögelést végezhetünk. 5.5. Az algoritmus pontossága és válaszideje Az előző áttekintésből látszik, hogy az átlagolás valamennyi algoritmusnál szerepet játszik. A vett jel LQI-ja a rádiós csatorna, az antenna irányítottsága és a környezet tulajdonságai miatt változást mutat. A mobil eszközök üzeneteihez tartozó LQI értékek átlagolása növelheti az algoritmus pontosságát. Minél hosszabb idő alatt begyűjtött üzenetek LQI-ját átlagoljuk, annál nagyobb válaszidejű algoritmust kapunk. [6] 20
6. Az eredmények megjelenítése webes felhasználói felületen
Web szervízek
Silverlight alkalmazás
Az 5.4.1.1. fejezetben ismertetett web szervíz szolgálják ki a kliens oldali webes felhasználói felületet, melyet az új Microsoft Silverlight platform 2.0-s verziójára [12] készítettem el. A Silverlight egy interaktív médiaplatform, mely a .NET keretrendszerre épül. A választás azért esett a Silverlightra, mert a későbbiekben hatékony módon fogja támogatni a hálózat elemeinek grafikus megjelenítését egy koordináta rendszerben. Az eredmények megjelenítése egyelőre táblázatos formában történik.
18. ábra – A webes felhasználói felület Silverlight platformon (1) Egy demo alkalmazás jelenleg is futás alatt áll a fejlesztett rendszerem bemutatására. 4 mozgó objektum (ForkLift1 – ForkLift4 névvel ellátott eszközök, melyek targoncákat jelképeznek) van egy épületében. Az épületben telepítettem egy – a fentiekben bemutatott – ZigBee követő hálózatot, mely a 4 mozgó egység
21
követését végzi az ismertetett Signpost algoritmus alkalmazásával. A rendszer képes mutatni azt, hogy az egyes mozgó egységek az épület milyen zónájában tartózkodnak és mozognak e. Továbbá az is látszik a felületen, hogy mikor látta utoljára a hálózat az egyes targoncákat. Link: http://demo.diwicon.com/ZigBeeTrackingSilverlight2/ZigBeeTra ckingPilotSilverlightTestPage.aspx
19. ábra – A webes felhasználói felület Silverlight platformon (2) FIGYELEM! A fenti oldal böngészéséhez Silverlight 2.0 verziója kell legyen telepítve a kliens számítógépre. A fenti oldalon megjelenített hálózati eszközöket és a mozgó egységet a további fejlesztésekre jelenleg is használom, nem mindig tartom őket bekapcsolva, ezért nem lesznek mindig láthatóak a fenti oldalon. Mivel a kommunikációs timeout 1 perc, ha az adatbázisba már nem került 1 perce adat, az algoritmus úgy tekinti, hogy a mozgó egység kikerült e követés területéről, ilyenkor a tartózkodási helye: ”-”. Ilyenkor csak az látszik, hogy mikor látta utoljára a hálózat a mobil objektumot. A közeljövőben megvalósításra kerül a felület grafikus változata, ahol a referencia és mobil egységek egy koordináta rendszerben jelennek meg.
22
7. Telepítő eszköz A vezeték nélküli szenzorhálózat technológiák, így az IEEE 802.15.4-es és ZigBee szabvány előnyeiről és lehetséges alkalmazási területeiről sokat olvashatunk. Azonban a hálózat telepítésének módjáról legtöbbször kevés szó esik, és a szabvány sem nyújt telepítési protokollt, a legtöbb alkalmazás – így a fent bemutatott követő rendszer is – viszont tudatos és dokumentált telepítést igényel. [9] A hálózati eszközök tudatos elhelyezését, üzembe helyezését, konfigurálását, a hálózat felépítését és helyszínen való tesztelését, valamint az egész folyamat dokumentálását telepítésnek (commissioning) nevezzük. [9] A Cason Mérnöki Zrt és tanszéki konzulenseim ösztönzésére a telepítést általánosnak tekintettem, és igyekeztem egy univerzális és bővíthető eszközt megalkotni, mely nemcsak a beltéri követést szolgáló alkalmazás telepítésénél segíthet.
7.1. A telepíthetőség igénye és feladatai A ZigBee szenzorhálózat a legtöbb esetben nem hasonlít az ideális smart dustra, melynél a felhasználási helyen kiszórhatjuk eszközeinket, és a hálózat önszerveződő képessége miatt a rendszer már működésbe is lép. [9]
7.1.1. Tudatos elhelyezés A tudatos elhelyezésre hangsúlyt kell fektetnünk, ha megfelelő minőségű kapcsolatokat akarunk elérni hálózatunkban. Ez az egyes telepített eszközök esetében megkívánja a szomszédos csomópontok által adott jelek erősségének mérését és a velük folytatott kommunikáció PER (packet error ratio) tesztjét. 7.1.2. Konfigurálhatóság A hálózati egységek szoftverének konfigurálhatónak kell lennie. Számos attribútum optimális beállítása csak az üzembe helyezéskor történhet meg. [9] Ha otthonunk világításának vezérlését akarjuk megoldani egy ZigBee hálózattal, be kell tudnunk állítani, hogy melyik kapcsoló melyik lámpát fogja vezérelni (binding management). 7.1.3. Hálózati jellemzők regisztrálása és tesztelés Az elkészített hálózat struktúrájának és más hálózati jellemzőinek rögzítése és helyszíni tesztek elvégzése. 7.1.4. Dokumentálás, adminisztráció A rendszer üzembe helyezésének dokumentálása pontos képet ad arról, hogy milyen azonosítójú egységek hova kerültek elhelyezésre. A követő alkalmazásnál el kell jutattunk adatbázisba azt, hogy az egyes referenciaként szolgáló hálózati eszközök hova kerültek telepítésre.
23
7.2. A telepítés munkafolyamatának kérdései 7.2.1. Telepítést végző személyek és feladataik A telepítő személyek szakmai háttere kulcskérdés a telepítés munkafolyamatának meghatározásakor. [9] A ZigBee hálózat struktúrájának lekérdezése és hálózati tesztek elvégzése mindenképp mérnöki feladat, azonban az elhelyezést (beszerelést, bekapcsolást) lehet hogy villanyszerelők végzik majd. Látható, hogy a telepítés munkafolyamata több állomásra osztható és az egyes lépések között akár a telepítő személyek is változhatnak, illetve hosszú idő is eltelhet az egyes feladatok között. 7.2.2. Megszorítások a hálózattal kapcsolatban Ha egy olyan hálózat telepítéséről van szó, melynek végpontjai a lakások gáz fogyasztását mérik egy adott településen, akkor megszorításként kell kezelnünk azt a tényt, hogy a végpontokat a gázóráknál kell elhelyezzük. Ebben az esetben a ZigBee routerek helye viszonylag szabadon megválasztható: A ZigBee szabvány jelenleg nem támogatja az elemes, alacsony fogyasztású routereket, így a routerek helye hálózati tápellátáshoz kötött minden esetben.
7.3. Követelmények a telepítő eszközzel szemben Hálózati kapcsolat: Be tud kapcsolódni a ZigBee hálózatba és annak részeként – mint végpont – képes lekérdezéseket végrehajtani. Kommunikáció hálózaton kívül: Ha az elhelyezés térerősség mérések segítségével zajlik, a hálózati csomópontok elhelyezésekor szükséges velük kommunikálni és küldött üzeneteik térerősségét regisztrálni még mielőtt hálózatba lépnek. Hordozhatóság, grafikus felhasználói interfész: Notebookon vagy PDA-n levő felhasználói felület. A terepi munkához a PDA alkalmasabb, mint a notebook. GPRS kommunikáció: A telepítés adatainak rögzítése történjen egy szerveren levő adatbázisban. A szerverrel való kommunikáció a GPRS szolgáltatással megoldható, ha a PDA rendelkezik ezzel. Ezzel elvégezhető például a követő alkalmazásnál a routerek helyének felvitele az adatbázisba. Segítség fejlesztéskor: Fontos megjegyezni, hogy egy telepítő eszköz a fejlesztési folyamatot is megkönnyítheti azzal, ha információt nyújt a létrejött hálózat jellemzőiről.
20.ábra – Beltéri ZigBee hálózat telepítése [9]
24
7.4. Telepítő üzemmód és ZigBee hálózat üzemmód Probléma: Kommunikációra nincs lehetőség az alkalmazás számára a hálózatba való lépés előtt a ZigBee szabvány szerint. ([2], 1.2.8.2.1). Az APS (Application Support Sublayer) réteg minden olyan keretet visszautasít, amit az eszköz hálózatba való lépése (association) előtt generált az alkalmazási rétegben. A hálózatba lépés előtti kommunikáció az általam definiált telepítésnél elengedhetetlen követelmény. Megoldás: Megvalósítottam egy telepítő üzemmódot, amely egy olyan szoftver réteg, ami a ZigBee protokoll stack elindítása előtt fut a csomópontokon. Egyszerű, saját fejlesztésű kommunikációs protokollt használ. A telepítő eszköz utasíthatja a telepített eszközöket, hogy hagyják el ezt az üzemmódot és csatlakozzanak a hálózathoz, és arra is, hogy hálózati ZigBee módból lépjenek vissza a telepítő módba. Magyarázat az ábrákhoz: A telepítő módban levő eszközöket zöld színnel, a hálózati módban levőket piros színnel jelöltem.
7.4.1 Telepítő üzemmód (saját fejlesztésű szoftver réteg és protokoll) A telepítő üzemmódban az eszközök a saját azonosítójukat (64 bites IEEE cím) hirdetik meghatározott időközönként, nem részei hálózatnak, csak a telepítő eszközzel kommunikálhatnak, egymással nem. A telepítő eszköz közvetlenül kommunikál az egyes csomópontokkal, regisztrálja a hirdetett azonosítókat és a hozzájuk tartozó jelek erősségét, így ez az üzemmód támogatja az eszközök elhelyezését a vett térerősség alapján, és PER (packet error ratio) teszt végzését teszi lehetővé különböző pontok között. A terepen kirakott eszközök azonosítása egyszerűen elvégezhető: Ha a telepítőt egy végpont vagy egy router mellé helyezzük, akkor a tőle kapott azonosító csomag erőssége lesz a legmagasabb (-19 dB és -25 dB közötti érték várhatóan). A telepítő módban beállításokat hajthatunk végre. Nem hallja a telepítő eszköz D. A. B. - 67 dBm
- 19 dBm
Telepítő eszköz Elhelyezés térerő A : - 67 dBm alapján, PER teszt, konfig C: -52 dBm
C.
- 52 dBm
Nem hallja a telepítő eszköz E.
21. ábra – Telepítő üzemmód (zöld szín) A 21. ábra szemlélteti az elhelyezést térerősség alapján a telepítő üzemmódban. A telepítő eszköz a B. csomópont „mellett” van. A B. eszközt úgy helyeztük el, hogy az A. node -67 dBm-es, a C. pedig -52 dBm-es erősségű jellel éri el. A telepítő eszköz nem hallja a D. és E. hirdetett azonosítóit, így valószínűleg a B. eszköz sem (kapcsolatuk gyenge). Alacsony fogyasztás: A telepítő módban levő végpontok és a routerek alszanak (2.5 uAes fogyasztás) és meghatározott időközönként ébrednek fel. Ébredéskor elküldik azonosítójukat majd visszaalszanak. (A szoftver hasonlít a követő alkalmazásnál levő
25
mozgó eszközök szoftveréhez.) A telepítő eszköz veszi ezeket az elküldött azonosítókat és csak akkor tud egy végponttal vagy egy routerral kommunikálni, amikor az ébren és hallótávolságon belül van. Egy szoftveres buffert tart fenn arra a célra, hogy a felhasználói interfész felől jövő kéréseket eltárolja. Mivel a telepítő mód fogyasztása alacsony, megengedhető, hogy az elemes eszközök is jelentős időt töltsenek ebben az üzemmódban. Ezzel az egységek felszerelése, bekapcsolása és a hálózat felépítése akár időben távol lehet egymástól.
7.4.2. ZigBee hálózati (szabványos) üzemmód (ZigBee protokoll): Ebben a módban az eszközök a ZigBee hálózat részei, őket a telepítő eszköz a hálózaton keresztül éri el, általában nem közvetlenül. Ebből adódik, hogy térerősség mérésre, PER teszt végzésére nincs lehetőség. Azonban használja a ZigBee protokoll lekérdezéseit (IEEE address request ([2], 2.4.3.1.2.), MGMT LQI request ([2], 2.4.3.3.3.), Routing table request ([2], 2.4.3.3.4.) melyekkel a hálózat tulajdonságairól részletes képet kaphatunk (bővebben lásd 7.7.). A.
D.
B. C. Telepítő eszköz Hálózat jellemzők
E.
22. ábra – ZigBee hálózat üzemmód (piros szín)
7.5. A telepítés munkafolyamata 7.5.1. Rögzített helyű eszközök elhelyezése Felszerelésre kerülnek azok az eszközök, melyek helye előre meghatározott. Ezek a céleszközök többnyire a végpontok szerepét töltik be a hálózatban. Ha egy olyan hálózat telepítéséről van szó, melynek végpontjai a lakások gáz fogyasztását mérik egy adott településen, akkor a végpontokat a gázóráknál kell elhelyezni. A felszerelt csomópontok telepítő üzemmódban indulnak el. A követő alkalmazás eltér a fenti általános esettől, mert nincsenek kötött helyű végpont eszközök. Azonban a telepítés idejére elhelyezhetünk nyugalomban levő teszt végpontokat a területen. Az általuk hirdetett azonosítók vételével jelölhetjük ki azt a területet, amin belül mozgó objektumainkat követni szeretnénk. Ekkor a telepítő eszközzel való munkánk célja az, hogy egy olyan routerekből álló hálózatot építsünk, ami kapcsolatban van (hallótávolságban van) az összes teszt végponttal. 7.5.2. Koordinátor elhelyezése A hálózat mélysége a ZigBee szabvány szerint maximum 15 lehet. ([2], 3.6.1) Hogy minél nagyobb átmérőjű területet tudjunk lefedni, érdemes a koordinátort a terület középpontjába helyezni.
26
ED3
ED4
ED1
ED9
ED7 CD
ED5
COORD ED10 ED2
ED6
ED8
ED11
23. ábra - Rögzített helyű eszközök (ED: End Device) és a koordinátor (COORD) elhelyezése, Telepítő eszköz (CD – Commissioning Device) 7.5.3. Koordinátorhoz közeli, kötött helyű eszközök hálózatba léptetése A telepítő eszköz a koordinátor helyén elhelyezve hallja a telepítő módban levő végpontok egy részének azonosítóit. Térerősség méréssel megállapítható a koordinátorral való kapcsolat minősége, majd konfigurációt hajthatunk végre ezeken a végpontokon. A telepítő eszköz segítségével utasítjuk őket, hogy csatlakozzanak a koordinátorhoz. ED1
ED1 ID, -65 dB
ED5
ED7
CD
CD
ED5
COORD
ED7
COORD
ID, -52 dB ED2
ED2
24. ábra - Kötött helyű eszközök hálózatba léptetése (1)
25. ábra - Kötött helyű eszközök hálózatba léptetése (2)
7.5.4. Routerek telepítése (mélység:1) A koordinátortól elindulva megkeressük azt a helyet, ahol a koordinátorral való kapcsolat minőség még megfelelő és távolabbi, a koordinátortól nem hallott eszközöket érünk el. Ide routert helyezünk el, ami szintén telepítő módban indul. Tesztek és konfiguráció után utasítjuk a routert, hogy lépjen át hálózati üzemmódba és csatlakozzon a koordinátorhoz. (Természetesen nem biztos, hogy a végpontok és a koordinátor kapcsolata áthidalható egyetlen router felhasználásával. Ilyenkor a szükséges router láncot a megfelelő tesztek elvégzésével telepítjük.)
27
ED3
ED4
ED1
ED9
ED7 ID, -40 dB
ED5
COORD
CD R1 ED10
ED2
ED6
ID, -62 dB
ED8
ED11
26. ábra - 1-es mélységű routerek telepítése (R: router) (1)
ED3
ED4
ED1
ED9
1.mélység R2 ED5
ED7 CD
COORD R1 1.mélység
ED6
ED2
ED10 ED8
ED11
27. ábra - 1-es mélységű routerek telepítése (R: router) (2) 7.5.5. Routerek telepítése (mélység:2) Az 1-es mélységű routerektől elindulva megkeressük azt a helyet, ahol további kötött helyű eszközök kerülnek lefedésre. Teszteljük a kapcsolatot az 1-es mélységű routerrel és a látott végpontokkal, majd utasítjuk routerünket, hogy lépjen be a hálózatba (csatlakozzon 1-es vagy annál kisebb mélységű eszközhöz). A 2-es mélységű routertől látott végpontokat is beléptetjük a hálózatba. 7.5.6. Folytatás a szenzormező lefedéséig Az előző lépéseket ismételjük addig, amíg az összes végpont beléphetett hálózatba. Amennyiben elértük a maximális mélységet és az alkalmazás területén még nem jött létre összefüggő hálózat, új koordinátor felszerelésére van szükségünk, mely egy új PAN-t fog létrehozni. Ez után az újabb PAN-re ismételjük meg az 1-6. lépéseket. 7.5.7. Hálózati jellemzők feltérképezése: Minden telepített PAN-en ZigBee szabványos hálózati lekérdezésekkel megállapítható a hálózat struktúrája, a szomszédossági táblák és a routing táblák. Szabványos parancsokkal az eszközök konfigurálhatóak.
28
7.6. A telepítő eszköz hardvere
Bluetooth – Serial bridge
MC13213 NCB PDA
28. ábra – A megvalósított telepítő eszköz hardvere Felhasználói interfész: Felhasználói interfésznek a PDA ideális megoldást nyújt: hordozható és sok PDA rendelkezik GPRS kapcsolattal is. A PDA-n futó szoftver saját fejlesztésű (lásd 7.8.). IEEE 802.15.4 / ZigBee node: Képes kommunikációra a hálózaton kívül és a hálózaton belül levő egységekkel egyaránt. Hálózatba lépése esetén végpont szerepét tölti be, mások hozzá kapcsolódni nem tudnak. Ezt a FreeScale Semiconductor 13213 NCB kártyája [10] valósítja meg, melyre saját készítésű firmware került. PDA – ZigBee node kapcsolat: Kulcs kérdés a hardver megtervezésénél a PDA és a ZigBee panel közötti interfész megválasztása. Szinte minden PDA rendelkezik Bluetooth kapcsolattal, amit a Bluetooth Serial Port profil segítségével szoftverből mint COM portot érhetünk el. A telepítő eszköz hardver része ebben az esetben igényel egy Bluetooth – soros modemet. Ilyenek kaphatóak például a Bluegiga vagy a Free2move [11] oldalán. Ezek a modemek transzparens módon konvertálják a Bluetooth és soros üzeneteket, így a mikrokontroller számára a PDA mint egy soros periféria kezelhető. A telepítő eszköz felépítésekor a Free2move F2M01C1 [11] modulját használtam. Ez kommunikáció közben a hardver fogyasztását 50-60 mA-rel növeli meg.
29
Telepítő eszköz
Freescale MC13213 NCB panel
Free2move F2M01C1
Freescale MC13213
Telepített eszközök
HCS08 uC RS232
Bluetooth Serial Port PDA Profile
antenna SPI
MC13192 rádió modem
802.15.4 / ZigBee
RF
29.ábra – A telepítő eszköz blokkválzlata Saját fejlesztésű komponensek: 1. PDA – grafikus felhasználói interfész (lásd 7.8.) 2. Protokoll a felhasználói interfész és a mikrokontroller között (lásd 7.7) 3. Telepítő eszköz firmware MC13213-ra . (lásd 7.7): A) Telepítő módot megvalósító szoftver. B) Hálózati lekérdezéseket kezdeményező és a válaszokat feldolgozó szoftver. 4. Telepített eszköz firmware MC13213-ra
7.7. A telepítő eszköz szoftvere és protokollja A két üzemmód szerint a firmware-t két részre lehet osztani:
7.7.1. Telepítő mód Saját fejlesztésű C-ben írt szoftver csomag MC13213 SiP-re [7]. A telepítő réteg egy másik verziója kerül a végpontokra és a telepítő eszközre, mert a telepítő eszköz szoftverének szolgáltatásai különböznek a végpontokra és a routerekre kerülő szoftver szolgáltatásaitól. A telepítő eszköz a hallótávolságában levő telepítendő eszközöket közvetlenül megcímezve éri el. PRE: 2 byte preambulum, értéke 0xFFFF
Hirdetett azonosító csomag (node → telepítő) PRE 0x00 IEEE ADDRESS DATA1 DATA2 Ezt az üzenetet hirdetik a telepítő módban levő node-ok. Az IEEE address az eszköz 64 bites fizikai címe. A data1 és data2 mezők a későbbiekben szabadon felhasználhatóak. A telepítő méri a jelek erősségét, az elhelyezés ez alapján történik.
30
PDA GUI
hirdetett ID, mért LQI konfiguráció kérés konfiguráció válasz teszt kérés teszt üzenetek
hirdetett ID
Telepítő Eszköz
konfiguráció parancs
Telepítő mód
teszt kérés
soros kommunikáció (Bluetooth Serial Port Profile)
konfiguráció válasz
Telepített eszköz (ED vagy R)
teszt üzenetek
802.15.4
30. ábra – Telepítő mód üzenetváltások Az azonosító küldés gyakoriságának beállítása (telepítő eszköz → node telepítő módban) A jelenlegi verzióban 2 féle küldési gyakoriság állítható be. Ha az eszköz hirdeti az azonosítóját, magasabb a fogyasztása, de elhelyezése könnyebb és kommunikálhatunk vele. PRE 11 1 másodpercenkénti küldés beállítása: 10 másodpercenkénti küldés beállítása: PRE 22
gyakrabban gyakrabban ADDRESS ADDRESS
Leíró (descriptor) beállítására való parancs (telepítő eszköz → node telepítő módban) PRE 0xDD IEEE ADDRESS LENGTH DESCRIPTOR A telepítő beállíthat egy maximum 16 karakter hosszú nevet vagy leírót, ami az eszköz könnyebb azonosítását teszi lehetővé a továbbiakban. Tipikusan jellemezheti a leíró a node helyét is. (Példát lásd a 7.8. fejezetben.): Leíró (descriptor) lekérdezése (telepítő eszköz → node telepítő módban) PRE 0x88 IEEE ADDRESS Válasz erre: PRE 0x66 IEEE ADDRESS LENGTH DESCRIPTOR PER teszt A PER (packet error rate) a vezeték nélküli hálózat fontos QoS (szolgálatminőség) paramétere. A PER definíció szerint ([1], 6.1.7.) azt az átlagos értékét adja meg, hogy a küldött csomagok hányadát kapja meg helytelenül a vevő. A tesztelt eszköz 255 üzenetet küld. A mérés elindításával a PDA-ra fejlesztett program számolja, hogy hány hibátlan teszt csomag érkezett meg. PER teszt kezdeményezése (telepítő eszköz → node telepítő módban) PRE 0x33 IEEE ADDRESS Küldött PER teszt üzenetek (node telepítő módban → telepítő eszköz) PRE 0x77 IEEE ADDRESS Telepítő mód elhagyására való parancs (telepítő eszköz → node telepítő módban) PRE 0xFF IEEE ADDRESS
31
7.7.2. ZigBee hálózati mód A hálózati módban a kommunikáció a ZigBee szabvány szerint történik. A firmware a Freescale Semiconductor BeeStack 2.0-s verziójára [13] épülő saját fejlesztésű alkalmazás. A telepítő eszköz esetében a protokoll stack applikációs rétege veszi a hálózati lekérdezéseket a GUI felől és az APS réteg szolgáltatását igénybe véve továbbítja a ZigBee hálózatba. A csomag címzettet közvetett módon, a hálózaton keresztül éri el. A lekérdezések eredménye visszakerül az applikációs rétegbe, ahonnan feldolgozás után soros vonalon halad tovább a PDA-n levő GUI felé. PDA GUI
hálózati lekérdezés
A hálózaton keresztül a telepített eszköz
Telepítő eszköz APP
válasz ZigBee APS ZigBee NWK BeeStack 2.0.
IEEE 802.15.4 MAC IEEE 802.15.4 PHY
soros kommunikáció (Bluetooth Serial Port Profile)
802.15.4, ZigBee
31. ábra – ZigBee hálózati mód üzenetváltások 1. Struktúra felderítés: Az eszközök hálózati címeinek és a hálózat struktúrájának felderítése a rendszerbe vitt IEEE address request lekérésekkel történik ([2], 2.4.3.1.2.). Az első IEEE address requestet a koordinátor felé irányítjuk. A kérésre adott válaszban a koordinátor elárulja a gyerekei címét. Ezután a koordinátor gyerekeihez (1. mélységű eszközök) fordulunk IEEE address request kérésekkel. A folyamat addig tart, amíg minden hálózati eszköz gyerekeinek címét megszereztük. 2. Szomszédossági mátrixok rögzítése: A szomszédossági táblák felvétele a rendszerbe vitt MGMT LQI request lekérésekkel történik ([2], 2.4.3.3.3.). 3. Routing táblák felderítése: A routing táblák regisztrálása a hálózatba vitt RTG request lekérésekkel történik ([2], 2.4.3.3.4.). 7.7.3. Üzenetek a PDA és a mikrokontroller között - A telepítő eszköz állapotának lekérése (PDA → uC) - A rádió vevőjének be- és kikapcsolása (PDA → uC) - Telepítő eszköz hagyja el a telepítő módot (PDA → uC) A többi rádiós üzenet (7.7.1, 7.7.2) megfelelő keretbe rendezve továbbítódik a PDA és a uC között. 7.7.4. UDP csomagok a PDA és a szerver között A soros vonalon a PDA számára küldött csomagok (azonosító üzenetek, lekérdezésekre való válaszok, teszt eredmények) megfelelő keretbe rendezve továbbítódnak a szervernek. A PDA GPRS szolgáltatást használ.
32
7.8. Telepítő eszköz grafikus felülete PDA-n A PDA-ra saját fejlesztésű grafikus felhasználói felület került. Platform: Windows Mobile 5.0, Nyelv: C++, Fejlesztő környezet: Visual Studio 2005
1. A telepítő eszköz vezérlése - A telepítő eszközzel való soros kommunikáció menedzselése - Rádiós vétel engedélyezése és tiltása - A telepítő átkapcsolása telepítő és hálózati mód között 2. Konfiguráció, lekérdezések és megjelenítés - Státuszinformációk megjelenítése - Hallótávolságban levő node-ok és vett jelük erősségének megjelenítése - A felépített hálózat egészének (struktúrájának) megjelenítése - Konfiguráció kezdeményezése és a nyugtázás megjelenítése - Lekérdezések kezdeményezése és a válaszok kiértékelése és megjelenítése - Tesztek indítása és az eredmények megjelenítése 3. Szerverrel való kommunikáció vezérlése - GPRS szolgáltatással UDP protokoll szerint az adatok szerverre való küldése settings.txt: Ebben a konfigurációs fájlban kell beállítani a fontos kommunikációs paramétereket: 1. Serial Port Profile-t használó Bluetooth kapcsolat milyen COM porton érthető el szoftverből, 2. Szerver IP címe, 3. Szerver által hallgatott UDP port száma
7.8.1. A GUI vezérlő– és státuszpanele
A telepítő eszköz státuszát jelző LED-ek
Kommunikáció státusza Navigáció: Telepítő módban levő nodeok listája A legfrissebb eseményt megjelenítő ablak Kommunikációt vezérlő gombok
32. ábra – Vezérlő és státuszpanel (1) Az alábbi fejezetekben a GUI felépítését és működését mutatom be egy példán keresztül. Ebben a leegyszerűsített példában 5 routert szeretnénk telepíteni azzal a céllal, hogy egy
33
bejárat
beltéri követésre alkalmas rendszer egy részét képezzék. Az épület alaprajzának egy részlete a 33. ábrán látható.
porta
vészkijárat
folyosó
33. ábra – Példa épület részlet 7.8.1.1. Kommunikációt vezérlő gombok (alsó toolbar) 1. Bluetooth: Az 1. gombbal lehet a Bluetooth kapcsolatot kiépíteni és bezárni. 2. GPRS: A 2. gombra kattintva a szoftver felveszi a szerverrel a kapcsolatot a settings.txt fájlban található paraméterek alapján. A kommunikáció a GPRS szolgáltatást és UDP szállítási protokollt használ. 3. ZigBee: A ZigBee chip rádiójának vételét engedélyezhetjük és tilthatjuk az alacsonyabb fogyasztásra törekedve. A rádió tiltása / engedélyezése csak akkor válik elérhetővé, ha a Bluetooth kapcsolat már kiépült, hiszen a mikrokontroller csak így érhető el a PDA-ról. 5. Mode Change: A telepítő mód és a hálózati mód között lehet vele váltani. 7.8.1.2. A telepítő eszköz státuszát és a kommunikációt jelző LED-ek 1. Started LED: Ha a Bluetooth kapcsolat kiépült, a GUI lekérdezi a mikrokontrollert, hogy be van e kapcsolva. Ha kap választ, akkor a Started LED zölden fog világítani. 2. Network LED: Abban az esetben világít zölden, ha a telepítő eszköz a hálózathoz kapcsolódott és a csomópontokat ZigBee protokoll szerint a hálózaton keresztül képes elérni. Ha telepítő módban vagyunk, akkor pirosan világít. 3. Bluetooth LED: Kéken villog minden Bluetoothon kapott üzenet esetén. 4. GPRS LED: Zölden villog a szerverrel való kommunikáció esetén.
A 3. vezérlő gomb ikonjának színe jelzi, hogy a ZigBee vételt már engedélyeztük. Egyik routerünket a bejárathoz helyezzük el és bekapcsoljuk. Látható, hogy egy új eszközt detektált a telepítő. Az új eszköz hirdetett azonosítója 0050C21414141414. Ez az eszköz felvételre került a Test Node List gomb alatt elérhető listába. 0050C21414141414
ED
34. ábra – Vezérlő és státuszpanel (2)
34
CD
7.8.1.3. Telepítő Node Lista – a telepítő módban levő node-ok listája A gombra kattintva azon eszközök táblázata nyílik meg, melyeket már a telepítő hallott és telepítő módban vannak. A fenti alaprajz áttanulmányozása után úgy döntünk, hogy egy hálózati egységet a bejárathoz, egyet a portára, kettőt a folyosóra és az utolsót a vészkijárathoz szeretnénk tenni úgy hogy a követés egész területe a hálózat hallótávolságán belül legyen. Ez a 6 eszköz akkor alkot egy összefüggő, stabil hálózatot, ha a kapcsolatok minősége megfelelő. (A koordinátort a vészkijárat melletti szobában helyezzük el.) A Node Lista dialógusban elérhető térerősség mérés segít az elhelyezésben.
7.8.2. Telepítő módban levő eszközök listája Node Lista: Ez a lista tartalmazza a detektált telepítő módban levő eszközöket és a hozzájuk tartozó attribútumokat. A checkboxokkal lehet beállítani, hogy a táblázatban mely attribútomok jelenjenek meg: IEEE cím (64 bites azonosító), LQI érték [dBm] (a legutóbb vett azonosító csomag jelének erőssége), PER teszt eredménye, stb. Látható, hogy a telepítő eszköz a 0050C21515151515 azonosítójú node közelében helyezkedik el, mert ehhez tartozik a legkisebb LQI érték. Ezzel a terepen a 0050C21515151515 című csomópontot már be is azonosítottuk. Ezt az eszközt helyezzük el a bejárathoz. LQI: A Progress Control arra az egységre vonatkozó LQI értéket jeleníti meg, amelyik a listában ki van választva. Az LQI mérés teszi lehetővé azt, hogy megállapítsuk két telepítendő hálózati eszköz közötti szakaszcsillapítást. Telepítő módban levő, detektált node-ok táblázata az utojára vett azonosító csomag LQI-jával. Checkboxok
Gombok, amik új dialógusokhoz vezetnek: - Parancsok küldése dialógus -Vonalkód beolvasás dialógus Az azonosító érkezési gyakorisága A küldött azonosító erőssége (LQI)
35. ábra – Node Lista (1) A Send Command gomb segítségével az a dialógus kerül megjelenítésre, ahonnan a kiválasztott eszköznek parancsot küldhetünk. A Barcode gomb egy olyan ablakhoz vezet, ahol beírhatjuk a listából kiválasztott eszköz vonalkódját.
35
7.8.3. Telepítő módban kiadható parancsok
36. ábra – User Descriptor beállítása
37. ábra – Küldési gyakoriság Ez a router a bejárathoz került, ezért ő a „bejarat” azonosítót kapja. Az 36.ábrán levő alsó keretben látható, hogy ezt az azonosítót le is lehet kérdezni a későbbiek folyamán. 255 teszt üzenetet küld el a 0050C21515151515 című eszköz a telepítőnek, ha egy PER teszt végrehajtását kérjük tőle. A program a megérkezett üzeneteket számolja a timeout leteléséig. A PER teszt eredménye fontos QoS paraméter. Elvégezhetjük pl. a folyosón elhelyezett router és a bejáratnál levő router PER tesztjét. A 39. ábrán átható, hogy az azonosító küldésének gyakorisága megnőtt és a „Test Descriptor” mezőben a „bejarat” szó jelent meg a 0050C21515151515 eszköz sorában.
38. ábra – PER teszt
36
39. ábra – Node Lista (2)
40. ábra – Node Lista (3)
Az 40. ábrán látható, hogy minden eszközhöz rendeltünk leíró részt. LQI mérések segítségével úgy helyezzük el az 5 eszközt az 5 különböző zónában, hogy a kapcsolatok minősége megfelelő legyen, és ezekkel a referencia eszközökkel sikerüljön lefednünk a követési területet, akkor mind az 5 node-ot ZigBee hálóati módba léptetjük.
7.8.4. A hálózat felderítése hálózati módban Miután az 5 eszköz csatlakozott a hálózathoz, lekérhetjük a hálózat struktúráját és az egyes eszközök szomszédossági tábláját. Ha a telepítő eszközt ZigBee hálózati módba léptetjük, ő is csatlakozik a hálózathoz. A LED-ek állapota mutatja, hogy a telepítő eszköz már a hálózat része. Láthatjuk továbbá, hogy a Test Node List gomb helyét a ZigBee Node List és a Structure gomb váltotta fel.
Struktúra felderítés: Megjelent a struktúra felderítés gomb (balról az 5. gomb az alsó toolbaron), rákattintva a hálózatba vitt IEEE address request lekérések segítségével kirajzolódik a hálózat struktúrája. Ehhez mindenképp szükség van, mert így jutunk hozzá az eszközök hálózati címéhez (2 byte-os NWK cím) is, ami szükséges ahhoz, hogy routereinkkel kapcsolatba lépjünk a hálózaton keresztül. Szomszédossági táblák lekérése: További adatok derülnek ki a szomszédossági táblák lekérésével: az eszközök hálózati szerepe, kapcsolat minősége szomszédjaival.
37
41. ábra – ZigBee hálózati mód
42. ábra – a hálózat struktúrája
A hálózat struktúrája: A hálózat feszítő fáját látjuk az 42. ábrán. A fában a hálózati címek vannak feltüntetve, melyeket az egyes eszközök szülőjüktől kaptak csatlakozáskor. A koordinátor hálózati címe mindig 0x0000. A fában 7 eszközt látunk: 5 telepített routert, a koordinátort és magát a telepítő eszközt is. Hogy melyik hálózati címhez melyik IEEE cím tartozik, az a ZigBee Node List dialógus alatt derül ki. ZigBee Node List: Hálózati eszközök listája, a lista elemei: Hálózati címek, gyerekek száma, státusz (ok ha válaszolt, no rsp ha nem), típus, descriptor.
43. ábra – ZigBee Node List
38
A screenshoton látszik, hogy a GUI fektetett képernyő módban is működik. A felület érzékeny arra, hogy fektetett vagy állított üzemmódot használunk és a vezérlőket ennek megfelelően méretezi át.
A ZigBee node list alatt látható navigációs gombok: - More Info: Részletes információs lista nyílik meg a táblázat kiválasztott eszközével kapcsolatban (44-46. ábra). - Commands: Parancsokat küldhetünk a táblázatban kiválasztott eszközenek (47-50. ábra). - Show Tree: A kiválaszott eszközt megmutatja a fa struktúrában (42. ábra).
7.8.5. További információk a hálózatról A koordinátort kiválasztva a ZigBee Node Listában kattintsunk a More Info gombra. Így megnézhetjük, hogy a struktúra és a szomszédossági táblák lekérdezésével milyen adatokhoz jutottunk.
Node Information: Ebben a táblázatban látható a hálózati eszközök 64 bites MAC címe és 16 bites hálózati címe. A mélysége, gyerekeinek száma és gyerekeinek címe a struktúra lekérdezés alkalmával derült ki (lásd 42. ábra). A hálózatban betöltött szerepekhez (koordinátor, router, end device) a szomszédossági táblák lekérésével jutunk (lásd 44. ábra). Neighbour table: A szomszédossági táblában a szomszédok hálózati címe, típusa, a szomszédokkal létesített kapcsolatok minősége (LQI) és a szomszédokhoz való viszony található (lásd 45. ábra). Routing table: A routing táblák lekérésével hozzájuthatunk a hálózaton belül kialakult útvonalakhoz.
45. ábra – Szomszédossági tábla
44. ábra – Információs doboz
39
46. ábra – Routing tábla
A koordinátor minden PAN-ben a 0000 című eszköz. IEEE címe ennek a koordinátornak 1111111111111111. Mélysége 0, szülője nincs, 3 gyereke és 3 szomszédja van. (44. ábra) Az 45. ábrán a 0000 című koordinátor szomszédossági tábláját láthatjuk. 3 szomszédja közül mindhárom gyermek node, egyikük végpont (ez maga a telepítő eszköz) a másik 2 router. Kapcsolatuk minősége a táblázatból kiderül. Ha a 0001 router routing tábláját lekérdeztük, az információs doboz és a szomszédossági tábla mellett elérhetővé válik a routing tábla is (46. ábra). Látható hogy a 796F című eszközt a 0001 a koordinátoron keresztül éri el. A 0002 és 035F eszközzel azonban közvetlen kapcsolata van.
7.8.6. Hálózati parancsok A jelenlegi verzió a következő hálózati parancsokat támogatja.
47. ábra – User Descriptor lekérés
48. ábra – Szomszédossági tábla lekérés
40
49. ábra – Routing tábla lekérés
50. ábra – Visszalépés telepítő módba
7.9. Összehasonlítás a Daintree Telepítő eszközével A Daintree Networks SNA-ja [14] részben teljesíti a 7.3. fejezetben támasztott követelményeimet.
Közös tulajdonságok: 1. Képes a ZigBee hálózati eszközök konfigurálására 2. A kész hálózat struktúrájának feltérképezésére és egyéb hálózati jellemzők megjelenítésére alkalmas. 3. Tesztek hatékony elvégzését segíti elő. Különbségek: 1. Az SNA (Sensor Network Analyzer) laptopon futtatható. 2. Képes biztonsági beállítások elvégzésére, a konfigurálás mellett az eszközök teljes firmware frissítését is el lehet vele végezni. 3. Nem támogatja azonban az eszközökkel való kommunikációt hálózatba lépés előtt, így nem biztosít lehetőséget RSSI mérésekkel és PER tesztekkel segített hálózatépítésre. 4. Nem tart kapcsolatot szerverrel, így a telepítési adatok nem kerülnek be adatbázisba, így nem használható adminisztrációs eszközként sem.
41
8. Összegzés, értékelés, kitekintés Sikerült megvalósítani egy olyan rendszert, amely beltéri objektumok követésére nyújt megoldást. Alacsony fogyasztású mozgó eszközöket egy statikus, referencia csomópontokból álló hálózat figyel. A mozgó objektumok hirdetett üzenetei és a hozzájuk tartozó, mért RSSI értékek a ZigBee hálózaton keresztül központokba kerülnek, ahonnan egy GPRS – ZigBee átjárón keresztül a szerverre jutnak (lásd 3.). A szerveren egy Signpost nevű, egyszerű lokalizációs algoritmus becsüli meg a mobil egységek helyét (zónáját) a követés területén (lásd 5.). Az eredmények kilens oldalon webes felhasználói felületen jelennek meg (lásd 6.). A megvalósított rendszer paramétereinek beállítását egy kompromisszumos döntés eredményeképp végezhetjük el, melyet a fogyasztás, pontosság, hálózati forgalom és költség figyelembe vételével kell meghozni (lásd 3.). A hálózat méretét a szabványban definiált maximális mélység korlátozza (15), de a követés nagy kiterjedésű ipartelepeken is lehetségessé válik, ha több ZigBee hálózatot telepítünk egymás mellé.
51. ábra – Az eredmények megjelenítése webes felületen Összehasonlítás: Dolgozatomban az elkészült rendszert a Texas Instruments hasonló célú megoldásával vetettem össze (lásd 3.). Az én megoldásomban fontos volt az, hogy a mozgó egységek a lehető legalacsonyabb fogyasztással rendelkezzenek, és akár évekig működjenek elemcsere nélkül. A lokalizációs algoritmus szerveren való elhelyezése különböző algoritmusok rugalmas használatát és összehasonlítását teszi lehetővé. A nagy számítási kapacitással rendelkező szerveren összetett feladatok is megoldhatók lesznek (lásd 5.).
42
Rámutattam arra is, hogy a követő rendszer üzembe helyezésénél szükségünk lesz egy telepítő eszköz használata (lásd 3.3.), mely eszközeink elhelyezésében és konfigurálásában, hálózatunk tesztelésében és a telepítés dokumentálásában segít bennünket. Az elkészített telepítő eszközzel felderíthetjük a kialakult hálózat struktúráját, a teljes szomszédossági mátrixot és a kialakult útvonalakat is. A telepítő eszköz (PDA része) kapcsolatot tart a szerverrel, ez nemcsak a telepítés dokumentáltságát biztosítja, de lehetővé válik például a referencia egységek koordinátáinak adatbázisba vitele a követő alkalmazásnál.
Összehasonlítás: Dolgozatomban az elkészült telepítő eszközt a Daintree Networks hasonló céllal készült eszközével vetettem össze (lásd 7.9.).
52. ábra – a telepítő eszköz felületének részlete
Kitekintés - a jövőben a következő feladatok megoldásával foglalkozom: - A tervek szerint a Cason Zrt. segítségével lehetőségem lesz arra a jövőben, hogy a fejlesztett rendszert egy athéni ipartelepen kipróbáljam, ahol 30 targoncát kell követni majd (v.ö. 2. fejezet). - Összetettebb lokalizációs algoritmusok kipróbálása, értékelése és összehasonlítása - A webes felhasználói felület funkcionalitásának növelése: a hálózat és a mozgó entitások grafikus megjelenítésével koordináta rendszerben. - 2008. október 22-én vált elérhetővé ZigBee Pro (ZigBee stack profile 2) a Freescale protokoll stackben. Ennek kipróbálására a követő hálózatban hamarosan sor kerül. - A telepítő eszköz szolgáltatásainak növelése: A saját fejlesztésű telepítő eszköz nagy előnye, hogy alkalmazás szintű konfigurációt és lekérdezéseket is támogathat: a telepítő eszköz szoftverébe és felhasználói felületébe könnyedén beilleszthetők további alkalmazás szintű parancsok.
43
9. Irodalomjegyzék [1] IEEE 802.15.4. – Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs), 2006. [2] ZigBee Specification – 2007 - The ZigBee Specification describes the infrastructure services available to applications operating on the ZigBee platform [3] Practical Considerations of Localization in ZigBee Networks – Spyros Kyperountas, Motorola, 2004. [4] CC2431, System-on-Chip for 2.4 GHz ZigBee / IEEE 802.15.4 with Localisation Engine, Chipcon Products from Texas Instruments, 2007. [5] Channel Conditions in Indoor and Mobile Radio Communications, Lecture Notes, Kolumbán Géza, 2007. [6] Location monitoring with low-cost ZigBee Devices, Mark Norris, Wireless ECE, 2006. [7] MC13213 Reference Manual , Freescale Semiconductor, MC1321xRM.pdf, www.freescale.com/zigbee, 2007. [8] Cason Mérnöki Zrt., www.casonplc.com/Products.aspx [9] Understanding ZigBee Commissioning, Daintree Networks, Understanding_ZigBee_Commissioning.pdf, http://www.daintree.net/resources/index.php, 2007. [10] 1321x Development Kits, Freescale Semiconductor www.freescale.com/webapp/sps/site/prod_summary.jsp?code=1321x_Dev_Kits [11] Free2move’s Serial Port Plug, Free2move, www.free2move.se [12] Microsoft Silverlight, http://silverlight.net/ [13] Freescale BeeStack Software Reference Manual, Freescale Semiconductor, www.freescale.com/files/rf_if/doc/ref_manual/BSSRM.pdf, 2007. [14] ZigBee Commissioning Tools, Daintree Networks, zigbee-commissioning-tools.pdf http://www.daintree.net/resources/index.php, 2007. [15] Self-Calibrating RSSI-based Indoor Localization with IEEE 802.15.4, Paolo Barsocchi, Stefano Lenzi, Stefano Chessa, arp.unipi.it/vedifile.php?ide=122856&fi=self-calibrating%20localization.pdf, 2008. [16] Freescale BeeStack Platform Reference Manual, Freescale Semiconductor, www.freescale.com/files/rf_if/doc/ref_manual/FSPRM.pdf, 2007.
44
