ZigBee hálózat analizátor fejlesztése

Átírás

1 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 október

2 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 Szenzor mezı Megfigyelık (observers) A PC-n futó felhasználói program, betöltött szerepek 8 3. Az elkészített monitor rendszer rétegei Adatgyőjtés, megfigyelés (Sniffer HW) Adatkoncentrálás (SW) Adatfeldolgozás, analizálás (SW) Megjelenítés (SW) Lekérdezı egység (commander HW, SW) Értelmezés Konzol és menedzsment A saját fejlesztéső adatgyőjtı Sniffer eszközök és azok szoftveres vezérlése Az adatgyőjtı Sniffer hardver specifikációja Az IEEE es szabványnak megfelelı hardver legfontosabb tulajdonságai A legfontosabb paraméter: bemeneti sebesség Sniffer firmware terv A bemeneti sebesség becslése Az adatgyőjtık RS232 USB interfésze A Sniffer eszközök vezérlése a kezelıprogrammal A monitor program (I.) az adatkoncentrátor és megjelenítés (PHY nézet) Nyomok (trace-ek) Üzenetek összefésülése, redundáns üzenetek kezelése, archiválás, kliens-szerver Rendszerüzenetek, kliensek csatlakozása egy távoli szerverhez A monitor program (II.) az analizátor és megjelenítés Csomag szőrı (packet filter) ZigBee csomag dekóder MAC nézet és MAC réteg, csatlakozási folyamatok a 2. példahálózatban 31 1

3 NWK nézet és NWK réteg, route-ok kiépülése és riasztások a 2. példahálózatban APS nézet és APS réteg, binding és riasztások a 2. példahálózatban Statisztika Hálózati struktúra Szomszédossági mátrix Hálózati forgalom, node-ok aktivitása PER (packet error rate) teszt ZigBee hálózatok vizsgálata Hálózat regenerációja Freescale Protocol Stack Router kiesése a hálózatból Koordinátor átmeneti kiesése a hálózatból Csomópontok terhelésének eloszlása Protokoll stack hibák kiszőrése Lekérdezı egység Hálózati csomópontok fejlesztése A füst érzékelése A detektor eltávolításának érzékelése Értékelés és kitekintés Adatgyőjtık illesztése GSM/GPRS modemhez Köszönetnyilvánítás Irodalomjegyzék Függelék A Sniffer kapcsolási rajza Layout terv Top Layout terv Bottom 58 2

4 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 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 ) 1. ábra - Az IEEE és ZigBee szabványok illeszkedése [4] 3

5 É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

6 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 é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

7 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 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 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

8 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 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 maximális hossza 5 m lehet, ha nem alkalmazunk hubokat. [6] Ez korlátozza a megfigyelhetı szenzormezı méretét. Az 5. ábra a megfigyelhetı szenzormezı mérete IEEE 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

9 van. Ezzel kapcsolatos megfontolásokat a rész tartalmaz. A megvalósításra a közeljövıben fog sor kerülni 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

10 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

11 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 Adatfeldolgozás, analizálás (SW) Csomag dekóder: Dekódolja a IEEE 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 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 / 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

12 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.) 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.) 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 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

13 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 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 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 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 = (k 11) MHz, ahol k = 11, 12,, 26 a csatorna száma. ([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

14 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

15 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 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

16 regiszterében beállítható változó. Ha z=10 f = 20MHz. A 20 MHz a µc számára beállítható busz frekvencia maximális értéke, így választásom erre esett. Bus 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 Bus BR = [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 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

17 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

18 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

19 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] 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 = ms-nál volt igaz. Ebbıl a bemeneti sebesség számolása: v input = = 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 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

20 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], ) 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

21 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 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

22 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

23 15. ábra Az elkészített analizátor program PHY nézete 22

24 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ó ( 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 COM6- ra 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

25 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 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

26 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 / 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

27 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], ) 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 a CSMA/CA algoritmusnak megfelelıen 17. ábra Csomag ütközés [4] 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

28 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], ) á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], ) 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 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

29 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 ZigBee csomag dekóder A szőrın átjutott csomagokat az IEEE 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ú volt, ennek a csomagnak a MAC payloadja a NWK nézetben ki kell értékelıdjön, hiszen ez már a NWK réteghez tartozik. Ha a csomag MAC command típusú volt, akkor a MAC réteggel kapcsolatos parancsot hordoz. A MAC réteg legfontosabb feladatai: 20. ábra - Az IEEE és ZigBee szabványok rétegei [4] 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 é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

30 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], ) Csoportos címzés kezelése ([2], ) 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 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], ). 29

31 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

32 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 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

33 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= : Az elızıhöz hasonlóan a narancssárga új router is csatlakozik a PAN-hez a kék routeren keresztül :Egy szürke színt kapó eszköz lép be, melynek szülıje a kék lesz á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

34 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

35 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, címő végberendezés üzenetet irányít a 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, C2 0A C 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, : 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 ábra az ismertetett útvonal (lásd még 6.4.) : 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 ) 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

36 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

37 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], ) 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 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

38 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 C2 07 1C 0C 14 0A, a C2 0A C 13 és a 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ó 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

39 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 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

40 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

41 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 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], ) 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

42 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

43 7. ZigBee hálózatok vizsgálata 7.1. Hálózat regenerációja Freescale Protocol Stack 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

44 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], ), melyben közli IEEE címét és új rövid címét is : 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 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

45 az új PAN-t. Végtelen ciklus következik a koordinátor beacon kérelmeivel: A fenti folyamat ciklikusan ismétlıdik anélkül, 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 ( ) 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ı 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. 46. ábra utak az 5. példahálózatban 47. ábra utak a 6. példahálózatban 44

46 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 esetén! 7.3. Protokoll stack hibák kiszőrése 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: összehasonlítás koordinátor 9.39% 12.3% 1. router 4.22% 1.67% 2. router 17.8% 16.9% 3. router 32.16% 17.62% 4. router 7.04% 23.1% 1. end device 10% 9.2% 2. end device 16.43% 16.67% 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], ) 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

47 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], ) -active_ep_req: Az erre adott válaszban az egység aktív endpointjainak listája található. ([2], ) -mgmt_rtg_req: Egy eszköz routing táblájának lekérdezése. ([2], ) Az eszközt egy SARD kártyán valósítottam meg, melyre egy olyan szoftvert írtam, mely a soros vonalon érkezı karaktersorozatot IEEE 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

48 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], ) 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

49 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

50 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 0- ba á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 A füst érzékelése 56. ábra füst detektálása ( hálózati forgalom nézet ) 49

51 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ı 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