Hevesi Richárd ZigBee alapú adatgyűjtő hálózat tervezése Budapesti Műszaki- és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Méréstechnika és Információs Rendszerek Tanszék KONZULENS Tóth Csaba BUDAPEST, 2022
Hevesi RichárdZigBee alapú adatgyűjtő hálózat
tervezése
Budapesti Műszaki- és Gazdaságtudományi EgyetemVillamosmérnöki és Informatikai Kar
Méréstechnika és Információs Rendszerek Tanszék
KONZULENS
Tóth CsabaBUDAPEST, 2023
Hallgatói Nyilatkozat
Alulírott Hevesi Richárd, szigorló hallgató kijelentem, hogy ezt a diplomatervet meg
nem engedett segítség nélkül, saját magam készítettem, csak a megadott forrásokat
(szakirodalom, eszközök, stb.) használtam fel. Minden olyan részt, melyet szó szerint,
vagy azonos értelemben de átfogalmazva más forrásból átvettem, egyértelműen, a forrás
megadásával megjelöltem.
Tudomásul veszem, hogy az elkészült diplomatervben található eredményeket a
Budapesti Műszaki- és Gazdaságtudományi Egyetem, a feladatot kiíró egyetemi
intézmény saját céljaira felhasználhatja.
Kelt: Budapest, 2023. 05. 25.
.....................................................................Hevesi Richárd
Kivonat
Az elektronikus alkatrészek méretcsökkenése új távlatokat nyitott az
informatikában. Az intelligens alkatrészek szinte mindenhol feltűntek, megjelent a
mindenütt jelenlévő számítástechnika, „ubiquitos computing” fogalma. A kis
méretű és fogyasztású alkatrészek lehetővé tették szenzorhálózatok kialakítását,
amelyeket különböző célokra kezdtek felhasználni, például épületek fűtésének,
világításának szabályozására, környezeti monitorozásra, ipari adatgyűjtésre.
A BME Méréstechnika és Információs Rendszerek Tanszéken fejlesztett
szenzorhálózati rendszer a mitmót. Moduláris szerkezete és ISM sávú rádiós
modulja alkalmassá teszi környezeti monitorozó hálózat kiépítését a rendszer
segítségével.
A piacon elérhetőek különböző kész megoldások, illetve kísérleti platformok,
hátrányuk, hogy sok esetben saját, nem szabványos megoldásokat használnak a
hálózati kommunikációra, illetve zárt forráskóddal rendelkeznek, portolásuk nem
lehetséges mitmótra.
Diplomamunkám célja egy szabványos, ZigBee alapú környezetmonitorozó
hálózat tervezése a mitmót rendszer sajátosságainak figyelembe vételével, és a
ZigBee egy részének implementálása. A teljes szabvány implementálása nem fér
bele egy félévnyi munkába, a cél egy bővíthető rendszer létrehozása, amely már
rendelkezik a ZigBee alapvető funkcióival, képes a szabványos kommunikációra.
Az általam nyújtott megoldás képes a szabványos kommunikációra, és fel van
készítve a bővítési lehetőségekre.
3
Abstract
Decreasing size of electronic parts brought new horizons to informatics.
Intelligent sensors have become part of our life, we spoke about „ubiquitos
computing”. Small and low power-cunsuming parts made it possible to form sensor
networks, which can be used for home automation, environmental monitoring,
industrial monitoring.
Mitmót is sensor network platform, developed at the Department of Measurement
and Information Systems, BUTE. Its modular design and ISM radio module makes
it possible to build an environmental monitoring system.
On the market, there are existing solutions for this problem, but most of them
uses non-standard network protocols, or their source code is closed, it is impossible
to port it to mitmót.
The goal of my graduate work is to examine the abilities of ZigBee for building
an environmental monitoring system using mitmót, to design the system, and to
implement some parts of it. Implementing a whole standard is impossible within a
semester, so my goal is to implement a subset that is able to communicate
according to the rules of the standard. My solution fulfils theese requirements, and
can be expanded to implement more parts of the standard.
4
Tartalomjegyzék
1 Bevezető.............................................................................................................12 Adatgyűjtő hálózatok.........................................................................................2
2.1 Követelmények.............................................................................................22.2 Létező technológiák áttekintése...................................................................9
2.2.1 Tenet...................................................................................................92.2.2 TinyOS..............................................................................................122.2.3 SensiNet............................................................................................152.2.4 SunSpot.............................................................................................182.2.5 ZigBee alkalmazások........................................................................19
3 A ZigBee szabvány áttekintése........................................................................243.1 A ZigBee elhelyezkedése a vezeték nélküli technológiák között..............243.2 IEEE 802.15.4............................................................................................253.3 ZigBee architektúra....................................................................................313.4 Alkalmazási réteg.......................................................................................32
3.4.1 Csomagformátum..............................................................................333.4.2 Csoportcímzés...................................................................................333.4.3 Kötés (binding).................................................................................343.4.4 Alkalmazásprofilok...........................................................................343.4.5 Eszközleírók......................................................................................353.4.6 Eszközök felderítése.........................................................................363.4.7 ZigBee Device Object és ZigBee Device Profile.............................37
3.5 Hálózati réteg.............................................................................................373.5.1 Topológia..........................................................................................383.5.2 Csomagformátum..............................................................................393.5.3 Elosztott címhozzárendelés...............................................................393.5.4 Útvonalválasztás...............................................................................40
3.6 A ZigBee értékelése...................................................................................424 ZigBee alapú környezetmonitorozó rendszer mitmóton..................................43
4.1 Követelmények...........................................................................................434.2 Architektúra................................................................................................474.3 Megvalósítandó funkciók...........................................................................52
4.3.1 IEEE 802.15.4...................................................................................524.3.2 Zigbee...............................................................................................53
4.4 ZigBee alkalmazás profil...........................................................................564.4.1 Adatgyűjtő cluster.............................................................................57
4.5 Szenzorhálózaton kívüli elemek.................................................................595 A szoftverkomponensek megvalósítása...........................................................62
5.1 Platform......................................................................................................625.2 Felhasznált komponensek..........................................................................62
5.2.1 DPY API...........................................................................................625.2.2 Com_r04_s01b1 API........................................................................635.2.3 IEEE 802.15.4 fizikai és MAC réteg................................................63
5.3 Architektúra................................................................................................63
5
5.4 Tervezési döntések.....................................................................................665.4.1 Eltérések a szabványtól.....................................................................665.4.2 Programozási konvenciók.................................................................675.4.3 Hibakezelés.......................................................................................675.4.4 Azonosítók, címek............................................................................685.4.5 Megvalósított egységek....................................................................695.4.6 Konfiguráció.....................................................................................70
5.5 Példaalkalmazás.........................................................................................705.5.1 A főprogram......................................................................................73
5.6 Továbbfejlesztési lehetőségek....................................................................73Összefoglalás............................................................................................................75
6
1 BevezetőAz informatika rohamos fejlődése már néhány évvel ezelőtt lehetővé tette kis
méretű, alacsony tápfeszültségről üzemelő számítógépek építését. Lendületet kapott
az ezekből az eszközökből épített szenzorhálózatok kutatása, fejlesztése. Egy igen
gyakori alkalmazás lett az adatgyűjtő hálózat, ahol a terepre kihelyezett szenzorok
egy központ felé továbbítják a mért adatokat.
Kreatív megoldások születtek a szenzorhálózatok felhasználására, mint például
beteg emberek egészségi állapotának monitorozása, környezetvédelmi projektek,
katasztrófavédelem támogatása, épületek energiafelhasználásának optimalizálása.
A hálózatokban ISM sávú rádiós kommunikációt alkalmaztak, felmerült az igény
szabványok kidolgozására, amelyek biztosítják több rendszer egymás mellett élését,
együttműködését.
Az IEEE 802.15.4 [19], és a rá épülő ZigBee [21] szabványok hivatottak ennek
megvalósítására, de léteznek más megoldások is. Sok cég teljes rendszert kínál,
mások csak hardvereszközöket. A legnépszerűbb szoftveres platform a Berkeley
egyetemen fejlesztett TinyOS operációs rendszer [5].
A következő fejezetben az adatgyűjtő hálózatok által támasztott
követelményeket, a felmerülő problémákat ismertetem, és a létező fontosabb
technológiákról nyújtok áttekintést. A terület fiatalsága miatt belekerültek jövőbe
mutató, de manapság még nem túl széles körben ismert termékek, megoldások is.
A 3. fejezetben bemutatom a 802.15.4 és ZigBee szabványok fontosabb elemeit.
A 4. fejezetben egy rendszertervet ismertetek, amely egy mitmót [24] rendszerre
épülő, ZigBee szerint működő környezetmonitorozó hálózatot valósít meg.
Az 5. fejezetben az elkészített szoftverkomponensek tervezésének menetéről,
architektúrájáról, illetve a szabványtól való eltérésekről számolok be.
A dolgozatot az eredmények értékelése, a továbbfejlesztési lehetőségek
ismertetése zárja.
2 Adatgyűjtő hálózatok
2.1 KövetelményekA szenzorhálózatok egy igen elterjedt, talán a leggyakrabban használt
alkalmazása az adatgyűjtő hálózat. Egy ilyen hálózatban a csomópontokhoz
szenzorok kapcsolódnak, és a feladat a szenzorok által mért érték eljuttatása egy
központi helyre. A szenzorokhoz kapcsolódó egységek általában vezeték nélküli
hálózati kapcsolattal rendelkeznek. Az adat ezen a szakaszon (a rádiós hálózaton)
keresztülhaladhat több egyenrangú csomóponton, vagy fölérendelt forgalomirányító
állomáson. A hálózat határán egy bázisállomás, amely átjáróként is funkcionálhat,
átveszi a mért értékeket. Ettől a ponttól még az adat eltárolása, feldolgozása,
megjelenítése van hátra, erre is több módszer létezik. A bázisállomás sok esetben
rendelkezik Internet kapcsolattal, és egy távoli szerverre tölti fel periodikusan az
összegyűjtött fájlokat, de ez manuálisan is megtehető, vagy az is elképzelhető, hogy
a bázisállomás egyben a feldolgozó szerver is. A szenzorok közötti vezeték nélküli
kapcsolat a legtöbb esetben ingyenesen használható ISM (Industrial, Scientific,
Medical) frekvenciasávokon van megvalósítva.
A diplomamunka keretében környezeti adatgyűjtő, monitorozó hálózatokat
fogunk vizsgálni. Manapság egy aktuális probléma a globális felmelegedés és a
vele járó következmények. Az ezzel kapcsolatos folyamatok megértésében (és más
környezeti vizsgálatok, kísérletek esetében is) igen nagy segítséget tudnak nyújtani
a világ különböző pontjain elhelyezett szenzorokból származó adatok.
Egy világméretű példa erre az International Long Term Ecological Research
(ILTER) [18] hálózata. A szervezet célja ökológiai adatok gyűjtése, feldolgozása a
világ minden tájáról. Az adatok segítik a tudósokat hosszú távú globális folyamatok
megfigyelésében, az összefüggések megértésében.
Magyarország a Síkfőkút projekten keresztül van kapcsolatban a szervezettel. A
Síkfőkút projekt a Debreceni egyetemen alapult 1972-ben, akkoriban
avarlebomlással kapcsolatos kutatásokat folytattak egy Noszvaj melletti erdős
területen. A hosszú távú megfigyelések a 90-es évektől kerültek előtérbe, ekkor
kerültek kapcsolatba az ILTER projekttel. A régi eszközök lecserélése és egy
modernebb adatgyűjtő hálózat tervezése kapcsán a BME MIT tanszéke is
kapcsolatban áll a projekttel, az önálló laboratórium során olyan hardver- és
szoftverelemeket terveztünk, fejlesztettünk, amelyek a tervek szerint Síkfőkúton
fognak megfigyeléseket végezni.
Az előzőekben említetthez hasonló jellegű hálózatoknál régebben gondot
jelentett, hogy gyakorlatilag nem volt hálózat. A dataloggerek ki voltak téve a
terepre, a szakemberek néha kiutaztak, összegyűjtötték őket, feltöltötték az
akkumulátort, letöltötték az adatokat, a szenzorokat ezután visszatették a helyükre.
Az adatokat a laborban értékelték ki. Egy szenzorhálózat nagy segítséget nyújthat
ennek a feladatnak az automatizálásában, és a költségeket is jelentősen
csökkentheti.
Adatgyűjtő hálózatot elképzelhetünk egy épületen belül is, például hőmérséklet
adatok gyűjtésével optimalizálható a fűtés szabályozása, vagy egy irodaházban az
alkalmazottak tartózkodási helyét is nyomon követhetjük. Egy gyártósoron a
termékek pozícióját vagy bizonyos tulajdonságait figyelhetjük meg egy adatgyűjtő
hálózat segítségével. Ezek a hálózatok, bár egymáshoz nagyon hasonlóak, mégis
különböző követelményeket támaszthatnak erőforrásigény, mintavételi frekvencia
és egyéb szempontokból.
A továbbiakban főleg a környezeti adatgyűjtő rendszerekre összpontosítunk, az
ezek által támasztott követelményeket gyűjtjük össze.
Az alábbi ábrán egy ilyen rendszer tipikus felépítése látható:
2-1. ábra Egy adatgyűjtő hálózat architektúrája
A bázisállomás általában össze van kötve egy nagyobb teljesítményű, Internet
kapcsolattal rendelkező számítógéppel, a folyamatos áramellátás biztosított. Az
átjátszó állomások úgy vannak elhelyezve, hogy a legtávolabbi szenzoregység jelét
is tudja fogni valamelyik. A szenzornode-ok a legegyszerűbb egységek, időnként
végeznek egy mérést, az adatot elküldik a központba, majd kis fogyasztású alvó
üzemmódba kapcsolnak. Csak a bázisállomással vagy egy routerrel tudnak
kommunikálni, egymással nem. A routerekre azért van szükség, hogy a
bázisállomás hatósugarán kívül lévő szenzoregység üzeneteit is továbbítani tudja.
Az eszközökkel szemben különböző követelményeket támasztunk.
Erőforrásigény:
A szenzornode-okat általában a terepre teszik ki, ahol nincs állandó hálózati
tápellátás, ezért elemről, akkumulátorról kell működniük. Ehhez mérten csak kis
órajelű (maximum néhányszor 10 MHz) processzort és kevés memóriát
engedhetünk meg. A működést néhány éves időtartamig kell fenntartani, mert az
eszközök begyűjtése, feltöltése és újra kihelyezése költséges művelet, ezt nem
akarjuk évente többször megismételni.
A routerekre vagy átjátszó állomásokra is megszabhatunk ilyen szigorú
feltételeket, ám a jelenlegi megoldásokban általában azt feltételezik, hogy van stabil
tápfeszültségük. Ennek oka, hogy ezeknek az egységeknek nagyon gyakran kell
vételi üzemmódba kapcsolniuk, hogy ne késsék le a szenzorok által küldött
adatokat, és ki tudják cserélni a hálózat adminisztrációs üzeneteit. Elemes működés
esetén rövidebb élettartamra számíthatunk, de ezek az eszközök általában
nagyságrendekkel kevesebben vannak, mint a szenzoregységek, így az újratöltés
kevésbé költséges.
A bázisállomásról feltételezzük, hogy hálózati vagy egyéb nagy teljesítményű,
stabil tápegységgel rendelkezik.
Adatátviteli sebesség
A hálózatban nincs szükség nagy adatátviteli sebességekre, mert a forgalom
jellegzetesen ritka, kis mennyiségű adat, ezért néhányszor 10 kbit/s általában elég, a
ZigBee szabvány 20, 40, és 250 kbit/s sebességet támogat. Egyes alkalmazásoknál
fontos a kicsi vagy fix késleltetés, ennek kielégítésére is léteznek megoldások,
például előre kiosztott időrések. Kis késlelteés igényű alkalmazások inkébb az ipari
problémák esetén fordulnak elő, környezeti rendszerekben kevésbé. Például egy
gyártósor szabályozásánál a vészjelzések számára fontos, hogy a lehető
legkevesebb késleltetéssel befussanak a központba, így a megfelelő óvintézkedést
időben meg lehet tenni.
A bázisállomást és a központot összekötő hálózatban már koncentráltan jelennek
meg az adatok, de a legtöbb alkalmazásnak egy modemes vagy egy GPRS
kapcsolat már elég, ha az adatokat nem azonnal kell elküldeni, csak időnként, és
esetleg még tömörítésre is van lehetőség.
Mintavételi frekvencia
Egy környezeti adatokat gyűjtő hálózatban a mintavétel gyakorisága órákban. A
mért jellemzők (hőmérséklet, páratartalom, stb.) jellegzetesen lassan változnak,
nem szükséges percenként vagy gyakrabban mérni. Egy CO2 koncentrációt mérő
szenzor nem is képes ilyen frekvenciával működni, az érzékelő bekapcsolása is
perceket vesz igénybe. Természetesen, egy gyártósoron vagy egy épületben más
igények is felmerülhetnek, akár másodpercenkénti vagy másodpercenként többszöri
mérésre is szükség lehet (például futószalag vibrációjának mérése).
A mintavételi frekvencia a tápfeszültségigénnyel is kapcsolatban áll: minél
gyakrabban kell mérést végezni, és a mért adatokat elküldeni a központba, annál
több energiát fogyaszt, annál hamarabb meríti le a szenzor az áramforrást.
Konfigurálhatóság
A csomópontok nagy száma miatt előnyös tulajdonság, ha az eszközök távolról
programozhatók, újraindíthatók, mert előfordulhat, hogy új feladatot kell
végrehajtani, vagy egy új verziójú szoftvert kell feltelepíteni. Nehezen vagy
költségesen megközelíthető hálózatoknál a konfigurálhatóság fontos kritérium.
Kommunikáció más típusú eszközökkel
A szenzornode-októl csak azt várjuk el, hogy egy routerrel vagy a
bázisállomással tudjanak kommunikálni, ezáltal kisebb programot kell futtatni ezen
egységeken.
A routerektől és a bázisállomástól elvárás, hogy minden típusú csomóponttal
képes legyen kommunikálni.
Periodikus működés
Az energiatakarékosság miatt a szenzoregységek az idő nagy részét alvó
állapotban töltik, bizonyos időközönként felébrednek, és elküldik a mért adatot. A
hálózatnak támogatnia kell ezt a fajta működési módot. Ehhez a routernek
folyamatosan vételkész állapotban tartott rádióval kell rendelkeznie, vagy
szinkronizációra van szükség a közte és a vele kommunikáló csomópontok között.
Hibatűrés
Az eszközök nagy számban, nagy területen lehetnek elszórva, ezért fontos, hogy
néhány csomópont kiesése miatt ne omoljon össze a teljes hálózat. Előnyös, ha hiba
esetén a hálózat önszerveződő módon új útvonalakat keres.
Biztonság
Az eszközök nagyon gyakran nyílt terepre vannak kihelyezve, bárki által
hozzáférhető módon, általában felügyelet, őrizet nélkül. Ezen okok miatt mind
fizikai támadásokra (lopás, rongálás, hamis eszközök becsempészése), mind
hálózati támadásokra (üzenetek elnyomása, kicserélése, hamis üzenetek
közbeékelése, féreglyuk támadások) fel kell készülni.
Hálózati kapcsolat
A bázisállomás, routerek, szenzorok között a legtöbb esetben követelmény a
vezeték nélküli kapcsolat az egyszerű telepíthetőség miatt, vagy azért, mert nincs
lehetőség kábelezésre az adott területen (például az erdei állatok megrághatják a
vezetéket). Vezeték nélküli kapcsolat esetén előny, ha ingyenes frekvenciasávot
használunk: erre az ISM sávok biztosítanak lehetőséget. Az ISM sávok kiosztása
kontinensenként eltérő. Amerikában a 900MHz körüli sáv is ingyenes, Európában
helyette a 868MHz körüli sáv használható szabadon, mert 900MHz-en a GSM
hálózatok működnek. A 2.4GHz-es sáv Európában és Amerikában is szabad, ezért
sok rádiós eszközt tesznek alkalmassá ezen a sávon való kommunikációra. A több
különböző típusú eszköz egymás melletti működését az adóteljesítményre, kitöltési
tényezőre vonatkozó előírások teszik lehetővé.
A hálózat határán szükség van egy átjáróra, amely Internet kapcsolattal
rendelkezik, az adatok továbbítása miatt. Ez lehet a bázisállomás is, de ha külön
egység a bázisállomás és az átjáró, akkor közöttük valamilyen kapcsolatra szükség
van. Ez általában egy soros kapcsolat szokott lenni, például RS282 vagy RS485.
Ezek a csatlakozások könnyen elérhetőek, a legtöbb mikrovezérlőn megtalálható
valamelyik. Mivel az átjáró és a bázisállomás fizikailag közel helyezkednek el
egymáshoz, nincs szükség sok vezetékre sem.
2.2 Létező technológiák áttekintése
2.2.1 Tenet
A Tenet [1] rendszer a University of Southern California által fejlesztett hálózat.
A rövidítés jelentése: Tiered Embedded Networks (Többszintű Beágyazott
Hálózat). A többszintűségen a szerzők két szintet értenek.
Az alsó a kis erőforrással rendelkező szenzorcsomópontok szintje, a felső a
központi egységeké, amit tipikusan nagyobb erőforrásokkal rendelkező gépek
valósítanak meg, gyors hálózati kapcsolattal egymás között. Ezek általában nagy
teljesítményű akkumulátorokkal, napelemekkel, vagy hálózati tápegységgel
rendelkeznek. A 2-2. ábrán [1] látható a rendszer felépítése.
2-22-3. ábra A TENET rendszer felépítése [1]
Az architektúra alapelve, hogy a szenzorok legyenek ugyanolyanok, futtassák
ugyanazt a kódot, és a koordinátorok határozzák meg a hálózat működését, ezáltal a
struktúra könnyebben karbantartható, fejleszthető. A szenzorok a központi
egységek által küldött üzeneteket értelmezik, és hajtják végre, így mindenféle
programozást a központi egységeken kell elvégezni. Egy új feladat esetén nem kell
begyűjteni és átprogramozni a szenzorokat, illetve nem kell bonyolult
módszerekkel megoldani a futás közbeni átprogramozást.
A topológia minden esetben fa alakzatú, a szenzoregységek közötti
kommunikáció ugyanis elbonyolítaná a protokollt. A fák gyökerei a központi
egységek, ezek között már nem követelmény a fa topológia.
A klasszikus megközelítés szerint az adatfeldolgozást az adat forrásához a lehető
legközelebb kell elvégezni. Ez csökkenti a kommunikációs költségeket, de nagyban
megnehezíti a karbantartást, mert minden csomópontot egy adott feladatra kell
felkészíteni, új feladat esetén új program szükséges, a fejlesztőknek több szinten
meg kell birkózniuk az algoritmusok fejlesztésével, a szűkös erőforrásokkal.
A Tenet architektúrában a szenzorcsomópontok csak a lokálisan keletkezett
adatokon végeznek adatfeldolgozást, ezzel csökkentve a számítási költségeket, de a
több szenzor adatait megkapó közbülső csomópontok egyáltalán nem (itt például
átlagolást, összegzést, stb. lehetne végezni). Minden további feldolgozás a
központban történik.
A szenzorok működését taskok határozzák meg, melyek egymás után végrehajtott
taskletekből tevődnek össze. A tasklet egy egyszerű funkcionalitást biztosító
programrészlet.
A tervezők a következő alapelveket tartották szem előtt:
Aszimmetrikus kommunikáció: a központból a szenzor felé csak taskok
leírásait szabad továbbítani, a szenzoregységek pedig csak a taskok
eredményét küldhetik, más taskot nem indíthatnak.
Címezhetőség: a központi egységek kommunikálhatnak egymással és
bármelyik szenzorral, amíg erre fizikailag lehetőségük van. A
szenzoregységek csak a központi egységekkel kommunikálhatnak,
egymással nem, és csak a taskok eredményét küldhetik el.
Task library elv: A szenzoregységek egyszerű funkcionalitást biztosítanak,
például időzítőket, tömörítést, érzékelő felületeket. Egy task ezen funkciók
egy sorozatát hajtja végre.
Robusztusság és karbantarthatóság: Robusztus hálózati szolgáltatásokra és
hasznos funkciókat nyújtó felületekre van szükség.
A taskok leírását egy egyszerű programozási nyelv segítségével lehet megadni,
korlátozott mértékben van lehetőség ciklusszervezésre és elágazásra, ezek a
taskletekbe vannak beépítve. Például egy task, amely 500 milliszekundumonként
mintát vesz az ADC0 csatornáról, és egy 20 mintából álló csoportot elküld a
központba LIGHT címkével, a következőképpen néz ki:
Sample(500ms, 20, REPEAT, 1, ADC0, LIGHT) -> SendPkt()
Elágazásokat thresholdokkal adhatunk meg, a ClassifyAmplitude tasklet
segítségével:
Sample(10000ms, 1, REPEAT, 1, ADC0, LIGHT)
-> ClassifyAmplitude(39, 1, LIGHT, ABOVE)
-> StampTime(TIME, LOCAL)
-> LinkAttributes(LIGHT, TIME, AND) -> SendPkt()
Ez a program időbélyeggel ellátva elküldi azokat a LIGHT értékeket, amelyek
39-nél nagyobbak. A StampTime tasklet a TIME címkéhez hozzárendeli az aktuális
időpontot, a LinkAttributes köti össze a két változót, az időpontot és a LIGHT
értéket.
A szerzők állítása szerint néhányszor tíz sornyi kódban megvalósítottak
különböző feladatokat, mint például hálózatfelügyelet, rezonanciamonitorozás. A
taskok futhatnak párhuzamosan is.
A hálózati alrendszer két fő funkciója a taskok utasításainak eljuttatása a
központi rétegből a szenzorhoz, és a válasz visszajuttatása a központba. A rendszer
TinyOS fölött van jelenleg implementálva, a szenzoregységeken az operációs
rendszer által támogatott 16 bites címzést használja. A központi egységek is 16
bites címmel rendelkeznek, az IP cím alsó 16 bitje szolgál Tenet címként, mivel a
központi rétegben IP hálózatot használnak.
A központi rétegben így IP útvonalválasztással kommunikálnak a csomópontok,
az alsó rétegben a taskok terjesztésére megbízható elárasztásos protokollt
használnak. A taskok eredményét az alsó rétegbeli csomópont a legközelebbi
központi egységnek küldi, aki továbbítja a címzettnek a központi, nagyobb
sebességű hálózaton.
A felső rétegbeli csomópontok periodikusan beacon kereteket bocsátanak ki, ami
alapján az alsó réteg eszközei adminisztrálják a legközelebbi központi egységet.
A taskok eredményének visszaküldésénél lehetőség van megbízható adatátvitelre
is, a hálózat képes csomagokat és adatfolyamot (például képi, vagy akusztikus
információt) is továbbítani.
A rendszer alsó rétege TinyOS alapon, a felső réteg PC-ken és IP hálózaton van
megvalósítva, az irodalomjegyzékben található honlapról [1] letölthetőek
ismertetők, esettanulmányok és maga a szoftver.
A használt elv nem újdonság, de figyelemre méltó: az egyes csomópontok helyett
a teljes hálózat irányításában gondolkodni jó ötletnek tűnik, a tervezők, és az
üzemeltetők számára átláthatóbb rendszert eredményez. Hátrány a nagyobb hálózati
forgalom, és a háttérben igényelt infrastruktúra bonyolultsága.
2.2.2 TinyOS
A TinyOS [5] a Berkeley egyetemen fejlesztett, kimondottan szenzorhálózati
alkalmazásokhoz készült operációs rendszer. Kis mérete lehetővé teszi az egyszerű
eszközökön való futtatást. A moduláris szerkezet miatt könnyen fejleszthető. A
tervezők célja egy olyan operációs rendszer kifejlesztése volt, amely alkalmas
szenzorhálózati alkalmazások fejlesztésére, tesztelésére, hibakeresésre.
A programozás egy saját, C-szerű nyelvvel (NesC) lehetséges. A nyelv
alapelemei a modulok és interfészek. A modulok interfészeket valósítanak meg,
illetve interfészeket használnak. Így lehetőség nyílik ezeken keresztül
összekapcsolni az egyes modulokat.
Az energiatakarékos üzemmód be van építve, a rendszer által támogatott
platformokon automatikusan történik az alacsony fogyasztású üzemmódba váltás,
ha épp nincs végrehajtandó feladat.
A hálózati működés operációs rendszer szinten támogatott. Az üzenetek egységes
formátumúak, az ActiveMessage interfészen keresztül kezelhetőek, az eszközök 16
bites címekkel rendelkeznek. A hálózati üzenetek kezelése a GenericComm,
AMStandard interfészeken keresztül történik.
Jelenleg a 2.0-ás verziónál tartanak, ebben kétféle hálózati protokoll van
implementálva, egy elárasztásos üzenettovábbítás, és egy fastruktúrájú hálózat
kialakítása, és a hozzátartozó útvonalválasztási algoritmus (MintRoute).
Az operációs rendszer támogatja a hálózaton keresztüli programletöltést a Deluge
[6] modul segítségével. Az újrakonfiguráláshoz újraindítás szükséges, mely után az
eszköz az új, letöltött programot futtatja.
Az operációs rendszer jelenleg főként kísérleti platformokra van portolva,
közülük is a Crossbow cég termékei vannak túlsúlyban: Mica2, MicaZ, TelosB
mote. Az ábrán a Mica2 [8] mote látható.
2-42-5. ábra Mica2 mote [8]Az Intel által kifejlesztett IntelMote platformot is a TinyOS maximális
támogatásával, a TinyOS fejlesztők együttműködésével tervezik.
A BME-n fejlesztett mitmót platform[24] is futtatja a rendszert. Az önálló labor
keretében készült egy TinyOS alapú adatgyűjtő hálózat, ahol a központi egység egy
PC-hez csatlakozva periodikus lekérdezésekkel vezérelte a hálózatot. A központ az
adattovábbításra elárasztásos protokollt használt, a szenzorok a mért adatokat egy
fastruktúrába szerveződve juttatták el a központba.
A TinyOS volt az első jelentős szenzorhálózati platform, ezért eléggé ismert és
elterjedt, viszonylag jó a hardvertámogatottsága. A programozóknak jó eszközöket
biztosít a fejlesztéshez, hibakereséshez. A meglévő komponensek
újrahasznosíthatóak, így a fejlesztés gyorsabbá válhat, ha találunk a célunknak
megfelelőt. Az előnyök közé sorolható még az ingyenes elérhetőség.
2.2.3 SensiNet
A SensiNet rendszer teljes vezeték nélküli hálózati megoldás szenzorokkal,
átjátszó állomásokkal, bázisállomással, szoftverrel, speciálisan adatgyűjtési célokra
kifejlesztve, ipari és irodai felhasználásra. A rendszer a vezeték nélküli
technológiák fejlesztésével fpglalkozó SensiCast cég fő terméke.
A hálózat a SensiNet Gateway-ből, átjátszó routerekből és szenzoregységekből
épül fel. A hálózat szerveződése automatikus, valamely csomópont kiesése, hibája
esetén önjavító módon helyreáll. Az útvonalválasztási algoritmus két útvonalat tart
nyilván minden Gateway felé, így egy útvonal kiesése esetén a másikra átterelhető
az adatforgalom. A SensiNet Gateway az internet felé továbbítja a hálózaton
begyűjtött adatokat, amelyek így bárhol feldolgozhatóak.
A routerek csak a saját környezetükben lévő szenzorokat tartják nyilván, a tőlük
érkező periodikus üzeneteket figyelik, melyek a jelenlétet jelzik. Ezek az
adminisztrációs üzenetek nem terjednek szét az egész hálózatban, ezzel is csökken
a felesleges adatforgalom, skálázhatóbb hálózatot kapunk. Egy egység
meghibásodása vagy hiánya esetén keletkezik egy adminisztrációs üzenet, amely
szétterjed a hálózatban. Ez szükséges az önjavító tulajdonság biztosításához.
A szenzorok rádióval egybeépítve kaphatók: kontaktusérzékelő, hőmérséklet,
páratartalom, feszültség, áram mérésére alkalmas egységek szerepelnek a
kínálatban.
Az ábrán látható SensiNet Gateway kapcsolja össze a hálózatot a külvilággal,
beépített webszerver fut rajta, így az adatok egy böngészőből lekérdezhetőek. A
népszerűbb rendszerekkel (például: LabView) is összekapcsolható, így a meglévő
infrastruktúrához is könnyen hozzáilleszthető.
2-62-7. ábra SensiCast alkatrészek
Az ábra jobb oldalán egy hőmérő szenzor és egy router látható. A router
egységek hálózati tápellátást igényelnek, de elemről is képesek üzemelni
áramszünet esetén. A szenzorok elemről üzemelnek, és több éves működésre
vannak tervezve. A tervek között szerepel a routerek alkalmassá tétele hosszabb
távú elemről való működésre.
A hálózat 900MHz-en és 2.4GHz-en működik. 2.4 GHz-en a 802.15.4-es
szabványt támogatja (fizikai réteg szinten), de nagyobb amplitúdójú jeleket használ
az ipari környezetben előforduló zavarok jobb tűrése érdekében. A hibatűrés
érdekében automatikusan képes átváltani másik frekvenciasávra, ha az éppen
használt csatorna túl zajos.
Az eszközök bekapcsoláskor önszerveződő módon építik ki a hálózatot, az
adatforgalmazás nyugtázva történik, a routerek képesek több útvonalat
nyilvántartani, és hiba esetén tartalék útvonalon továbbítani az adatot.
Az egyszerű vezérlés és karbantarthatóság miatt lehetőség van programok
letöltésére a szenzorokra rádiós kapcsolaton keresztül. Így rövid idő alatt, az
eszközök begyűjtése és számítógéphez csatlakoztatása nélkül újraprogramozható az
egész rendszer.
A SensiNet egy jól kialakult rendszer, beszerezhető hozzá minden szükséges
alkotóelem, ami az adatgyűjtéshez kellhet. A hálózat vezeték nélküli része nem
szabványos, hanem saját termék, így ebben a rétegben csak SensiNet eszközökkel
bővíthető a hálózat. Az átjárón keresztül kompatibilis egyéb szoftver vagy
hardverelemekkel is. Az önjavító képesség és a begyűjtés nélküli programozás
mindenképpen előnyös tulajdonságai a rendszernek.
2.2.4 SunSpot
A SunSpot rendszer a Sun Microsystems
terméke, a mote-ok érdekessége, hogy
képesek futtatni a Java virtuális gépet. A
Spot betűszó feloldása: Small
Programmable Object Technology. A Sun
technológiai palettáján megtalálhatóak
nagy mennyiségű adat tárolásához,
feldolgozásához szükséges központi
elemek, mint szerver gépek, lemezes
tárolóegységek, szoftverek. A SunSpot
technológia az adatok begyűjtésénél
kapcsolódik be a képbe.
Kifejlesztettek egy új, kis
erőforrásigényű Java virtuális gépet
Squawk néven, ami operációs rendszer nélkül képes futni, az elérhető információk
[3] szerint ARM platformon, illetve a JavaCard kártyákon is ezt használják. A
virtuális gép érdekessége, hogy igyekeztek minél nagyobb részét Java nyelven
fejleszteni, csak a hardverfüggő részeket írták alacsony szintű nyelveken. A
virtuális gép portolása így egyszerűbbé válik. A szűkös erőforrások miatt máshogy
működik, mint egy normál Java virtuális gép, például az osztálybetöltés nem
futtatáskor történik, hanem az alábbi mechanizmus alapján [4]:
A fejlesztés történhet bármilyen Java fejlesztőeszközön, a lefordított bájtkódot a
suite creator program elemzi, optimalizálja, a betöltődő osztályok alapján elkészíti a
memóriaképet, és digitális aláírással látja el az elkészült „.suite” file-t. Így az
eszközön nem kell implementálni az optimalizálást és az osztálybetöltést, amivel
memóriát és processzoridőt spórolhatunk. A digitális aláírás biztosítja, hogy
érvénytelen kódot ne futtasson a virtuális gép, az ellenőrzés elliptikusgörbe-
kriptográfián alapul, ami elérhető az alkalmazások számára is, például a hálózati
kommunikáció biztonságának megteremtéséhez. Az ellenőrzéshez szükséges, hogy
az eszközben el legyen tárolva a fejlesztőeszköz publikus kulcsa. Az aláírást a
program telepítésekor ellenőrzi a gép.
A virtuális gép körülbelül 1 megabájt memóriát igényel.
A SunSpot hardver moduláris felépítésű, a processzort, memóriát tartalmazó
alapkártyához hozzáilleszthetőek különféle szenzorkártyák. A Squawk virtuális gép
futtatását 180 MHz-es ARM 9 processzor végzi, 512Kb belső és 4Mb külső flash
memóriával, ez igen nagy erőforrásokat jelent más hasonló termékekhez képest.
2.4GHz-es IEEE 802.15.4 szabványt támogató rádióval, hő-, fény- és
gyorsulásmérő szenzorokkal rendelkezik. A hozzátartozó Java API támogatja a
802.15.4 rádiós szabványt, és az elliptikusgörbe-kriptográfiát.
A Java technológia bevezetése erre a területre érdekes kihívás, a szabványos
megoldások, a technológia elterjedtsége miatt rengeteg lehetőséget hordoz
magában. A meglévő komponensek és a bináris kód szinten hordozható program
nagyban leegyszerűsíthetik a fejlesztést. A technológia azonban még nagyon friss, a
dolgozat készítésének idején, 2007 áprilisában kezdték meg a SunSpotok árusítását
az USA-ban.
2.2.5 ZigBee alkalmazások
A ZigBee Alliance több cég együttműködése nyomán jött létre, céljuk egy nyílt
szabvány elterjesztése, amely lehetővé teszi alacsony fogyasztású vezeték nélküli
hálózatok kialakítását. A nyílt szabvány miatt ezek a hálózatok egymással
kompatibilisek.
A fő piac az ipari és otthoni automatizálás. A vezeték nélküli technológia
támogatásának oka, hogy a már meglévő otthonokba, üzemekbe utólagos kábelezés
nélkül telepíthető legyen a hálózat.
A szabvány a hálózati és az alkalmazási réteget definiálja az IEEE 802.15.4-re
épülve, biztonsági szolgáltatásokkal. A hálózatot háromféle eszköz alkotja:
végponti eszköz, router, és koordinátor. Ezek erőforrásigénye is eltérő. Egy
végpontnak nem kell a szabvány legbonyolultabb részeit is implementálnia, elég, ha
csak a routerrel képes kommunikálni.
Az épületautomatizálás területén a Control4 és a Schneider Electronics TAC
vállalatának terméke érdemel említést. A Control4 egy otthoni felhasználásra szánt
rendszer, képes kezelni a világítást és a szórakoztató elektronikai eszközöket. Egy
érintőképernyőn keresztül lehet vezérelni, az egyes eszközök egymással ZigBee
hálózaton keresztül tartanak kapcsolatot, a külső eszközökhöz RS232, Ethernet
vagy infra porton kapcsolódhatnak.
A TAC nagyobb épületek, irodaházak vezérlésére alkalmas, például világítás
vagy fűtés szabályozására.
A MaxStream cég terméke a
képen látható alkatrész egy
beépíthető ZigBee modul. 2.4
GHz-es sávon működik,
maximum 100 méteres
hatósugara van. Az XBee Pro-val
akár másfél kilométeres
hatótávolság is elérhető, amit nagyobb adóteljesítménnyel érnek el. Az XBee
teljesítménye 1mW, az XBee Pro-é 60 vagy 100 mW [12,13]. Ezeken kívül AT
parancsokkal vezérelhető modemmel egybeépített egységeket is gyártanak,
amelyek USB vagy RS232 porton keresztül kapcsolódhatnak más rendszerekhez.
A Sensors Silicon Systems [25] cég hőmérséklet-, nyomás- és páratartalom-mérő
szenzorokat kínál a ZigBee moduljához. A begyűjtött adatokat a SensGate rendszer
ODBC meghajtón keresztül képes adatbázisba naplózni. A SensGate egy külön
hardveregység. A csomópontok elemről működtetve végpontokként, hálózati
tápegységről üzemeltetve routerként funkcionálhatnak.
A Silicon Labs [26] szoftveres és hardveres megoldásokat kínál a
ZigBee rendszer alkalmazásával, és fejlesztőeszköz is vásárolható.
A fejlesztőeszköz tartalmaz hat darab rádiós egységet,
fejlesztőeszközt előre definiált tipikus hálózati topológiákkal.
Az ábrán látható CirroNet ZN2401 [9,10] meglévő szenzorokhoz illeszthető,
ezáltal a különálló szenzorokból ZigBee hálózatot hozhatunk létre. Négy darab 4-
20 mA-es bemenete, és két kimenete van, ezen kívül egy hőmérséklet-szenzor
kapcsolható még hozzá. A ZN9001 számú modell ennek a modemnek a 900MHz-
en működő változata.
A Software Technologies Group a nevével ellentétben nem csak szoftvert gyárt,
az SNI (Sensor Network Infrastructure) [14] termékcsalád segítségével a teljes
hálózati infrastruktúrát kiépíthetjük. A termékek között találhatóak szenzorok,
routerek, átjárók, és kész megoldások is. A honlapon két érdekes példaalkalmazás
található: termeszek helyét meghatározó hálózatot készítettek a rovarirtó szer
hatékony elosztására, és egy autókölcsönzési rendszerben lehetséges alkalmazást is
bemutatnak. Ebben a ZigBee modulok az autó fedélzeti számítógépéhez
kapcsolódnak (szabványos felületen), így amikor visszahozzák a kölcsönzőbe,
azonnal csatlakozni tud az ott működő hálózathoz, és le tudja jelenteni a megtett
kilométereket és egyéb, a kölcsönző számára fontos adatot. A 2-5. ábra [14] az
autókölcsönzős alkalmazás kezelőfelületét mutatja.
2-82-9. ábra Autókölcsönző alkalmazás [14]
Az Ember [16] cégtől beszerezhetőek ZigBee hardverek és teljes
szoftverrendszer, fejlesztőeszközökkel együtt. Az EM260 egy rádiós modullal
egybeépített processzor, SPI buszon kezelhető, a processzor teljes ZigBee stacket
futtat. Ezen tulajdonságok miatt egyszerűen illeszthető bármilyen processzorhoz,
mikrokontrollerhez. Az EM250SoC ennél egy kicsivel több, tartalmaz RAM-ot és
programozható mikrokontrollert is, önmagában kész rendszert alkot. A honlapról
[16] származó ábra szemlélteti az EM260-on belül a komponensek elhelyezkedését:
2-102-11. ábra Ember stack [16]
2-122-13. ábra EM260 alkatrészA Microchip [17] honlapján is érdekes dolgokat lehet találni. A ZigBee stack
forráskódja letölthető, egy program is jár hozzá, amivel az ábrán látható felületen
konfigurálhatjuk a hálózatot. A konfigurációból C forráskódot generál, amit a
Microchip ZigBee stack-kel lefordítva működő ZigBee hálózatot lehet kapni. A
ZigBee Alliance-en kívüli világ kereskedelmi célokra nem használhatja ingyenesen
a programot és a forráskódot.
2-142-15. ábra Microchip program képernyőképe
A 2-8. ábrán a letölthető program konfigurációs felülete látható.
A cég palettáján található még egy, a ZigBeenél egyszerűbb hálózati protokoll, a
MiWi. A ZigBeehez hasonló, de kevesebb memóriát használ, nem támogatja a
biztonsági funkciókat, és maximum egymástól négyugrásnyira lévő csomópontok
képesek kommunikálni.
Az MRF24J40 alkatrész képviseli a hardver vonalat, ez egy 2.4 GHz-es rádió adó
teljes MAC támogatással, AES titkosítási képességgel. A külvilággal SPI
interfészen kommunikál. Kompatibilis a Microchip ZigBee és MiWi termékeivel.
A ZigBee nyílt szabvány, különböző gyártók termékei működhetnek együtt egy
rendszerben. Jelenlegi legelterjedtebb felhasználási területe épületek
automatizálása. Az alacsony erőforrásigény, az alkalmazási rétegig terjedő
architektúra, a különböző típusú és erőforrásigényű csomópontok alkalmassá teszik
adatgyűjtő hálózat kialakítására. Mellette szól még a rendkívül széles
eszközválaszték, nagyon sok gyártó alkatrésze támogatja a szabványt.
3 A ZigBee szabvány áttekintéseA BME Méréstechnika és Információs Rendszerek Tanszéken kifejlesztett
mitmót rendszer elkészülte után megjelent az igény egy szabványos hálózati
protokollra. Az önálló laboratórium keretében az IEEE 802.15.4 rádiós protokoll
implementálásával foglalkoztam, és ez a munka eljutott olyan szintre, hogy a
diplomamunkémban lehetett rá építkezni. A következő logikus lépés az említett
szabványra épülő ZigBee protokollkészlet egyes részeinek implementálása. A
fejezetben ismertetem a szabvány fontosabb elemeit. Ez az összefoglalás a jövőbeli
fejlesztésekben is hasznos lehet.
3.1 A ZigBee elhelyezkedése a vezeték nélküli technológiák között
A számítógépek közötti vezeték nélküli kommunikációt IEEE szabványok írják
le. Az eltérő igényeknek megfelelően rengeteg különböző vezeték nélküli
hálózattípus létezik, amelyek adatátviteli sebességben, hatótávolságban, és
erőforrásigényben is széles skálán mozognak.
A személyi számítógépek, laptopok, PDA-k összekapcsolásakor leggyakrabban
használt 802.11 szabványcsalád maximum 54 Mbit/s adatátviteli sebességgel, 50-
100 méteres hatótávolsággal rendelkezik. A hatótávolság a terepviszonyoktól és a
használt eszközöktől függően ettől eltérő, akár nagyobb is lehet. Ez igaz bármely
más vezeték nélküli technológiára is. A 802.11 család azon nagy sebességigényű
alkalmazások számára jó alternatíva, ahol a kábelek nem megengedhetőek, vagy
kényelmetlenséget okoznak, mint például az előzőekben említett laptopok, PDA-k
esetén. A vezeték nélküli hálózatok ezen csoportjára WLAN (Wireless Local Area
Network) néven szoktak hivatkozni.
A kisebb területre kiterjedő hálózatokat a WPAN (Wireless Personal Area
Network) rövidítéssel jelölik, ezek néhány tíz méter kiterjedésű hálózatok. A
802.15.1, közismertebb nevén Bluetooth szabvány a viszonylag kis átviteli
sebességet igénylő eszközök esetében elterjedt. Tipikus felhasználási területéhez
tartoznak a fejhallgatók, egerek, mobiltelefonok. Adatátviteli sebessége fizikai
szinten maximum 3 Mbit/s, hatótávolsága 1, 10 vagy 100 méter. A hatótávolság
attól függ, hogy milyen osztályú rádiót használunk. A szabvány 3 rádióosztályt
specifikál, a kívánt hatótávolságnak megfelelően.
Néhány alkalmazás még ennél is kisebb adatátviteli sebességgel is megelégszik,
viszont fontos az alacsony energiafogyasztás és a kis erőforrásigény (memória,
processzoridő). Ezen alkalmazások számára nyújt megoldást az IEEE 802.15.4
szabvány, amely fizikai és adatátviteli réteget definiál. Az adatátviteli sebesség 20,
40, 100 vagy 250 kbit/s lehet, a hatótávolság 30-50 méter. Kevésbé komplex, mint
a Bluetooth, kisebb kódméret, kisebb energiafogyasztás jellemzi. A kis sebesség
miatt az LR-WPAN (Low-Rate WPAN) hálózatok csoportjába tartozik. A ZigBee
protokoll erre a szabványra épül, így a következő alfejezetben részletesebben
megvizsgálom az IEEE 802.15.4 lehetőségeit.
3.2 IEEE 802.15.4Az IEEE 802.15 WPAN részlegének 4-es munkacsoportja [19] kis sebességű és
komplexitású, több hónapos vagy több éves élettartamú hálózat kifejlesztésével
foglalkozik. 2003-ban adták ki a szabvány első verzióját, majd 2006-ban adtak ki
egy újabbat. A 2006-os verzió egyszerűsít néhány dolgot, és nagyobb átviteli
sebességeket is megenged.
Az alábbi táblázat [20] röviden összefoglalja a fizikai réteg fő paramétereit.
Amint látható, a szabvány ingyenes ISM frekvenciasávokat használ a
kommunikációhoz.
Frekvenciasáv Használható Moduláció Átviteli sebesség868-868.6 MHz Európában BPSK / ASK / O-QPSK 20 / 100 / 250 kbit/s902-928 MHz Amerikában BPSK / ASK / O-QPSK 40 / 250 kbit/s2400-2483,5 MHz Egész világon O-QPSK 250 kbit/sAz alacsonyabb frekvenciatartományokban a nagyobb átviteli sebességeket a
szabvány 2006-os változásakor vezették be.
Az átviteli közegért versengés folyik, a versengés CSMA-CA ütközéselkerülő
algoritmussal történik. A fizikai réteg által továbbított csomag hossza maximum
127 bájt lehet. Az alábbi ábrán a fizikai csomagformátum látható.
3-163-17. ábra Fizikai szintű keret
A PSDU rövidítés feloldása: Protocol Service Data Unit, ez a fizikai réteg által
továbbított adategység.
Az adatkapcsolati réteg megbízható üzenettovábbítást biztosít két csomópont
között. Az adatcsomagok hibadetektáló CRC kóddal vannak ellátva, és minden
csomagot azonnal nyugtáznia kell a fogadó csomópontnak. Hiba esetén újraküldés
történik.
Kétféle csomópontot különböztetünk meg egy 802.15.4-es hálózatban, ebből
adódnak a kialakítható topológiák is. Az egyszerűbb csomópontokat a szakirodalom
[20] Reduced Function Device (RFD) néven említi, a bonyolultabbakat Full
Function Device (FFD) néven. Az FFD csomópontok a teljes szabványt
implementálják, az RFD csomópontok csak egy részét. A szabvány jelezi, hogy az
RFD-k mely részeket nem kötelesek implementálni. Ennek következménye, hogy a
kommunikáció csak meghatározott csomópontok között lehetséges:
Egy FFD kommunikálhat bármely FFD-vel és bármely RFD-vel.
Egy RFD csak FFD-vel kommunikálhat.
3-183-19. ábra IEEE 802.15.4 csomópontok
Ezekből a szabályokból következik, hogy a hálózatok leggyakrabban csillag
topológiájúak, az egyszerű csomópontok egy FFD köré csoportosulnak. Az egymás
hatósugarán belül lévő FFD-k szövevényes hálózatot alkothatnak, így jöhet létre az
ábrán is látható topológia.
A hálózatban van egy kitüntetett csomópont, a koordinátor. Az ő felelőssége a
hálózatban található eszközök nyilvántartása, címek kiosztása, a hálózat
szinkronizálása beacon (jelzőfény) keretek segítségével.
A jelzőfény keretekre az időréselt üzemmód használatakor van szükség. A
hálózat két üzemmódban működhet: réseletlen módban bármikor küldhetnek adatot
a csomópontok a csatornáért való versengés után. Időréselt módban a koordinátor
által periodikusan küldött beacon keretekhez szinkronizálnak a hálózati eszközök,
adatküldés csak az időrések elején történhet. A beacon keretben található meg a
periódus hossza, az alvási és a készenléti időintervallumok hossza. Az alvási és a
készenléti időtartamok a szabvány által nyújtott lehetőségek az energiafogyasztás
mérséklésére. Az alábbi ábra szemlélteti az időréselt működési mód állapotait.
3-203-21. ábra IEEE 802.15.4 periódusok
A beacon érkezésekor kezdődik az aktív periódus, amelyben a hálózati
csomópontok versenghetnek az átviteli közegért, adatot forgalmazhatnak. A teljes
aktív periódus 16 egyenlő részre van osztva (ezek nem az adás kezdetét jelző
időrések!), ebből maximum az utolsó hetet ki lehet osztani az alacsony késleltetési
igényű csomópontoknak garantált időszeletként. Ekkor az a csomópont, amely
megkapta az időszeletet, versengés nélkül küldhet adatot, a többi csomópont nem
forgalmazhat. Az adást a beacon vételétől kezdve 20 szimbólumidőként lehet
megkezdeni a sikeres csatornahozzáférés után.
A hálózat periódusidejét a beacon keretben található két adatból lehet
kiszámítani:
BO: beacon order, értéke 0 és 15 közötti
SO: superframe order, értéke 0 és 15 közötti, és SO<=BO
Ha SO=BO=15, akkor a hálózat réseletlen üzemmódban működik, egyébként:
BI=960*2BO szimbólum
SD=960*2SO szimbólum
A szimbólumidő 20kbit/s esetén 50 us, ezzel az értékkel számolva SO és BO
minimális értéke 0.048 s, maximális értéke 786.432 s, körülbelül 13 perc.
A csomópontok címzésére két lehetőség van: az eszközök rendelkeznek egyedi
64 bites azonosítóval, ami alapján lehet címezni őket. A másik lehetőség 16 bites
rövid címeket enged meg.
Lehetőség van még broadcast címzésre is, ez mind 16, mind 64 bites esetben a
csupa 1-es bitből álló cím.
A rövid címeket a hálózat koordinátora osztja ki a csatlakozási folyamatban
(association). Egy csomópont bekapcsolás után a csatornákat végigpásztázva
megpróbálja felderíteni a hatósugáron belül lévő hálózatokat. Erre két módja van:
Aktív felderítéskor beacon request kérést küld, ha ezt a koordinátor veszi, akkor
egy beacon kerettel válaszol rá. Ezzel a réseletlen hálózatok felderítése válik
lehetővé.
Passzív felderítéskor az eszköz adott ideig várakozik vételi állapotban tartott
rádióval, és ha beacon keretet vesz, akkor a paramétereit beállítja, és szinkronizál a
hálózathoz.
Ezután a megtalált hálózat koordinátorával lefolytat egy csatlakozási folyamatot,
(ezt association-nek nevezik) amely során a koordinátor bejegyzi az eszközt a
hálózatban lévő eszközök közé, és ha igényelt rövid címet, akkor allokál neki egyet.
Az allokált címet a csatlakozó csomópontnak kell lekérdeznie a poll eljárással.
A poll eljárás azért szükséges, mert a legtöbb csomópont csak időnként kapcsol
be, az ideje nagy részét alvó állapotban tölti, amikor nem képes üzeneteket fogadni.
Amikor ébren van, a koordinátortól lekérdezheti a neki címzett üzeneteket. Ekkor
egy poll request üzenetet küld a koordinátornak, és ha az a nyugtában a megfelelő
bitet (frame_pending) beállítja, akkor az eszköz vételkész üzembe helyezi a rádiót,
így képessé válik az adat fogadására.
A csomópontok címzésén kívül minden koordinátor által felügyelt hálózat
rendelkezik egy 16 bites címmel.
A MAC keretszerkezet bonyolultabb a fizikainál. Négyféle keretformátum
létezik:
Adat
Nyugta
Parancs
Beacon
Az alábbi ábra az adat csomag formátumát szemlélteti.
3-223-23. ábra IEEE 802.15.4 MAC keret
A Frame Control mező határozza meg a keret típusát, leírja, hogy a keret
titkosítva van-e, illetve ebből derül ki a címmezők hossza. 16 bites címzés esetén 2,
64 bites címzés esetén 8 bájt hosszúak a címek. 0 bájtos hossz indirekt címzés
esetén fordul elő, a koordinátor számára lehet így üzenetet küldeni. A keret végén
lévő 16 bites CRC kód a hibadetektálást segíti.
Az adatkapcsolati réteg elérésére a szabvány két szolgáltatás-hozzáférési pontot
(Service Access Point, SAP) definiál. Az adatok továbbításával kapcsolatos
primitívek az MCPS-SAP (MAC Common Part Sublayer-SAP) elérési ponton
keresztül hozzáférhetőek. A hálózat felderítéssel, csatlakozással, paraméterek
beállításával kapcsolatos primitíveket az MLME-SAP (MAC Sublayer
Management Entity-SAP) ponton keresztül lehet elérni.
3.3 ZigBee architektúraA szükséges előismeretek után térjünk át a ZigBee tanulmányozására. Az alábbi
ábrán [21,22] látható a ZigBee réteges szerkezete, és a 802.15.4 rétegeivel való
kapcsolata.
3-243-25. ábra ZigBee stack [21,22]
A kerekített sarkú téglalapok jelentik a rétegek közötti kapcsolódási pontokat. (A
MAC rétegnél a szabvány szerint MCPS-SAP-ként hivatkozott pont itt MLDE-SAP
néven jelenik meg.)
Az ábrához tartozó fontosabb rövidítések:
APSME: Application Support Sublayer Management Entity
APSDE: Application Support Sublayer Data Entity
NLME: Network Layer Management Entity
NLDE: Network Layer Data Entity
A ZigBee két protokollverem réteget határoz meg, a hálózati és az alkalmazási
réteget. Az egyes rétegek feladatait a következő fejezetekben ismertetem. Az ábrán
látható „Endpoint” hozzáférési pontok a szabvány által biztosított lehetőségek az
alkalmazások üzeneteinek multiplexálására. A TCP/IP hálózatokban ismert port
fogalomhoz lehet őket hasonlítani. A dolgozatban továbbra is az angol kifejezést
fogom használni, a hálózati végpont fogalmával való keveredést kerülendő.
A ZigBee Device Object (ZDO) a 0. endpointra csatlakozó alkalmazás, ez
inicializálja a protokoll vermet, és hálózatmenedzsment feladatokat lát el a hálózati
és az alkalmazási réteg által biztosított menedzsment interfészeken keresztül.
3.4 Alkalmazási rétegAz alkalmazási réteg a ZigBee által definiált legfelső réteg, szabványos felületet
nyújt a felhasználói programok felé. Főbb szolgáltatásai a kötés (binding) és az
alkalmazásprofilok. A réteg feladatai:
Kötési táblák létrehozása
Üzenetek továbbítása az összekötött eszközök között
Csoportcímzésű üzenetek továbbítása, szűrése
Több csomagban elküldhető üzenetek darabolása, összerakása
Megbízható adattovábbítás
Az alkalmazási rétegben futó programok úgynevezett endpointokhoz
kapcsolódnak. Az endpointok 0 és 240 közötti sorszámmal rendelkeznek, egy
eszközön belül egyediek. Az egyes alkalmazások ezáltal válnak címezhetővé, mint
egy TCP hálózaton a különböző port számokkal rendelkező alkalmazások. A 0
sorszámú endpoint speciális, erre mindig a ZigBee Device Object csatlakozik. A
ZDO feladatai:
Az eszköz szerepének definiálása (koordinátor vagy végponti eszköz)
A hálózatban lévő eszközök, az általuk támogatott alkalmazásprofilok felderítése
Kötési kérelmek inicializálása, válasz küldése a beérkező kérelmekre
Biztonságos kapcsolat kiépítése hálózati csomópontok között
3.4.1 Csomagformátum
A következő pontok megértése előtt szükség van az alkalmazási réteg által
értelmezett csomagformátum ismeretére. Az alábbi ábra mutatja az adat csomag
szerkezetét. (Létezik még nyugta- és parancscsomag-formátum.)
3-263-27. ábra ZigBee alkalmazási szintű keret
A Frame Control mező a következőket határozza meg:
A csomag típusát, ami lehet adat, nyugta vagy parancs.
A címzést, ami lehet direkt vagy indirekt. Indirekt címzés esetén a célcímek nem
szerepelnek a csomagban, az címzettjét a kötési táblából kell kikeresni a forráscím
és a clusterazonosító alapján.
A cél típusát, ami lehet egy eszköz, egy csoport vagy minden csomópont.
A titkosítás használatát vagy mellőzését.
A nyugtázás szükségességét. A csomagokat alkalmazásszinten is lehet
nyugtázni.
A cluster- és profil azonosítók a felhasználói alkalmazás számára teszik
egyértelművé, hogy a csomag adatrészében milyen formátumú adat található.
A 8 bites sorszám a duplikált üzenetek észlelését teszi lehetővé.
3.4.2 Csoportcímzés
A csomópontokat megcímezhetjük egyedileg, de kialakíthatunk csoportokat is,
ahol egy, a csoportnak címzett üzenetet minden tag megkap. A csoportokba az
APSME-SAP ADD-GROUP primitívjével vehetünk fel elemeket. A csoportba nem
az eszközöket, hanem a rajtuk lévő endpointokat lehet felvenni.
3.4.3 Kötés (binding)
A ZigBee alkalmazásszinten lehetőséget biztosít endpointok logikai
összekapcsolására, kötésére, ami által az összekapcsolt alkalmazások közötti
üzenetküldés leegyszerűsödik. A kötés megvalósításának eszközei az indirekt
címzés, clusterazonosítók, csoportcímek, és a kötési tábla. A kötési tábla a
forráseszközön is meg lehet valósítva, illetve lehetnek olyan csomópontok, amelyek
tárolják és szinkronban tartják a hálózatban található kapcsolatokat.
Kötést az egymással gyakran kommunikáló alkalmazások között szoktak
létrehozni, a ZigBee specifikációban [21] például kapcsolók és lámpák közötti
példán szemléltetik. Az összekapcsolt alkalmazásoknak nem kell ismerni egymás
címét, az üzenet indirekt címzéssel jut el az első olyan eszköz alkalmazási rétegébe,
ahol van kötési tábla. Ez akár a forráseszköz is lehet, a kötés célja az, hogy az
alkalmazásokat mentesítsük a címek ismerete alól. Természetesen, ha a kötési táblát
más eszközön valósítjuk meg, akkor a forráseszköz memóriaigénye csökken.
A célcsomópont meghatározásához a kötési tábla indexként a forráscím,
forrásvégpont, clusterazonosító hármast, a hozzá tartozó bejegyzésben pedig egy
cél cím, cél végpont párokból álló listát tartalmaz. A célcím csoportcím is lehet.
Azért van szükség arra, hogy listát tároljunk a táblában, mert a kötést ugyanazon
forrástól létrehozhatjuk több céleszköz felé is.
Kötések létrehozása a BIND primitívvel lehetséges.
3.4.4 Alkalmazásprofilok
A ZigBee az alkalmazás profilokon keresztül támogatást nyújt a csomópontok
közötti egységes kommunikációra. Egy profil az alkalmazások üzeneteinek
formátumára vonatkozó megegyezés. Egy meghatározott célú hálózatban az
alkalmazások előre definiált üzeneteket váltanak egymással, például egy
épületautomatizálási rendszerben a kapcsolók és a lámpák között ki-bekapcsolásra
vonatkozó üzenetek továbbítódnak, vagy egy hőmérő és a fűtés
szabályozórendszere között is néhány előre ismert üzenet fordul elő. A profilon
belül az üzeneteket a clusterazonosító különbözteti meg.
Egy profil létrehozásához a következőkre van szükség:
Profilazonosító igénylése a ZigBee Allinace-től [23]
Eszközleírók megtervezése
Clusterek megtervezése
A profil- és clusterazonosítók 16 bit méretűek. Egy clusterazonosító egy profilon
belül egyedi, egyértelműen azonosítja az üzenettípust. A profilnak megfelelő
üzenetet az alkalmazási réteg egy adatkeretben küldi el, megfelelően kitöltött
profil- és clusterazonosítóval. Az adatrészbe egy 8 bites sorszám és az alkalmazás
üzenete kerül, ami a cluster paramétereiből áll. A sorszámot minden üzenet
elküldése után növelni kell eggyel, ez a felhasználói program felelőssége.
Az eszköz leírókat a következő pontban ismertetem. Egy profil tervezésekor el
kell dönteni, hogy mely clustereket milyen leíróval rendelkező eszközök képesek
használni: például, a villanykapcsoló csak küldi a bekapcsolás üzenetet, de nem
fogadja.
3.4.5 Eszközleírók
Az eszközleírók (descriptor) a hálózati eszköz tulajdonságairól tárolnak
információkat. A hálózatban lévő Primary Discovery Cache Device egységekre
töltik fel a csomópontok a saját leíróikat, ahonnan ezután más csomópontok a
szolgáltatások felderítése céljából lekérdezhetik. A leírók tárolását a ZDO végzi.
Ötféle leíró létezik:
Node
Node power
Simple
Complex
User
Az utolsó kettő opcionális, az első három kötelezően megvalósítandó. A leírók az
alábbi információkat tárolják:
Node descriptor
Megtalálható benne az eszköz típusa (koordinátor, router, végponti eszköz), a
Complex és User descriptorok meglétét jelző bit, az eszköz által használt
frekvenciasáv, pufferméret. Információt tárol arra nézve, hogy a csomópont
folyamatos vételi állapotban tartott rádióval rendelkezik-e, továbbá a hálózatban
betöltött szerepét is tartalmazza (például Primary Discovery Cache Device).
Node power descriptor
A csomópont energiaellátására vonatkozó információkat tárol, mint például az
aktuális és az elérhető energiaforrások típusa, töltöttsége. A current power mode
mező megadja, hogy az eszköz vevője folyamatosan be van kapcsolva,
periodikusan kapcsol be vagy csak külső beavatkozásra (gombnyomás).
Simple descriptor
Ebből a leíróból több is tartozhat egy eszközhöz, minden egyes leíró egy
támogatott alkalmazásprofilt ír le. Tartalmazza a végpont azonosítóját, amin a
profilt használó alkalmazás fut, a profilazonosítót, és az implementált bemeneti és
kimeneti clusterek listáját.
3.4.6 Eszközök felderítése
Egy, a hálózatba bekerülő csomópont előzetes konfiguráció nélkül képes
kapcsolatot teremteni az általa igényelt alkalmazásprofilt támogató eszközökkel.
Erre a felderítés (discovery) funkció nyújt lehetőséget, amit a Primary Discover
Cache Device csomópontokon tárolt eszközleírók segítségével lehet megvalósítani.
Lehetőség van egy meghatározott eszköz egy adott végpontjáról lekérdezni, hogy
milyen profilt támogat, illetve egy azonosító alapján meg lehet határozni a keresett
profilt támogató eszközök listáját.
A felderítés érdekessége, hogy nem APSME primitíveken keresztül történik,
hanem a ZDO végzi a ZigBee Device Profile nevű szabványos alkalmazásprofil
üzeneteivel.
3.4.7 ZigBee Device Object és ZigBee Device Profile
A ZigBee Device Object egy alkalmazás, amely annyiban különbözik a
felhasználói programoktól, hogy mindig a 0. sorszámú végponton fut. A
felhasználói programok a ZigBee Device Profile nevű szabványos
alkalmazásprofilon keresztül kommunikálhatnak vele. Mivel a profilüzenetek az
APSDE-SAP-on keresztül alkalmazási rétegbeli adatcsomagok formájában
továbbítódnak, így az eszközöket képessé kell tenni a „gépen belüli”
kommunikációra, hogy képesek legyenek kommunikálni azzal a ZDO-val, amelyik
ugyanazon a csomóponton fut.
A ZDO felelősségei közé tartozik az alkalmazási és a hálózati réteg inicializálása,
az ezekkel kapcsolatos menedzsmentfeladatok (csatlakozás, kötés, stb.) ellátása.
A ZigBee Device Profile üzenetek lehetővé teszik az egyes leírók feltöltését, és
az eszközök felderítéséhez nyújtanak támogatást.
3.5 Hálózati rétegA hálózati réteg feladata, hogy elérhetővé tegye az alkalmazási réteg számára a
802.15.4 adatkapcsolati rétegének szolgáltatásait. Ehhez két szolgáltatás-elérési
pontot nyújt. A Network Layer Data Entity SAP (NLDE-SAP) adattovábbítási
szolgáltatást nyújt, a Network Layer Management Entity SAP (NLME-SAP) a
hálózatmenedzsmenttel kapcsolatos szolgáltatások eléréséért felelős.
Az NLDE feladatai
Hálózati PDU, vagyis NPDU (Network Protocol Data Unit) előállítása az
alkalmazási rétegtől átvett csomagból.
Az előállított NPDU továbbítása közvetlenül a címzetthez, vagy a címzett felé
vezető útvonalon lévő első állomáshoz.
Az adatátvitel hitelességének és bizalmasságának biztosítása.
Az NLME feladatai
A bekapcsolt eszköz konfigurálása ZigBee koordinátorként, vagy csatlakozás
egy meglévő hálózathoz.
Új hálózat indítása.
Csatlakozás egy hálózathoz vagy lecsatlakozás.
Koordinátorként vagy routerként címek kiosztása az újonnan csatlakozó
eszközöknek.
Szomszédos csomópontok nyilvántartása.
Útvonalak felderítése.
A rádió vételi üzemmódjának szabályozása.
3.5.1 Topológia
A szabvány háromféle topológiát támogat: csillag, fa és szövevényes topológia.
Csillag topológiájú hálózatokban kétféle csomóponttípust különböztetünk meg, a
ZigBee koordinátort és végponti eszközt. A végponti eszközök a koordinátor köré
csoportosulnak. A hálózat működhet időréselt vagy réseletlen módban.
Fa topológiájú hálózatokban a koordinátor hatósugarát ZigBee routerek bővítik
ki, fastruktúrába szerveződve. Szintén megengedett a réselt és a réseletlen
működési mód. A routerek is a koordinátorhoz hasonlóan működnek, köréjük is
végponti egységek szerveződnek. Réselt működési mód esetén ők is küldenek
beacon kereteket, de a teljes hálózatban mindenkinek azonos periódusidővel kell
rendelkezni, a beacon ütközések elkerülése érdekében egymáshoz képest eltolt
kezdeti időpontokkal. Az alvó periódus hosszát úgy kell megválasztani, hogy a
többi, hatósugáron belül lévő hálózat aktív periódusa az aktuális hálózat alvó
periódusába essen.
Szövevényes hálózatokban mindhárom csomópont előfordul, de a routerek nem
fastruktúrába szerveződnek. Ebben az esetben a réselt működési mód nem
megengedett, a routereknek folyamatosan vételkész állapotban kell tartaniuk a
rádiót.
3.5.2 Csomagformátum
Az alábbi ábrán látható a hálózati rétegben továbbított adatcsomagok formátuma.
3-283-29. ábra ZigBee hálózati szintű keret
A Frame Control mező írja le többek között a csomag típusát, címzési módját és
a továbbításra vonatkozó információkat, például, hogy vannak-e source route
információk, és hogy a cél egyedi, broadcast vagy multicast cím.
A Sugár paraméter egy egész szám, amit a hálózat tervezői határoznak meg a
hálózat méretének függvényében. A csomópontok maximális számát határozza
meg, amelyeken a csomag áthaladhat. Minden csomópont, amely továbbküldi a
csomagot, eggyel csökkenti az értékét. Amelyik egység nulla értékre változtatja a
paramétert, az már nem küldi tovább. A hálózatban végtelen ideig bolyongó
csomagok elleni védekezés miatt szükséges. Hasonló az IP csomagok TTL
funkciójához.
A Multicast Control mező multicast címzés esetén a továbbítás típusára (member
vagy non-member, lásd később) vonatkozó információkat is tartalmaz.
A csomag útvonalválasztási információkat is tartalmazhat, ekkor a Source Route
mezőben megtalálható a forrás és a cél közötti csomópontok listája, a lista hossza és
egy mutató a következő csomópontra.
Az adatmezőben a felsőbb rétegtől kapott továbbítandó adat kap helyet, illetve a
hálózati parancsok.
3.5.3 Elosztott címhozzárendelés
A hálózatban használt címek eszközökhöz rendeléséért a ZigBee koordinátor és a
ZigBee routerek a felelősek. A címkiosztás történhet egyedi módon is, de a ZigBee
definiál egy elosztott algoritmust, amely a fastruktúrájú hálózatokban az
útvonalválasztást is egyszerűbbé teszi. Ehhez az alábbi változókra van szükségünk:
Cm: Az adott koordinátorhoz/routerhez kapcsolódó egységek száma
Lm: A hálózat maximális mélysége
Rm: A csatlakozó egységek között a routerek maximális száma
Ekkor Cskip(d), a d. mélységben az egyes routerek által kiosztható címek száma:
Cskip(d)=1+Cm*(Lm-d-1), ha Rm=1
Cskip(d)=1+Cm-Rm*Cm*RmLm-d-1 különben
Az Aparent című csomóponthoz kapcsolódó n. egység címét a következőképpen
határozhatjuk meg:
An=Aparent+Cskip(d)*Rm+n
Így fastruktúrába szerveződött hálózatokban a gyökértől a levelek irányába tartó
üzenetek következő lépését mindig meg lehet határozni. A következő csomópont a
legnagyobb címmel rendelkező router, amelynek címe még nem nagyobb a cél
címénél.
3.5.4 Útvonalválasztás
A ZigBee több útvonalválasztási stratégiát támogat többlépéses hálózatokban.
Fastruktúrájú elrendezésnél az előző pontban említett, elosztott címhozzárendelésen
alapuló módszert is lehet használni, szövevényes hálózatokban forrás-
útvonalirányításra (source routing) vagy routing táblák használatára van lehetőség.
Ezek a módszerek kombinálhatóak.
Az útvonal kiválasztásakor lehetőség van a kapcsolatok minőségének
vizsgálatára. Az útvonalköltség (Path Cost) az útvonal által lefedett kapcsolatok
összköltsége. Egy kapcsolat költsége nullától hétig terjedő egész szám lehet,
meghatározása a következő képlet alapján történik:
C{l}=min(7,round(1/pl4)), ahol pl a sikeres továbbítás valószínűsége az adott
linken. Ennek mérésére ajánlásokat ad a specifikáció, de kötelezően nem ír elő
semmit, C{l} értékeke konstans (7) is lehet, ha nem akarjuk vizsgálni a kapcsolatok
költségét. A mérés történhet a 802.15.4 által biztosított Link Quality Indicator
alapján, ami egy csomag vételére vonatkoztatva adja meg a jel minőségét, vagy
használhatóak csomagvesztést figyelő módszerek, stb.
Az útvonal felderítése Route Request és Route Reply parancs üzenetekkel
történik az első alkalommal, amikor az adott címre csomagtovábbítási kérelem
érkezik a felsőbb rétegtől. A Rote Request üzenetek broadcast címzéssel érik el a
hálózat összes csomópontját, és az válaszol rá Route Reply üzenettel, aki
rendelkezik információval az adott címről. A kezdeményező fél a kapott válaszok
alapján kiválasztja a legkedvezőbb útvonalat, és felveszi a routing táblájába.
Hálózati hibák, csomópontok kiesése esetén valamely csomópont érzékeli, hogy
már egy előre definiált értéknél többször nem sikerült adatot küldenie a kiesett
csomópontnak. Ekkor kezdeményezheti az útvonal javítását az új útvonal
kereséséhez hasonló algoritmussal.
Még két dolgot érdemes ebben a pontban megemlíteni, a broadcast és multicast
üzenetek továbbítását. A broadcast üzenetek továbbításakor az ismétlések
elkerülése végett minden egység, aki továbbította az üzenetet, feljegyzi a sorszámot
és a forráscímet. Mivel a nyugtázás nem megoldható, passzív nyugtázást
megengedett alkalmazni, de nem kötelező. A passzív nyugtázás során a küldő fél
azt veszi pozitív nyugtának, ha a szomszédaitól visszakapja az üzenetet (így azok is
továbbították). Az üzenet továbbítója újraküldheti az üzenetet, ha nem találja
kielégítőnek a passzív nyugtázást. A torlódások elkerülése miatt a továbbításkor
véletlen idejű késleltetést is előír a specifikáció.
A multicast üzenetek is a fentekhez hasonlóan továbbítódnak, de a passzív
nyugtázás nem megengedett, helyette többszöri újraküldést kell alkalmazni minden
esetben. A végponti egységek nem továbbíthatnak multicast üzeneteket. Minden
egység, amely veszi az üzenetet, megvizsgálja, hogy tagja-e a kérdéses multicast
csoportnak. Amennyiben igen, úgy a csomagot továbbadja a felső rétegnek.
3.6 A ZigBee értékeléseÖsszefoglalva, a ZigBee alkalmas adatgyűjtő hálózatok kialakítására a
központosított topológia támogatása, a szenzorok számára elérhető alacsony
energiafogyasztás miatt. További előny az alkalmazási réteg fejlettsége, a hálózat
önjavító képessége. Hátrány, hogy ezt az önjavító képességet csak a szövevényes
hálózatokban lehet kihasználni, ahol a router egységek folyamatos vételi
üzemmódban kötelesek lenni, így folyamatos tápellátást igényelnek.
4 ZigBee alapú környezetmonitorozó rendszer mitmóton
A szabványok, lehetőségek áttekintése után egy ZigBee alapú adatgyűjtő hálózat
tervét ismertetem. Az adatgyűjtő hálózatok különbözőfélék lehetnek, különböző
igényeket támaszthatnak, más lehetőségek vannak a tápellátás megoldására,
ahogyan az a bevezetőben is látható. Egy gyártósoron az alkatrészek minőségének,
tulajdonságainak mérésekor nagyobb mintavételi frekvenciára van szükség, mint az
erdőben a napi átlaghőmérséklet számításakor.
Jelen terv célja, ahogy a fejezet címe is sugallja, egy környezeti monitorozó
rádiós hálózat tervezése. A tervezés során figyelembe veszem az egyetemi
körülményeket is, a hálózat a MIT-en fejlesztett mitmót rendszer adottságainak
figyelembevételével készül. Az egyik lehetséges alkalmazás, ahol a rendszer
működhet, a Síkfőkút projekt által használt erdős terület, így a tervben az itt
elérhető lehetőségeket is figyelembe veszem az általánosság csorbítása nélkül.
A rádiós kommunikáció protokolljának a ZigBee-t választottuk. A választás azért
esett erre a technológiára, mert egy szabványos, ingyenesen használható ISM
sávokon működő protokoll, és az előző féléves önálló laboratóriumi munkámban
elkészült a ZigBee által használt 802.15.4 MAC réteg, így már előzménye is volt a
tanszéken, több félév óta foglalkoztunk vele.
A diplomaterv által kitűzött feladatok közé tartozik a fontosabb
szoftverkomponensek implementálása is, ennek részleteit az 5. fejezetben
ismertetem. Az implementálás során a jelen fejezetben ismertetett terv egy
részhalmazát valósítom meg. A teljes rendszer egyes hardver és
szoftverkomponensei már elkészültek az előző félévekben.
4.1 KövetelményekA tervezendő rendszerrel szemben az alábbi követelményeket támasztjuk. Mivel
bizonyos szempontokban az egyes komponensek igénye más és más, néhány
pontban a követelmények eltérhetnek egymástól.
Mérendő adatok
A rendszer ökológiai adatok mérésére legyen alkalmas, legyen képes mérni a
hőmérsékletet, a levegő, páratartalmát, stb.
Elhelyezkedés, kiterjedés
A hálózat nyílt terepen, erdős területen is legyen működőképes, a csomópontok
legyenek védettek az esővízzel, tűző nappal szemben. A lefedett terület néhány
százszor néhány száz méter kiterjedésű.
Mintavételi frekvencia
A méréseket óránként, vagy több óránként kell végrehajtani a mért adatok lassú
változása miatt.
Erőforrásigény
Erőforrásigény szempontjából több csoportra oszthatjuk a rendszert, mindegyik
csoport más-más követelményeket támaszt:
Koncentrátor: A koncentrátor a központi adatgyűjtő egység, a szenzorok által
mért adatokat tárolja ideiglenesen, és bizonyos időközönként átjáró szerepet játszva
az adatokat továbbítja egy távoli szerverre. Vele szemben elvárás, hogy
rendelkezzen Internet kapcsolattal, hálózati tápfeszültséggel és valamilyen
háttértárral, ami áramszünet esetén sem veszíti el a rajt lévő információt.
(merevlemez, flash drive, stb.)
Bázisállomás/koordinátor: A bázisállomás közvetlen kapcsolatban van a
koncentrátorral, gyakran egy egység a két komponens. Itt is feltételezhető, hogy
hálózati tápfeszültséggel rendelkezik. Folyamatosan vételkész állapotban kell
lennie, hogy a hálózatból jövő információkat fogadni tudja. Számítási kapacitás
igény szempontjából egy ZigBee koordinátort kell megvalósítaniuk.
Routerek/átjátszó állomások: A bázisállomás és a távol lévő szenzorok között
helyezkedik el, továbbítja az üzeneteket. Itt már nem feltételezhetjük a hálózati
tápellátást, ezek a csomópontok általában elemről működnek. Velük szemben
követelmény, hogy az energiaforrással jól gazdálkodjanak, több hónapnyi
folyamatos működést tegyenek lehetővé. Mivel ez csak periodikus működés esetén
lehetséges, ez meghatározza a hálózat topológiáját is: a ZigBee tulajdonságai miatt
fa topológiájú hálózatot kell kialakítani, mert csak ebben engedélyezett a beacon
keretek küldése.
Szenzorok: A tápfeszültséget elemről kapják. Csak méréskor kell bekapcsolniuk,
így hosszabb működési idő (1-2 év) is megkövetelhető egy elemcserével. Ez
követelmény is, mert általában ezekből az egységekből van a legtöbb, begyűjtésük
és karbantartásuk költséges.
Adatátviteli sebesség
Az átviteli sebesség nem kritikus, 10-20 kbit/s sebesség már elfogadható. A
késleltetés ingadozása sem kritikus, a hosszú távú megfigyelések és az órás
nagyságrendű mintavételi frekvenciák miatt néhány másodpercnyi késleltetés
elfogadható, még az sem jelent gondot, ha az adatok késleltetése nem állandó
mértékű.
Konfigurálhatóság
Nagy méretű hálózatoknál követelmény lehet, hogy a csomópontokat begyűjtés
nélkül át lehessen konfigurálni, hálózaton keresztül. A konkrét esetben ezt nem
követeljük meg, minden mitmótnak dedikált szerepe lesz, és a hálózat mérete sem
túl nagy, mert csak néhány helyen mérünk, kevés különbözőféle adatot.
Periodikus működés
Az átjátszó állomások számára követelmény, hogy adott időközönként képesek
legyenek vételi üzemmódba kapcsolni a rádiót, a szenzoregységek ekkor küldhetik
el a mért adatokat. Az átjátszó állomások és a szenzorok óráinak ezért nem lehet túl
nagy az egymáshoz képesti csúszásuk. Itt emlékezzünk egy fontos adatra: a
802.15.4 szabványban a hálózat maximális periódusideje körülbelül 13 perc. Ebből
következik, hogy a routereknek sűrűbben kell felébredniük az energiatakarékos
állapotból, mint a méréseket végző egységeknek, hiszen nekik el kell küldeniük a
beacon keretet. A nagy periódusidő miatt a szenzoregységeknek célszerű minden
vett beacon keret után az átjátszóhoz igazítani az időzítőt, különben előfordulhat,
hogy kiesik a szinkronból, és nem tudja elküldeni az adatot.
Hibatűrés
Jelen esetben kétféle hiba javítását várjuk el. Egy router csomópont kiesése
esetén követelmény, hogy a hozzá tartozó szenzoregységek megpróbáljanak más,
hatótávolságon belüli routerhez csatlakozni. Ugyanígy, ha egy szenzoregység lekési
a router vételi ablakát, vagyis kiesik a szinkronból, próbáljon meg újracsatlakozni
ugyanahhoz, vagy másik routerhez. Elvárás még a kiesések detektálása. Ha egy
vagy több csomópont huzamosabb időn keresztül nem küld adatot, a koncentrátor
figyelmeztesse az üzemeltetőket, hogy beavatkozásra van szükség.
Biztonság
Ahogyan az általános követelményeknél látható, a fizikai és a hálózati
biztonságra fokozottan oda kell figyelni egy éles rendszer esetében. Jelen feladat
keretein belül a biztonsági kérdésekkel nem foglalkozunk, ez a téma egy (vagy
több) külön diplomafeladatot lefed.
4.2 ArchitektúraEgy szenzorhálózat tervezésekor nem elégséges pusztán az egyes csomópontokat
összekötő hálózat megtervezése. A szenzorok tárkapacitása korlátos, az
összegyűjtött adatokat más eszközön kell eltárolni, és folyamatosan vagy bizonyos
időközönként el kell juttatni a feldolgozás helyére. A hálózat tervezésekor a teljes
infrastruktúrát figyelembe kell vennünk. Mindig az adott helyszínen lévő
körülményekhez kell igazodnunk, ezért a terv egyes részeiben több alternatívát is
felvázolok, és a konkrét egyetemi projektben alkalmazható megoldást külön
kiemelem.
Az alábbi ábra a teljes rendszerről nyújt egy áttekintést.
4-304-31. ábra A hálózat architektúrája
Az adatgyűjtő hálózatot, a routereket és a bázisállomást mitmót egységek
alkotják. A Síkfőkút projektben a bázisállomás a terepen található kis házban van
elhelyezve a koncentrátorral együtt, ami egy ipari PC, GPRS Internet kapcsolattal.
Az adatok egy egyetemi szerverre kerülnek, ahol feldolgozás után egy webszerver
segítségével a világ bármely pontjáról megtekinthetőek.
A következőkben bemutatom a rendszert alkotó egyes komponenseket. Először a
konkrét, az egyetemi projektben alkalmazott megoldást mutatom be, majd ahol
szükséges, ismertetek néhány általánosan használható alternatívát.
A szenzorhálózatot alkotó mitmót rendszert a BME MIT tanszékén fejlesztették
ki. Ez egy modulárisan, kártyákkal bővíthető hardverrendszer, a fő alkotóeleme az
Atmel AVR mikrovezérlő, amely 8 MHz-es órajellel és 128KB flash memóriával
rendelkezik. Az eszköz elemről és hálózati tápegységről képes működni. Az
elemtartó dobozra van rögzítve az Atmel AVR 8 bites processzort tartalmazó
kártya, ehhez lehet csatlakoztatni a rádiós kártyát és a szenzort kezelő kártyát. A
rendszer előnye, hogy könnyen illeszthető hozzá bármilyen típusú szenzor, és egy
egységhez akár több is.
Általános esetben ezen elemeket helyettesítheti bármely, a mitmót képességeivel,
erőforrásaival (ISM rádió, 8MHz processzor, 128KB memória, csatlakoztatható
szenzorok) rendelkező eszköz is.
A terepi kihelyezéshez a mitmótokat vízálló tokkal kell ellátni, mert a jelenlegi
megoldás nem áll ellen a természet hatásainak.
A szenzorokat kezelő csomópontokat elemes (akkumulátoros) tápellátásra kell
felkészíteni, a terepen nem számíthatunk hálózati tápellátásra. A mérés elvégzése
után az adatot el kell juttatniuk a legközelebbi átjátszó állomásig (vagy a
bázisállomásig, ha ez a legközelebbi), és ezután energiatakarékos üzemmódba kell
kapcsolniuk. Ha van rá lehetőség, az eszközöket célszerű napelemmel kiegészíteni,
ami napos időben energiát szolgáltat, újratölti az akkumulátort, így az élettartam
meghosszabbítható. Ez a megoldás természetesen az átjátszó állomásoknál is
alkalmazható.
Az átjátszó állomásoknál szintén nem számíthatunk hálózati tápellátásra, ám
ezeknek az egységeknek jóval több időt kell működőképes állapotban tölteni
(vételre kész rádióval). A tápellátást nagyobb teljesítményű akkumulátorokkal,
vagy az előző pontban említett napelemes kiegészítéssel kell megoldani. Ha ez nem
lehetséges, akkor a hálózatot úgy kell kialakítani, hogy minden csomópont a
bázisállomás hatósugarán belül legyen, így nincs szükség routerekre.
A routerek nagyobb fogyasztása a kisebb periódusidőből, és a hosszan vételi
állapotban tartott rádióból adódik. A szenzoregységek csak akkor tudnak adatot
forgalmazni, ha a környezetükben lévő átjátszó állomás rádiója vételi állapotban
van, érzékeli az elküldött jelet. Ehhez a 802.15.4 által biztosított periodikus,
időréselt szinkronizációt javasolt alkalmazni.
A periódusidő megválasztása a hálózati hibákra való reagálás gyorsaságát is
befolyásolja. Egy átjátszó csomópont kiesése esetén a hozzá tartozó csomópontok
megpróbálnak újracsatlakozni. Ahhoz az állomáshoz fognak csatlakozni,
amelyiktől először fogadnak beacon keretet. A működőképes állapot a hiba után az
első beacon keret érkezésekor áll helyre. Ha egy végponti eszköz elveszti a
szinkronizációt, ugyanaz a teendő, mintha a csomópont meghibásodott volna: újra
keresni kell egy hálózatot (akár ugyanazt), amelyikhez csatlakozhatunk. A beacon
keret vételéhez, vagyis a hálózat megtalálásához a rádiót vételi üzemmódban kell
tartani, ami nagy energiafogyasztással jár, így a szinkronizáció megtartására
érdemes ügyelni, főleg nagy periódusidejű hálózat esetén. Ehhez a végpontoknak
érdemes minden beacon érkezése előtt felébredni, még akkor is, ha nincs szükség
mérésre, és kicsivel a beacon várt ideje előtt vételi üzemmódba kapcsolni a rádiót.
Így a beacon érkezésekor újra lehet szinkronizálni az időzítőket, az órák egymáshoz
képesti csúszása kevesebb gondot okoz, ritkábban fordul elő, hogy az eszköz lekési
a beacont. Vezessünk be néhány jelölést, hogy a rádió bekapcsolásának időpontját
meghatározhassuk:
T0: A beacon keret érkezésekor kiszámolt következő beacon érkezésének
időpontja másodpercben.
T: A beacon keretben található Beacon Order és Superframe Order
információkból meghatározott periódusidő másodpercben.
Toffset: A beacont küldő állomás órájának eltérése a fogadóhoz képest. Előjele
késő óra esetén pozitív, siető óra esetén negatív. Amennyiben a periódusidőt
másodpercben adjuk meg, az eltérést is másodpercre vonatkoztatva kell megadni,
például us/sec.
Twakeup: A sleep üzemmódból normál üzemmódba váltás ideje, másodpercben. A
csomópont sleep üzemmódból fog bekapcsolni, hogy a rádiót kezelni tudja, ezért a
számításnál ezt is figyelembe kell vennünk.
Trwakeup: A rádió vételi üzemmódba kapcsolásának ideje másodpercben.
Tconst: konstans biztonsági idő, „ráhagyás”. A kiszámolt idő előtt ennyivel
kapcsoljuk be a rádiót, a számítási hibák, nem várt késleltetések kiküszöbölése
miatt. Értékét század vagy ezredmásodperces nagyságrendben elegendő
megválasztani.
Végül a kiszámolt bekapcsolási idő (Ton):
Ton=T0 + (T * Toffset) – Twakeup – Trwakeup – Tconst
A T * Toffset kifejezés a beacont kibocsátó állomás órájának csúszása a teljes
periódusra vonatkoztatva.
Az átjátszó állomások számának, helyzetének tervezése kulcsfontosságú a hálózat
szempontjából, ők határozzák meg a hálózat maximális méretét, és a csomóponti
hibák elleni ellenállóképességet. Amint már korábban említettem, ők felelősek a
szenzoregységek üzeneteinek továbbításáért a bázisállomás felé. Csak
szenzoregységekből legfeljebb akkora hálózatot lehet kiépíteni, amelynek minden
csomópontja a bázisállomás hatósugarán belül van, mert ezek az egységek nem
képesek egymás üzeneteit továbbítani. A hatósugár mitmót esetén nyílt terepen
maximum 100 méter, ám ezt csökkenthetik terepakadályok (épületek, fák, dombok,
stb.). Ennél nagyobb hatósugárra más eszközök esetén sem számíthatunk. Az
átjátszó állomások számát a követelmények alapján határozhatjuk meg.
Amennyiben a követelmény az egységek minimális száma, úgy az állomásokat
célszerű minél távolabb helyezni egymástól, így érhetjük el a legnagyobb
lefedettséget minimális számú routerrel. Ha hibatűrést is szeretnénk a hálózatba,
akkor a topológia megtervezésekor úgy kell eljárni, hogy egy végponti egység több
router hatósugarán belül legyen. Ekkor, ha az egyik meghibásodik, az egység képes
csatlakozni egy másikhoz, ezt a 802.15.4 szabvány biztosítja.
Az alábbi ábrán látható egy lehetséges elrendezés, ahol a hibatűrés a fő szempont.
Az ábrán jelölve van az S1 csomópont kiesése esetén létrejövő új útvonal.
4-324-33. ábra Útvonal javítás
A bázisállomás a rendszer központja, ide jut el minden mért adat a hálózatból. Az
állandó tápellátás miatt lehetőség van arra, hogy folyamatosan vételkész állapotban
legyen, így külön szinkronizáció nélkül bármikor képes adatot fogadni. A mitmót
rendszer esetében RS232 soros porton csatlakozik a koncentrátorhoz, és itt adja át a
hálózatból jövő információt.
A koncentrátort a projektben egy ipari PC valósítja meg, feladata a koordinátortól
kapott adatok eljuttatása Interneten keresztül a feldolgozást végző szerverre. Az
Internet kapcsolat esetünkben GPRS modemen keresztül érhető el, de bármilyen, az
adott terepen elérhető kapcsolat használható általános esetben. Legvégső esetben,
ha a terepen semmiféle internet csatlakozás, GSM lefedettség sincs, akkor az
adatok továbbítása manuálisan is megoldható: időnként kiutazik valaki a helyszínre,
a koncentrátorról lementi az adatokat, és elszállítja a feldolgozás helyére.
Az adatokat feldolgozás után eltároljuk, és egy webszerver segítségével a világ
bármely pontjáról lekérdezhetővé tesszük, így a méréseket kiértékelő szakemberek
munkája egyszerűbbé, költséghatékonyabbá válik.
4.3 Megvalósítandó funkciókEgy teljes, szabványos hálózat elkészítéséhez a 802.15.4 és a ZigBee szabványok
teljes implementálása szükséges. Az egyetemi projektben nincs szükségünk minden
funkcióra, ezért ebben a pontban megvizsgálom, hogy mely funkciókat célszerű
megvalósítani ahhoz, hogy a hálózat már működőképes legyen, de ne vegyen el sok
időt a felesleges funkciók fejlesztése. A funkciókat a tapasztalatok alapján két
lépésben célszerű megvalósítani:
Első lépésben egy olyan hálózatot kell létrehozni, amelyben minden csomópont a
koordinátor hatósugarán belül van, nincsenek router egységek. A koordinátor
folyamatosan vételkész állapotban lévő rádióval rendelkezik, így nincs szükség az
időréselt működésnél elengedhetetlen szinkronizációra. Így már létrehozható egy
bemutató hálózat, ami mellesleg a Síkfőkút projekt igényeinek egy részét ki tudja
elégíteni.
Második lépésben a hálózatot lehet bővíteni a router egységekkel, és az időréselt,
beacon keretek által szinkronizált működési móddal.
4.3.1 IEEE 802.15.4
Üzenetküldés
Az adatkapcsolati rétegben a nyugtázott üzenetküldést és a csatornahozzáférésért
folytatott CSMA/CA versengési algoritmust mindenképpen meg kell valósítani.
Amennyiben szükség van arra, hogy a végponti egységeknek is tudjunk üzenetet
küldeni, a lekérdezéses üzenetküldést is implementálni kell. Ennek
magvalósításához a poll primitívre, és az indirekt tranzakciók kezelésére van
szükség.
Csatornafelderítés
A környezetünkben lévő hálózatok felderítése elengedhetetlen az ésszerű
működtetéshez. Réseletlen esetben az aktív felderítést kell megvalósítani. Ekkor a
felderítést végző csomópont „Beacon Request” kérést küld a felderítendő
csatornákon, és a rá érkező választ várja. Réselt esetben a passzív felderítés
alkalmazandó, amikor a felderítést végző csomópont vételi üzembe helyezi a rádiót,
és megadott ideig vár a periodikusan küldött beacon keretre.
Association, disassociation, automatikus címkiosztás
A ZigBee protokoll megvalósításához szükséges, hogy a hálózatban lévő
csomópontok csatlakozzanak valamely routerhez vagy a bázisállomáshoz. Ezt
nevezzük az adott csomópont szülőjének. A 16 bites címek szülő általi allokálása és
kiosztása is szükséges, mert a ZigBee keretekben ezek a címek jelennek meg.
Réselt működési mód
A második lépésben szükséges megvalósítani, amikor a routerekkel bővítjük a
hálózatot. A routerek már nem számíthatnak hálózati tápellátásra, így
takarékoskodniuk kell az energiával. Ezt a periodikus, alacsony kitöltési tényezőjű
működéssel érik el.
Garantált időszeletek
Az általam tervezett alkalmazásban nincs rá szükség. Olyan esetekben kell
megvalósítani, amikor fontos, hogy a mért adat továbbítása ne szenvedjen nagy
késleltetést.
4.3.2 Zigbee
Eszközök
A ZigBee háromféle eszközt definiál: koordinátor, router és végponti egység (end
device). A központi bázisállomást egy koordinátor csomópontnak kell
megvalósítania, a szenzorokat kezelő eszközöket pedig végpontoknak. A router
csomópontok implementálására a második lépésben van szükség, amikor bővítjük a
hálózatot.
Alkalmazási réteg, végpontok
A ZigBee egyik nagy előnye az alkalmazásokat támogató réteg. A végpontok
kezelését, a ZigBee Device Object-et és a kötelező leírókat (Simple Descriptor,
Node Descriptor, Node Power Descriptor) mindenképpen meg kell valósítani.
Figyelni kell arra, hogy a megoldás támogassa a csomóponton belüli üzenetküldést
a végpontok között, a ZDO-val való kommunikáció ugyanis így történik.
Alkalmazás profilok
Az alkalmazás profilok által nyújtott lehetőségeket érdemes kihasználni, és az
adatok továbbítását a megtervezett profil üzeneteire alapozni. Ennek használatára
leginkább az alkalmazásunkat kell felkészíteni, de a hálózati program részéről is
szükség van némi támogatásra, ezért a következő két pont is a megvalósítandó
feladatok közé tartozik.
Discovery Cache Device
A hálózatban található eszközök feltölthetik a saját leíróikat az ilyen típusú
csomópontokra. Az elérhető szolgáltatások lekérdezhetősége miatt érdemes
megvalósítani ezt az eszközt. Kis méretű hálózatban elég, ha a koordinátor tölti be
ezt a funkciót, nagyobb hálózatokban akár több ilyen eszköz is lehet.
Eszközök felderítése (Device Discovery)
Ha automatikusan, minél kevesebb beavatkozással működő rendszert akarunk
létrehozni, az eszközöket képessé kell tenni arra, hogy megtalálják a számukra
szükséges szolgáltatásokat nyújtó (a megfelelő profilokat támogató)
csomópontokat.
Csoport címzés
A ZigBee lehetőséget biztosít csoportos címzésre is. Például csoportokat
képezhetünk a szenzorok típusa szerint, így egy üzenettel kezelhetjük az öszes
hőmérőt, az összes CO2 szenzort, stb. Nem létfontosságú funkcionalitás, de ha
rendelkezésre áll, kiterjeszti a lehetőségeket.
Kötés (binding)
A kötések segítségével összekapcsolhatunk több csomópontot, amelyek között a
program számára az üzenettovábbítás egyszerűbbé válik, nem kell ismerniük a cél
csomópont címét. A csoport címzéshez hasonlóan ez is hasznos funkció, de nem
létfontosságú, mivel a szenzorok mindig a koordinátor felé forgalmaznak adatot,
így a kötés által csak néhány bájtnyi memóriát lehetne megspórolni. Ez a spórolás
ráadásul kétséges, mert a koordinátor címét a 802.15.4 adatkapcsolati rétege
mindenképpen eltárolja, tehát nem nyerünk semmit.
Útvonalválasztás
Amíg a hálózat minden csomópontja a koordinátor hatósugarán belül van, addig
nincs rá szükség. Ha elkezdjük bővíteni a hálózatot, akkor a router csomópontokon
meg kell valósítani a fa struktúrájú útvonalválasztási algoritmust. A fa struktúra a
routerek periodikus működésére vonatkozó követelményből következik.
4.4 ZigBee alkalmazás profilAz alkalmazás profilok jó lehetőséget biztosítanak az alkalmazás szintű
szabványos kommunikációra. Ebben a pontban egy adatgyűjtő hálózatokban
használható alkalmazás profilt ismertetek. Egy alkalmazás profil tervezésénél a
következőkre van szükségünk:
Profil azonosító igénylése a ZigBee Alliance-től.
Clusterek megtervezése.
A profil használatához létre kell hozni egy alkalmazást, amelynek Simple
Descriptor leírójában meg kell adni a profil azonosítót, és a támogatott clusterek
listáját.
Az egyetemi projekt keretében nem igénylünk azonosítót a ZigBee Alliance-től,
hanem saját hatáskörben választunk egyet.
A clusterek üzenet típusokat jelentenek. A típusok tervezésénél a következő
szempontokat vettem figyelembe:
Egy környezeti adatgyűjtő hálózatban a továbbítandó adatok általában egész vagy
lebegőpontos számokkal ábrázolhatóak. Bonyolult, szenzortípusonkénti
megkülönböztetés helyett adattípusok szerint különböztetem meg az üzeneteket.
Szenzortípusonkénti megkülönböztetés alatt azt értem, hogy például külön clustert
hozok létre a hőmérő szenzoroknak, egy másikat a CO2 szint mérőknek, stb.
Ehelyett egyszerű adattípusokhoz definiálom a clustereket. Az üzenetekbe bekerül a
mérést végző szenzor azonosítója, így a központban el lehet dönteni, hogy mit
jelent az adat. Ezáltal a szenzorhálózati egységek egyszerűbbé válnak, a sok
nyilvántartást igénylő feladatok végrehajtása kitolódik a hálózaton kívülre. Előny
még, hogy amennyiben egy új szenzort kapcsolunk a hálózatba, nem kell profil
bővítést, szoftverfrissítést végrehajtani a többi elemen – csak akkor, ha olyan
adattípust kell bevezetni, ami az eredeti profil üzeneteivel nem írható le.
A mért adatok továbbításán kívül szükség lehet még a mérés gyakoriságának
beállítására, a mérés felfüggesztésére, és újraindítására. Ezek a funkciók kényelmi
célokat szolgálnak, hiszen a mérési frekvenciát el lehet dönteni a hálózat
tervezésekor is, de néha szükség lehet a változtatásokra. Ekkor jól jön, ha nem kell
az egész hálózatban szoftvert frissíteni, hanem egy üzenettel megoldható a
konfiguráció.
4.4.1 Adatgyűjtő cluster
A fentieket figyelembe véve az alábbi clustereket definiálom, melyek közül az
első négyet a szenzorokat kezelő csomópontok küldik, a koordinátor fogadja:
Data_int16
Előjeles egész szám típusú adatok továbbítására szolgáló üzenet. A
sorszám minden üzenet elküldése után eggyel növekszik, hálózati hibák
miatt késleltetett üzenet esetén a koncentrátor meghatározhatja belőle a
mérés időpontját.
Cluster id: 0x0001
Paraméterek:
Sorszám: 8 bit egész szám
Szenzor ID: 16 bit szenzor azonosító
Adat: 16 bit előjeles egész szám
Data_uint16
Előjel nélküli egész szám típusú adatok továbbítására szolgáló üzenet.
Cluster id: 0x0002
Paraméterek:
Sorszám: 8 bit egész szám
Szenzor ID: 16 bit szenzor azonosító
Adat: 16 bit előjel nélküli egész szám
Data_float32
Előjeles lebegőpontos szám típusú adatok továbbítására szolgáló üzenet.
Cluster id: 0x0003
Paraméterek:
Sorszám: 8 bit egész szám
Szenzor ID: 16 bit szenzor azonosító
Adat: 32 bit előjeles lebegőpontos szám
Data_ufloat32
Előjel nélküli lebegőpontos szám típusú adatok továbbítására szolgáló
üzenet.
Cluster id: 0x0004
Paraméterek:
Sorszám: 8 bit egész szám
Szenzor ID: 16 bit szenzor azonosító
Adat: 32 bit előjel nélküli lebegőpontos szám
A következő parancsokat a koordinátor küldi, és a szenzorokat kezelő végpontok
fogadják. Ennek előfeltétele, hogy a csomópontok implementálják 802.15.4 által
biztosított „poll” primitívet, vagyis a végponti egységek le tudják kérdezni a
hozzájuk tartozó routertől a nekik címzett üzeneteket.
SetPeriod
A mérés periódusidejének beállítására szolgáló üzenet. A szenzor
azonosító azért szerepel a paraméterek között, mert előfordulhat, hogy egy
csomópont több szenzorral is rendelkezik, és mindegyiknek más a
periódusideje.
Cluster id: 0x0100
Paraméterek:
Szenzor ID: 16 bit szenzorazonosító
Periódusidő: a mérés periódusideje, másodpercben megadva. 16 bites
egész szám, ez elegendő a környezeti adatgyűjtés során megkövetelt
periódusidők leírására.
Pause
A mérés felfüggesztésére szolgáló parancs.
Cluster id: 0x0200
Paraméterek:
Szenzor ID: 16 bit szenzorazonosító
Resume
A mérés újraindítására szolgáló parancs.
Cluster id: 0x0300
Paraméterek:
Szenzor ID: 16 bit szenzorazonosító
4.5 Szenzorhálózaton kívüli elemekA szenzorhálózaton kívüli elemeken a koordinátor utáni szakaszt értjük. A teljes,
használható rendszer tervezésekor az alábbiakra is gondot kell fordítanunk:
Kommunikáció a koordinátor és a koncentrátor között.
A koncentrátor internet csatlakozása.
Adattovábbítás a koncentrátorról.
Az eredmények eltárolása, megjelenítése.
A koordinátoron futó program amint adatot kap, továbbítja azt a koncentrátor felé
a köztük lévő kommunikációs vonalon keresztül, ami a mi esetünkben RS232 soros
port. Az egyszerűbb és gyorsabb feldolgozás miatt ezen a szakaszon esetünkben a
ZigBee alkalmazásprofil üzeneteit adjuk tovább. Ennek előnye, hogy a koordinátor,
amint felismeri, hogy nem adminisztrációs üzenetet, hanem adatot kapott, már
küldheti is tovább, mindenféle konvertálás nélkül. A nagyobb erőforrásokkal
rendelkező koncentrátor fogja megfelelő formátumúra konvertálni az adatokat.
Az internet csatlakozásra, mint említettük, a terepen elérhető bármilyen típusú
kapcsolat megfelelő. Egyetemi környezetben előnyös, ha minél olcsóbb, és nincs
szükség előfizetésre a használatához. A GPRS technológia a szinte bárhol elérhető
GSM hálózaton keresztül biztosít kapcsolatot az Internethez. Ez fontos szempont,
mert a konkrét síkfőkúti terepen található ugyan telefonvonal, de a rendelkezésre
állása esetleges, a kábelt gyakran elszakítják a faágak. A GPRS technológia
általános esetben is jó választás, mert sok helyen elérhető, a célnak megfelel, és a
számlázás a legtöbb szolgáltatónál adatforgalom után történik. Ha úgy döntünk,
hogy néhány hónapig nem használjuk a hálózatot, nem kell havidíjat fizetni vagy
szerződést bontani. A Síkfőkút projektben ez a technológia használható, a választott
szolgáltatónak van lefedettsége a területen, a szükséges hardver is a birtokunkban
van, és illesztve van a koncentrátorhoz.
A koncentrátorról az adatokat XML formátumban küldjük tovább. Ennek előnye,
hogy szabványos módszerek léteznek az ellenőrzésére, feldolgozására, és jól
tömöríthető, ami fontos, ha lassú vagy drága az Internet kapcsolat.
El kell döntenünk, hogy milyen adatokat szeretnénk leírni az XML
dokumentummal. Ha ehhez létrehozunk egy DTD fájlt (Document Type
Definition), akkor ennek ismeretében más rendszerekkel szabványos módon
összekapcsolhatjuk az infrastruktúránkat. A DTD leírja az XML dokumentumban
előforduló lehetséges elemeket, csomópontokat, így lehetővé válik, hogy az
általunk generált XML fájlt mások programjai feldolgozhassák. A következőkben
megadom, hogy milyen adatok fordulhatnak elő az általunk generált
dokumentumban. Ezek alkalmasak az előző pontban leírt ZigBee alkalmazásprofil
üzeneteinek továbbítására, és a legtöbb környezeti adatgyűjtés során előforduló adat
továbbítható vele. Speciális igények esetén szükség lehet bővítésre.
Sensor
Egy szenzor adatait tartalmazó elem. Nem szükséges mindig beleírni a fájlba, a
teljes hálózati topológiát el lehet tárolni előre is. Változások detektálásakor célszerű
a hálózatból kinyert információk alapján legenerálni a struktúrát.
SensoridA szenzor azonosítója, amit például a szenzor elektronikus adatlapjáról lehet
kiolvasni, de a hálózat tervezői is adhatnak azonosítót az egyes szenzoroknak.
TypeA szenzor típusa, például hőmérő, páratartalom mérő.
AddressA hálózati csomópont 64 bites címe, amelyen a szenzor található.
StateHibakeresési célokat szolgáló állapotinformáció. A koncentrátor nyilvántarthatja
a hálózatban jelen lévő szenzorokat, és ha valamelyiktől sokáig nem kap adatot,
ezen a mezőn keresztül hibajelzést küldhet az adminisztrátornak.
Acquisition
Egy bejövő adatot leíró elem.
SensoridA szenzor azonosítója, amely a mérést végezte.
TypeAz adat típusa, például int, float, stb.
ValueA mért adat értéke.
TimestampA koncentrátor által az adathoz rendelt időbélyeg. A koncentrátor az időbélyeg
számításakor figyelembe veheti az alkalmazásprofil üzenet sorszám paraméterét.
Előfordulhat, hogy egy csomópont az egyik mérés után nem tudja elküldeni az
adatot hálózati hiba miatt. Ha a következő mérés után a hálózat helyreállt, a kisebb
sorszámú adatról a koncentrátor láthatja, hogy nem a mostani időpontra vonatkozik,
hanem az egy periódussal ez előttire.
Az adatokat folyamatosan kell írni az XML fájlba, amit naponta fel lehet tölteni a
központi szerverre (és a koncentrátoron egy új fájlt kezdeni). A szerveren a
legegyszerűbb megjelenítési mód, ha egy XSLT stíluslappal HTML formátumúra
konvertáljuk az adatokat. Bővebb lehetőségekhez valamilyen szkript nyelven
programot írhatunk, ami statisztikát generál az adatokból.
5 A szoftverkomponensek megvalósításaA feladat előírja a mitmót alapú hálózat lényeges szoftverkomponenseinek
implementálását. Ebben a fejezetben ismertetem a megvalósított elemeket. A
feladat megoldásakor felhasználom az önálló laboratóriumban elkészített IEEE
802.15.4 protokoll egyes részeit megvalósító programomat.
5.1 PlatformA programot C programozási nyelven készítem, a 8 bites Atmel AVR
processzorral rendelkező mitmót hardveren fog futni. A vezeték nélküli
kommunikációt az Integration IA4420 rádiós modul teszi lehetővé. A program nem
használ operációs rendszer támogatást, a hardverkezelő részek C és assembly
nyelveken készültek. Ezek a részek már meglévő komponensek, nagyrészt mások
munkájának eredményeképpen jöttek létre.
A bemutató rendszer az egyszerűbb kezelhetőség, hibakeresés érdekében a DPY
kijelző kártya szolgáltatásait is igénybe veszi.
A fejlesztést az Eclipse környezetben végzem, innen elérhetőek a mitmótok
felprogramozásához szükséges eszközök is.
5.2 Felhasznált komponensekA fejlesztésnél az alábbi, már meglévő komponenseket is felhasználom.
5.2.1 DPY API
A kijelző kártyán található gombok, kapcsolók, LED-ek, és a hét szegmenses
kijelző kezelését lehetővé tevő programozási felület. A terepre kihelyezett
rendszernél nem lesz rá szükség, energiatakarékossági okokból. Az API Scherer
Balázs munkája.
5.2.2 Com_r04_s01b1 API
Ez a felület lekérdezéses módon elérhetővé teszi a mitmóton található rádiós
kártyát. A 433 MHz-es ISM sáv határain belül lehetőséget biztosít különböző
frekvenciasávok használatára. A vételi erősséget és az adatátviteli sebességet is
lehet vele szabályozni. Üzenetek küldését és fogadását is lehetővé teszi. Az API
nagyrészt Scherer Balázs munkája. Az önálló labor során néhány helyen
módosítottam, illetve a CSMA/CA algoritmushoz szükséges vivőjel-érzékelés
támogatásával kiegészítettem.
5.2.3 IEEE 802.15.4 fizikai és MAC réteg
A fizikai és adatátviteli réteget megvalósító program a saját önálló laboros
munkám. Segítségével kialakítható egy réseletlen, 802.15.4 szerint működő hálózat.
A réselt működési mód csak részben támogatott, a koordinátor fel van készítve a
beacon keretek periodikus küldésére, ám a hálózat többi csomópontja nem tud
hozzá szinkronizálni.
Az adatátviteli sebesség 20 kbit/s. A CSMA/CA algoritmus működőképes, adat
küldésekor-fogadásakor a nyugtázás, újraküldés, CRC ellenőrzés automatikus. A
lekérdezés (poll) funkció is meg van valósítva.
Az eszközök képesek hálózatfelderítésre, és a csatlakozás, rövid cím lekérdezés
végrehajtására. A koordinátor egy adott kezdőcímtől képes meghatározott számú
címet kiosztani, a hálózatot elhagyó egységek címeit újrahasznosítani.
5.3 ArchitektúraA következő oldalon látható egész oldalas ábrán a ZigBee architekturális
ábrájának egyszerűsített változata látható. A szaggatott vonalak a csomóponton
belüli kommunikációt jelölik, a folyamatos vonalak a rétegek közötti adatáramlás
útvonalait. A kapcsolódási pontoknál feltüntettem az ott használt függvények,
primitívek nevét.
A felhasználói alkalmazás az APSDE-SAP ponton kapcsolódik az alkalmazási
réteghez, ezen keresztül van lehetősége kommunikálni más csomópontokkal, vagy
az ugyanazon csomóponton lévő más endpointokkal, például a ZDO-val. A ZDO az
APSME-SAP pontot is igénybe veszi.
Az adatcsomagokat az alkalmazási réteg az NLDE-SAP ponton keresztül adja át
a hálózati rétegnek. A réteg másik elérési pontját, az NLME-SAP menedzsment
szolgálatokat elérhetővé tévő pontot a ZDO kezeli.
Ettől alacsonyabb szinten a hálózati réteg kommunikál a 802.15.4 adatkapcsolati
rétegével, aki a fizikai réteget kezeli.
5-345-35. ábra ZigBee protokoll verem
5.4 Tervezési döntésekA tervezés során a fő szempont a funkciók egy olyan részhalmazának
létrehozása, amely akár már magában is alkalmas egy egyszerűbb hálózat
kiépítésére, és könnyen továbbfejleszthető. Ezért minden megvalósított funkció a
szabványos primitíveken keresztül zajlik, még ha csak egy része van is
implementálva. Így az esetleges továbbfejlesztés során a kódot bővíteni kell, és
nem teljesen átírni.
5.4.1 Eltérések a szabványtól
A szabványok előírásaitól néhány esetben eltértünk, egyszerűsítés miatt vagy
kényszerűségből.
A fizikai rétegben rögtön akad néhány megoldás, ami sérti a specifikációt. A
mitmóton lévő rádi 433 MHz-en működik, ami ISM sáv, de a 802.15.4 ezt a sávot
nem támogatja. A vevők szinkronizálásához szükséges előhang és a keret kezdetét
jelző SFD (Start of Frame Delimiter) sem az előírt, szintén a rádió tulajdonságai
miatt.
A ZigBee hálózati üzenet szinten támogatja egy csatlakozott eszköz számára a
lecsatlakozást, a megoldásom csak az adatkapcsolati szintű disassociation
primitíven keresztül.
Az IEEE 802.15.4-et megvalósító program nem támogatja az időréselt működési
módot, így ilyen hálózatot nem lehet létrehozni a jelenlegi megoldással.
A Zigbee hálózati rétege csak átjátszó szerepet tölt be az alkalmazási és az
adatkapcsolati réteg között. Hálózati funkciókat, mint például routing, csoport
címzés, nem valósítok meg. Természetesen, a hálózati szinten elküldött keretek
megfelelnek a szabvány előírásainak. A hálózati réteg minden funkcionalitása nincs
kihasználva, azért készítettem el mégis a megfelelő függvények vázát, hogy minden
függvényhívás a szabvány előírásainak megfelelően történjen. A program így
könnyebben továbbfejleszthető lesz, az adatutakat nem kell megváltoztatni, csak a
függvények hiányzó részeit kell implementálni.
A ZigBee Device Profile üzeneteket nem értelmezi a ZDO, így az eszköz leírók
feltöltése és a hálózatban lévő szolgáltatások felderítése sem lesz megoldott.
A ZigBee biztonságiEzeken kívül a legnagyobb eltérés az egyszerűsítés, a
szabványok egyes kötelező részeinek kihagyása. Mivel a megvalósítás csak egy kis
részt érint, néhány olyan rész is kimaradt, ami kötelezően implementálandó egy
teljes értékű megvalósításnál. A működőképességet ezek nem befolyásolják.
kiterjesztéseit sem valósítom meg. Amint az architekturális ábrán is látszik, a
biztonsági modul nem a rétegek közé, hanem a rétegek mellé van beépülve, így
később egyszerűbben bővíthető ezzel a program.
5.4.2 Programozási konvenciók
A kódmérettel való takarékosság miatt a programban több helyen használok
feltételes fordítási opciókat. Egyes részletek csak a koordinátor/router egységek
végleges programjába kerülnek bele, így a végponti eszközök kevesebb memóriát
igényelnek.
A rétegek közötti kommunikáció request, confirm és indication primitíveken
keresztül zajlik. A request primitívek esetén a fölsőbb réteg veszi igénybe az alsóbb
réteg szolgáltatásait. Ez függvényhíváson keresztül valósul meg. A confirm
primitív a request primitívek eredményét adja meg a fölsőbb réteg számára, ez a
függvények visszatérési értékén keresztül valósul meg. A 802.15.4 megvalósításban
ez máshogy van, ott a confirm primitívek is függvényhívások, az alsóbb rétegben
deklarált függvényt kell a fölső rétegnek megvalósítania. Tapasztalataim szerint ez
a módszer nehézkes, és feleslegesen bonyolult, ezért tértem át a fent alkalmazottra.
Az indication primitívvel az alsóbb réteg jelez valamit a felsőbb számára, ez a
felsőbb réteg számára kötelezően implementálandó függvényen keresztül valósul
meg.
5.4.3 Hibakezelés
A hibakezelésnél a szabvány szerint történik, a confirm primitívekben átadott
státusz paraméter jelzi az előfordult hibákat a felsőbb rétegnek.
5.4.4 Azonosítók, címek
Egy ZigBee hálózat létrehozásához szükségünk van néhány azonosítóra, illetve
címre. Az ezekkel kapcsolatos kérdéseket tisztázom a következő pontokban.
64 bites IEEE cím
Az egyes eszközök az egész világon egyedi címekkel kell, hogy rendelkezzenek.
Az IEEE-től lehet igényelni címtartományt, így kerülhetőek el az ütközések. Nem
igényeltem címtartományt, a címeket magam határozom meg. Éles, más
rendszerekkel is együttműködő hálózat esetén ez nem megengedhető. A címeket az
eszközök felprogramozásakor kell megadni, bele kell fordítani a programba, mert a
mitmótokon nincs lehetőség olyan adat (sorozatszám, stb.) lekérdezésére, amiből
ilyen cím generálható.
16 bites cím
A 16 bites rövid címeket a koordinátor osztja ki, ezek a hálózaton belül egyediek.
A koordinátor a saját címét egy programba fordított konstansból határozza meg.
Hálózati cím
A hálózati címet a koordinátor választja meg úgy, hogy ne ütközzön a
hatósugáron belül lévő hálózatok címeivel. Esetünkben a koordinátor egy, a
programba fordított konstanst választ a hálózat címének.
Profilazonosító
A profilazonosítót a ZigBee Alliance-től lehet igényelni, ezt a megoldásban
szintén mellőztem, a példaalkalmazáshoz választottam egy azonosítót, és azt
használom.
Cluster azonosítók
A clusterazonosítók egy alkalmazás profilon belül egyediek, a tervező dönti el
őket. A 4. fejezetben találhatóak a megtervezett profilhoz tartozó clusterazonosítók.
5.4.5 Megvalósított egységek
A legfontosabb kérdés a lényeges elemek kiválogatása, mivel a rendelkezésre
álló idő alatt a teljes szabvány megvalósítása nem megoldható feladat. A következő
komponensek megvalósítását tűztem ki célul.
ZigBee Device Object egyes részei
A ZDO feladatai közé a teljes protokollverem inicializálása, a
hálózatmenedzsment feladatok kezelése és a ZigBee Device Profile megvalósítása
tartozik. Az utolsó feladat rengeteg parancs értelmezéséből áll, ezt a részt nem
valósítottam meg. Az eszközök felderítésének támogatásához lenne erre szükség
főképp.
Az alkalmazási és a hálózati réteg, ezen keresztül az alsóbb rétegek inicializálását
elvégzi. Koordinátor csomópont esetén beállítja a hálózat paramétereit, ha végponti
egységként indul, akkor felderíti a hatósugáron belül található hálózatokat, és
csatlakozik.
Ezen feladatait a hálózati réteg NLME-SAP elérési pontján keresztül látja el.
Keretrendszer az alkalmazások kezeléséhez
A ZigBee fontos eleme a felhasználói alkalmazásokkal való kapcsolat, ami az
endpointokon keresztül jelenik meg. Ezek kezeléséhez létre kell hozni egy
rendszert, ahol az alkalmazásokat hozzá lehet rendelni a végpontokhoz, és ezek
után továbbítani lehet a nekik szóló vagy a tőlük kapott adatokat.
A megvalósításhoz egy tömböt használok, amelynek elemei függvényekre mutató
mutatók. Az alkalmazás az openEp(endpoint, callback) függvénnyel rendeli magát
hozzá a kiválasztott végponthoz. Az endpoint paraméter a végpont számát jelöli, a
callback egy függvény, amit az alkalmazás implementál. Az alkalmazási réteg ezen
a függvényen keresztül fogja átadni az endpointnak címzett üzeneteket. Az
endpointról való lecsatlakozás a closeEP(endpoint) függvénnyel lehetséges.
A programok az alkalmazási réteggel csak az APSDE-SAP DATA primitívjén
keresztül kommunikálhatnak.
Alkalmazás szintű keretformátum, üzenetküldés
A szabványos üzenetek küldése, feldolgozása minimális elvárás, ezért az
adatcsomagok előállítása, a kapott csomagok értelmezése része a programnak.
Az alkalmazási réteg ezen kívül lehetőséget nyújt a csomóponton belüli
kommunikációra, így az egy csomóponton lévő végpontok is kommunikálhatnak
egymással.
Hálózati szintű keretformátum, üzenetküldés
A hálózati rétegben szintén megvalósítottam az adatcsomagok előállítását,
értelmezését. A felsőbb rétegnek csak a csomópont címére vagy broadcast címre
szóló csomagok jutnak el. Csoportcímzéssel még érdemes lenne kiegészíteni.
Hálózatmenedzsment szolgáltatás egyes elemei
A ZDO a hálózati rétegen keresztül kezeli az adatkapcsolati réteget. A hálózati
rétegben ezért meg kellett valósítani az NLME-SAP néhány primitívjét, meg kellett
oldani az adatkapcsolati réteggel való kommunikációt. A következő funkciók lettek
megvalósítva: hálózatfelderítés, paraméterek beállítása, csatlakozás a hálózathoz,
lekérdezés (poll), lecsatlakozás, a rádió vételi üzemmódjának kezelése.
5.4.6 Konfiguráció
A program főbb paraméterei a ZigbeeConfig.h állományban konfigurálhatóak, a
módosítás újrafordítást igényel. A ZB_COORDINATOR, ZB_ROUTER és
ZB_ENDDEVICE konstansok az eszköz hálózatban betöltött szerepét definiálják.
A program feltételes fordítási opciók segítségével figyelembe veszi az eszköz
szerepét, és csak a szerepnek megfelelő részletek kerülnek be a végleges
programba. Ebben az állományban adhatjuk meg az eszköz 64 bites címét, illetve
koordinátor esetén a 16 bites címet és a hálózat paramétereit is.
5.5 PéldaalkalmazásA rendszer demonstrálására készült egy példaprogram. A program egy csillag
topológiájú hálózat létrehozását, az eszközök kapcsolódását és adatforgalmazást
szemlélteti. A szemléltetéshez minimálisan két mitmót szükséges: egy koordinátor
és egy vagy több végponti egység.
A koordinátor indulás után folyamatosan vételi állapotban tartózkodik. A
végponti egységek gombnyomásra aktív hálózatfelderítést kezdenek, és
csatlakoznak a koordinátorhoz. Ezután gombnyomásra elküldik az aktuális
hőmérsékletet a 4. fejzetben leírt alkalmazásprofil üzeneteivel, amit a koordinátor
kiír a soros portra.
A végponti egységek a soros portra információkat írnak ki a megtalált hálózatról,
a kapott rövid címről.
A program működését az ábrák szemléltetik. Az első ábrán a koordinátor által
kiírt üzenetek láthatók.
5-36. ábra A koordinátor üzenetei
Inicializálás után egy eszköz próbál csatlakozni 0xaaaaaaaa 64 bites címmel. A
koordinátor engedélyezi a csatlakozást, és a 0x02 16 bites címet rendeli a
csomóponthoz. Ezután két üzenetet kap a csatlakozott eszköztől, a 100-as
endpointról kiindulva. A nem „#”-al kezdődő sorban az alkalmazásprofil nyers
üzenete látható. A „Bejovo adat” kezdetű sorban a forráscím és endpoint, a
következő sorban az értelmezett alkalmazásprofil üzenet látható. Vegyük észre,
hogy a sorszám nem egyesével növekszik. Ennek okát a következő ábránál
magyarázom meg.
Az alábbi ábrán a végponti eszköz által a soros portra írt üzenetek láthatók.
5-37. ábra A végponti eszköz üzenetei
A csatornafelderítés eredményeképpen a 0xcccc azonosítójú hálózatot találta a 3-
as csatornán, a koordintáor rövid címe 0xaa. Sikeres csatlakozás után a 0x02 rövid
címet kapta. (Ez az eset az előző ábrán látható kommunikáció másik oldala.) Az
egység inicializálása ezzel befejeződött, a program ekkortól gombnyomásra vár,
amelynek hatására a hőmérő aktuális értékét elküldi a koordinátornak. A „Kuldes
eredmenye” sorokban láthatjuk az adat küldés státuszkódjait. A 0 érték jelenti a
sikert, az e9 érték azt jelenti, hogy nem érkezett nyugta, többszöri újraküldés után
sem. Ez az érték azért fordul elő, mert a nyomógombok nincsenek
pergésmentesítve, egy gombnyomásra kétszer próbálja meg elküldeni az adatot a
program. A koordinátor a második esetben el van foglalva az előzőleg kapott
adatok soros portra írásával, ami lassú művelet. A rádiója nincs vételi
üzemmódban, így nem kapja meg a páratlan sorszámú üzeneteket. Ebből látszik,
hogy az alkalmazás értesül arról, ha a másik oldal nem kapja meg az üzentet.
5.5.1 A főprogram
Az alábbi kódrészlet szemlélteti a főprogram szerkezetét.
int main(void){ unsigned char status; status=ZigbeeInit(); if(status==ZIGBEE_SUCCESS){ registerApplications(); run(); }else{ #if defined (ZBDEBUG) printf("Inicializalas sikertelen. Kod: %X\r\n",status); #endif }}
A ZigbeeInit() függvény inicializálja a ZDO-t, ami elvégzi a protokollverem
kezdeti beállításait, és megnyitja a 0. sorszámú endpointot. Sikeres lefutás esetén a
registerApplications() függvény a 100. sorszámú endpointra beregisztrálja a
példaalkalmazás megfelelő függvényét. A run() függvény végpont esetén
gombnyomásra vár, koordinátor esetén folyamatosan vételi állapotban tartja a
rádiót. Bejövő adat esetén a koordinátoron futó alkalmazás a 100. végpontra
beregisztrált függvényen keresztül kapja meg a csomagot.
5.6 Továbbfejlesztési lehetőségekA program további funkciókkal bővítve még inkább kiterjesztené a lehetőségeket.
Az eszközleírókhoz tartozó ZigBee Device Profile parancsok implementálása
lehetővé tenné a leírók feltöltését egy kitüntetett eszközre és a hálózatban lévő
eszközök automatikus felderítését. Ennek megvalósításához a ZigBee Device
Object bővítésére van szükség. Értelmezni kell a szabványos alkalmazásprofil
üzeneteket, és adatbázisokat kell karbantartani a leírók számára. A végpontokon a
leírók feltöltését és lekérdezését kezelő parancsokat szükséges megvalósítani.
ZigBee routerek implementálásával a hálózat hatósugara megnövelhető lenne.
Ezr a hálózati réteg intenzív fejlesztését kívánja meg. Az útvonalválasztáson, a
routerek egymással való kommunikációján kívül a címkiosztást is meg kellene
oldani. A routerek felelősek a hozzájuk csatlakozó eszközök számára a rövid címek
kiosztásáért. Fastruktúra esetén a ZigBee kész megoldást kínál a címtartomány
ésszerű kiosztására, ld. elosztott címhozzárendelés.
A csoportcímzés és a kötés is hasznos funkciók, ezek implementálásához a
hálózati és az alkalmazási réteg bővítése szükséges. Az adatkezelő primitíveknél a
csoport címek szűrését kell megoldani, a menedzsment. primitíveknél a
csoporttagság, kötések regisztrálását, illetve hálózati szinten az üzenetek eljuttatását
a célig.
ZigBee routerek implementálásával a hálózat hatósugara megnövelhető lenne.
A ZigBee biztonsági kiterjesztéseinek alkalmazása is megfontolandó, mivel a
kommunikáció könnyen lehallgatható, és az üzenetek hitelességét sem biztosítja
semmi jelen esetben.
ÖsszefoglalásÚgy érzem, diplomamunkámmal sikerült a kitűzött feladatokat teljesítenem.
Ismertettem az adatgyűjtő hálózatok jellegzetességeit, megfogalmaztam az
általuk támasztott követelményeket. Áttekintettem a jelenlegi technológiákat. A
harmadik fejezetben ismertettem az adatgyűjtő hálózatok létrehozására is alkalmas
ZigBee, és az alapjait képező IEEE 802.15.4 szabványok lehetőségeit. Az
áttekintésekből látszik, hogy adatgyűjtő hálózatok megvalósítására sok lehetőség
kínálkozik. Vásárolhatunk teljes rendszert, egyetemi projektek és kísérleti
platformok segítségével összerakhatunk rugalmasabb, az igényekhez jobban
alkalmazkodó hálózatot. A legtöbb megoldás hátránya, hogy saját módszereket
alkalmaz, ritkán követ ipari szabványokat. A ZigBee jó lehetőséget kínál
szabványos megoldások létrehozására. Jelenlegi legelterjedtebb alkalmazása az
épületautomatizálás.
Ezek fényében megvizsgáltam, és dokumentáltam egy környezeti monitorozó
rendszert, amely egy ZigBee szabvány szerint működő szenzorhálózatra épül. A
tervezés nem csak a szenzorhálózati részre terjedt ki, hanem az adatok más
hálózaton történő továbbítására, feldolgozására is.
A tervezés során figyelembe vettem a mitmót rendszer, és a Síkfőkút projekt
sajátosságait is.
Dokumentáltam egy környezeti monitorozásra alkalmas hálózat rendszertervét,
kiemelt figyelmet fordítva a mitmót rendszer sajátosságaira, és az önálló laborban
elkezdett Síkfőkút projektre.
Sikerült megvalósítanom a ZigBee egy részhalmazát, amely alkalmas csillag
topológiájú, egylépéses hálózat létrehozására. A program mitmót platformra készült
el az előző féléves önálló laboratóriumi munkát felhasználva, szem előtt tartva a
továbbfejleszthetőséget, és a szabvány minél több ponton való betartását. Az
alapvető funkciókat megvalósítottam, a főbb eltéréseket és a továbbfejlesztési
lehetőségeket dokumentáltam.A mitmót platformon megvalósítottam a ZigBee
alapvető funkcióit. Az elkészült megoldás alkalmas kisméretű, demonstrációs
hálózatok létrehozására, és jó alapot nyújt a ZigBee bonyolultabb szolgáltatásainak
megvalósításához.
Irodalomjegyzék[1] Tenet (University of Southern California)
http://enl.usc.edu/projects/tenet/
[2] SunSpot
http://www.sunspotworld.com
[3] Squawk Vitrual Machine
http://research.sun.com/projects/squawk/squawk-sunspot.html
[4] Java(TM) on the Bare Metal of Wireless Sensor Devices -- The Squawk Java Virtual Machine
http://research.sun.com/projects/squawk/docs/vee06-squawk.pdf
[5] TinyOS
http://www.tinyos.net
[6] TinyOS programming over wireless network
http://www.cs.berkeley.edu/%7Ejwhui/research/deluge/
[7] Crossbow
http://www.xbow.com/
[8] Mica2 mote
http://www.xbow.com/Products/productdetails.aspx?sid=174
[9] Cirronet
http://www.cirronet.com/sensor-network.htm
[10] http://www.cirronet.com/pdf/brochure_zn2401.pdf
[11] http://www.commsdesign.com/showArticle.jhtml?articleID=192200323:
[12] XBee Pro
http://www.maxstream.net/products/xbee/xbee-pro-oem-rf-module-zigbee.php
[13] XBee
http://www.maxstream.net/products/xbee/xbee-oem-rf-module-zigbee.php
[14] Software Technoligies Group
http://www.stg.com/wireless
[15] ZigBee FAQ
http://www.zigbee.org/en/about/faq.asp
[16] http://www.ember.com/products_zigbee_software.html
[17] http://www.microchip.com/zigbee
[18] http://www.ilternet.edu/
[19] IEEE 802.15 WPAN Task Group 4 http://www.ieee802.org/15/pub/TG4.html
[20] 802.15.4 IEEE Standard for Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs)
[21] ZigBee Specification
http://www.zigbee.org/en/spec_download/download_request.asp
[22] Meshnetics ZigBee FAQ
http://www.meshnetics.com/zigbee-faq/
[23] ZigBee Alliance
http://www.zigbee.org/
[24] Mitmót
http://bri.mit.bme.hu/
[25] Sensors Silicon Systems
www.s3cinc.com
[26] Silicon Labs
http://www.silabs.com/
MellékletA CD Tartalma
A mellékelt CD lemezen két könyvtár taláható: Forráskód és Diploma. A
forráskód könyvtárban a program forráskódja, és a makefile található, a Diploma
könyvtárban a diplomamunka PDF formátumban. A diplomamunka során készült
forráskódok a Zigbee* nevűek. A többi állomány az előző félévekben, vagy mások
által elkészített kódokat tartalmazza.