Budapesti Mőszaki és Gazdaságtudományi Egyetem, Villamosmérnöki és Informatikai Kar
TDK dolgozat
ZigBee hálózat analizátor fejlesztése Lengyel Zoltán V. villamosmérnök hallgató
Konzulensek: Bánky Tamás és Csörnyei Márk Szélessávú Hírközlés és Villamosságtan Tanszék 2007. október
Tartalomjegyzék 1. Bevezetés – vezeték nélküli szenzorhálózatok és a ZigBee
3
2. A hálózat analizátor specifikációja és komponensei
5 6 7 8
2.1. Szenzor mezı 2.2. Megfigyelık (observers) 2.3. A PC-n futó felhasználói program, betöltött szerepek
3. Az elkészített monitor rendszer rétegei 3.1. Adatgyőjtés, megfigyelés (Sniffer HW) 3.2. Adatkoncentrálás (SW) 3.3. Adatfeldolgozás, analizálás (SW) 3.4. Megjelenítés (SW) 3.5. Lekérdezı egység (commander HW, SW) 3.6. Értelmezés 3.7. Konzol és menedzsment
4. A saját fejlesztéső adatgyőjtı Sniffer eszközök és azok szoftveres vezérlése 4.1. Az adatgyőjtı Sniffer hardver specifikációja 4.2. Az IEEE 802.15.4-es szabványnak megfelelı hardver legfontosabb tulajdonságai 4.3. A legfontosabb paraméter: bemeneti sebesség 4.4. Sniffer firmware terv 4.5. A bemeneti sebesség becslése 4.6. Az adatgyőjtık RS232 – USB interfésze 4.7. A Sniffer eszközök vezérlése a kezelıprogrammal
9 9 10 10 11 11 11 11
12 12 12 14 16 18 19 19
5. A monitor program (I.) – az adatkoncentrátor és megjelenítés (PHY nézet) 20 5.1. Nyomok (trace-ek) 5.2. Üzenetek összefésülése, redundáns üzenetek kezelése, archiválás, kliens-szerver 5.3. Rendszerüzenetek, kliensek csatlakozása egy távoli szerverhez
20 23 24
6. A monitor program (II.) – az analizátor és megjelenítés
25 25 28 31
6.1. Csomag szőrı (packet filter) 6.2. ZigBee csomag dekóder 6.2.1. MAC nézet és MAC réteg, csatlakozási folyamatok a 2. példahálózatban
1
6.2.2. NWK nézet és NWK réteg, route-ok kiépülése és riasztások a 2. példahálózatban 6.2.3. APS nézet és APS réteg, binding és riasztások a 2. példahálózatban
6.3. Statisztika 6.4. Hálózati struktúra 6.5. Szomszédossági mátrix 6.6. Hálózati forgalom, node-ok aktivitása 6.7. PER (packet error rate) teszt
33 36 36 37 39 40 40
7.2. Csomópontok terhelésének eloszlása 7.3. Protokoll stack hibák kiszőrése
42 42 42 43 44 45
8. Lekérdezı egység
46
9. Hálózati csomópontok fejlesztése
48 49 50
7. ZigBee hálózatok vizsgálata 7.1. Hálózat regenerációja – Freescale Protocol Stack 7.1.1. Router kiesése a hálózatból 7.1.2. Koordinátor átmeneti kiesése a hálózatból
9.1. A füst érzékelése 9.2. A detektor eltávolításának érzékelése
10.1. Adatgyőjtık illesztése GSM/GPRS modemhez
51 52
11. Köszönetnyilvánítás
53
12. Irodalomjegyzék
53
13. Függelék
56 56 57 58
10. Értékelés és kitekintés
13.1. A Sniffer kapcsolási rajza 13.2. Layout terv – Top 13.3. Layout terv – Bottom
2
1. Bevezetés – vezeték nélküli szenzorhálózatok és a ZigBee Ahogy a vezeték nélküli szenzorhálózat technológia fejlıdik, az erre épülı alkalmazások egyre szélesebb területen hódítanak teret. A hatékony fejlesztés, a különbözı gyártók eszközeinek együttélése és egymással kompatibilis termékek létrehozása szabványosítással érhetı el. A ZigBee Alliance cégek szövetsége, mely az IEEE 802.15.4 WPAN szabványában specifikált fizikai (PHY) és közeghozzáférési (MAC) rétegekre építve létrehozott egy nyílt szenzorhálózat szabványt. A ZigBee szabvány alkalmazásának robbanásszerő terjedését érzékelteti, hogy 2005-ben már mintegy 1 millió ZigBee eszköz készült el, becslések szerint 2010-re ez a szám több mint 160 millióra növekedhet. Az alkalmazások megalkotásához elengedhetetlen olyan eszközök használata, melyekkel a fejlesztés alatt álló hálózat mőködése folyamatosan tesztelhetı valamint az elkészült és még megfigyelést igénylı rendszer felügyelhetı egy távol elhelyezkedı számítógépen is. Az elmúlt fél évben egy ZigBee hálózat fejlesztését segítı és azt monitorozó rendszert terveztem és valósítottam meg. A munkát a tanszéken folyó szenzorhálózatok fejlesztése ösztönözte. Általános szenzorhálózat jellemzık: A vezeték nélküli szenzorhálózatok közös jellemzıi az alacsony átviteli sebesség, rövid hatótávolság, alacsony költség, kis fogyasztás – így hosszú élettartam (1-10 év elemmel mőködtetve), hibatőrés, robosztusság. A rádiós kommunikáció az engedélyhez nem kötött ISM sávokat használja. A hálózatot alkotó node-ok lehetıség szerint kis méretőek, a processzor sebessége és memóriája limitált. A hosszú élettartam elérése érdekében az egységek nagyon kis kitöltési tényezıvel üzemelnek. ([1], 5.5.5) A szenzorhálózat alkalmazásának nagy elınyei a magas árú vezetékezés elkerülése, az alacsony telepítési költség valamint az egyszerő bıvíthetıség és karbantarthatóság. A ZigBee Alliance jelenleg több mint 200 tagja támogatja a szabvány elterjedését, hoz létre SW és HW termékeket és teszteli a technológia együttélését más vezeték nélküli technológiákkal. [3] Alkalmazási területek: • Mérnöki alkalmazások (épületek, mőtárgyak statikai monitorozása, közlekedés) • Egészségügy: (kórházi menedzsment, katasztrófa elhárítás, otthoni betegellátás) • Gyártás, raktározás (gyártósor monitorozás, készletnyilvántartás) • Környezetvédelem (élıhely monitorozás, katasztrófa elırejelzés) • Mezıgazdaság („precíziós mezıgazdaság”)
3
1. ábra - Az IEEE 802.15.4 és ZigBee szabványok illeszkedése [4]
• • •
Épület automatizálás (intelligens otthon, intelligens munkahely) Védelmi alkalmazások (megfigyelés, követés, detektálás) [5] Szórakoztató elektronika
ZigBee kompatibilis termékek nemcsak szigorú értelemben vett szenzorhálózat alkalmazásokban fordulnak elı, elképzelhetünk egy olyan otthont, ahol elektronikus eszközeink (villanykapcsolók, főtésvezérlés, biztonságtechnikai rendszerek, szórakoztató elektronikai eszközök stb.) egyetlen hálózatba kapcsolódnak [30] és például egy mobiltelefonnal vezérelhetık. Az elsı ZigBee kommunikációra is képes mobiltelefon már 2004-ben elkészült [31], a piacra dobásra azonban még itt is várni kell. Néhány ZigBee szabványnak megfelelı rádiós chipet gyártó cég: Atmel (AT86RF230), Duolog (WP2400), Jennic (JN5139), Ember (EM260), Freescale Semiconductor (MC13213), MaxStream (Xbee), Silicon Labs, Texas Instruments (CC2430). Jelenleg a ZigBee legelterjedtebb felhasználási területe az épület automatizálás, példaként néhány ismert cég, melyek hatékony kereskedelmi forgalomban levı termékekkel jelentek meg az utóbbi idıben ezen a piacon: Siemens, TAC: épületautomatizálás ipari, irodai felhasználásra [29], Control4: épületautomatizálás otthoni felhasználásra – világítás, hımérséklet szabályozás, vagyonvédelem, szórakoztató elektronika [30], A Software Technologies Group nemcsak protokoll stacket, hanem szenzorokat, gateway-t is kínál. Honlapjuk kész szenzorhálózat alkalmazást mutat be termeszek detektálására. Az utóbbi években hazai kisvállalkozások is (pl. SpinBee Kft.) mára külön fejlesztési profilt képesek építeni a ZigBee technológiára alapozva.
4
2. A hálózat analizátor specifikációja és komponensei Specifikáció: A TDK munkához kapcsolódó fejlesztés célja egy olyan monitor rendszer létrehozása, mely lehetıséget nyújt: • Az éppen fejlesztett ZigBee hálózat mőködésének folyamatos tesztelésére. • A már elkészült hálózat mőködésének ellenırzésére. 1. A szenzormezıbe kihelyezendı adatgyőjtı hardver eszközök megvalósítása a cél, melyekkel a hálózaton folyó vezeték nélküli kommunikáció rögzíthetı és USB kábelen egy számítógép felé továbbítható. 2. Továbbá egy olyan Windows alatt futtatható monitor program elkészítése a cél, amely elvégzi az üzenetek szőrését, az IEEE 802.15.4. és ZigBee szabványú csomagok dekódolását, archiválását, statisztikát készít, feltérképezi a hálózat struktúráját, ábrázolja a hálózati forgalom és az egyes node-ok aktivitásának változásait, tesztek elvégzését segíti elı. A program adatait egy távoli, ismert IP címő szerverre küldheti tovább, így a hálózat megfigyelhetı egy szerveren futó monitor programmal a hálózattól távol is. 3. Cél továbbá egy olyan eszköz elkészítése, mellyel lehetséges a hálózati csomópontok lekérdezése és ezzel további információ nyerése. A ZigBee hálózat analizátor segít következtetéseket levonni a fejlesztett csomópontokon levı hálózati protokoll stack és az alkalmazási réteg mőködésérıl, a hálózat teljesítıképességérıl, a node-ok terhelésének eloszlásáról. Megkönnyíti az egységek minısítését RF szempontból és elhelyezésük optimalizálását a hálózat telepítésénél. Mindezzel a szenzorhálózat megbízhatóságának és az alkalmazás minıségének javítására nyújt hatékony megoldást.
2. ábra – A hálózat és az azt megfigyelı rendszer
5
A következı fejezetekben a monitor rendszer felépítését, majd az azt alkotó logikai rétegeket tárgyalom, késıbb nemcsak az egyes komponensek és rétegek részletes bemutatására kerül sor, hanem a megvalósításkor figyelembe vett szempontok, felmerülı problémák és lehetséges továbbfejlesztési lehetıségek áttekintésére is.
2.1. Szenzor mezı A ZigBee vezeték nélküli szenzorhálózat a hálózat központjából (PAN koordinátor), a szenzorokat és beavatkozókat tartalmazó hálózati végpontokból (end device) és forgalomirányító (router) csomópontokból áll. A koordinátor felelıs a PAN (Personal Area Network) létrehozásáért, a hálózat szinkronizálá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. ([2], 1.1.4) Az IEEE 802.15.4-es szabvány kétféle funkcionalitású eszközt definiál: • Full-function device (FFD): FFD az elıbb felsorolt mindhárom szerepet (koordinátor, router, végpont) betöltheti, FFD-vel és RFD-vel is folytathat kommunikációt. • Reduced-function device (RFD): Csak hálózati végpont szerepét töltheti be és csak FFD-vel kommunikálhat. Ezek tipikusan egyszerő eszközök (pl. kapcsoló vagy infravörös szenzor), melynek nincs szüksége nagy mennyiségő adat küldésére és minimális memória kapacitással rendelkezik. Hozzájuk csatlakozni nem lehetséges. Általában telepes tápellátásúak. ([1], 5.1) A szabvány két hálózati topológiát határoz meg: • Csillag (Star): Kommunikáció csak a hálózat koordinátora és a csomópontok között lehetséges. • Peer-to-peer: Ebben elviekben bármely két eszköz között lehet üzenetváltás. o Cluster tree: A peer-to-peer topológiából származtatva bonyolult hálózati struktúrák alakíthatók ki, egy speciális peer-to-peer eset a cluster fa is. Az FFD eszközökhöz újabb FFD-k illetve RFD-k csatlakozhatnak, az utóbbi node-ok a fa leveleit alkotják, hiszen hozzájuk csatlakozni nem lehetséges. ([1], 5.3) A lehetséges telepítési módok: • Ad-hoc: Az egységek telepítése véletlenszerő, ezek a szomszédos (hallótávolságon belüli) csomópontokkal kommunikálnak. Tartozhat a hálózathoz egy nyelı, mely legalább egy csomópont szomszédja kell legyen. • Tervszerő: Az egységek tudatos elhelyezése, melyet pl. a monitorozó rendszerünk segíthet (lásd: 6.3.). A hálózat analizátor fejlesztése során a Freescale Semiconductor ZigBee kompatibilis 13192SARD szenzorkártyái, valamint tanszéki tervezéső próbakártyák alkották a szenzorhálózatot. Rájuk kezdetben Freescale BeeKit BeeStack protokoll stackjének példaprogramjai kerültek beégetésre ([17], [18], [19], [20], [21]), majd saját magam írtam példa-alkalmazásokat. Dolgozatomban példahálózatok kerülnek majd bemutatásra, amiket a
6
3. ábra – Freescale 13192SARD kártya
4. ábra – Tanszéki fejlesztı kártya
fejlesztett monitor rendszerrel figyeltem (lásd: 7.). A hálózat analizátor a tanszéki ZigBee szenzorhálózat fejlesztésében jelenleg is részt vesz.
2.2. Megfigyelık (observers) A saját fejlesztéső Sniffer HW egységek végzik az adatgyőjtést, és ZigBee – USB interfészt valósítanak meg (lásd: 4.). Csillag hálózati topológia esetén érdemes egyetlen megfigyelıt a koordinátor mellé helyezni, aki definíció szerint mindenkivel kapcsolatban van, így a hálózat analizátor az egész hálózat életét nyomon követheti. Peer-topeer hálózat esetén több Sniffer eszközt a szenzor mezı különbözı pontjaira helyezünk el, lehetıleg úgy, hogy minden node valamelyik Sniffer hallótávolságán belül legyen. A megfigyelı egységek USB kábellel csatlakoznak a PC-hez, amin az analizáló program fut, ez a felhasználói interfész. Az USB specifikáció szerint az USB kábel 5. ábra – a megfigyelhetı maximális hossza 5 m lehet, ha nem alkalmazunk hubokat. szenzormezı mérete [6] Ez korlátozza a megfigyelhetı szenzormezı méretét. Az IEEE 802.15.4. szabvány fizikai rétegének megfelelı eszközök beltérben kb. 10 m sugarú hallótávolsággal kell rendelkezzenek. ([1], 1.2) Az 4. ábra szemlélteti egy ideális esetben beltérben megfigyelhetı 2 dimenziós szenzormezı méretét, ha 4 Sniffert helyezünk el az ábrán látható módon, melyek USB kábellel csatlakoznak az analizátort programot futtató PC-hez. A felügyelhetı hálózat mérete kiterjeszthetı több kliens PC csatlakozásával egy szerverhez. GPRS kommunikáció: Ha a Sniffer hardverhez GPS/GPRS modemet illesztünk, mentesülünk a kliens számítógépekhez való kötıdéstıl és a szenzorhálózat tetszıleges telepítési helyen tesztelhetıvé válik. Az analizátor programot felkészítettem arra, hogy távoli kliensek kapcsolódhassanak hozzá. Ezek pedig nem feltétlenül PC-k, lehetnek olyan adatgyőjtık is, melyek olyan GPS/GPRS modemet tartalmaznak, melyeken belsı TCP/IP stack
7
van. Ezzel kapcsolatos megfontolásokat a 10.1. rész tartalmaz. A megvalósításra a közeljövıben fog sor kerülni.
2.3. A PC-n futó felhasználói program, betöltött szerepek A számítógépen saját fejlesztéső analizátor program fut, mely a csomagok dekódolást, a hálózati struktúra felrajzolását, statisztika készítését, stb. végzi (lásd: 5., 6.). A felhasználói program 3 szerepő lehet: Egyedülálló (standalone application): A számítógép a hálózat mellett található, pl. az 5. ábrán látható módon elhelyezve, hozzá Sniffer hardverek csatlakoznak USB kábelekkel. Kliens: Olyan applikáció, amivel az internetre csatlakozó számítógép egy ismert IP címő szerver PC-nek küldheti ki a begyőjtött adatokat. Szerver: A szerverhez megfigyelı egységek nem köthetık, adatait távoli kliens PC-(k)tıl kapja, melyek a ZigBee hálózatnál helyezkednek el. A szerver program valós idıben végzi a csomagok dekódolását és az analízist, így a hálózat mőködése nyomon követhetı. A program a 6. ábrán látható dialógussal indul, itt választhatók ki azok a COM portok, melyekre adatgyőjtı egységek csatlakoznak. Az "application role" keretben a betöltött szerep állítandó be.
6. ábra – COM portok és szerepek kiválasztása az analizátor programban
8
3. Az elkészített többkomponenső monitor rendszer rétegeinek áttekintése A monitor adatok összegyőjtésével és azok kiértékelésével a rendszer viselkedését és teljesítıképességét írja le. A szenzorhálózatok mőködésének tesztelésére egy eseményvezérelt on-line hálózati monitor fejlesztése célszerő. A triggermechanizmus fajtája szerint eseményvezérelt, hiszen bizonyos események – rádió üzenetek vétele – esetén aktivizálódik. Az eredmények megjelenítésének módja szerint pedig on-line monitorról beszélhetünk, ha a mérés és az abból levont következtetések kijelzése folyamatos. Azonban az adatok archiválásával lehetıség kell nyíljon azok késıbbi elemzésére is. [7], [8] A monitorozó rendszer több HW és SW komponensbıl áll. A többkomponenső rendszer a következı rétegeket valósítja meg:
7. ábra – a megvalósított monitor rendszer rétegei és komponensei
(Minden soron következı réteget én terveztem és valósítottam meg.)
3.1. Adatgyőjtés, megfigyelés (Sniffer HW) A megfigyelés az egymástól függetlenül mőködı adatgyőjtıkben (saját fejlesztéső Sniffer hardverek) implicit kémkedésnek (implicit spying) hívott módon történik: válogatás nélkül minden üzenetet vesznek a beállított csatornán. Nem részei a hálózatnak, nem kommunikálnak 9
a szenzor csomópontokkal, így többletterhelést sem jelentenek. (Overhead: a monitor mőködésébıl adódó többlet terhelés, amely megváltoztathatja a rendszer mőködését és ezzel hibás képet mutat a hálózatról.) [7], [8] Az implicit kémkedést szoftveres szőrıvel kombinált, mely az analizátor réteghez tartozik (lásd: 6.1.). A fejlesztett rendszerben egy PC-hez legfeljebb 10 különbözı Sniffer csatlakozhat. A tartomány (domain) a monitor által megfigyelhetı események halmaza. A Sniffer eszközök számára a hálózati csomópontok által küldött üzenetek számítanak eseménynek. A nyom (trace) az eseményekhez kötıdı bejegyzések, melyeket részben az adatgyőjtı, részben a koncentrátor illeszt az üzenethez, ezek az eseményhez szorosan kapcsolódó adatok (vett jel erıssége, esemény ideje, forrása, stb.) (bıvebben lásd: 5.1.). [7], [8]
3.2. Adatkoncentrálás (SW) • • • • •
Összefésülés: A koncentrátor a Snifferek által összegyőjtött üzeneteket összefésülve helyezi el az adatbázisban. Bélyegek hozzárendelése: Egyes mőveleteket még az adatgyőjtık végeznek (LQI mérés), de a legtöbb bélyeget az adatkoncentrátor rendeli az üzenetekhez. Redundáns üzeneteket figyelmen kívül hagyása: Egy üzenet redundáns, ha két különbözı megfigyelı által ugyanaz a csomag regisztrált (lásd: 5.2.). Adatok archiválása és importálása: A késıbbiekben a kimentett csomagok visszatölthetık, így az analízis és az értelmezés késıbb elvégezhetı (lásd: 5.2.). Ha a felhasználói programban a kliens szerepet állítjuk be, akkor lehetséges, hogy az analizátor program egy távoli PC szerverre csatlakozhasson. A szerver PC-n futó program adatkoncentrátora a saját analizátor moduljának adja át az adatokat. A felügyelt hálózat mérete kiterjeszthetı több kliens PC csatlakoztatásával egyetlen szerverhez.
3.3. Adatfeldolgozás, analizálás (SW) •
•
Csomag dekóder: Dekódolja a IEEE 802.15.4-es és ZigBee szabványok szerint az üzeneteket. A PHY, MAC, NWK, APS szintő információk különbözı nézetek felé kerülnek továbbításra (lásd: 6.2.). A csomagok dekódolása is saját fejlesztéső algoritmus szerint történik. Elvégezhetı olyan szenzorhálózat vizsgálata is, mely PHY és MAC rétegében teljesen megfelel az IEEE 802.15.4-es szabványnak, de további rétegei nincsenek megvalósítva vagy nem szabványosak. Csomagszőrés: A MAC nézetben részben specifikálható az a szőrı, amely kiszőri azokat a beküldött csomagokat, amik: o Nem tartoznak a viszgált PAN-hez (Personal Area Network). o Nem IEEE 802.15.4 / ZigBee szabvány szerint mőködı, de ugyanazt a frekvenciasávot használó elektronikus eszköz kommunikációjából származnak (pl. egy Bluetooth eszköz mőködése), a ZigBee szenzorhálózat számára zavarnak tekinthetık. o Ütközött csomagok. (lásd: 6.1.) A PHY nézetben a kiszőrt csomagok is megjelenítésre kerülnek, de mivel nem jutnak felsıbb rétegekbe, MAC, NWK és APS szintő dekódolásuk már nem történik meg.
10
Statisztika: Az üzenetek tartalmának ismeretében statisztika készíthetı (lásd: 6.3.). Struktúra felderítés: A hálózatba becsatlakozó node-ok egy fa struktúrába szervezhetık a szülı – gyermek kapcsolatok nyilvántartásával (lásd: 6.4.). • Szomszédossági mátrix: Annak a felderítése, hogy a hálózat mely node-jai szomszédosak egymással (lásd: 6.5.). A bemeneti szélesség az egyetlen eseményhez kötıdı információs bitek halmaza, mely a monitorban elraktározásra kerül [7], [8]. Esetünkben ezen nem csupán a szabványok által teljes mértékben dekódolt csomag értendı, hanem mindaz, ami belıle következik és az adatbázisba felvételre kerül. Itt ahhoz a kulcskérdéshez jutottunk, hogy milyen következtetéseket is vonhatunk le hálózatunkról a vett üzenetek birtokában (lásd: 5.,6.).
• •
3.4. Megjelenítés (SW) • • • • • •
A PHY, MAC, NWK, APS nézetekben a szabványok szerint dekódolt üzenetek jelennek meg (lásd: 5., 6.2.). A hálózati struktúra egy külön nézetben rajzolódik ki (lásd: 6.4.). Újabb nézetet kapott a statisztika és a hálózat szomszédossági mátrixa (lásd: 6.3., 6.5.). Grafikon mutatja a hálózati forgalom és a node-ok aktivitásainak változásait (lásd: 6.6.). A PER (Packet error rate) tesztet egy külön nézetben lehet elvégezni (lásd: 6.7.). A rendszerüzenetek egy elrejthetı ablakban jelennek meg (lásd: 6.8.).
3.5. Lekérdezı egység (commander HW, SW) Implicit kémkedéssel nem mindig jutunk hozzá minden információhoz, amire szükségünk van. Egy olyan egységet is megvalósítottam, mellyel a hálózati node-ok lekérdezhetıvé válnak a tesztelı rendszerben. Szondázásnak vagy probingnak hívjuk azt a monitorozási módszert, amikor speciális üzeneteket továbbítunk a hálózatba, és ezek segítségével jutunk hozzá többlet információhoz. [7], [8] A hálózati forgalmat növeli. Fejlesztés közben vizsgálhatjuk különbözı üzeneteknek a hálózat node-jaira való hatását. (Lásd 8. rész)
3.6. Értelmezés Ezen a megjelített információhalmaz értelmezése értendı. Ezt a fejlesztendı ZigBee hálózatot tesztelı mérnök vagy a kész hálózatot megfigyelı hálózat menedzser végzi.
3.7. Konzol és menedzsment A konzollal lehetséges a rendszer paramétereinek megváltoztatása, mely a monitor által szolgáltatott adathalmaz értelmezése alapján történik [7], [8]. Hivatott erre egy speciális HW eszköz is, ami kommunikációra képes a szenzor egységekkel, és üzenetek váltásával képes azok paramétereit befolyásolni. Erra a célra korlátozott mértékben szolgálhat a 8. részben tárgyalt lekérdezı egység is. A legtöbb alkalmazásban érdemes ilyen funkciókkal ellátni a hálózat koordinátorát is. A menedzsment döntéseket hoz a monitor mérései alapján és elképzeléseit a konzolon keresztül valósítja meg.
11
4. A saját fejlesztéső adatgyőjtı Sniffer eszközök és azok szoftveres vezérlése 4.1. Az adatgyőjtı Sniffer hardver specifikációja Olyan adatgyőjtı egység tervezése volt a cél, ami: • szolgáltatja azt a hardvert, ami egy 2.4 GHz-es ISM sávban, az IEEE 802.15.4-es szabványnak megfelelıen mőködı csomópontnak szükséges, így a szabványos ZigBee üzenetek vételére képes. • elegendı mérető RAM-ot tartalmaz a vett üzenetek átmeneti tárolására (lásd: 4.4.) • a PC-hez USB kábellel képes csatlakozni (lásd: 4.5., 4.6.), melyen keresztül o képes a vett üzenetek és a hozzájuk tartozó mért jelerısség LQI (link quality indicator) beküldésére a PC-nek o vezérelhetı a PC-n futó analizátor programból.
8. ábra - A Sniffer hardver blokkvázlata
4.2. Az IEEE 802.15.4-es szabványnak megfelelı hardver legfontosabb tulajdonságai
A MC13213 System in Package (SiP) egy HCS08 mikrokontrollert és egy MC13192 ZigBee modemet integrál. A ZigBee chip és a µC között SPI interfész teremt kapcsolatot. A µC 60kB Flash-sel és 4kB RAM-mal rendelkezik. [9] Az IEEE 802.15.4 szabvány 3 ISM sávot definiál: 868 MHz : Európa, 915 MHz : USA, 2.4 GHz : világszerte. Az MC13213 a 2.4 GHz-es sávot használja, mely 16 csatornára osztható fel: Fc = 2405 + 5 (k – 11) MHz, ahol k = 11, 12, …, 26 a csatorna száma. ([1], 6.1.2.1) Ebben a sávban a beltéri hatótávolság 10 méter, szabadban 200 m, így a ZigBee-t a WPAN ill. WLAN hálózatok közé sorolhatjuk. A csatorna hozzáféréséhez CSMA/CA (Carrier sense multiple access with collision avoidance) algoritmust használ. ([1], 5.5.4) Átviteli sebesség: 250 kbit/s, az egyéb vezetéknélküli technológiákhoz képest alacsony átviteli sebesség miatt a hálózat a LR-WPAN (low rate) kategóriába kerülhet. Az alacsony átviteli sebességgel teljesíti a szenzorok és beavatkozók igényeit. ([1], 5.1)
12
DSSS (direct sequence spread specturm) és O-QPSK (offset quadrature phase-shift keying) modulációs technikát használ. ([1], 6.8.2) A megérkezett csomagok energiáját mérve LQI-t (Link Quality Indicator) állapít meg minden egyes üzenethez. ([1], 6.9.8)
9. ábra - A ZigBee üzenetek fizikai (PHY) szintő keretformátuma ([1], 6.3) SHR (Szinkronizációs header): A Preamble (elıtag rész) egyrészt jelzi, hogy ZigBee üzenet érkezik másrészt a vevı erre a bitmintára szinkronizálódik rá. Az SFD a szinkronizációs bitminta végét és a csomag kezdetét jelzi. PHR (PHY header): Az üzenet hosszát tartalmazza. PHY payload: MAC szintő keretet tartalmaz. ([1], 6.3) A fizikai réteg által továbbított csomag maximális hossza 127 byte. Az adatgyőjtıktıl az adatkoncentrátornak továbbítandó a PHY payload és az üzenethez tartozó LQI. A rádió frekvenciás áramkör: Az RF rész megtervezése kritikus minden rádiós szenzor csomópont és a Sniffer hardver megfelelı hallótávolsága és teljesítménye szempontjából is. Különösen igaz ez a keveset fogyasztó kompakt tervezés esetén, ahol a rendelkezésre álló hely általában kevesebb, mint szükséges lenne. Mivel a tanszéki ZigBee próba kártyák chip antennát tartalmaztak és már voltak tapasztalataim velük, így az adatgyőjtık hardvere is egy chip antennát kapott, ezzel elkerülve az antenna tervezés nehézségeit. A Johanson Technology egy 2.4 GHz-es balunja (2450BL15B050) [11] alakítja át az antenna aszimmetrikus jelét a modem számára szükséges szimmetrikus jellé, az illesztı hálózat meghatározásakor az alkalmazási segédlet utasításait követtem. [9], [10].
10. ábra – az adatgyőjtı RF része Mivel az alkalmazás csak vételt igényel, csak egy vevıantennát kellett felhasználni, az illesztı hálózat a µC RFIN_P, RFIN_M portjaihoz csatlakozik, az IC-be beépített LNA (Low Noise Amplifier) javítja a vétel érzékenységét.
13
11. ábra – Az elkészült Sniffer Layout tervezés: A tervezésnél fontos volt, hogy a kész áramkör egy kb. 1.7 x 4 cm alapterülető tokba beleférjen. (A beültetésre nem került LED-ek csak debuggolás céljára kerültek a PCB-re, ezek és az oldalsó üresen hagyott sáv még levágandó.) A kapcsolási rajzot és a layout tervet a Függelék tartalmazza.
4.3. A legfontosabb paraméter: bemeneti sebesség Bemeneti sebesség (input rate): A bemeneti sebesség az események gyakoriságának az a maximális értéke, amelyet a monitor még hibátlanul meg tud figyelni. [7], [8] Két félét különböztethetünk meg: o folyamatos esetben azt a sebességet kell megadni, amit a rendszer tartósan elvisel. Ez a hálózat maximális átlagos forgalmát jelenti kbit/sec-ban megadva (lásd 4.5.). o lökésszerő (burst) esetben azt a sebességet kell megadni, amit a rendszer még rövid távon kezelni tud. Esetünkben ez az érkezı ZigBee üzenetek ideiglenesen megnövekedett érkezési gyakorisága: az átmenetileg megnövekedett hálózati forgalom. [7], [8] A folyamatos a lökésszerő bemeneti sebességnél értelemszerően kisebb. Amennyiben a bemeneti sebességnél nagyobb az események gyakoriságának az értéke, hibás mőködés lép fel (lásd: 4.4.). A legfontosabb követelmény: gyorsaság: Az alkalmazás idıkritikus – a legfontosabb cél a lehetı legkisebb arányú csomagvesztés elérése. Tehát az eszköznek minimum olyan gyorsan kell mőködnie, mint a többi hálózati csomópontnak. Az órajel frekvenciájának növelése: Az órajel frekvenciájának emelésével a µC sebessége növelhetı. A 16 MHz-es kvarc által szolgáltatott órajelbıl a ZigBee chip 62.5 kHz-es külsı órajelet állít elı, melyet a µC használ. A mikrokontroller PLL-ével felszorozva a következı f ⋅ 64 ⋅ z összefüggés szerint számolható ki a busz frekvencia: f Bus = ext , ahol z a µC ICGC2 2 14
regiszterében beállítható változó. Ha z=10 f Bus = 20MHz . A 20 MHz a µC számára beállítható busz frekvencia maximális értéke, így választásom erre esett.
A soros kommunikáció sebessége: Magasabb baud rate magasabb lehetséges bemeneti sebességet tesz lehetıvé, a soros kommunikáció egy szők keresztmetszetnek számít. A baud rate-t a busz frekvencia leosztásával kaphatjuk meg a következı összefüggés szerint: f BR = Bus [9] Az osztás nagyságát (x) a µC baud rate regiszterében kell beállítanunk. A PC-n 16 ⋅ x futó analizátor program COM port kezelı részének fejlesztéséhez egy olyan C++ osztályt használtam fel [26], mely által támogatott maximális baud rate 115200 pbs volt. A vétel módjának beállítása: A ZigBee chip 2 féle módban történı vételt támogat, ezek összehasonlítása: • Packet Receive Mode: az adat a ZigBee chipen található packet RAM-ban tárolódik és csak a teljes csomag vétele esetén generálódik megszakítás, az IT rutin feladata, hogy kiolvassa a RAM-ból a teljes csomagot, ezalatt új csomag vétele nem lehetséges. • Stream Receive Mode: a vétel word-by-word alapon (2 byte-onként) történik. Az elsı interrupt a vétel kezdetekor generálódik, ekkor olvasható ki a csomag hossza. Ezután minden szó (2 byte) vétele után generálódik interrupt RX_IRQ státusszal. A csomag teljes vétele után STREAM_DONE státusszal történik megszakítás (vö. 12. ábra). [9] A Packet Mode elınye, hogy a ZigBee chip nem igényeli a mikrokontroller beavatkozását a teljes csomag vétele alatt. Stream Mode esetén szavanként szükséges az interrupt kiszolgálása, azonban az adat vétel során azonnal rendelkezésre áll és feldolgozható, elmenthetı szavanként. Ekkor nem kell majd hosszú idıt eltölteni a packet RAM vétel utáni hosszú olvasásával és mentésével. Fejlesztés során mindkét mód kipróbálásra került. Tapasztalataim szerint a Packet Receive Mode nagyarányú csomagvesztéssel jár, hiszen amíg a mikrokontroller a teljes packet RAM-ot üríti, minden érkezı üzenetet elveszt. Ezzel szemben Stream Receive Modeban, szavanként történı vétel esetén, a teljes csomag vétele után a ZigBee chip azonnal készen áll a következı üzenet fogadására, ennek ára a bonyolultabb kiszolgálási algoritmus. A Sniffer alkalmazás során nagy hangsúlyt kell fektetnünk a lehetı legkisebb mértékő csomagvesztésre, hogy a hálózat mőködésérıl minél pontosabb képet kapjunk, így a Stream Receive Mode alkalmazandó. [9]
LQI mérés: Minden vett üzenethez tartozik egy LQI, melyet a vett jel erısségének mérésével kapunk meg. Ez az egyetlen trace (lásd: 3.1.), amit az adatgyőjtı Sniffer illeszt az eseményhez. Ennek minden üzenet utáni kiküldése a soros vonalon csökkenti a maximális bemeneti sebességet, de hasznos információkat nyújt az egyes csomópontokról. Az LQI értékek általában -18dB és -95 dB közé esnek. A skála felsı részén az érték erısen nemlineárisan változik. ([9], 7.3.5)
15
4.4. Sniffer firmware terv A programban 3 fı állapotot különböztetünk meg (12. ábra): • 1. Menü állapot: itt beállíthatjuk a kívánt csatornát és elindíthatjuk a Sniffert. Leállításával a program ebbe az állapotba kerül. Itt vétel nem lehetséges, az interruptok le vannak tiltva. • 2. Alapállapot: Ha új teljes csomag vételérıl értesül (transmit jelzıflag, amit az interrupt rutin állít be), akkor azt kiküldheti soros vonalon. Ezt az állapotot interrupttal (vétel vagy error) hagyja el a program a 3. állapotba vagy a Sniffer leállításával az 1. állapotba. • 3. Interrupt rutin: Ebben az állapotban olvassuk ki a vett csomagot a ZigBee chiprıl, így nem fogadhatunk közben másik csomagot. Minden esetben a ZigBee chip státusz regiszeterének kiolvasásával indul, melybıl kiderül az interrupt oka: - Vétel történt: Amennyiben ez egy üzenet vételének kezdete, a csomag hosszát kell kiolvasni a chip egy regiszterébıl, ahova a vett keret 9. ábrán ismertetett PHR részébıl kerül. Ezután a program kilép az interruptból és a vétel folytatását, így újabb interrupt bekövetkezését várja, amit az érkezı szó elsı byte-jának kiolvasásával szolgálunk ki. Ha a csomag hossza szerint a csomagnak itt vége van, akkor visszatérünk a 2. állapotba. Ha még nincs vége, kiolvassuk a második byte-ot is és csak ezután térünk vissza a 2. állpotba. - Stream done: Teljes csomag vételének befejezıdése esetén generálódik. Ki kell olvasnunk a státusz regisztert, ezzel az interrupt nyugtázásra került. Visszatérünk a 2. állapotba. A ZigBee chip új üzenet fogadására kész. - Stream error: Hiba történt vétel közben, általában ez akkor lép fel, ha egy megszakítást nem kezeltünk le idıben. Stream Mode-ban egy interrupt kiszolgálására maximum 64 mikrosec fordítható (páratlan számú byte hosszú csomag esetén az utolsó byte kiolvasására csak 32 mikrosec áll rendelkezésre). Ennek a feltételnek a megsértése esetén a rendelkezésre álló adat felüíródhatna, így a chip error státusszal vált ki interruptot.
12. ábra – Leegyszerősített firmware blokkvázlat
16
Csomagok átmeneti tárolása - cirkuláris puffer: Puffertöltési folyamat: A csomagok átmeneti tárolása a mikrokontroller 4 KB-os RAM-jának nagy részét elfoglaló cirkuláris pufferban történik. Az interrupt rutin (3. állapot) itt raktározza el a vett üzeteteket és itt maradnak mindaddig, amíg a program megszakítható 2. állapotában ki nem olvassa innen és küldi el soros vonalon a PC felé a monitor programnak. A cirkuláris pufferhez a 3. állapot egy indexet rendel hozzá, amivel jelzi, hogy hova kerüljenek az újonnan érkezett adatok. Az index mindig a puffer azon byte-jára mutat, ami legrégebben íródott bele (vagy még üres). Pufferürítési folyamat: Ez a cirkuláris pufferban átmenetileg eltárolt üzenetek kiküldése a PC felé a 2. állapotban. A pufferhez külön indexet rendel hozzá, mely a legrégebben érkezett és még ki nem küldött byte-ra mutat. Minden csomaghoz egy flaget rendelünk, amely megmutatja, hogy az adott csomag éppen milyen státuszban van (új / már kiküldött). Az egyes csomagok hosszai és lqi értékeik egy-egy másik cirkuláris pufferben helyezkednek el.
13. ábra – Az érkezett csomagok cirkuláris puffere Mégegyszer hangsúlyozandó, hogy a Sniffer csak akkor küld adatot a soros vonalon, amikor megszakítható állapotban (2. állapot) van, hiszen a vétel interruptjának kiszolgálása a legmagasabb prioritású, a soros vonalon való kommunikáció várhat olyan idıpillanatra, amikor épp nincs vétel. A csomagok megjelenése a PC kezelıfelületén valósidejőnek tőnik a megfigyelı számára, azonban a fent említett ok miatt a soros beküldés késleltetéssel jár, különösen átmenetileg megnövekedett hálózati forgalom (burst) esetén.
Információvesztés veszélye(!): A puffertöltési folyamatot a pufferürítési folyamat a lehetı legközelebb kell, hogy kövesse. Amennyiben a puffertöltési folyamat sebessége tartósan nagyobb, mint a pufferürítési folyamat maximális gyorsasága, a bemeneti sebességet meghaladtuk. Így régebb érkezett és még tovább nem küldött üzenetek íródnak felül vagy pedig le kell állítani újonnan érkezı üzenetek mentését - így mindenképp adatvesztéshez jutunk. A puffer mérete: Az elegendı RAM méret kritikus az alkalmazás mőködése szempontjából. Ez a cirkuláris puffer méretét korlátozza. Amennyiben a RAM méret túl kicsi lenne, átmenetileg megnövekedett hálózati forgalom esetén (pl. sok egység bejelentkezése a hálózatba 17
rövid idın belül) elıfordulhatna, hogy mivel az eszköz folyamatosan veszi a csomagokat, nem marad ideje kiküldeni a felhalmozódott üzeneteket, így a RAM megtelik. Minél nagyobb a puffer mérete, annál tartósabban képes elviselni az adatgyőjtı a hálózati forgalom átmeneti megnövekedését, tehát a puffer ürítési folyamat lemaradását a puffer töltés mögött. Látható tehát, hogy a RAM méret a lökésszerő bemeneti sebességet korlátozza elsısorban. Az adatgyőjtık firmwarét a Code Warrior fejlesztıi környezetben készítettem a BeeKit SMAC (Simple MAC) protokoll stack függvényeinek felhasználásával [33].
4.5. A bemeneti sebesség becslése A bemeneti sebesség mérésére 2 tanszéki demo szenzor kártyára írtam tesztprogramot. Egy koordinátor és egy végeszköz kommunikál egymással úgy, hogy a végeszköz T [ms] idıközönként küld egy 27 byte hosszúságú csomagot, amit a központ a 3 byte hosszúságú ACK kerettel nyugtáz (tipikusnak tekinthetı üzenethosszak). Ez azonban csak a MAC keret, ahhoz hogy a ténylegesen átvitt byte-ok számát megkapjuk az egyes keretekhez hozzá kell adni a 2 byte hosszú CRC kódot, a PHY headerben 2 byte-ot elfoglaló hossz mezıt és az 5 byte-ot kitevı elıtagot (lásd 9. ábra). ([1], 6.3) Így a végeszköz egy 36 byte hosszú üzenetet küld T idıközönként, amit a koordinátor egy 12 byte hosszú kerettel nyugtáz. 27 byte (+ 2 byte CRC + 2 byte length + 5byte SHR) = 36 byte = 288 bit 3 byte (+ 2 byte CRC + 2 byte length + 5byte SHR) = 12 byte = 96 bit A programban a T ms-ban megadható egész szám volt. A bemeneti sebesség becsléséhez iteratív módon azt a minimális T-t kell meghatározni, amikor az adatgyőjtıben levı puffer töltési folyamat átlagos sebessége még nem haladja meg a puffer ürítés folyamatét. Ezt T = 8 288 + 96 ms-nál volt igaz. Ebbıl a bemeneti sebesség számolása: vinput = = 48 kbit/sec Ha T < 8 8 ms ms, a puffer ürítés már nem tud lépést tartani a puffer töltéssel, adatvesztés történik. Az IEEE 802.15.4.-es szabvány szerint a 2.4 GHz-es rádiós kommunikáció átviteli sebessége 250 kbit/sec. Azonban a kiszámolt 48kbit/sec egy átlagsebesség, a ZigBee hálózat node-jai valójában az idı csak kis részében (1%-nál kisebb) kommunikálnak, ennek okai: 1. A szenzorhálózatok általában kis kitöltési tényezıvel üzemelnek. Mivel az ismertetett rádiós chippel mőködı eszközök az adáshoz tipikusan 30 mA-t, a vételhez 37 mA-t vesznek fel, tehát az alvó módokhoz képest relatív sok energiát fogyasztanak, az egységek kommunikációjának gyakoriságát minimalizálni kell. 2. A keretek maximális hossza 128 byte, minden új keret elküldését pedig a csomag elıkészítés és a közeghez való hozzáférés elız meg CSMA/CA módszerrel. ([1], 5.5.4) Minden csomag fogadása is idıt igényel – a vevı eszköz MAC rétegének véges idıre van szüksége ahhoz, hogy a PHY réteg által továbbított adatokat feldolgozza.
18
3. A szabvány elıírja, hogy egy kiküldött keretet követıen csak egy bizonyos idıintervallum letelte után szabad új keretet küldeni. Ezt az idıintervallumot IFS-nek (interframe spacing) hívjuk, melynek mérete a legutóbb kiküldött üzenet hosszának is a függvénye. ([1], 7.5.1.3) Tapasztalataim szerint a legnagyobb mennyiségő csomag vételre pl. a hálózat kiépülésekor, ill. node-ok ismételt riasztása (esemény észlelése) esetén kerülhet sor. Ezt az átmeneti állapotot hivatott áthidalni a cirkuláris puffer mőködése (lásd 4.4.). Összegezésként megállapíthatjuk, hogy nem valószínő ennek a becsült 48 kbit/sec átlagértéknek a meghaladása egy helyesen mőködı ZigBee hálózat esetén. A bemeneti sebesség tovább növelhetı lenne, ha: - lemondunk az LQI értékekrıl, ezzel azonban hasznos információt vesztünk - kódunk idıkritikus részét assembly nyelven valósítanánk meg - a 8 bites µC helyett pl. egy 32 bites ColdFire mikroprocesszort alkalmaznánk, a sebesség növekedése azonban így csak nagyobb alkatrész költség és méret elfogadásával lehetséges - több egymáshoz szinkronizált MC13213-as chip alkalmazása
4.6. Az adatgyőjtık RS232 – USB interfésze A CP2103 chip egy UART – USB bridge, ami egyszerő és kis helyigényő megoldás arra, hogy az UART-tal rendelkezı mikrokontrolleres rendszer USB 2.0 kommunikációval csatlakozhasson a számítógéphez. A chip driverének installálásával az adatgyőjtık mint megnyitható virtuális COM portok jelennek meg a PC számára. [12]
4.7. A Sniffer eszközök vezérlése a kezelıprogrammal • •
A virtuális COM portokon érkezı üzeneteket a Windows alatt futó program legalsó rétege, az adatkoncentrátor fogadja. A PC-hez kapcsolódó Sniffer egységeket a következı hardver parancsokkal vezérelheti a program: o több Snifferen az adatgyőjtés indítása a 16 csatorna (lásd 4.2.) valamelyikén o adatgyőjtı leállítása
19
5. A monitor program (I.) – adatkoncentrálás és megjelenítés (PHY nézet) Az adatgyőjtık USB kábellel csatlakoznak a PC-hez, amin a saját fejlesztéső monitor program fut. A Windows alatt futtatandó program megírására a Visual C++ nyelvet és a Visual Studio fejlesztıkörnyezetet választottam. A soros porti kommunikációt már kész osztállyal támogató nyelvet kellett választanom, erre a Visual C++ megfelelı volt. A felhasználói interfészt angol nyelvőre készítettem el, hiszen a megjelenített szöveg jelentıs része az IEEE 802.15.4.-es és ZigBee szabványokra [1], [2] utaló kifejezéseket tartalmaz. A szoftver legalsó rétege, az adatkoncentrátor fogadja a megnyitott COM portokon jövı ZigBee üzeneteket és a hozzájuk tartozó LQI értékeket. Hasonlóan ez a réteg felelıs egy file megnyitásáért és adatainak beimportálásáért vagy a file-ba való archiválásért. Ha a programban a szerver szerepet állítjuk be, ez a réteg fogadja a kliens számítógépek által küldött adatokat. Bár logikailag a megjelenítés külön szint, érdemes az adatkoncentrátor által fogadott és elıállított adatokat megjelenítésükkel együtt tárgyalni, ezek a program PHY nézetében érhetıek el (lásd 15. ábra).
14. ábra – Az elkészített monitor rendszer adatkoncentrátorának blokkvázlata
5.1. Nyomok (trace-ek) Ahogy 3.1.-ben definiáltuk, az adatkoncentrátor az üzenetekhez bejegyzéseket illeszt, ezek a következık: Eseményszámlálás: Ahhoz, hogy az üzeneteket az analizátor program összes nézetében azonosítani tudjuk, a csomagokhoz számokat rendelünk beérkezési sorrend szerint. Így
20
lehetıség van ugyanannak az üzenetnek PHY, MAC, NWK és APS szintő értelmének összevetésére. Ez jelenik meg a PHY nézet 1. oszlopában (lásd 15. ábra). Idıbélyegek: Az 15. ábrán a 2. oszlopban a vételi idı jelenik meg. A vételi idı megállapítására több lehetıség is kínálkozik: o 1. Vételi idı rögzítése a Sniffer timerével: Az idı mérése történhet a µC timerével, aminek kezelése biztosan csökkenti a bemeneti sebességet. A másik nagy probléma, hogy az egyes adatgyőjtık óráit össze kellene hangolni. Ezt az órák egymáshoz képest való esetleges elcsúszása miatt rendszeresen meg kellene tenni. o 2. Vételi idı rögzítése a Snifferen egy RTC (Real Time Clock): Egy Real Time Clock IC (RS5C372B) alkalmazásával is történhetne az idı mérése, ami I2C buszon kommunikál a µC-el. Minden üzenet vételekor az idıbélyeg lekérdezése csökkenti a bemeneti sebességet, és gond lehet az idı elcsúszásával is a kvarc pontatlansága miatt. o 3. Vételi idı rögzítése az adatkoncentrátorban: Idıbélyeget kaphat a monitor programba való érkezésekor is a Windows óráját használva (CTime osztály). A módszer egyszerőségének azonban az az ára, hogy az adatkoncentrátor vétele és a tényleges rádiós vétel között idıeltolódás van (lásd 4.4.), ami a hálózati forgalom átmeneti megnövekedése esetén megnıhet az adatgyőjtık cirkuláris pufferének mőködésébıl adódóan. Így akár 1-2 másodperces idıeltolódással számolhatunk, mely ingadozik a hálózati forgalom függvényében is, tehát nehezen kompenzálható. A kérdés az, hogy valójában milyen pontos idıbélyegekre van szükségünk. A végleges alkalmazásban a 3. megoldást alkalmaztam. Az idıbélyegeket a 6.6. pontban tárgyalásra kerülı hálózati forgalmat ábrázoló grafikon is felhasználja.
Esemény forrása: Az 15. ábrán a 3. oszlopban jeleneik meg. Ez annak a megnyitott COM portnak a száma (így "COM1", "COM2", stb.), ahonnan az üzenet érkezett a monitor programba. Több Sniffer egyetlen PC-hez való csatlakozása esetén a forrás alapján dönhetı el, hogy az egyes üzenetek melyik adatgyőjtıtıl származnak. Amennyiben a monitor program egy szerver PC-n fut, mely adatait távoli kliens PC-khez csatlakozó adatgyőjtıktıl kapja, akkor a kliens a forrást is elküldi a szervernek, így a szerveren megjelenı forrás pl. "COM4@Client #1".
LQI [dB]: A link quality (kapcsolat minıség) értékek segítenek elhelyezni a hálózati csomópontokat a térben, rávilágítanak környezeti akadályok befolyására ill. esetleges RF hardverhibákra is. A LQI értékeket a statisztika modul felhasználja, hogy az egyes eszközökhöz átlagos LQI értékeket rendeljen (lásd: 6.3.)
Az 15. ábra áttekintése (22. oldal): Menu sor és parancsikonok: Az adatgyőjtık vezérlésével (lásd 4.7.) és file mőveletekkel kapcsolatos (lásd 5.2.). Itt tehetı meg a Snifferek indítása/leállítása, csatorna beállítás. Fa struktúra – bal oszlop: A kommunikáló eszközök fa struktúrában nyilván tartva. Rendszerüzenetek – jobb oszlop, 1. sor: Lásd 5.3. File nevek megadása, vázlatos forgalom – jobb oszlop, 2. sor: Lásd 5.2. Megjelenítési réteg – jobb oszlop, 3. rész: PHY, MAC, NWK, APS, statisztika, szomszédossági mátrix, topológia, hálózati forgalom nézetek (lásd 6. fejezet). A piros színő üzeneteket az analizátorban megvalósított csomagszőrı (lásd 6.1.) szőrte ki.
21
15. ábra – Az elkészített analizátor program PHY nézete 22
5.2. Üzenetek összefésülése és redundáns üzenetek kezelése, archiválás, kliens-szerver Az adatkoncentrátor több különbözı COM porton is képes egyszerre üzeneteket fogadni. A különbözı csatornán érkezı byte-ok egy-egy bufferba kerülnek átmenetileg. Minden COM porthoz, a fileból való importáláshoz és a kliensektıl való vételhez egy-egy külön buffer tartozik. (lásd 14. ábra). Az adatkoncentrátorban egy cirkuláris puffer található, itt is két folyamatot különböztethetünk meg: • Puffer töltési folyamat: Ha egy soros vonalon küldött üzenet teljes egészében megérkezett, a csomag készen áll a cirkuláris pufferbe való betöltésére (lásd 14. ábra). Ugyanígy egy külön bufferba olvassuk be a file-ból importált üzenetet, majd ezután kerül be a cirkuláris pufferba (hasonlóan a kliensek esetében). Mivel a cirkuláris bufferba egyszerre csak egy COM port átmeneti tárolójából másolhatunk (ezek egymást kizáró események), nem léphet fel az adatok összekeveredése. • Puffer ürítési folyamat: Ha a cirkuláris pufferben egy kész üzenet kerül elhelyezésre (melyet egy flag jelez), a program készen áll továbbítani a csomagot az analizátor réteg felé. Az analizátor egy indexet tart nyilván, ami a legrégebbi, még nem kiolvasott üzenetre mutat. Kiolvasás nemcsak az analizátor réteg felé történhet, hanem vele egy idıben történhet archiválás és szerverre való küldés, amennyiben a felhasználó erre utasítást ad. Itt a puffer töltési folyamat mindig lassabb, mint a puffer ürítési folyamat, hiszen az elıbbit a soros kommunikáció (115200 bps) sebessége korlátozza, az utóbbi pedig a program futásának sebessége a PC-n, így csomagvesztéssel itt nem kell számolnunk.
Redundáns üzenetek kezelése: Több adatgyőjtı is küldhet egy PC-re üzeneteket, hogy ezzel kiterjesszük a vizsgált szenzormezı méretét. Azonban elıfordulhat, hogy két vagy több Sniffer ugyanazt az üzenetet veszi és küldi be. Egy üzenet redundáns, ha byte-ról byte-ra ugyan az, mint egy másik COM porton már megkapott üzenet. A redundáns üzenetek külön színt kapnak a PHY nézetben (15. ábra). Ezek a csomagok már nem kerülnek fel az analizátorba és nem jelennek meg a MAC, NWK és APS nézetben. Példa: (a számok az 15. ábra üzeneteinek sorszámára utalnak) A 39. üzenetet csak a COM6ra csatlakozó eszköz hallotta, szemben a 40. és 43. számú csomaggal. Valószínő, hogy a kommunikáló eszközöktıl a COM7-re csatlakozó Sniffer távolabb helyezkedik el, hiszen a 41. és 44. redundáns üzenetek LQI-je kisebb. A 41. és 44. üzenetnél bordó szín jelöli azt, hogy a redundáns üzenet a COM7-en jött be. A listán azok az üzenetek, amik redundánsak és a COM6-hoz tartoznak, kék színőek.
Archiválás és importálás: Az archiválás lehetıséget nyújt arra, hogy az érkezett adatokat és a rajtuk elvégzett analízist késıbb is elvégezhessük. Sokszor hozzá kell tudni férni a rendszer elıéletével kapcsolatos információ halmazhoz. A magasabb szinten levı adatok az alacsonyabb hierarchiaszinteken levıkbıl generálódnak, [7], [8] így az adatkoncentrátor kimenı adatainak file-ba írása elégséges, mert ezek késıbb majd az adatkoncentrátorba visszatölthetık, és ıket a felsıbb szintek ugyanúgy feldolgozzák. Az archiválásra való
23
utasítás a "Log to file" gombbal történhet (lásd 15. ábra). Ennek bekapcsolásával az érkezı üzenetek az "output file" mezıben specifikált file-ba íródnak LQI és idıbélyegeikkel együtt. A késıbbiekben pedig az "input file" mezıben adható meg annak a file-nak a neve, amibıl importálni szeretnénk, ez az "import from file" paranccsal hajtható végre.
Kliens-szerver kapcsolat: Kliens szerepő alkalmazások eljuttathatják adatgyőjtıktıl kapott vagy file-ból beolvasott üzeneteiket és a hozzájuk tartozó LQI értékeket egy távoli szervernek. (Lásd 2.3., 3.2. és 5.3.) A TCP socketek programozását a [13] msdn dokumentáció és a [14] tutorial segítette.
5.3. Rendszerüzenetek, kliensek csatlakozása egy távoli szerverhez Egy külön ablakot készítettem a rendszerüzenetek megjelenítésére. A program a következı eseményekrıl tájékoztat: o Az induló alkalmazás szerepe (lásd 2.3.): Standalone application started / Server started / Client started. o Az adatgyőjtık indításáról / leállításáról szóló visszajelzés: Observer(s) started…/ Observer(s) halted… (ez látszik az 15. ábrán is) o Waiting to accept client #1…: A szerver programban egy olyan szál elindulását jelzi, ami egy tetszıleges IP címő kliens elfogadását – accept metódus – várja. Az accept egy blokkoló utasítás, a szál mindaddig blokkolt állapotban van, amíg az egy kliens csatlakozni nem kíván. o Client connecting…A kliens programban egy olyan szál elindulását jelzi, ami a megadott IP címő szerverhez való kapcsolódás lezajlását várja. A connect szintén egy blokkoló utasítás. o Server connected to client #1…Waiting to accept client #2: Ami az 1. PC sikeres csatlakozását és egy újabb szál elindulását jelzi, mely a 2. csatlakozására vár. A kliens a Client connected üzenettel jelzi a connect parancs sikeres végrehajtását. o Server disconnected: Ha a send parancs (funkciója adat küldése a klienstıl a szerverre) hibát jelentı visszatérési értéket ad, a szerverrel a kapcsolat megszakadt, a kliens újra csatlakozni próbál: Client connecting…
24
6. A monitor program (II.) - az analizátor és megjelenítés A csomagokat az adatkoncentrátor az analizátor felé irányítja, mely a monitor program következı rétege. Leginkább itt kell végiggondolunk azt, hogy milyen információkhoz tudunk ill. szeretnénk jutni a kapott csomagok birtokában, ami a hálózat fejlesztésében, teljesítıképességének vizsgálatában a segítségünkre lehet. Érdemes az analizátor funkcióit is a hozzájuk tartozó nézetekkel együtt tárgyalni. Az elkészített analizátor legfontosabb moduljait az 16. ábra tekinti át.
16. ábra – Az elkészített monitor rendszer analizátorának blokkvázlata
6.1. Csomag szőrı (packet filter) Mivel az adatgyőjtés a Snifferekben az implicit kémkedésnek (vö. 3.1.) hívott módon történik, szoftveres szőrésre van szükség. A koncentrátor már kiszőrte a redundáns üzeneteket, azonban van még 3 csoportja azoknak a csomagoknak, amiket nem célszerő a csomag dekóder felé továbbítani: • Más PAN üzenetei: Egyetlen hálózat fejlesztéséhez/teszteléséhez használjuk a monitor programot, így csak egy adott PAN-hez tartozó eszközökre és üzeneteikre vagyunk kíváncsiak. A cél az, hogy kiszőrjünk minden olyan IEEE 802.15.4 / ZigBee szabványhoz tartozó csomagot, ami nem az általunk vizsgált PAN-ben való kommunikációhoz tartozik. Vigyáznunk kell azonban arra, hogy az "FF FF" azonosítójú
25
•
•
PAN felé irányított üzeneteket is átjuttassuk a szőrın, hiszen az "FF FF" azonosító broadcast üzenetre utal, ami minden PAN-nek szól. ([1], 7.2.1.3) Zajok: Nemcsak más ZigBee-s hálózat csomagjaival kell számolnunk, hanem más olyan szabvány szerint mőködı eszközzel, ami használja ugyanazt a frekvenciasávot, mint ZigBee hálózatunk (pl. Bluetooth, WiFi). Ütközött csomagok: Létrejöhet interferencia a különbözı node-ok által küldött üzenetekben. Nem szabad továbbítani a csomag dekóder felé az ütközött csomagokat sem. Erre az 17. ábra mutat példát. Ez a rejtett terminál problémához [4] hasonló eset, mely az adatgyőjtık egy fontos alkalmazási korlátjára mutat rá. "A" és "C" eszköz 17. ábra – Csomag ütközés [4] a CSMA/CA algoritmusnak megfelelıen belehallgat a csatornába és üresnek találja azt, mert egymás hallótávolságán kívül vannak. "B"-nél interferencia lép fel, a csomagok elvesznek. A mi esetünkben "B" a Sniffer, ami nem a hálózat egy csomópontja és nem lép kapcsolatba az eszközökkel, így számára "A" és "C" üzenetei elvesztek, 100%-os csomagvétellel tehát nem számolhatunk.
Komplex szőrési feltétel: A felhasználó a MAC nézetben beállíthatja annak a PAN-nek a 2 byte-os ID-jét, amit vizsgálni szeretne. A szőrés egyrészt PAN ID alapján történik, ami az üzenetek egy meghatározott mezıjében van (MAC szint, addressing fields). ([1], 7.2.1) Ennek a feltételnek a megadásával a legtöbb zaj és más PAN-ekhez tartozó üzenetek kiszőrhetıek lennének, a probléma azonban komplexebb, mert nem minden szabványos üzenet tartalmazza a PAN azonosítót így pl. a nyugta (acknowledgment) sem. Ezek a csomagok azonban felismerhetık más mezık vizsgálatával. A szőrési feltétel tehát komplex, melyet a felhasználó részben specifikál a PAN ID megadásával. Ha a MAC nézetben ez a szőrési feltétel (lásd 22. ábra) nem kerül kitöltésre, a szőrı inaktív. CRC kód(?): Felmerülhet a kérdés, hogy miért nem használom fel a ZigBee chip CRC ellenırzését a "hibás" csomagok kiszőrésére. Ennek az okai a következık: • A chip egy külön regiszterébıl olvasható ki minden üzenet érkezésekor, hogy teljesül e a CRC. Ennek lekérdezése minden üzenet vétele után csökkenti a bemeneti sebességet. A CRC ellenırzés eredményének kiküldése soros vonalon tovább lassítja a folyamatot. • Hibás csomagok információ tartalma: A PHY nézet egyik feladata, hogy megjelenítse a kiszőrt üzeneteket is (lásd 15. ábra), mert ezek a "hibás" csomagok is tartalmaznak hasznos információt a hálózatunkról: o A zajok mennyisége a használt csatorna foglaltságát jelzi, ha a használt frekvenciasávban más elektronikus eszközök is kommunikálnak, érdemes egy "csendesebb" csatornára váltani. A zajok mennyiségének mérése jó útmutató a hálózat telepítésének a helyén is, azt illetıen, hogy melyik csatornát válasszuk ki. o Az ütközött csomagok magas számából helytelen mőködésre következtethetünk, amennyiben az adatgyőjtıket megfelelı helyre raktuk. o Nem szabványos teszt üzenetek számlálása (PER Test) A csomag szőrı a PHY nézetben megjelenı üzenetnek (lásd 15. ábra) piros színt ad, amennyiben nem jutottak át rajta, a többit a ZigBee csomag dekóder dolgozza fel tovább.
26
1. Példahálózat – szinkronizálás beaconökkel – beaconök ütközése Bevezetı: Az alábbiakban ütközött csomagok megjelenítésére adok egy példát, egy beaconök ([1], 5.5.3.1) által szinkronizált hálózatban. A példában 3 egység vesz részt: A központ és a router mindig ébren van, a végeszköz pedig csak rövid idıkre ébred fel periodikusan. Amennyiben az end device szeretne üzenetet küldeni, ezt ébrenléti ideje alatt teheti meg. Problémát jelent azonban az, ha a koordinátor / router akar csomagot eljuttatni hozzá, hiszen nincs tudomása arról, hogy a címzett épp alszik e. Ezt a szabvány ([1], 7.5.4) azzal oldja meg, hogy a végeszköznek a neki szánt adatokat le kell kérdeznie (polling). A beaconös hálózatban a koordinátor és a forgalomirányító periodikusan generál beaconöket, amikhez az végeszközök alvás-ébrenlét ciklusai szinkronizálódnak. A beaconök egy külön mezıje (pending address field, [1], 7.2.2.) pedig jelzi, ha a forrásban keretek várakoznak végberendezés számára. A beaconök követésével a végeszköz így értesül arról, hogy van e számára csomag, amit a data request utasítással kérhet le (polling) ([1], 7.3.4). A példában a központ és a router is generál beaconöket 540 ms-onként. Elıfordulhat az az eset, hogy egyszerre generálnak beaconöket: a beacon adása elıtt mindketten belehallgatnak a csatornába, üresnek találják és adnak – interferencia történik. Mivel a beaconöket nem kell nyugtázni, nem értesülnek arról, hogy a szomszédos eszközök hibátlanul vették e ıket. A probléma elkerülésére a 802.15.4-es szabvány nem ad útmutatást. A ZigBee szabvány ([2], 3.7.4) viszont a különbözı eszközök által generált beaconök idıben való eltolását írja elı (konstans idı: Tx offset). A Tx offset megfelelı megválasztása kritikus a beaconös hálózat mőködése szempontjából. A feketén megjelenített keretek helyesen megérkezett csomagok, a piros szín hibás keretekre – itt ütközésre utal. A beaconök értelmezését a csomag dekóder résznél (lásd 6.2.) mutatom be. Tehát egy példát láttunk arra, hogy a nagy arányú csomag ütközés hibás protokoll stack vagy hálózati paraméterek átgondolatlan megválasztására utalhat.
18. ábra – ütközött beaconök hibás beacon idızítéssel, PHY nézet
Példa – Zajok A fenti példában 00:52:44-ig nem kapcsoltunk be hálózati egységeket, így csak zajokat vehettünk. A rádiós chip mőködésébıl adódik, hogy a legkisebb LQI -95 dB értékő, ennél kisebb jelerısségő jelek is -95 dB-es LQI bélyeget kapnak. 27
19. ábra – zajok, PHY nézet A zajok forrása egy távoli nem ZigBee eszköz mőködésébıl adódik, így a piros színnel megjelenített zajok legtöbbször -95 dB-es LQI értékkel jelennek meg a PHY nézetben.
6.2. ZigBee csomag dekóder A szőrın átjutott csomagokat az IEEE 802.15.4–es szabványnak és a ZigBee specifikációnak megfelelıen dekódolja – a szabványokban definiált keretmezıkre szétbontja és értelmezi az egyes mezıkben levı adatok jelentését. Követi a szabványok által használt OSI réteg modellt: a megjelenítési réteg ez alapján biztosít különbözı nézeteket (MAC, NWK, APS). A dekóder mőködésének ismertetése elıtt tekintsük át elıbb a szabvány egyes rétegeinek feladatait majd a hozzájuk tartozó nézeteket.
MAC (Medium Access Control) réteg: A MAC nézetben a MAC keret egyes mezıi kerülnek megjelenítésre és kiértékelésre. Amennyiben egy csomag MAC data típusú 20. ábra - Az IEEE 802.15.4 volt, ennek a csomagnak a MAC payloadja a NWK nézetben és ZigBee szabványok ki kell értékelıdjön, hiszen ez már a NWK réteghez tartozik. rétegei [4] Ha a csomag MAC command típusú volt, akkor a MAC réteggel kapcsolatos parancsot hordoz. A MAC réteg legfontosabb feladatai: • A koordinátor által generált beacon keretek kezelése, csomópontok szinkronizálása a beaconökhöz. ([1], 7.5.4) • Eszközök PAN-be való belépése / kilépése, 2 byte-os NWK címek hozzárendelése a hálózati csomópontokhoz. ([1], 7.5.3) • Guaranteed Time Slot (GTS) – idıréselt mőködés kezelése. ([1], 7.5.7) • Csomagok nyugtázása acknowledgment (ACK) keretekkel. ([1], 7.2) A MAC nézet "MAC tree" nevő füle (lásd 22. ábra) alatt tájékozódhatunk a MAC keret felépítésérıl, ehhez egyelıre vezérlı funkció nem tartozik. Ez alapján utánanézhetünk az egyes mezık jelentésének a szabványban [1]. 21. ábra - IEEE 802.15.4 és ZigBee keretek Mivel az üzenetek MAC rétegbeli része hordozza a címzési mezıket és a PAN-be való belépéssel kapcsolatos információt, innen 28
nyerhetık ki azok az adatok, amik a hálózat struktúrájának felderítését és a szomszédossági mátrix felrajzolását segítik (lásd 6.4., 6.5.). Minden egység egyedi 64 bites IEEE azonosítóval rendelkezik. Ezen kívül a hálózatba való belépésekor minden eszköz egy 16 bites NWK címet is kap.
NWK (Network) réteg: A NWK nézetben a NWK keret egyes mezıi kerülnek megjelenítésre és kiértékelésre. Amennyiben egy csomag NWK data típusú volt, ennek a csomagnak a NWK payloadja az APS nézetben ki kell értékelıdjön, hiszen ez már az APS réteghez tartozik. Ha az üzenet NWK command típusú, akkor a NWK réteggel kapcsolatos parancsot hordoz. A NWK réteg legfontosabb feladatai: • Routing topológia szerint • Új eszköz konfigurációja • Eszköz újra becsatlakozása, a hálózat elhagyása • Szomszédok felfedezése ([2], 3.) Hasonlóan a MAC nézethez a NWK nézethez is tartozik egy "NWK tree" fül, ahol a NWK keret felépítésérıl tájékozódhatunk. (lásd 26. ábra)
APS (Application Support Sublayer) réteg: Az APS nézetben az APS keret egyes mezıi kerülnek megjelenítésre és kiértékelésre. Az APS keret payloadja alkalmazás specifikus információt hordoz. Az APS réteg legfontosabb feladatai: • A binding tábla kezelése – a binding két eszköz összekötése szükségleteik és szolgáltatásaik alapján (pl. egy hımérı összekötése egy ventillátorral, egy villanykapcsoló összekötése egy fényforrással). ([2], 2.1.6) • Üzenetek továbbítása összekötött eszközök között: indirekt címzés esetén a célcímek a csomagból elhagyhatók, a koordinátor a forráscím és a cluster ID alapján állapítja meg a címzettet a binding tábla felhasználásával. Ezzel elkerülhetı, hogy a végeszközök ismerjék annak a csomópontnak a címét, ahova adataikat el szeretnék juttatni, elég üzeneteiket a központ felé továbbítani. • Attribútumok lekérdezése, módosítása (egy ilyen attribútum pl. a node power descriptor, ami a csomópont tápellátásáról, elemes üzemmód esetén az elemszintrıl tájékoztat). ([2], 2.3.2.5) • Csoportos címzés kezelése ([2], 2.1.7.4) • Applikáció specifikus parancsok, adatok az APS keret payloadjában találhatók.([2], 2.2.5) Az alkalmazási rétegben található programok ún. endpointokhoz kapcsolódnak. A ZDO-t (ZigBee Device Object) a 0. végpont tartalmazza, ez az eszköz hálózatban betöltött szerepét határozza meg, inicializálja az APS és NWK rétegeket és kezeli pl. a binding folyamatot. Az 1-240. endpointokon nem ZigBee szabvány által specifikált alkalmazások lehetnek. Az egyes alkalmazásokat a végpontok számával címezzük applikációs szinten. ([2], 2.5.5.4).
29
22. ábra – a MAC nézet részlete a 2. példahálózatban I. – csatlakozási folyamatok (mezık folytatása:1. és 1. ábra) 30
23. ábra – a MAC nézet részlete a 2. példahálózatban II. – csatlakozási folyamatok
24. ábra – a MAC nézet részlete a 2. példahálózatban III. – csatlakozási folyamatok
6.2.1. MAC nézet és MAC réteg – csatlakozási folyamatok a 2. példahálózatban 2. példahálózatunkban csatlakozási folyamatokon keresztül mutatjuk be a dekóder mőködését. A példahálózat csomópontjain a Freescale Semiconductor protokoll stackje fut, melyre itt példa applikációkat töltöttem fel.
Elrejthetı mezık és színek: A nézetek bal oszlopában (lásd 22. ábra) választhatók ki azok a mezık, amiket meg szeretnénk jeleníteni, így egyes vizsgálatoknál közömbös keretmezık elrejthetık. Az elnevezések a szabványok által használt fogalmakra utalnak. A különbözı eszközöktıl jött üzenetek különbözı háttérszínt kapnak. A dekóder egy táblázatot készít, melyben az egyes node-ok hosszú IEEE (8 byte-os) és rövid NWK (2 byte-os) címükkel együtt vannak nyilvántartva. Külön feladatot jelent azonban az olyan keretek forrásának megállapítása, melyek nem tartalmaznak forráscímet, így pl. a nyugta keretek. Az ACK keret szekvencia száma (Seq. no.) ([1], 7.2) megegyezik annak a keretnek a szekvencia számával, amit nyugtáz. Ha ismert ennek a keretnek a célcíme, közvetett módon a nyugta forrása is megállapítható. Vannak azonban olyan üzenetek is, amik forrása nem dönthetı el, pl. a beacon request (22. ábra: 2., 3., 12. csomag), mely minden PAN-nek szól és a forrás mezı hiányzik belıle, ezek háttere fehér marad. Az 22., 23. és a 24. ábrán nyomon követhetjük a 3 node bekapcsolódását a 2. példahálózatba. 31
Csatlakozási folyamatok a 2. példahálózatban (22., 23., 24. ábra magyarázata): 2.: Beacon request, a koordinátor (zöld) bekapcsolásakor tájékozódik arról, hogy van e már kialakult hálózat a hallótávolságában. 3.: Beacon request, itt egy routert kapcsoltunk be (továbbiakban kék), mely beacont kér. 4.: Beacon, a koordinátor beaconnel válaszol, a beaconbıl a következık derülnek ki: (23. ábra) superframe specification – FFCF: lesz beaconökkel szinkronizálva a hálózat PAN coordinator – 1: a beacon egy központtól jött association permit – 1: a koordinátor engedélyezi a hozzá való csatlakozást (24. ábra) protocol ID – ZigBee Protocols: a NWK és az APP réteg a ZigBee szabványnak megfelelıen van implementálva a koordinátorban. nwkcProtocol version – 2: a 2006-os ZigBee szabványt használja. router capacity – yes: engedi, hogy hozzá forgalomirányítók csatlakozhatnak. device depth – 0: a központtól való távolság 0, hiszen saját maga koordinátor. end device capacity – yes: hozzá vég csomópontok is csatlakozhatnak … stb. 6.: Association request, erre a kék forgalomirányító tudatja a központtal, hogy csatlakozni szeretne a PAN-hez. Ehhez csatolja a saját tulajdonságait: (23. ábra) alternate PAN coordinator – 0: ı nem viselkedhet koordinátorként. device type – FFD (definíciót lásd 2.1. rész) power source – mains: az eszköz hálózati feszültséget kap … stb. 7.: Data request, a központot le kell kérdeznie a (kék) routernek arról, hogy van e számára várakozó csomag (polling). Erre a már ismertetett alvás-ébrenlét ciklusok miatt van szükség. 8.: Ack, a 7. üzenet (a képen nem megjelenített) frame control mezıjébıl kiderül, hogy az eszköz kért nyugtát a data request utasításra. Így erre a koordinátor nyugta keretet ad. 9.: Association response, a koordinátor elküldi a kék router számára allokált nwk címet (00 01) és tájékoztat a csatlakozás sikerességérıl (success). 10.: Ack, a router nyugtázza a sikeres belépést. Ezzel 1. routerünk csatlakozott a hálózathoz. 12.,14.,16.: Beacon request, egy újabb eddig ismeretlen eszköz kér beaconöket. 13.,15.: Beacon, erre a központ válaszol, azonban a 23. ábrán látható, hogy az association permit paraméter 0, így hozzá nem lehet csatlakozni. Az új eszköz addig próbálkozik, amíg olyan beacont nem kap, ami olyan csomóponttól érkezett, ami vesz fel új node-okat. 17.: Beacon, kék háttérszínőm, tehát ezt a router küldi. Az üzenetben association permit=1. 18.-22.: Az elızıhöz hasonlóan a narancssárga új router is csatlakozik a PAN-hez a kék routeren keresztül. 24.-31.:Egy szürke színt kapó eszköz lép be, melynek szülıje a kék lesz...
25. ábra – a struktúra felderítı által felrajzolt kép – bıvebben lásd 6.4. A hálózathoz ezt követıen további egységek csatlakoztak…
32
26. ábra – a NWK nézet részlete a 2. példahálózatban I. – útvonalak kiépülése
27. ábra – a NWK nézet részlete a 2. példahálózatban II. - riasztások
33
6.2.2. NWK nézet és NWK réteg – route-ok kiépülése és riasztások a 2. példahálózatban (az 26. és 27. ábra magyarázata) Miután az egységek bekapcsolódtak a hálózatba, megkezdıdhet a route-ok kiépülése: Route-ok kiépülése (26. ábra): 122.: NWK data – A halvány piros színnel jelzett, 00 82 címő végberendezés üzenetet irányít a 00 00 címő koordinátornak. A radius azt határozza meg, hogy az üzenet az útvonalon hány hopnyi távolságot tett meg. A kezdeti 0A értéket csökkentik a csomópontok, amint az üzenet rajtuk áthalad, mindaddig amíg az üzenet célhoz nem ér. Ebben a hálózatban a maximális megengedett hop szám 10. A source address és a network address NWK szintő forráscím arra az egységre utal, aki az üzenetet eredetileg elıállította és annak a csomópontnak a címét adja meg célpontként, ahova az üzenet a route-on keresztül tart, tehát nem azonosak a MAC szintő címekkel. Így a 122. adat MAC forráscíme ugyan szintén 00 82, de annak MAC szintő célja a szülıje (lila színő router, 00 50 C2 0A 40 10 4C 13), akin keresztül a hálózatba került, és akin keresztül most egy út kiépítését kezdeményezi. 123.: Route request – az elıbbi 122. számú adatot miután a lila router megkapta, út kiépítésébe kezd. A NWK célcím itt FF FC, ami azt jelenti, hogy valamennyi routernek szól. A forráscímben a saját NWK címe van, 00 03. 124.: Route request – a 123. üzenetet a szürke színő router (00 50 C2 0E 58 0C FC 0D) továbbítja valamennyi további routernek, a NWK forráscím azonban az eredeti küldı, a lila router címe (00 03). Mivel az útvonal kérelem csomag már 1 hopot megtett, egyet le kell vonni a radiusból, így lesz 09. 28. ábra – az ismertetett útvonal (lásd még 6.4.) 125-127.: Route reply – a 124. üzenet eljutott a (zöld) koordinátorhoz. Az útvonal kérésre adott választ, a 124. forrásához, a szürke színnel jelzett forgalomirányítónak továbbítja. Ahogy a route requestet egy úton végigadták a routerek, úgy adják visszafele is a route replyt is. Kiépült az az út, amelyen a riasztások terjedni fognak (lásd 28. ábra).
Riasztások (27. ábra): A riasztások a példában a halvány piros színnel jelzett (00 50 C2 07 1C 0C 14 0A) végeszközön gomblenyomás hatására jönnek létre. (lásd még 6.2.3.) A táblázatból kiderül, hogy az adatok az elıbb kiépült útvonalon (28. ábra, piros jelzés) haladnak végig az end device-tól (halvány piros) a koordinátorig (zöld) a lila és a szürke routeren keresztül. A radius értéke az út mentén egyre csökken jelezve a megtett távolságot. A NWK payload APS szintő tartalma az 30. ábrán látható.
34
29. ábra – az APS nézet részlete a 2. példahálózatban – binding folyamat
30. ábra – az APS nézet részlete a 2. példahálózatban – riasztások
35
6.2.3. APS nézet és APS réteg, binding és riasztások a 2. példahálózatban Binding (29. ábra): A példában a koordinátor és a halvány piros színnel jelzett (00 50 C2 07 1C 0C 14 0A) végeszköz azonos profilú. Közöttük binding folyamat megy végbe a már ismertetett útvonalon keresztül. A source endpoint a ZDO (ZigBee Device Object), mert a kötési folyamat kezelése a ZDO feladata, a profile ID a ZDP (ZigBee Device Profile). ([2], 2.1.6.) A binding lényegét az APS réteg feladatai között ismertettem. (lásd 29. old) Riasztások (30. ábra): A riasztások a példában a halvány piros színnel jelzett (00 50 C2 07 1C 0C 14 0A) végeszközön gomblenyomás hatására jönnek létre (vö. 27. és 30. ábra). A példa életszerő, sok mikrokontrolleres rendszernél egyes jelenségek egy-egy IO láb 1-be vagy 0-ba billenéseként érzékelhetıek. Vegyük példának a System Sensor füstdetektor B312NL aljzatát. Itt a füst jelzése az 1. számú remote annuciator láb 1-be billenésével történik, a probléma tehát ekvivalens egy gomb lenyomásának érzékelésével. (lásd 9.) A végeszköz riaszt a 225., 233., 241., 249. üzenetével. A riasztások a koordinátor felé áramlanak a már kiépült útvonalon. Az ábrán látszik, hogy az APS counter minden egyes riasztás jelenséggel inkrementálódik. A source endpoint a 8. számú, ezen az végponton levı alkalmazás felel ezért a jelenségért. Az APS payload magát az adatot tartalmazza, melybıl a középsı byte egy növekvı tranzakció szám, az utolsó byte jelenti tulajdonképpen azt, hogy a gombot lenyomták ~ riasztás van.
6.3. Statisztika A statisztika modulban a csomagok és az eszközök statisztikája készül, melyet az ehhez tartozó nézet jelenít meg. Csomagok statisztikája: • Az összes vett csomag száma (a PHY nézetben elérhetı csomagok száma) • A komplex szoftveres szőrın átjutott üzenetek száma • NWK és APS keretet hordozó üzenetek száma (vö. 6.1.) Eszközök statisztikája: • Sent messages: Egy-egy csomópont hány üzenetet küldött • AVG(LQI): Ezen üzenetek LQI-jának átlaga • Intended destination: Egy-egy eszköz hányszor volt címzett
31. ábra – a statisztika nézet a 2. példahálózatban 36
Sent messages: A küldött üzenetek számolását fontosnak tartom. Általánosan elmondható hogy mivel a node-ok korlátos energiával rendelkeznek, a gyakran használt csomópontok ki vannak téve annak a veszélynek, hogy hamarabb lemerülnek. Egyes eszközök kiesése a hálózatból a struktúra lényeges megváltozásával és a rendszer megbénulásával járhat. (Így pl. sok szenzorhálózat alkalmazásnál az adatok áramlása sok forrás (szenzorok) felıl néhány nyelı (beavatkozók, gateway eszközök) felé tart. Azok a hálózati csomópontok, melyek a szenzormezıben a nyelık környékén helyezkednek el, az adatáramlási útvonalak gyakran használt állomásai. Többet kommunikálnak, mint más csomópontok, ezért fenn áll a veszélye annak, hogy hamarabb lemerülnek [4]. A táblázat sent messages oszlopából kitőnik, hogy mely eszközök vannak a legtöbbet használatban és melyek nincsenek eléggé kihasználva. Fizikai helyzetük változtatásával, az alkalmazás módosításával, a kiépülı útvonalak változtatásával a helyzet javítható. Látható a példában, hogy a 00 50 C2 07 1C 0C 14 0A, a 00 50 C2 0A 40 10 4C 13 és a 00 50 C2 0E 58 0C FC 0D csomópontok és a koordinátor kommunikációja a legintenzívebb (vö. 28. ábra). AVG(LQI): Az LQI értékek vizsgálata lehetıséget nyújt arra, hogy a hálózat csomópontjait a térben optimálisan helyezzük el. Ha az adatgyőjtıt a hálózat egyes elemeihez helyezzük el, mérhetjük a vele szomszédos csomópontokkal létesíthetı kapcsolat minıségét (LQI). Nem létezik jól definiálható hallótávolság a rádiós kommunikáció számára, az eszközök pozíciójának kis változásai is drasztikus változásokat idézhetnek elı a rádiós kapcsolat minıségét ill. erısségét illetıen. Ezért hasznos a csomópontok elhelyezésének méréssel való támogatása. Egy további jellemzı, hogy a hálózati forgalom hányad része tényleges adatátvitel és hányad része a hálózat felépülését, karbantartását szolgáló MAC ill. NWK parancs ill. nyugta. Ez a statisztikából szintén kiolvasható.
6.4. Hálózati struktúra Csillag topológiájú hálózat kiépülése: Miután egy FFD aktívvá vált, megalapíthatja a saját hálózatát és PAN koordinátorrá válhat. Hozzá FFD és RFD eszközök csatlakoznak. ([1], 5.3.1) Cluster tree kiépülése: Egy FFD új hálózatot indít majd hozzá FFD-k és RFD-k csatlakoznak. A becsatlakozott egységet gyermeknek, a másikat pedig szülınek nevezzük. Az FFD-khez további FFD-k és RFD-k csatlakoznak. A fa levelei RFD-k, melyekhez csatlakozás már nem lehetséges. A PAN koordinátor utasíthat FFD eszközöket, hogy PAN koordinátorrá válva új clustert alkossanak. Sok cluster összekapcsolódásával nagy területet lefedı hálózatok hozhatók létre. ([1], 5.3.2) A hálózat analizátor egy modulja megkísérli a hálózat struktúrájának felrajzolását. Ha olyan egység kommunikációját vesszük, melynek becsatlakozását nem regisztráltuk, az új eszköz a struktúra gyökerénél kerül elhelyezésre. Ehhez az alábbi eseményeket kell regisztrálni: Hálózathoz való csatlakozás: 1. association MAC keretekkel: minden új egység csatlakozási kérelmet (association request) küld egy már hálózatban levı egységnek, akitıl majd választ (association response) és felvétel esetén egy nwk rövid címet kap (lásd 6.3.). 37
2. explicit join applikáció szinten: Elıre eltervezett szülı-gyermek kapcsolatok, melyet az alkalmazás épít ki. ([1], 7.5.3) 3. rejoin NWK kérés: Egy eszköz kérheti, aki elvesztette a kapcsolatát a szülıjével. Hálózatból való kilépés: 1. NWK leave parancs egy node kilépését jelzi a hálózatból, mely hordozza azt az információt is, hogy kilépésével gyermekeit is el szándékozik e távolítani. ([2], 3.5.4) 2. explicit leave request ([1], 7.5.3) Ha egy node eltőnik (lemerül vagy eltávolítják), eltőnésérıl semmilyen információnk sincs. A grafikus struktúrát a [15] tutorial alapján készítettem el.
32. ábra – a 2. példahálózat struktúrája Útvonalak és binding tábla: Érdemes lenne a jövıben beépíteni egy olyan program részt is, ami az útvonalakat és az összekötött egységeket jeleníti meg.
6.5. Szomszédossági mátrix Minden hálózati csomópont egy szomszédossági listát tart nyilván. Ezt monitorunkkal is felrajzolhatjuk, ha regisztráljuk, hogy mely két eszköz között történt már direkt kommunikáció. Ha két csomópont nem kommunikált, akkor nincsenek benne egymás szomszédossági listájában. ([1], 5.3.2) Feltehetıen nincsenek egymás hallótávolságában vagy logikai kapcsolat nincs köztük: pl. két RFD sem kommunikálhat egymással (lásd 2.1.). A mátrixban X jelöli, ha két csomópont szomszéd. 38
33. ábra – Szomszédossági mátrix a 2. példahálózatban
34. ábra - a hálózati forgalom és a csomópontok aktivitásának alakulása az idı függvényében
39
6.6. Hálózati forgalom, node-ok aktivitása Egy külön nézet hivatott megjeleníteni a hálózati forgalom alakulását és az egyes csomópontok aktivitását az idı függvényében (lásd 35. ábra). • Egy grafikonon ábrázolja a vett üzenetek számát az idı függvényében. • A program minden egyes eszközhöz is egy-egy függvényt rendel hozzá, mely a küldött csomagok számát jeleníti meg. Az egyes csomópontokhoz tartozó függvények más-más színnel jelennek meg és dinamikusan elrejthetık. A függvények egyes részletei kinagyíthatók. A megjelenítéshez a [28] cikkben bemutatott C++ osztályt használtam fel.
35. ábra – útvonalak kiépülése, binding és riasztások Ebben a példában a hálózati forgalom 2-szer nı meg számottevıen. Egyszer az adatáramlási útvonalak kiépülésénél, a végberendezés és koordinátor összekötésénél, ez kb. 4-5 másodpercig tart. Másodszor pedig a riasztás jelzések továbbításánál az útvonal mentén, a jelzést a piros végeszköz generálta, a csomagok a lila és szürke routereken keresztül haladtak a zöld koordinátorig, mely nyugtázza az adatátvitelt.
6.7. PER (packet error rate) teszt A PER (packet error rate) a vezeték nélküli hálózat fontos QoS (Quality of Service – 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ı. Ehhez azonban kell egy teszt eszköz, ami adott számú üzenetet küld. Analizátor programomhoz egy olyan nézetet is fejlesztettem, ami támogatja a PER teszt elvégzését. Beállítható a várt teszt üzenet száma és tartalma. A mérés elindításával a program számolja, hogy hány hibátlan teszt csomag érkezett meg.
40
36. ábra – Az analizátor PER Teszt funkicója A fenti példa mérését egy teszt eszköz segítségével hajtottam végre. A teszt eszközre olyan programot töltöttem, ami 1000 db fent látható teszt üzenetet küld. Egy adatgyőjtı hallgatja az adott csatornát és küldi be az érkezett csomagokat az analizátornak. A program PER modulja számolja a helyesen megérkezı teszt üzeneteket. A mérés eredményét természetesen befolyásolja a csatorna zajossága, a két eszköz távolsága és az akadályok (pl. falak) is. Különbözı alkalmazású hálózatokhoz más és más QoS követelményeknek kell megfeleljenek.
41
7. ZigBee hálózatok vizsgálata 7.1. Hálózat regenerációja – Freescale Protocol Stack 7.1.1. Router kiesése a hálózatból Fontos követelmény, hogy egyes csomópontok kiesése estén is életképes maradjon a hálózat. Az 38. ábrán az eredeti 3. példahálózat, az 37. ábrán pedig az analizátor MAC nézetében a küldött adatok láthatók. Az üzenetek a szürke végberendezés felıl a narancssárga routeren át a koordinátor felé haladnak: 144.: Data: A végeszköz által küldött adat. 145.: Ack: A forgalomirányító nyugtája az elıbbi keretre. 146.: Data: Adat, melyet az elıbbi eszköz továbbküldött. 147.: Ack: A központgnyugtája.
37. ábra – adatáramlás az eredeti route mentén (a MAC nézet egy részlete)
38. ábra – 3. példahálózat: az eredeti út (a struktúra nézetben utólag jelölve)
39. ábra – a kiépülı új rout (a struktúra nézetben utólag jelölve)
A narancssárga színnel jelzett routert azonban kikapcsoljuk, így a végeszköz elveszíti szülıjét és kapcsolatát a központtal…
40. ábra – a végberendezés adatai, melyek nem jutnak el a koordinátorhoz (NWK nézet egy részlete)
42
A szabvány azonban ezen a ponton a regenerációt nem támogatja közvetlenül. Az újra becsatlakozást az applikációnak kell igényelnie, ha azt állapítja meg, hogy a kapcsolata megszakadt. Így ekkor én arra utasította a végeszközt, hogy kezdeményezzen újra csatlakozási folyamatot. (lásd 41. ábra) A 443.: Rejoin request ([2], 3.5.6) az end device-tól, melyben felsorolja a tulajdonságait. 448.: Rejoin response ([2], 3.5.7) a kék routertıl, ezzel ez az eszköz válik a végberendezés szülıjévé, ami új nwk címet kap: 14 30, majd bejelenti, hogy újra becsatlakozott az új nwk címmel, ez a 450.: end device annce ([2], 2.4.3.1.11), melyben közli IEEE címét és új rövid címét is. 451-458.: Az end device annce keretek elárasztásos módon terjednek el a hálózatban (lásd 42. ábra). (Ha a hálózat analizátor ilyen keretet detektál, frissíti az eszközök nyilvántartását végzı táblázatot az új nwk címmel).
41. ábra – újra becsatlakozás kérése és a rá adott válasz (NWK nézet részlete)
42. ábra – újra becsatlakozás hirdetése (APS nézet részlete)
Tehát a Freescale protokoll stack használatával az újra becsatlakozási folyamat hibamentesen lezajlott, azonban ehhez az applikáció kérésére volt szükség.
7.1.2. Koordinátor átmeneti kiesése a hálózatból A következı példa a Freescale protokoll stack egy hibájára világít rá. Itt a koordinátor tápellátását kapcsoltuk ki egy pillanatra. Azt várjuk, hogy amikor a koordinátort ismét bekapcsoljuk, új PAN-t alapít meg. A routerek új központ keresését kezdeményezik majd csatlakoznak az új PAN-hez. A végeszközök is újra becsatlakozási folyamatot kezdeményeznek, így újra kiépül a hálózat. Az analizátor azonban mást mutat: 43. ábra – 4. példa, a koordinátor kiesése Az újraindított koordinátor 160. és 163. üzenete beacon request, ezzel tájékozódik, hogy milyen PAN-ek vannak hallótávolságban. A két router beaconnel válaszol. Ekkor láthatólag a központ blokkolt állapotba kerül, folyton beaconöket kér és a ezek begyőjtése után nem alapítja meg
43
az új PAN-t. Végtelen ciklus következik a koordinátor beacon kérelmeivel: A fenti folyamat ciklikusan anélkül, ismétlıdik hogy a hálózat helyre 44. ábra – a koordinátor sikertelen feléledése (MAC nézet részlete) állna. Amikor a végeszköz adat küldését kezdeményezi az útvonalon (414.: data), a kék forgalomirányító továbbítja azt a 0000 címre, ami a mindenkori PAN koordinátor nwk címe. Azonban a központ végtelen ciklusban kér beaconöket és nem alapított új hálózatot, így a router nyugtát sem kap, és összesen 4-szer próbálkozik újraküldéssel (416-419.) majd a kézbesítést sikertelennek tekinti és visszalép.
45. ábra – a route megszakadása (MAC nézet részlete)
A hálózat tehát a koordinátor mőködésére nagyon érzékeny, a megbízhatóság nem megfelelı.
7.2. Csomópontok terhelésének eloszlása A következı 5. és 6. példahálózatban a hálózati csomópontok terhelésének eloszlását vizsgálom. A két esetben ugyanazok az eszközök szerepelnek, ugyanolyan fizikai elrendezéssel, a 5. példahálózatot egyszerően újraindítottam, így jött létre a 6 (ad hoc kiépülés). Arra voltam kíváncsi, hogy a kiépült útvonalak minden esetben azonosak lesznek e, és milyen terhelési eloszlást állapíthatunk meg az egyes esetekben. A 46. és a 47. ábrán látható a létrejött 5. és 6. példahálózat, melyet a struktúra nézet jelenített meg. A két hálózatban eltérı adatáramlási útvonalak épültek ki.
47. ábra – utak a 6. példahálózatban
46. ábra – utak az 5. példahálózatban
44
48. ábra – statisztika nézet az 5. példahálózat esetén
Az 5. példában a két végberendezés ugyanazon az úton keresztül juttatja el csomagjait a koordinátorhoz, a másik két router gyakorlatilag nem használt. Ezzel szemben a 6. esetben 2 különbözı útvonalon érnek el az adatok a központig. A küldött üzenetek száma körülbelül azonos, az egyik végeszköz kb. 2-szer annyit küld, mint a másik.
49. ábra – statisztika nézet a 6. példahálózat esetén Az összehasonlító táblázatból látszik, hogy a 6. példa terheléseloszlása egyenletesebb, mint az 5. példáé. A gyakran használt csomópontok késleltetése nagyobb lehet az út mentén és élettartamuk kisebb telepes ellátás összehasonlítás 5. 6. esetén!
7.3. Protokoll stack hibák kiszőrése
koordinátor 1. router 2. router 3. router 4. router 1. end device 2. end device
9.39% 4.22% 17.8% 32.16% 7.04% 10% 16.43%
12.3% 1.67% 16.9% 17.62% 23.1% 9.2% 16.67%
A ZigBee hálózat analizátor protokoll stack fejlesztésére hatékony megoldást nyújt. A tanszéken hálózati réteg fejlesztése folyt, ez a fejlesztett analizátor segítségével történt. A Freescale Semiconductor protokoll stack is tartalmaz hibát: A szabvány szerint az APS keret destination endpoint mezıje csak akkor van jelen a keretben, ha a delivery mode mezı normal unicast delivery-t vagy indirect addressing-et jelent és az indirect addressing mode almezı 0. ([2], 2.2.5.1.2) Ezzel szemben a Freescale protokoll stackben a destination endpoint akkor is jelen van, amikor a delivery mode almezı broadcasting. Ez a szabványnak ellentmond és veszélyezteti a csomópontok hibamentes kommunikációját más stacket használó csomópontokkal, hiszen ettıl a mezıtıl kezdve az üzenet értelmét veszti.
45
8. Lekérdezı egység Az implicit kémkedésen alapuló adatgyőjtést egy egyszerő lekérdezı egységgel egészítettem ki, mely a hálózati csomópontoktól további információ megszerzését segíti elı. Azt a módszert szondázásnak hívjuk, amikor speciális üzeneteket továbbítunk a rendszerbe és ezek segítségével jutunk ismeretekhez. Például kiadhatók a következı APS szintő parancsok: -power_desc_req: A csomópont tápellátását leíró 2 byte elkérése, benne pl. az elemszint. ([2], 2.4.3.1.4) -active_ep_req: Az erre adott válaszban az egység aktív endpointjainak listája található. ([2], 2.4.3.1.6) -mgmt_rtg_req: Egy eszköz routing táblájának lekérdezése. ([2], 2.4.3.3.3) Az eszközt egy SARD kártyán valósítottam meg, melyre egy olyan szoftvert írtam, mely a soros vonalon érkezı karaktersorozatot IEEE 802.15.4-es csomaggá konvertálja és elküldi a hálózatba. Az eszköz egy Visual C++-ban fejlesztett egyszerő GUI-val vezérelhetı. A küldött üzenetek és a rájuk érkezı válaszok egy Sniffer egységgel és a hozzá elkészített analizátor programmal figyelhetık meg. A windowsos kezelıfelületen bevitt, hexában értelmezett üzenetet soros vonalon a mikrokontroller felé továbbítódik.
50. ábra – a lekérdezı egység egyszerő kezelıfelülete
A jelenlegi kezelıfelület hátránya, hogy tetszıleges üzenet bevihetı, tehát nem szabványos, hibás csomagok is generálhatóak segítségével. Ez ugyanakkor szabadságot is ad tetszıleges MAC, NWK és APS szintő üzenetek kiadására is. A lekérdezı egység még fejlesztésre szorul.
Példák az alkalmazásra 1. Beacon kérése
51. ábra – beacon kérése a lekérdezı egységgel (MAC nézet részlete)
46
Az eszközzel egy broadcast beacon reqestet küldtünk. (51. ábra) Egy PAN koordinátor és két másik forgalomirányító válaszolt, melyek közül a narancssárga színnel jelzett engedélyezi a csatlakozást.
2. Power descriptor lekérése egy node-tól
52. ábra – power descriptor lekérése (1.) (APS nézet részlete) 53. ábra – power descriptor lekérése (2.) (APS nézet részlete)
A 0000 hálózati címő egység power descriptorát ([2], 2.3.2.5) kértük le, a válaszból kiderül, hogy a tranzakció sikeres volt, az egység csak hálózati tápellátású lehet és jelenleg ezt is használja.
3. Aktív endpointok lekérése:
54. ábra – aktív endpointok lekérése (APS nézet részlete)
Egy csomópont aktív végpontjait kérdeztük le. Válaszból kiderül, hogy 1 db található rajta, ennek azonosítója 8.
47
9. Hálózati csomópontok fejlesztése A fejlesztett ZigBee hálózat analizátor egy újabb munkámban, hálózati csomópontok alkalmazás szintő szoftverének fejlesztésében is segítségemre volt. Feladatom elsı része az volt, hogy Kelemen Szabolcs Tibor 2007-es diploma munkájában bemutatott füstdetektor ([34], 9.) hardverét adaptáljam MC13213 SoC mikrokontrollerhez. Ezután a mikrovezérlıkre ZigBee stack került, melyre saját magam írtam applikációs szoftvert. Ez a fejezet ismerteti a kész alkalmazást és ellenırzésüket a hálózat analizátorral.
Füstdetektor (applikációs szoftver fejlesztése) Hardver leírás: Egy füst detektor szerepét ellátó végeszközhöz egy System Sensor 2451TEM (füst- és hıérzékelı) csatlakozik, mely B312NL aljzatban található. 1. Füst detektálása: Nyugalmi (riasztás mentes) állapotban a szenzor áramfelvétele 60 µA körüli. Amikor az érzékelı tüzet észlel, megnöveli áramfelvételét 100 mA körüli értékre és remote annunciator lábán 1-es szinttel jelez. Miután érzékeltük a riasztást, a diploma munkában leírt tranzisztoros kapcsolás segítségével mikrokontrolleres vezérléssel megszakítjuk a szenzor tápellátását (áramkorlát bekapcsolása), így a 100 mA-es áramfelvétellel csak pár ms-ig kell számolnunk. Ezután visszaadjuk a tápellátást. A szenzor kb. 10 s alatt éled fel újra, és jelez ismét, ha még fenn áll a riasztást kiváltó esemény. Ekkor ismét áramkorlátot kapcsolunk be... Ez ismétlıdik ciklikusan, amíg a szenzor füstöt / magas hımérsékletet detektál. Ezzel a módszerrel alacsony fogyasztású szenzor végeszközt valósíthatunk meg. 2. Detektor eltávolítása: Ha a detektort illetéktelen személy eltávolítja, akkor mechanikusan megszakad a kapcsolat egyik kimenete (gnd_out) és a föld között. A mikrokontrollernek ciklikusan ezt is le kell kérdeznie. ([34], 9.)
Applikációs szoftver: Itt az alarm és detector az APP réteg változói.
55. ábra – A füstdetektor alkalmazás szintő szoftverének mőködése
48
1. Riasztás mentes állapot, detektor helyén az aljzatban: Az APP main ciklus fut a csomópont ébrenléti állapotaiban, az „ext. interrupt” állapotba nem lépünk bele. A timer megszakítás periodikusan hívódik meg, melyben megvizsgáljuk az alarm változót. Mivel értéke ennek 0, továbblépünk, és lekérdezzük annak a GPIO lábnak a jelszintjét, melyhez a detektor kimeneti földje csatlakozik egy tranzisztoros kapcsoláson keresztül. A detektor helyén van, így a detector változó lekérdezése következik: mivel korábban is a helyén volt, ennek értéke 0. Kilépünk a timer rutinból, vissza a main ciklusba. 2. Füst detektálása (detektor helyén): Ha az egység alszik, külsı megszakítással ébred, vagy ébrenléti állapotban a main ciklus azonnal megszakad és a kiszolgáló rutinba ugrik a program. Az alarm változót 1-be billentjük majd üzenetet küldünk a koordinátor felé. Mivel az eseményt már detektáltuk, alacsony fogyasztásra törekedve a szenzor tápfeszültségét lekapcsoljuk egy GPIO láb 0ba állításával (lásd hardver leírás). Amint a timer megszakítást okoz, detektáljuk, hogy az alarm változó értéke már 1. Ismét engedélyezzük a riasztást azzal, hogy az áramkorlátot megszüntetjük. Tájékoztatjuk errıl a központot. Ezután a szenzor eltávolításának vizsgálata következik, mely az 1. pont szerint zajlik le. 3. A detektort eltávolították (füst?): Ha a szenzor nincs a helyén, nem következhet be külsı interrupt. A timer megszakítás rutinja az alarm változót 0-nak érzékeli (hacsak a detektort nem egy riasztás és a timer megszakítás közt távolították el). A detektor azonban most nincs a helyén, így a detector változót 1-be billentjük és riasztást irányítunk a koordinátor felé, majd kilépünk a rutinból. A fent bemutatott applikációs szoftvert a ZigBee hálózat analizátor segítségével fejlesztettem.
9.1. A füst érzékelése
56. ábra – füst detektálása ( hálózati forgalom nézet )
49
Az 56. ábrán a füst detektálásának mőködése látszik. A tengelyek normáltak: a csomagok száma 10-zel, az idı pedig 100-zal került leosztásra. A füstöt spray kiszereléső füst detektor tesztelıvel idéztem elı. A kék eszköz a szenzor egység, a zöld pedig a koordinátor, mely másodpercenként 2 beacon csomagot állít elı. Ez a grafikonon minden másodpercnél zöld jelzéssel jelenik meg y≥2 értékkel. Az elsı 5 másodpercben az végeszköz csatlakozik a koordinátorhoz. A füstöt a 14. másodpercben állítottuk elı. Ekkor a szenzor üzeneteket küld a koordinátornak, mely nyugtázza ıket. A következı másodpercben meghívódik a timer megszakítás rutin, mely üzenettel tájékoztat az áramkorlát megszüntetésérıl. Majd az eszköz 10 másodperc hosszan hallgat. Azonban a füst jelensége tovább fenn áll, és már nincs bekapcsolva az áramkorlát sem. Ebbıl világosan látszik, hogy a szenzornak, miután a 9V-os tápfeszültséget megkapta, a feléledéshez 10 másodpercre van szüksége. Ennyi idı letelte után azonban újra riaszt, és az elıbb ismertetett folyamat játszódik le. Ez ismétlıdik ciklikusan 10 másodperces periódusidıvel, amíg a füst érzékelhetı.
9.2. A detektor eltávolításának érzékelése A tengelyek normáltak: a csomagok és a másodpercek száma 10-zel került leosztásra. Az 57. ábrán azt az esetet látjuk, amikor a detektort eltávolítottuk az aljzatból. A piros grafikon az összforgalmat jeleníti meg.
57. ábra – a detektor eltávolításának jelzése
A mikrovezérlı 5 másodpercenként ellenırzi a timer megszakítás rutinban, hogy helyén van e a detektor. Mivel a jelen esetben ez nem teljesül, a végberendezés üzeneteket küld, melyeket a koordinátor nyugtáz.
50
10. Kitekintés és értékelés Ahogy az IEEE 802.15.4.-es és ZigBee szabványok alkalmazások egyre szélesebb körében kerülnek felhasználásra, egyre nı az olyan eszközök iránti igény, melyek segítik a készülı hálózatok fejlesztését és monitorozását. A kész rendszer protokoll stack írásához, hálózati csomópontok alkalmazás rétegbeli szoftverének fejlesztéséhez hatékony segítséget nyújtott ZigBee szenzorhálózatok tervezésénél. Az elkészült hálózat tartós monitorozását leginkább az adatgyőjtı Snifferek számítógépekhez való kötıdése korlátozza. Ez komoly nehézséget jelent kültéri helyen levı szenzorhálózat tartósabb figyelésénél. (lásd még 10.1) Ilyen esetben a hálózat analizátor mindaddig elláthatja tesztelési feladatát, amíg a fejlesztett rendszer ki nem kerül rendeltetési helyére. Munkám megkezdése elıtt még alig találtam hasonló eszközt az interneten, ma azonban könnyebb felsorolnom néhány hasonló céllal készült terméket, ez is mutatja a fejlesztık növekvı igényét. A következıkben röviden összehasonlítást végzek ezekkel.
Daintree Networks – SNA (Sensor Network Analyzer): Az elsı és legfontosabb ZigBee hálózat analizátor, mely fıleg fejlesztési célra készült, a Freescale ZigBee protokoll stackjének fejlesztésében is nagy szerepe volt. Itt nem pusztán passzív adatgyőjtésrıl van szó, az observerek kommunikálni is képesek a hálózat csomópontjaival, lekérhetik elemszintjüket, stb. Az adatgyőjtık hasonlóan USB kábellel csatlakoznak a PC-hez, amin a hálózat analizátor program fut. Az adatok távoli PC-re való küldése Ethernet hálózathoz kötött. A munkát szépen kidolgozott grafikus interfész támogatja. A monitor rendszer teljes ára több mint $8000 már 1 adatgyőjtıvel is. [23] FTS4ZB IEEE 802.15.4 & ZigBee Wireless Protocol Analyzer, Packet Sniffer, & Bus Analyzer: Ez csupán egy protokoll analizátor, fejlesztési célra készült eszköz. Nincs szó több adatgyőjtı csatlakozásáról a hálózathoz, nem lehet távoli szerver gépre sem küldeni az adatokat. Az ismertetı nem szól struktúra felderítésrıl, statisztika készítésérıl sem. Az interneten több hasonló funkcionalitású eszközrıl sikerült még tudomást szereznem. [25] Tendril Networks – Tendril Monitor: Egyszerőbb felhasználói interfésszel rendelkezı analizátor, amely a kész hálózat monitorozását célozza meg. Egyes eseményekkor (pl. csomópont elemszint lemerülése) riasztások generálódnak. Nincs szó azonban adatgyőjtıkrıl és implicit kémkedésrıl, a monitor rendszer magába a Tendril Network Operating Platformba épül bele, tehát az alkalmazásoknak ezen kell alapulnia a monitor használatához. Tehát a hálózat felügyelése nem adatgyőjtı hardverek által vett üzenetek elemzésén alapul, hanem egy beépülı szoftverkomponens alkalmazásán. [24] Monitorom egyik elınye ezzel a megoldással szemben éppen az, hogy független a gyártótól és az általa használt szoftver stacktıl, az egyetlen kikötés csak az, hogy a hálózat kommunikációja szabványos legyen. Biztonság (security) kérdése: A vezeték nélküli szenzorhálózatnak sok esetben fel kell készülnie "hálózati támadások" ellen: üzenetek elnyomása (jamming), adatok vétele és feldolgozása illetéktelen személyek által, illetve hibás mőködést eredményezı csomagok 51
küldése rosszindulatú eszközökkel. A szabvány security része egy szimmetrikus kulcsokon alapuló kriptográfiai eljárást alkalmaz. Ez egy olyan technika, ahol a kódoláshoz és a dekódoláshoz szükséges kulcs egyforma. Egy közös kulcs tartozik két eszközhöz vagy egy egész csoporthoz. A protokoll szerint a titkosítás mértéke is megválasztható, azonban erısebb titkosítás nagyobb overheadet jelent. A MAC, NWK, APS rétegek külön-külön is felelısek a belılük induló keretek kódolásáért. ([2], 4)
Titkosítás használatával a hálózat analizátor alkalmazása lehetetlenné válik, ezért a monitorral való tesztelést a titkosítás kikapcsolásával kell elvégezni.
10.1. Adatgyőjtık illesztése GSM/GPRS modemhez Az alkalmazás egyik legfontosabb korlátját az adatgyőjtık számítógépekhez való kötıdése jelenti. Ezt a problémát azonban feloldhatjuk a Snifferek olyan GSM/GPRS modemmel való kiegészítésével, melyen belsı TCP/IP stack található. Az adatgyőjtık ekkor nem az USB/UART chip felé küldik a beérkezı csomagokat, hanem változatlanul RS232 kommunikációval a modem felé. Erre a célra egy Wavecom Fastrack M1306B eszközt választottam, mely AT parancsokkal vezérelhetı. A Snifferek programja nem változik számottevıen, csupán inicializáló és adat küldı AT parancsok kiadását kell használnunk, melyeket a [35] dokumentáció ír le. Nem szabad megfeledkezni a következı 2 lényeges változtatásról sem: adatgyőjtık tápellátása (ebben az esetben elemes), adatgyőjtık indítása, csatorna beállítása (ebben az esetben nyomógombok segítségével). Az analizátor program fel van készítve távoli kliensekkel való TCP/IP kapcsolatra, így a szoftveren és a felhasználói interfészen változtatást nem kell végezni. Ez a kiegészítés jelenleg még fejlesztés alatt áll.
52
11. Köszönetnyilvánítás A TDK-hoz kapcsolódó fejlesztés eszköz hátterét a SpinBee kft. Kutatásfejlesztési Pályázati és Kutatáshasznosítási Iroda (KPI) GVOP-3.3.105/1.-2005-05-0120/3.0 számú projektje biztosította.
1 2. Irodalomjegyzék [1] IEEE 802.15.4 – 2006: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs) (IEEE Standard for Information technology— Telecommunications and information exchange between systems— Local and metropolitan area networks— Specific requirements)
[2] ZigBee Specification – 2006 - The ZigBee Specification describes the infrastructure and services available to applications operating on the ZigBee platform
[3] David Geer, Users Make a Beeline for ZigBee Sensor Technology, IEEE Computer Society, ieeexplore.ieee.org/iel5/2/33102/01556477.pdf?arnumber=1556477, 2005. [4] Dr. Vidács Attila (TMIT), Szenzorhálózatok – Szabványok – elıadásvázlat, 2006. hsnlab.tmit.bme.hu/~vidacs/w3_hu/education/sensor_networks/ [5] Simon Gyula (MIT), Szenzorhálózatok – elıadásvázlat, 2006. [6] Universal Serial Bus: http://www.usb.org/home, 2007. [7] Dr. Tóth Csaba (MIT), Monitorok - elıadásvázlat, home.mit.bme.hu/~toth/, 2007. [8] P. Krishna Reddy, Monitors, International Institute of Information Technology (IIIT) www.iiit.net/~pkreddy/pecs02/slides/lec10_monitors.ppt, 2007. [9] MC13213 Reference Manual, MC1321xRM.pdf, Freescale Semiconductor, www.freescale.com/zigbee, 2006. [10] Compact Integrated Antennas, Designs and Applications for the MC1319x, MC1320x, and MC1321x, AN2731.pdf, www.freescale.com/zigbee, 2006. [11] 2.45 GHz Balun, Johanson Technology, www.johansontechnology.com, 2003.
53
[12] CP2103, Single-Chip USB to UART interface, Silicon Labs, www.silabs.com/ tgwWebApp/public/web_content/products/Microcontrollers/Interface/en/interface.htm, 2006. [13] Getting Started with Winsock, http://msdn2.microsoft.com/enus/library/ms738545.aspx, 2007. [14] Programming Windows TCP Sockets in C++ for the Beginner, http://www.codeproject.com/internet/beginningtcp_cpp.asp, 2007. [15] Custom drawn vertical tree control, http://www.codeproject.com/treectrl/vertical_treeV1.asp, 2005. [16] Configurating the System and Peripherial Clocks in the MC9S08GB/GT, Freescale Semiconductor, www.freescale.com, 2007. [17] 802.15.4 Media Access Controller (MAC) MyWirelessApp, User’s Guide, Freescale Semiconductor, www.freescale.com, 2006. [18] 802.15.4 MAC PHY Software, Reference Manual, Freescale Semiconductor, www.freescale.com, 2006. [19] 802.15.4 Media Access Controller (MAC) MyStarNetworkApp, User’s Guide, Freescale Semiconductor, www.freescale.com, 2006. [20] Freescale ZigBee Application, User’s Guide, Freescale Semiconductor, www.freescale.com, 2007. [21] MC1319x, MC1320x, and MC1321x Demonstration Operation, Running SMAC Based Demonstration Operations, Freescale Semiconductor, www.freescale.com, 2006. [22] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, E. Cayirci: A Survey on Sensor Networks, IEEE Communications Magazine, 08. 2002. [23] Daintree Networks, www.daintree.net/products/index.php, 2007. [24] Tendril Networks, www.tendrilnetworks.com/prod_monitor.php, 2007. [25] FTS4ZB IEEE 802.15.4 & ZigBee Wireless Protocol Analyzer, Packet Sniffer, & Bus Analyzer, www.fte.com/products/FTS4ZB-01.asp, 2007. [26] Serial library for C++, www.codeproject.com/system/serial.asp, 2003. [27] Zoran M. Todorovic, A Visual Framework (Views, Tabs and Splitters), www.codeproject.com/dialog/visualfx.asp, 2002. 54
[28] Paul Barvinko, A 2D data visualisation class, www.codeproject.com/miscctrl/graph2d.asp, 2000. [29] Siemens With ZigBee Deploys First Wireless Building Automation System www.zigbee.org/en/markets/success_stories.asp, 2007. [30] Control4 Unleashes Full Line of Standards-Based Controllers, Control4, www.control4.com/company/inthenews/c/162-313A61D6.htm, 2004. [31] World’s First Mobile Phone with ZigBee Solution, www.3g.co.uk/PR/December2004/8787.htm, 2004. [32] Wireless Networking with IEEE 802.15.4 and ZigBee, Software Technologies Group, www.stg.com/wireless, 2007. [33] Simple Media Access Controller (SMAC), User’s Guide, User’s Guide, Freescale Semiconductor, www.freescale.com, 2007. [34] Kelemen Szabolcs Tibor, Vezeték nélküli szenzoregységek fejlesztése, diplomamunka, 2007. [35] AT Commands Interface Guide for IP Connectivity, Wavecom, 2005.
55
1 3. Függelék 13.1. A Sniffer kapcsolási rajza
56
13.2. Layout terv – Top
1
1
1
2
2
1
2
2
5
4
38
3
2
1
6
1
6
4
2
1
2
1
2
2
1
1
2
1
58
13.3. Layout terv – Bottom 1
1
2
2
5 1
2
2 2
4
2
1
1
1 2
2
1
2
1 1
3 1
2 2
2 2
1
1
2
2
1
1
1
6
4
2
2
3
1
4
2 2 2
2
1
1 1
2
1
6
1
1
1
59
2
