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.