Méhkaptár riasztó - egy alkalmazásorientált vezetéknélküli szenzorhálózat fejlesztése

Méhkaptár riasztó - egy alkalmazásorientált vezetéknélküli szenzorhálózat fejlesztése Scheuring Ádám VI. villamosmérnök hallgató Konzulensek: dr. Csörnyei Márk és dr. Bánky Tamás Szélessávú Hírközlés és Villamosságtan Tanszék

2008. október

1

Tartalomjegyzék Bevezetés

4

Vezetéknélküli szenzorhálózatok

5

A koncepció ismertetése

5

A technológia és következményei

6

Alkalmazások és igényeik

7

Az IEEE 802.15.4 szabványról

8

A fizikai réteg

8

Az SMAC (Simple Media Access Controller)

10

A méhkaptár riasztó

11

A méhészetről

11

Az alkalmazás és a vezetéknélküli szenzorhálózatok kapcsolata

12

A kaptárriasztó modul

13

A központi egység

13

Az alkalmazás energiaigénye

13

A rendszer felépítése

14

A kereszt-réteg struktúra

14

Miért nem ZigBee?

15

A hálózat életre kel

17

A hálózat állapotai

18

A riasztó központ és a modul állapotai

19

A hálózat hardver eszközei

20

Szenzor modulok

20

A központi egység

21

Segédeszköz: a TTL-RS232 konverter

23 2

A hálózat tervezése

24

A terjesztett üzenetek

24

A csomópontok energiafogyasztásának optimalizálása

25

A központ energiafogyasztásának optimalizálása

27

A riasztási állapot hatása az üzenetek küldésére

27

A hálózat szoftverének fejlesztése

28

A feladat időzítő

28

A gyorsulás mérése

28

Soros port használata

30

GSM modem vezérlése soros porton keresztül

31

Üzenetek küldése és vétele

32

A sleep mode

33

A szoftver jelenlegi állapota

33

Összefoglalás, kitekintés

34

Irodalomjegyzék

35

Függelék

36

3

1.Bevezetés Dolgozatomban egy vezetéknélküli szenzorhálózat alkalmazás komplex hardver- és szoftverfejlesztésének lépéseit ismertetem. Célom egy olyan méhkaptár riasztó alkalmazás megvalósítása volt, amely földrajzilag elosztottan képes a kaptárak elmozdítását - azaz a lopási szándékot - érzékelni, a méréseket feldolgozni és a felhasználónak riasztást küldeni. Feladatom megvalósítása során önálló kutatást, fejlesztést és tervezést végeztem. Megvizsgáltam

az

ipari

szabványokon

alapuló

vezetéknélküli

szenzorhálózatok

tulajdonságait, majd az alkalmazás igényeinek megfelelően kialakítottam egy hálózatot, amit részben általam tervezett hardver eszközökön implementáltam, mely során megismerkedtem a 8 bites mikrokontrollerek programozásával. Az ötlet egy konkrét alkalmazásból fakadt, de a munka során szerzett tapasztalatokból általános konzekvenciák is levonhatók. A kaptár riasztó rendszer alapja a vezetéknélküli szenzorhálózatnak nevezett technológia, amely kis hatótávolságú,

alacsony

fogyasztású

rádiós

egységekből

áll,

melyek

esetünkben

gyorsulásmérő szenzorokkal is rendelkeznek. A hardver modulokat az SZHVT tanszéken Dr. Csörnyei Márk és Dr. Bánky Tamás csapata fejlesztette, míg a hálózat központját és a hozzá csatlakozó GSM modult tartalmazó egységet magam terveztem. Az eszközök funkcióinak megvalósításáért felelős szoftver komponenseket beágyazott C környezetben készítettem. A hálózat elemei tehát részben adottak voltak, részben az alkalmazáshoz kellett szabni őket, a valódi kihívás azonban egy olyan hálózati működés megvalósítása volt, amely képes figyelembe venni az alkalmazás igényeit. A hálózat tervezése során figyelembe vettem az eszközök adottságait, - így a rádiós interfész speciális tulajdonságait, a maximális hatótávolságot, az akkumulátorok élettartamát és a gyorsulásmérő szenzorok tulajdonságait -, valamint a célalkalmazás igényeit is. A bevezetés után dolgozatom 2. fejezetében a vezetéknélküli szenzorhálózatokkal kapcsolatos legfontosabb tudnivalókat ismertetem. A 3. fejezetben megfogalmazom a célkitűzést és specifikálom a méhkaptár riasztó alkalmazást. A 4. fejezet az első két fejezetben lefektetett alapköveken nyugvó architekturális elképzeléseimet tartalmazza, amit a kiválasztott eszközök bemutatása követ a 5. fejezetben. A 6. fejezetben a munkám során használt hardverek, a 7. fejezetben pedig a hardvereken futó szoftverek tervezéséről a 8-ban ezek készítéséről ejtek szót, melynek során néhány mérést is bemutatok. A 9. fejezetben foglalom össze munkám eredményeit és felvázolom a munka jövőbeli folytatásának irányait. 4

2.Vezetéknélküli szenzorhálózatok 2.1.A koncepció ismertetése A vezetéknélküli szenzorhálózat (angolul wireless sensor network, rövidítve WSN) összefoglaló név azokra a hálózatokra, melyek elemei ad-hoc rádiós protokollokkal kommunikálnak, kis méretűek, olcsók, alacsony az energiafogyasztásuk és szenzoraikkal képesek környezetük paramétereinek mérésére [1]. Ezek a hálózatok jellemzően sok csomóponttal rendelkeznek és nagy földrajzi területen helyezkednek el, ahol különböző méréseket végeznek. A mért paramétereket képesek feldolgozni, és azokat elküldeni egymásnak, vagy a hálózat központjának.

1. ábra - A vezetéknélküli szenzorhálózatok általános felépítése

Az 1. ábrán a vezetéknélküli szenzorhálózatok tágabb értelemben vett felépítése látható. A hálózat maga az úgynevezett szenzor mező, amelyen belül helyezkednek el a hálózat elemei, a csomópontok. A hálózatot jellemzően egy (néha több) központ koordinálja. Ez a központ végzi a rádiócsatorna kiválasztását, a hálózathoz csatlakozó csomópontok regisztrálását és nyilvántartását, valamint az adatok begyűjtését és továbbítását a felhasználó felé [1], [2]. A vezetéknélküli szenzorhálózatok által mért környezeti változók lehetnek a hőmérésklet, fényerősség, mégneses térerősség, páratartalom, nyomás, gyorsulás, azaz minden olyan paraméter, melynek mérésére rendelkezésre áll a megfelelő technológiájú és költségű szenzor. Az adatok abszolút pontossága jellemzően nem kritikus szempont, az egyes szenzorok által küldött adatok mennyisége pedig általában a 100 byte/perc nagyságrendbe esik. A vezetéknélküli szenzorhálózatok változatos alkalmazási lehetőségeket nyújtanak legyen szó ipari, biztonságtechnikai, katonai, mezőgazdasági vagy éppen egészségügyi feladatokról. 5

2.2.A technológia és következményei Az elmúlt évtized félvezető technológiai fejlődése több irányból is közelítette az előző pontban felvázolt koncepciót. Az egyik irány az olcsó, kis fogyasztású, jellemzően 8 bites mikrokontrollerek, a másik a szintén olcsó és kis fogyasztású, CMOS technológiával előállított rádiós interfészek, a harmadik pedig az intelligens szenzorok megjelenése és fejlődése volt. Az alacsony ár és fogyasztás hangsúlyozása tudatos. A fogyasztás kérdését tekintve látható, hogy az alkalmazások tulajdonságaiból fakadóan a vezetéknélküli szenzorhálózatok csomópontjaihoz a tápellátás nem érkezhet folyamatos forrásból: tárolt energia forrásra, akkumulátorra, vagy egyéb megoldásra (pl. szuperkapacitás) van szükség. Ez természetesen korlátozza a rádió maximális hatótávolságát, így ezeket a mikrokontrollerrel vezérelt, rádiós interfésszel és szenzorokkal felszerelt beágyazott eszközöket földrajzilag nagy sűrűségű hálózatba kell rendezni. Ha pedig nagy sűrűséget akarunk elérni aránylag nagy területen, akkor értelemszerűen sok ilyen eszközre van szükségünk, tehát a kör bezárult. A vezetéknélküli szenzorhálózatokhoz készült rádiós interfészek szabad frekvenciasávokban működnek. Az úgynevezett ISM (Industrial, Scientific, Medical) sávok előnye egyben a hátránya is, azaz hogy használatához nincs szükség liszenszre, ezért sok a felhasználó és elég nagy a zaj ebben a tartományban. Ezen a nyomon tovább vizsgálódva eljutunk a vezetéknélküli szenzorhálózatok rádiós interfészeinek egy nagyon fontos tulajdonságához. Ismert tény, hogy a mobiltelefonok szuperheterodin vevőjének két fontos alkatrésze, a tükörszűrő és a KF szűrő alkotja a készülék árának nagyrészét. A magas ár oka a technológiában keresendő, az olcsó eszközökben alkalmazott CMOS technológiával ugyanis nem lehet a mikrohullámú, GHz-es tartományban működő vevőszűrőt előállítani, a lineáris erősítők pedig sok energiát fogyasztanak és drágák is. Ennek következménye, ezek az adóvevők vétel közben körülbelül ugyanannyi áramot fogyasztanak, mint adáskor [17]. Az alacsony átlagos energiafogyasztás elérése érdekében ezt a tulajdonságot nagyon fontos szem előtt tartani a kommunikációs protokollok tervezésekor. A manapság használatos vezetéknélküli szenzor modulok tartalmaznak egy adóvevővel felszerelt mikrokontrollert, néhány szenzort, antennát és tápellátást, akár 3 x 3 cm-es méretben.

6

2.3.Alkalmazások és igényeik A fizikai réteg tulajdonságai után felülről, azaz az alkalmazások irányából közelítem a kérdést. A vezetéknélküli szenzorhálózatok egyik legnagyobb előnye, hogy működésükhöz a hálózat elemei biztosítják az infrastruktúrát, képesek elosztottan, önszerveződően működni. Azonban az alkalmazások elvárják, hogy a csomópontok megbízhatóan kommunikáljanak egymással [1]. A megbízhatóság természetesen nem annyira fontos szempont egy páratartalom mérő alkalmazásnál, mint egy tűzjelzőnél. A vezetéknélküli szenzorhálózatokban a kommunikáció gyakran multihop, ami azt jelenti, hogy az üzenet egy távoli ponttól a központig több másik ponton keresztül jut el. Tipikus helyzet, hogy a forgalmas útvonalakban elhelyezkedő csomópontok többet használják rádiós interfészüket, így hamarabb lemerülnek, mint a szenzormező szélein elhelyezkedők. Egy csomópont kiesése a mérés szempontjából nem minden esetben kritikus, ha a környezetében kellő sűrűséggel találhatóak még azonos környezeti paramétereket mérő csomópontok. Az adatok továbbítása szempontjából azonban problémát okozhat, hiszen elképzelhető, hogy a kiesés következményeképp a közelben lévő csomópontok sem tudják adataikat a központ felé továbbítani. A megoldás ezen probléma kiküszöbölésére

a

megfelelő

hálózati

topológia

és

útvonalválasztási

algoritmus

megválasztása. Ha a hálózati topológia kellően redundáns, akkor egy csomópont kiesése esetén a hálózat képes alternatív utakon eljuttatni az adatot a kívánt helyre. A csomópont kiesését pedig olyan útvonalválasztási algoritmusokkal lehet megelőzni, ami a terhelést elosztva eltérő útvonalakon vezeti keresztül az azonos forrás-cél párokat tartalmazó üzenettovábbítási kéréseket [2. ábra].

2. ábra - A robosztus útvonalválasztás

7

2.4.Az IEEE 802.15.4 szabványról A 2.2-es pontban általánosságban ejtettem szót a technológiáról, most pedig a hivatalos formában megfogalmazott kritériumokat ismertetem röviden. Az IEEE szervezet a 802.15.4es számú szabványban rögzítette az LR-WPAN-nek (Low Rate - Wireless Personal Area Network), azaz az alacsony adatátviteli sebességű, vezetéknélküli, személyi hálózatnak nevezett koncepció fizikai és adatkapcsolati (MAC és logikai kapcsolat) rétegének specifikációját [3]. A szintén WPAN kategóriába tartozó Bluetooth protokollal szemben azonban a 802.15.4 nem a különböző személyi eszközök hálózatba szervezését, hanem az általunk vezetéknélküli szenzorhálózatként definiált elképzelést célozta meg. A szabvány készítői figyelembe vették a piaci, technológiai lehetőségeket és az alkalmazások igényeit is.

2.4.1.A fizikai réteg A 802.15.4 első változata három ISM frekvenciasávot jelölt ki a szabvány fizikai rétegének, a 868-868.8 MHz-es európai, a 902-928 MHz-es észak-amerikai és a világszerte szabad 2.4-2.4835 GHz-es tartományt. Minthogy csak ez utóbbi az egyetlen, ami egységesen, mindenhol elérhető, a 802.15.4 szabványt megvalósító integrált áramkörök szinte kivétel nélkül ebben a frekvenciasávban működnek, minek okán dolgozatomban a továbbiakban csak ezzel foglalkozom. Ez a tartomány 15 csatornára oszlik, melyek középfrekvenciája egymástól 5 Mhz helyezkedik el, egy csatorna szélessége pedig 2 MHz. Az eszköz képes kell legyen minimum 0.5 mW (-3 dBm) kisugárzására, míg a maximális megengedett teljesítmény Európában 100 mW (20 dBm), ami mindkét esetben izotróp antennára vonatkoztatott effektív teljesítmény. A vevő érzékenysége legalább -85 dBm-nek van előírva (a nagyobb abszolút érték a jobb), ami a legegyszerűbb kültéri csillapítási modellt és a normál kisugárzott teljesítményt feltételezve megadja a maximális hatótávolságot [13]: L = 10*n*log10(d) ahol n=4 (n=2 ideális szabadtér, n=4 földfelszíni reflexió), L a csillapítás, d pedig az adó és a vevő közti távolság. Ha feltételezzük, hogy az adóteljesítmény 0 dBm (1 mW) és a vevő érzékenysége pont -85 dBm, akkor L maximális értéke 85 dBm lehet. Rendezve az egyenletet d-re, a megadott paraméterek mellett kb. 125 m jön ki. Egyéb, bonyolultabb csillapítási modelleket alkalmazva, nagyságrendileg azonos eredményeket kaptam.

8

Gyakorlati mérések azt mutatják, hogy 0 dBm-es adóteljesítménnyel szabadtéren 100-200 méter, beltéren 20-40 méter érhető el. A 2.4 GHz-es sávban működő 802.15.4 eszközök O-QPSK (Offset Quadrature Phase Shift Keying)

modulációt

használnak,

amivel

egy

szimbólumonként

32

chipből

álló,

pszeudorandom spektrumkiterjesztő kóddal össeszorzott jelsorozatot visznek át [3. ábra].

3. ábra - A DSSS szemléltetése az idő- és a frekvenciatartományban

A bemenő adatbiteket a rendszer egy pszeudo zaj kóddal szorozza meg, melynek spektrális sűrűségfüggvénye zajszerű, egyenletes eloszlást mutat. Vételkor a vevő is ismeri a megfelelő szimbólumhoz tartozó kódsorozatot és megszorozza vele a vette jelet. Az így elvégezett korrelációszámítási eljárás gyakorlatilag egy FIR szűrés, melyben a szűrő együtthatói a kódszekvencia bitjeinek egymást követő értékei. Ezt a spektrumkiterjesztési eljárást nevezik DSSS-nek (Digital Sequence Spread Spectrum), melynek több előnyös tulajdonsága is van. Egyrészt így az adott csatornában egyidőben több felhasználó is adhat, másrészt a többutas terjedésből adódó interferenciák valamint a keskenysávú zavarok, zavarások hatásai is kiküszöbölhetők. Fontos azonban hangsúlyozni, hogy a 802.15.4 típusú eszközök egy adott szimbólumhoz fix chip kódot rendelnek, tehát két ilyen eszköz szimultán adása hibás keretet eredményez a vevőben, mely mindkét adó jelét egyszerre veszi. Ez CSMA/CA közeghozzáférés esetén az úgynevezett rejtett terminál esetben fordul elő. Tehát a 802.15.4ben több felhasználó alatt több, az adott csatornában jelenlévő, különböző modulációs eljárást alkalmazó felhasználót értünk.

9

2.5.Az SMAC (Simple Media Access Controller) A 802.15.4 MAC rétege az elképzelt alkalmazásoknak és hálózati protokolloknak megfelelően került kialakításra. Bonyolultsága, mérete és energiafogyasztása okán azonban egyszerű alkalmazásoknál nem a legoptimálisabb megoldás. Az általam is használt eszközöket gyártó Freescale kifejlesztett egy saját függvénykönyvtárat (API), amit Simple Media Access Controllernek (SMAC) nevezett el és gyakorlatilag a 802.15.4 MAC rétegének alapfunkcióit tartalmazó függvények [4. ábra] [10]. Ez az egyszerűsítés nagy szabadságot nyújt a fejlesztőknek, hiszen erre a rétegre bonyolultabb funkciók is építhetők, ha azt az alkalmazás megkívánja.

4. ábra - A DSSS szemléltetése az idő- és a frekvenciatartományban

Az SMAC olyan egyszerű építőkockákkal rendelkezik, melyekkel akár a 802.15.4 MAC rétegének funkciói, akár egyedi hálózati funkciók is kialakíthatók. Az SMAC támogatja a csatorna energiaszintjének detektálását, üzenetküldést, üzenetfogadást, adóteljesítmény beállítást, timeout kezelést és az adóvevő vezérlését is. Az SMAC függvényeinek ismertetésébe a szoftver elkészítésének bemutatása során, a 8. fejezetben bocsátkozom.

10

3.A méhkaptár riasztó 3.1.A méhészetről Az ötlet egy a konzulensemmel folytatott beszélgetés során merült fel. A szakirodalom rengeteg alkalmazásról írt már, melyek többsége meglévő rendszerek vezetékeit váltotta fel a vezetéknélküli technológiával. Ilyenek például a tűzjelző rendszerek, lakásriasztók, a HVAC (Heating, Ventillating and Air Conditioning) vezérlők, vagy az automatikus mérőóra leolvasók. Olyan alkalmazást kerestem, ami nem csupán a vezetékeket váltja ki, hanem a vezetéknélküli szenzorhálózat koncepció alapvető tulajdonságaiból építve teremt új értéket. A mai Magyarország területén a méhészet évezredes múlttal rendelkező mesterség és hagyomány, melynek alapjait a Római Birodalom idején fektették le az itt élő népek [7]. A régió megfelelő időjárása és növényeinek változatossága ideális körülményeket biztosított a méhészeknek, akik a korai időkben a méhcsaládok otthonául szolgáló odvas fákat megjelölve járták az erdőt, majd a 18. század második felétől egyre komolyabb módszerekkel dolgoztak. Mária Terézia 1770-ben alapította az első méhész iskolát, ahol a tanulók a szakma alapvető fortélyaival ismerkedtek meg. Ebben az időben a mézet azonban a méhek elpusztításával nyerték ki a lépekből, amivel Tessedik Sámuel 1794-es könyvének hatására fokozatosan felhagytak. A 19. században a méhészet veszített jelentőségéből a parasztság körében és földesurak, papok, tanítók hobbijává vált. A változást egy Boczonádi nevezetű méhész 1913ban kifejlesztett kaptárrendszere hozta, melyet a mai napig “Boczonádi”-ként ismernek és használnak a hazai méhészetekben. A megfelelő kaptárak használata biztos alapokra helyezte a termelést, így mára 16700 méhész tevékenykedik hazánkban és összesen 690’000 kaptárral rendelkeznek, fejenként átlagosan 41-el. Egy kaptár ára 2008-ban 20 ezer Ft, a méhcsaládé és a kaptárban található mézé begyűjtés idején pedig együttesen kb. 30-40 ezer Ft. Ha ehhez hozzáadjuk a ráfordított munkaórákat is, látható, hogy egy 40 kaptárral rendelkező átlagos méhészet teljes értéke is bőven 2 millió Ft felett van. A vándorméhészek kora tavasztól késő őszig vándorolnak a méhekkel követve a virágport és nektárt adó növények virágzását. A vándorlás során a kaptárakat a legmegfelelőbb helyekre igyekeznek lerakni, ahol körülbelül egy hétig legelnek a méhek. A kaptárak őrzését legtöbbször nem tudják megoldani, ezért szükség van riasztó rendszerekre, a sajnos igen gyakran előforduló lopások miatt.

11

Hangsúlyozom, hogy méhkaptár riasztó termékek léteznek, az én ötletem és munkám egy vezetéknélküli szenzorhálózat fejlesztése volt, amely ezt az alkalmazást valósítja meg. A piacon kapható termékek és az általam fejlesztett rendszer összehasonlítását dolgozatom végén ismertetem.

3.2.Az alkalmazás és a vezetéknélküli szenzorhálózatok kapcsolata Az előző pontban ismertettem az alapproblémát, s most megmutatom, hogy mi dolgozatom célkitűzése. A vezetéknélküli szenzorhálózatok tipikus alkalmazásaira léteznek szabványos hálózati protokollok, melyek kielégítik legtöbbjük igényeit. Ilyen például a ZigBee, amely a hálózati rétegen felül úgynevezett profilokban definiálja a különböző alkalmazások kommunikációját, biztosítva ezzel a különböző gyártók közötti kompatibilitást például egy távirányító és egy világításkapcsoló (Home Automation Profile) vagy a gázóra és a leolvasást rögzítő központ (Automated Metering Profile) között. Képes sok végpontot nyilvántartani és menedzselni, amihez viszonylag nagy adatbázisokat használ. Dolgozatom célja, hogy megmutassam, speciális esetekben előnyösebb olyan hálózatot tervezni, amely szorosan igazodik a célalkalmazás igényeihez. Ehhez választottam egy szemléletes példát, a méhkaptárriasztót, melyen keresztül bemutatom egy alkalmazásorientált vezetéknélküli szenzorhálózat fejlesztését. A bevezetőben vázoltam, hogy a csomópontok az úgynevezett szenzormezőben helyezkednek el. Legyen ez a szenzormező az erdőszéli méhlegelő, a csomópontokat pedig szereljük be a kaptárakba [5. ábra].

5. ábra - A méhkaptár riasztó szenzorhálózat

12

A csomópontokat lássuk el olyan szenzorokkal, amelyek hatékonyan képesek érzékelni a kaptárak elmozdítását és minimálisra csökkentik a téves riasztások valószínűségét. A hálózat központi egysége gateway funkciókat is ellát, így képes kapcsolatot tartani más hálózatokkal.

3.2.1.A kaptárriasztó modul A riasztó szerepét egy vezetéknélküli szenzormodul tölti be. Rendelkezik 802.15.4-es Freescale adóvevővel, egy 8 bites Freescale mikrokontrollerrel és egy gyorsulásmérő szenzorral, ami mindhárom tengely gyorsulását képes mérni. A mikrokontrollerrel feldolgozzuk a gyorsulásmérő adatait és döntést hozunk, hogy szükséges-e riasztást küldeni vagy nem. Fontos az is, hogy a központ mindenképpen vegye a riasztást, tehát egyfajta garanciát kell biztosítani a magas prioritású üzenetek sikeres továbbítására. Fontos szempont még az energiatakarékosság, tehát az, hogy éppen annyit és akkor használjuk az adóvevőt, amikor szükség van rá. A hálózat menedzseléséhez a központtal tudatni kell a telep állapotát (feszültségét) és a kapcsolat minőségi paramétereit.

3.2.2.A központi egység A központi egysége feladata a rádiócsatorna kiválasztása, a hálózat egyszerű menedzselése, utasítások, kérések kiadása a csomópontok felé, valamint a kapcsolattartás a felhasználóval. A hálózati központ egyik része gyakorlatilag ugyanazt a hardvert tartalmazza, mint a csomópontok, a másik azonban egy modem, ami képes a riasztásokat SMS formájában GSM hálózatba küldeni.

3.2.3.Az alkalmazás energiaigénye Fontos megemlíteni még, hogy az alkalmazás speciális célra készült, ezért néhány kiindulási paramétert eszerint választottam meg. A központi egység akkumulátorának feltöltését heti, míg a csomópontokét 2-3 havi gyakorisággal (egy-két feltöltés/szezon) számoltam. A központi egység energiafogyasztásában a GSM modem állapota a kritikus és mivel itt gyakoribb feltöltési lehetőségre számítok, a hálózat tervezése során a központ fogyasztásának minimalizálása helyett inkább a maximális megbízhatóság hangsúlyozására törekedtem.

13

4.A hálózat felépítése 4.1.A rétegek szerkezete Ebben a fejezetben a feladat tervezési fázisában meghatározott elvárásokat és célokat ismertetem. Dolgozatommal azt az állítást szeretném megfogalmazni, hogy egyedi, célalkalmazások

igényeire

szabott

vezetéknélküli

szenzorhálózatok

több

előnnyel

rendelkeznek a szabványos kommunikációt megvalósítókkal szemben. Leírom a hálózat alapvető működését és a példán keresztül igyekszem rámutatni, hogy ezen állítás helyénvalóságát erősíti a megvalósított feladat. Az OSI modellt leegyszerűsítve ismertetem az általam tervezett hálózat architektúráját. A hálózat működéséhez szükség van média vezérlő rétegre (MAC), melynek funkcióit az SMAC primitívjei biztosítják. Szükség van továbbá az üzenetek, riasztások kezeléséhez, csomópontok menedzseléséhez egy hálózati rétegre (NWK), ami a MAC réteggel és az alkalmazással folyamatos kapcsolatot tart. Végül szükség van magára az alkalmazásra is (APP). A klasszikus rétegmodellel szemben én egy olyan kereszt-réteg struktúrát használtam, ami dinamikusan követi az egyes rétegek pillanatnyi igényeit, elmosva ezzel a határokat közöttük. Így a tervezéskor nem csak egy-egy réteg, hanem az összes réteg igénye is figyelembe vehető és a hálózat teljesítménye együttesen optimalizálható [6. ábra] [3]. A módszerrel elég gyakran találkozhatunk a vezetéknélküli szenzorhálózatok irodalmában (CLO - cross-layer optimization) [18].

6. ábra - Kereszt-réteg struktúra

A leírás során azonban követem a MAC, NWK, APP struktúrát és utalást teszek arra, hogy az adott réteg mely másikkal van kapcsolatban. A hálózatnak kezelnie kell a csomópontok regisztrálását, az üzenetek küldését és fogadását, valamint az üzenetek, az alkalmazás és a tulajdonos megkülönböztetését egyéb 802.15.4 eszközöktől.

14

4.2.Miért nem ZigBee? A kérdést talán későn tettem fel, de úgy gondolom, hogy sok fontos dologra szükséges volt rávilágítani a magyarázat megértéséhez. A ZigBee [4] a 802.15.4 [3] fölött működő hálózati és alkalmazástámogató réteg együttese, amelyet egy ZigBee Alliance-nek nevezett szervezet szabványosított 2004-ben. E szabványra felkészítve jelentek meg a 802.15.4-es fizikai és MAC réteget megvalósító adóvevők, így a két fogalom némileg össze is nőtt az évek során. A ZigBee a vezetéknélküli szenzorhálózatok alkalmazásainak leggyakrabban használt és gyakorlatilag egyetlen létező szabványos protokollja.

7. ábra - A ZigBee protokoll stack felépítése [4]

A ZigBee stack [7. ábra] implementálása szoftver úton történik, melyet általában az IC-t gyártó cég szoros árukapcsolásban bocsát a felhasználók rendelkezésére, garázsfejlesztői viszonylatban borsos áron. Az elkészült termék szabványosítása szintén nem olcsó. A ZigBee stack támogat csillag (star), fa (tree) és háló (mesh) struktúrát is. A szabvány 2007-es változata azonban kimondja, hogy a hálózat központja (coordinator) nem működhet energiatakarékos (sleep) üzemmódban, azaz mindig vétel, vagy adás állapotban kell legyen. Ez egyben azt is jelenti, hogy a hálózat menedzseléséért felelős eszköz (koordinátor) csak folyamatos tápellátással rendelkezhet. Egy gyors számolással megmutatom miért. Az általam használt mikrokontroller és rádiós adóvevő adáskor és vételkor körülbelül 50mA áramot fogyaszt (nem számítva egyéb perifériákat). 15

Egy nagyteljesítményű akkumulátor kapacitása 2000mAh, ami azt jelenti, hogy 40 órányi használat után ez a telep teljesen lemerül. Emlékezzünk csak vissza, mennyi időt szabtunk egy feltöltéssel a központnak? Körülbelül 1 hetet, azaz több, mint négyszer annyi időt, mint amit az akkumulátor felső becsléssel kibírna. Szélkerekes, napelemes megoldás szintén nem jöhet szóba sérülékenysége és meglehetősen magas ára okán. A ZigBee protokoll leírja, hogy hálózat csak olyan csomópontokkal képes kommunikálni, amelyek csatlakoztak a hálózathoz, tehát szükség van nyilvántartásra, routing táblákra és hálózati címekre. A ZigBee hálózat nem engedi meg az úgynevezett beacon üzenetek küldését sem. A beacon üzenetek olyan keretek kezdetét jelzik, melyben bizonyos csomópontok garantált időszelettel rendelkeznek. Ez a módszer a 802.15.4 által támogatott MAC szabvány része, a ZigBee azonban nem implementálta. Ennek oka, hogy a beacon alapú, időosztásos rendszert úgy tervezték, hogy a nem használt időszeletekben a koordinátor (azaz a központ) energiatakarékos üzemmódban várakozzék. Ez nem volna teljesen biztonságos, hiszen a memóriában tárolt routing táblákat, nyilvántartásokat ilyenkor le kellene menteni, továbbá a hálózat központja nem mindig lenne elérhető, ami a robosztusságot is csökkentené. Ezért a ZigBee szabvány jelenlegi változatában nem támogatja ezt a megoldást. Emellet a ZigBee stack sok helyet foglal a memóriában, ami megint csak növekvő költség (40-60 Kbyte) formájában szól ellene. Szintén probléma, hogy a fejlesztők elől rejtve van a forráskód, azaz az esetleges hibák nem kerülnek könnyen felszínre.

16

5.A hálózat életre kel A klasszikus szenzorhálózat koncepció olyan csomópontokról szól, melyek

mérések

eredményeit, adatokat juttatnak el a hálózat központjába, ahol a felhasználó vagy egy szerver feldolgozza és kiértékeli azokat. A méhkaptár riasztó azonban teljesen más. A felhasználó, azaz a méhész szempontjából teljesen mindegy, hogy a 17-es vagy a 23-as sorszámú kaptárat próbálják éppen eltulajdonítani, ellenben rendkívül fontos, hogy a riasztás tényét minél nagyobb biztonsággal tudassuk a hálózat központjával. Mivel a csomópontok antennái minden irányba közel egyformán sugároznak, adásukat a közelben lévők mind hallják (lokális broadcast), ha éppen vételi módban vannak. Ha minden csomópont továbbküldi a vett üzeneteket, akkor ezek az üzenetek fokozatosan elterjednek a hálózatban és végül olyan csomópontokhoz is eljutnak, akik ezt az információt felhasznáják. Ezt nevezik elárasztásos üzenettovábbításnak [6]. A hálózat tervezésekor mindezt kihasználtam és létrehoztam egy olyan modellt, amely a hálózat állapotait különbözteti meg. Ezen állapotok alapján a csomópontok és a központ egyszerű szabályokkal határozzák meg aktuális működésüket. Az állapotok a küldött üzenetekkel terjednek a hálózatban, így a csomópontoknak nem kell a hálózathoz csatlakozniuk, a hálózatnak nem kell az útvonalválasztással foglalkoznia és mellékes marad az is, hogy éppen melyik kaptárat mozdították el. Így az elárasztásos technika legnagyobb problémája, az üzenetek “szaporodása” a folyamatos továbbküldések miatt nem jelenik meg, mert a csomópontok valójában nem konkrét üzeneteket, hanem állapotokat továbbítanak. Az

állapotok továbbítása meghatározott tartalmú üzenetek periodikus

küldésével történik. Az üzenettovábbítás paramétereit úgy kell megválasztani, hogy az állapotok terjedése az alkalmazásnak megfelelő időn belül elérje a hálózat bizonyos részeit. Ehhez figyelembe kell venni az eszközök energiafogyasztását adás és vétel üzemmódban valamint a 802.15.4 üzenetek bitidejét. A paraméterek megválasztása és a megvalósítás alapjául szolgáló konkrét számítás a 7. fejezetben kap helyet. A következőkben ismertetem a hálózat valamint a központ és a csomópontok által felvett állapotok leírását.

17

5.1.A hálózat állapotai NWK OFF

SET BALANCE

NORMAL

ALERT

8. ábra - A hálózat állapotgráfja

Az állapotok elnevezésekor az irodalomban is használt kifejezések előfordulása miatt választottam az angol nyelvet. NWK OFF: [8. ábra] A központ nincsen bekapcsolva, ezt az állapotot a csomópontok érzékelik és kisebb gyakorisággal terjesztik az ezt jelző üzeneteket. SET BALANCE: A hálózat él, bekapcsolt központ van a közelben, amely megfelelő üzenettel jelzi jelenlétét. Ebben az állapotban az a parancs fogalmazódik meg, amely a csomópontokat utasítja gyorsulásmérőjük vízszintes állapotának rögzítésére. A mérés körülményei és a szenzorok eltérő ofszethibája miatt ugyanis a kaptárak kihelyezése után erre szükség van. Az üzenetet vevő csomópontok ezt az állapotot a NWK OFF állapotnál gyakrabban terjesztik, hiszen a cél az, hogy a hálózat gyorsan feléledjen. Ha egy csomópont megtette a beállítást, akkor onnantól NORMAL állapotot terjeszt. NORMAL: A csomópontok folyamatosan mérik a gyorsulást, az adatokat feldolgozzák és szükség esetén riasztanak, tehát ha nincsen riasztás, akkor NORMAL állapotot terjesztenek, ha pedig van, akkor ALERT-et. ALERT: A riasztás állapota, ilyenkor a csomópontok nagyobb gyakorisággal küldik ki az állapotot jelző üzeneteket, melyeknek a központig kell eljutniuk, hogy az továbbítsa a felhasználó felé.

18

5.2.A riasztó központ és a modul állapotai NWK OFF

SET BALANCE

SENSOR ON

SLEEP

ALERT 9. ábra - A hálózat állapotgráfja

NWK OFF: [9. ábra] A riasztó ilyenkor nem észlel működő hálózatot a közelben, így a modul NWK OFF állapotba kerül, ha a központot kikapcsoljuk, és ez az állapot az alapértelmezett bekapcsoláskor is. SET BALANCE: A központ bekapcsolás után rögtön ezt az állapotot terjeszti. A modul pedig ebbe az állapotba kerül, ha észleli a központ jelenlétét, azaz SET BALANCE üzenetet vesz. A modul beállítja a gyorsulásszenzor egyensúlyi pozícióját és a SET BALANCE üzenet terjesztése után SENSOR ON állapotba vált. SENSOR ON: A gyorsulásszenzor működik és az adatok feldolgozása folyamatban van. SLEEP: Ebben az állapotban az eszközök kevés áramot vesznek fel, ilyenkor nem méri a gyorsulást és az adóvevőjét is kikapcsolja. A hálózat energiafogyasztásának minimalizálása érdekében a moduloknak a lehető legtöbb időt SLEEP-ben kell tölteniük. A SENSOR ON és a SLEEP állapot egymást váltja előre meghatározott periodicitással. ALERT: Ha a gyorsulásszenzor elmozdítást érzékel, ALERT állapotba kerül a modul.

19

6.A hálózat hardver eszközei 6.1.Szenzor modulok A vezetéknélküli szenzorhálózatok fejlesztéséhez a tanszéken fejlesztett modulokat használtam, amik a Freescale cég NCB elnevezésű eszközének alapján [10. ábra] [Függelék 2.] készültek, egyedi tervezésű nyák antennával. A modulok központi eleme a Freescale által gyártott MC13123 [8], amely egy integrált áramköri tokban tartalmazza a vezérlést végző 8 bites mikrokontrollert és a 802.15.4-es modemet. A kártyán található még egy MEMS gyorsulásmérő szenzor (MMA7260QT [9]), amely a három tengely gyorsulását méri.

10. ábra - Az NCB modul és a debugger interfész

A MEMS mozaikszó az angol microelectromechanical systems kifejezésből származik. Ezen eszközök mérete az 1-100 mikrométer tartományba esik és mechanikai funkciókat ellátó részegységekkel rendelkeznek [12]. A MEMS gyorsulásmérők igen egyszerű szerkezetek, apró szilíciumból faragott rugókkal rendelkeznek, melyek mozgásait gyorsulásukkal arányos elektromos jelekké alakítják. A szenzor érzékenysége konfigurálható (1,5g/2g/4g/6g) és az adatlap szerint a tengelyek kereszt-érzékenysége maximum 5% [9]. Az NCB modulon található még egy USB csatlakozó, amely lehetővé teszi, hogy soros porton keresztül kommunikáljunk az eszközökkel. Az eszközök fogyasztását a mellékelt táblázat mutatja: fogyasztás normál módban fogyasztás sleep módban fogyasztás adáskor fogyasztás vételkor

MC13213 (MCU)

MC13213 (modem)

MMA7260QT összesen

~ 6 mA ~ 25 nA -

500 uA 35 uA 30 mA 37 mA

500 uA 3 uA -

11. ábra - A eszközök fogyasztása

20

~ 8 mA ~ 40 uA -

Látható, hogy normál működéskor, amikor a modem nem ad és nem vesz, összesen körülbelül 8mA-t fogyaszt a modul. Sleep módban összesen 40uA-t, míg adáskor 40, vételkor 45mA-t. Az alkalmazás igényeinél említettük, hogy körülbelül 2-3 hónapig szeretnénk a modulokat egy feltöltéssel működtetni, ami 10 héttel számolva 1680 órát jelent. Nagy kapacitású, 2000mAh-s telepeket feltételezve ez 1,19 mA átlagfogyasztást jelent. Ez alapján a működés állapotainak arányait a következőképpen osztottam el: 0,8% adás/vétel (42,5mA), 9,2% normál (8mA) és 90% sleep (0,04mA) mód, így 1,112 mA-es átlagfogyasztást kaptam, ami megfelel az általunk támasztott kritériumnak. Az energiafogyasztás optimalizálásának szoftveres megvalósításáról a 7. fejezetben esik szó.

6.2.A központi egység A központi egység két részből áll, egy áttervezett NCB és egy GSM modemet tartalmazó modulból [12. ábra]. A központ tehát gatewayként szolgál a vezetéknélküli szenzorhálózat és a GSM hálózat között. Az NCB modul átalakítását és a teljes GSM hardver [Függelék 1.] tervezését magam végeztem, az Altium Designer programmal. A felhasznált alkatrészek listája a függelékben található. A két részegység speciális, modulok összekapcsolására szolgáló, úgynevezett board-to-board csatlakozóval van ellátva. A hardvereket úgy terveztem, hogy ezen csatlakozón keresztül képesek legyenek soros és IO portokon keresztül kommunikálni. NCB modul IO port soros port

MC13213

ACC

GSM modul Y

B 2 B

GSM modem B 2 B

Y

3V

akkumulátor 3,6V RTC supercap

fesz. stab.

12. ábra - A központ vázlatos felépítése

A GSM modul lelke egy SIM300DZ típusú GSM modem [11], amelyet úgynevezett AT parancsokkal [14] lehet soros porton keresztül utasítani különböző funkciók végrehajtására. 21

A SIM300DZ-nek 48 lába van, képes soros porton kommunikálni, rendelkezik egy programozható GPIO (General Purpose Input and Output) csatornával, debug porttal, akkumulátortöltő áramkörrel, SIM kártya interfésszel, mikrofon és hangszóró csatlakoztatási lehetőséggel, valamint megfelelő mennyiségű földponttal. A hardver tápellátását egy 3,6V-os 720mAh-s Li-Ion akkumulátor biztosítja, amely képes a GSM modemek aktív működéséhez szükséges nagy csúcsáramok biztonságos leadására.

13. ábra - A központ GSM modult hordozó nyákja (beültetés előtt)

A GSM hálózatba csatlakozáshoz természetesen szükség van egy SIM kártyára, ezért a hardverre egy megfelelő kártyatartó került, melynek lábait a sztatikus elektromosság káros hatásai ellen védő áramkörre (ESD) kötöttem. A SIM300DZ két energiatakarékos állapotra képes, a POWER DOWN üzemmód gyakorlatilag a teljes kikapcsolást jelenti (45 uA). Erre egy speciális AT paranccsal utasítható a GSM modem, amelyet a mikrokontrollerrel tudunk kiküldeni. Bizonyos funkciók azonban ilyenkor is élnek, melyekhez azonban egy tartalék tápforrásra van szükség. Erre a célra egy 0,2F-os, 3,3V-os szuperkapacitást használtam, amit egy MCP1700 típusú 1,8V-os feszültségszabályozó IC-re kötöttem és a VRTC lábra csatlakoztattam. Az RTC (Real Time Clock) funkciója, hogy a modult POWER DOWN állapotból egy előre meghatározott (és beállítható) idő múlva normál, POWER ON állapotba kapcsolja. A másik takarékos üzemmódban (SLEEP) a modul 2,5mA-t fogyaszt, ilyenkor azonban az akkumulátort használja. Ebbe a DTR (Data Terminal Ready) láb logikai magas szintbe emelésével lehet a modult kényszeríteni. Ehhez az átalakított NCB modulon kivezettem egy I/O lábat, ami a csatlakozón keresztül kapcsolatot teremt a GSM modullal, így ez az üzemmód is vezérelhető a mikrokontrollerel.

22

A központ NCB moduljának a GSM modul szolgáltatja a tápforrást 3V-os MCP1700 feszültségszabályozó IC-vel, melynek kimenetét a csatlakozó egyik lábára vezettem. A GSM antennához egy SMA csatlakozót terveztem a nyákra, amit igyekeztem az akkumulátortól a lehető legtávolabb elhelyezni. Dolgozatom írásáig csak a nyák készült el [13. ábra], így a saját fejlesztésű GSM modulról, mint működő hardverről egyelőre nem tudok beszámolni.

6.3.Segédeszköz: a TTL-RS232 konverter A fejlesztés, tesztelés megkönnyítése érdekében a központ soros port lábait kivezettem két tüskére, hogy számítógépen keresztül tudjak az NCB és a GSM modullal is kommunikálni. Ehhez azonban egy olyan egyszerű áramkörre volt szükségem, amely a mikrokontrollerek TTL (transistor-transistor logic) szintjét a számítógép 5V-os RS232 szintjére konvertálja [13]. Az áramkört próbapanelen raktam össze. Az áramkör lelke a MAXIM cég MAX232 típusjelű IC-je, amely néhány passzív kiegészítő alkatrész hozzáadásával megvalósítja a kívánt funkciót. A próbapanelen összerakott egyszerű eszköz 5 V-os tápról működik, melyet összekötve az NCB modullal, a mikrokontroller 2 vezetékes soros portján keresztül képes a PC-vel kommunikálni, azaz üzeneteket fogadni és adni [14. ábra].

14. ábra - A TTL-RS232 konverter áramköri rajza és megvalósítása a próbapanelen

23

7.A hálózat tervezése Ebben a fejezetben a hálózat csomópontjainak szoftveréről esik szó. A programokat C nyelven írtam, melyet a Freescale CodeWarrior [15] nevezű integrált fejlesztőkörnyezetében készítettem. Ez a fejlesztőkörnyezet tartalmazza a szöveges C kód szerkesztőt, a linkert, a fordítót és a debuggert is. A MAC funkciók és a modem működésének menedzseléséhez az SMAC függvényeit [10] használtam. Az időzítők, perifériák konfigurálását a mikrokontroller adatlapja [8] alapján a megfelelő regiszterekbe történő írással oldottam meg. A kódolás előtt megterveztem a csomópontok működését, melyet az alábbiakban ismertetek.

7.1.A terjesztett üzenetek Az 5. fejezetben vázolt állapotokat egyszerű üzenetekből álló protokollal valósítottam meg. Az energiafogyasztás minimalizálása érdekében fontos volt, hogy az üzenetek a lehető legrövidebbek legyenek, ezért az üzenetek hosszát 4 byteban határoztam meg. Az első két byte a felhasználót azonosítja, a harmadik byte felső 4 bitje az üzenet típusát, az alsó 4 az üzenet számlálóját, a negyedik byte pedig az üzenet típusához tartozó értéket tartalmazza [15. ábra]. 0

7 user ID

15 user ID

23 message ID

31 value

15. ábra - Az üzenetek struktúrája

Az üzenet küldője és címzettje számunkra nem lényeges, a csomópontok ugyanis csak állapotokat terjesztenek. A felhasználó azonosítója 16 bites, tehát ez a protokoll 65536 hálózatot tud megkülönböztetni. Az üzeneteknek négy típusa van, NWK OFF, SET BALANCE, NORMAL és ALERT. Ezek az üzenettípusok jelentik a hálózat állapotait. A SET BALANCE állapothoz tartozik egy belső számláló a csomópontokban Ez ugyanis egy olyan állapot, amely egy olyan kötelező utasítást hordoz, melynek végrehajtásáról csak maga a csomópont tud. Ez a számláló alapértelmezett esetben nulla. Ha egy csomópont megkapja a SET BALANCE üzenetet és elvégzi a gyorsulásmérő kalibrálását, akkor belső számlálóját növeli és teszi ezt minden újabb SET BALANCE beérkezésekor.

24

Ilyenkor azonban a kalibrálást már nem végzi el. Ha az üzenet sorszáma elér egy kritikus értéket, akkor a csomópont onnantól kezdve a NORMAL állapotot terjeszti tovább.

7.2.A csomópontok energiafogyasztásának optimalizálása Az 16. ábrán látható a 802.15.4 adat keret formátuma [3]. Mint azt korábban említettem a 802.15.4 fizikai rétege 250 kb/s maximális átvitelre képes, ami átszámítva 31,25 kB/s, azaz 31,25 B/ms, amiből a megkapjuk, hogy egy byte átvitele a fizikai rétegnek 32 us-ig tart. A hasznos adaton felül a keretben 8 byte adatot a modem (az ábrán kék színnel), 2 byte adatot pedig az SMAC szolgáltat (az ábrán zöld színnel). A fizikai réteg mezői a vevő szinkronizációjához valamint a keret kezdetének és végének jelöléséhez szükségesek. Az SMAC 2 byte-ot foglal, ezen felül én 4 byte-ban határoztam meg az adatmező méretét, így egy csomag mérete összesen 14 byte.

16. ábra - A 802.15.4 adat keret

Így kiszámítható, hogy egy 14 byte hosszú csomag átvitele 448 us-ig tart. A 6. fejezetben kiszámoltam, hogy a modul a teljes idő 0,8 %-ában használhatja adóvevőjét. Ez azt jelenti, hogy 1000 ms alatt összesen 8 ms-ig lehet az adóvevő aktív. Ez esetünkben másodpercenként maximum 17,8 üzenet küldését jelentené. Számolnunk kell azonban az üzenetek vételével is. Az állapotokat hordozó üzenetek fogadásához a csomópontnak rendszeresen vételi üzemmódba kell kapcsolniuk adóvevőjüket. Ezért az alábbi elosztást dolgoztam ki [17. ábra]:

17. ábra - A normál csomópont optimális működésének állapotai az idő függvényében

25

Az első (adási) másodpercben minden csomópont 60 ms-onként küld üzenetet, azaz másodpercenként 16 darabot. A gyorsulásmérő értékeit kiolvasó és az egyéb működést végző normál állapotnak 9,2 % jutott, ami másodpercenként 92 ms-ot jelent. Az első másodpercben a csomópont minden küldés előtt 5 ms hosszan van ebben az állapotban, 60 ms-onként, másodpercenként 16-szor. A maradék 90 %-nak megfelelő 900 ms sleep állapot a maradék időréseket tölti ki. Ilyenkor a mikrokontroller csak néhány funkcióját tartja életben, valamint egy időzítőt, melynek lejártakor felébred. A számítás során az energiaigényesebb üzemmódoknál szándékosan lefele kerekítettem. így 16*5 is valójában csak 80 ms 92 helyett. A maradék időt mindig a sleep mód tesz ki. Az adás után meg kell terveznünk a vételi üzemmódot is. Ha a hálózatban csak két csomópont lenne, akkor 60 ms-on keresztül kellene vételi módba kapcsolni az adóvevőt ahhoz, hogy a csomópont biztosan elkapjon egy csomagot. Ha feltételezzük, hogy a csomópontok szinkronja véletlenszerű, akkor négy, egymás hatótávolságán belül lévő csomópont üzeneteit átlagosan 15 ms-onként hallja az éppen vevő csomópont. Tehát a hálózatban felételezett átlagos fokszám négy, ami 10-20 kaptárt véve egy körülbelül ezer négyzetméteres területen, 50-60 méteres hatótávolság mellett teljesül. Egyszerű számítással belátható, hogy két végpont maximális távolsága egy 33*33 m-es négyzetben 46 méter. Ahhoz, hogy a csomópontok egybefüggő 15 ms-ig tudjanak venni, a második másodpercben egyáltalán nem használják adóvevőjüket, csendben maradnak, a normál és a sleep mód váltogatják egymást. A harmadik másodpercre így át tudjuk vinni a másodikban megtakarított energiát, amikor is 16 ms-on keresztül kapcsoljuk vételi üzemmódba a modemet. A vételi ciklus egybefüggő, kezdetét véletlenszerűen állítja be a program a harmadik másodperc elején, így elkerülhető egyes csomópontok véletlen szinkronizálódása. Ezalatt a vevő csomópont átlagosan 0,25 üzenetet vesz, ha a környezetében csak egy csomópont van. A harmadik másodpercben vétel alatt folyamatosan működhet a mikrokontroller többi funkciója, utána 60 ms-onként 5 ms ideig lép normál állapotba.

26

7.3.A központ energiafogyasztásának optimalizálása A központ - ha csak az NCB modult nézzük - ugyanolyan csomópont mint a többi, egy különbséggel: más a működési idejével kapcsolatos elvárás. A 3.2.3 pontban leírtam, hogy a központot heti rendszerességgel kell feltölteni, az ehhez választott akkumulátor pedig 720 mAh kapacitású. Látható, hogy a csomópontra kiszámolt 1,112 mA-es fogyasztás 200 órán keresztül 322,4 mAh, tehát marad 497,6 mAh. Egy kis rátartással számolva vegyünk 450 mAh-t, ezt elosztva a 200 órával kijön, hogy 2,25 mA-nyi mozgásterünk maradt még, azaz összesen átlagosan 3,362 mA fogyasztás. A központ szempontjából ez azt jelenti, hogy 5 % adásvétel, 10 % normál működés és 85 % sleep mellett a fogyasztás 2,96 mA. Tehát 50 ms jut a modem használatára, 100 ms normál működésre és 850 ms sleepre [18. ábra].

18. ábra - A központ optimális működésének állapotai az idő függvényében

Ez azt jelenti, hogy a normál csomópontoknál bevezetett gyakoriságú üzenetküldés mellett 42 ms marad vételre. A központ is 60 ms-onként ad, de minden másodpercben 42 ms ideig vételi módba állítja a modemet. Ez azért fontos, mert ha a központot mozdítják el, azt azonnal érzékeli és ALERT állapotba vált, viszont a legfontosabb, hogy a központ értesüljön az elmozdítás tényéről, ami ezzel a megoldással nagyobb valószínűséggel biztosítható. Fontos hangsúlyoznom, hogy a fogyasztás optimalizálásánál a kiszámolt értékekhez képest mindig lefelé kerekítettem, így azok csak hozzávetőleges értékek.

7.4.A riasztási állapot hatása az üzenetek küldésére A 4. fejezetben említett kereszt réteg struktúra ebben a hálózatban ott kap szerepet, hogy a alkalmazási réteg, azaz a gyorsulásmérés és riasztás kezelés az üzenet küldését végző hálózati réteget sűrűbb üzenetküldésre utasítja. Ilyenkor már nem számít a fogyasztás, az elsődleges cél a riasztás mielőbbi eljuttatása a központba, onnan pedig a felhasználóhoz. 27

8.A hálózat szoftverének fejlesztése Az MC13123 mikrokontrollerre az SMAC által biztosított keretprogramot töltöttem fel. Ez egy minimális, bootloadert és inicializálást tartalmazó alapprogram. Ebből kiindulva fejlesztettem a csomópontok működését vezérlő szoftvert, melyet a lényeges elemeket kiemelve ismertetek.

8.1.A feladat időzítő Beágyazott rendszerekben általában fontos szempont, hogy a feladatok (taszkok) valós időben legyenek kiszolgálva. Ehhez úgynevezett valós idejű operációs rendszerek (RTOS - Real Time Operating Systems) használata szükséges, melynek alapja kis számítási kapacitással rendelkező, 8 illetve 16 bites mikrokontrollerek esetén egy egyszerű ütemező (scheduler). Ezt én a fejlesztés során egy nagyon egyszerű időzítéssel oldottam meg. Megfelelő értékekkel feltöltve a mikrokontroller számlálóhoz tartozó regisztereit [8], létrehoztam egy 1 ms periódusidővel futó órajelet, melyet az előző fejezetben leírt funkciók ütemezésére használtam. Az időzítő a mikrokontroller busz órajeléről fut, ami 8 MHz-es. Mivel ez nagyon gyors futás volna, leosztottam egy úgynevezett PRESCALER regiszter értékével, amit 128 ra állítottam [Függelék 5.], így a számláló már csak 62,5 kHz-en ketyegett. Ezután a MODULO regisztert 63-ra állítottam (0x3F), annak érdekében, hogy csak minden 63. órajelciklusra jelezzen az időzítő. Az interrupt vektorban a megfelelő helyre tettem a függvényemre mutató pointert, így kaptam egy 1 ms-onként periódikusan meghívódó függvényt, melyből egyszerűen lehet vezérelni az egyes funkciókat. A működést egy úgynevezett watchdog (őrkutya) figyeli, ami egy olyan időzítő, melyet periodikusan resetelni kell, ugyanis ha a program végtelen ciklusba kerül, a watchdog hiba állapotba kényszeríti a mikrokontrollert, mihelyst lejár az időzítője.

8.2.A gyorsulás mérése A csomópontok az elmozdulást, a kártyán található MEMS gyorsulásmérővel végzik és adott feltételek teljesülése esetén riasztást jelző üzeneteket küldenek tovább. A gyorsulásmérések elvégzéséhez szükséges egy gyorsulásmérő szenzor, valamint az általa mért értékeket digitalizáló analóg-digitális átalakító. 28

Az MC13213-as mikrokontroller tartalmaz egy beépített A/D átalakítót, mely nyolc csatornán képes digitalizálni a bemenetére érkező analóg jeleket. Mivel háromtengelyű gyorsulásmérőt használtam, egyszerre három A/D átalakítóra lett volna szükségem. Mivel az MC13213-ban csak egy darab van, szükség volt a csatornák működés közbeni váltogatására. Ez azt jelenti, hogy a három tengelyhez tartozó gyorsulás értékeket szigorú értelemben nem lehet valós időben egyszerre mintavételezni. Az A/D átalakító 8 bites funkcióját használtam, egyszeri mintavételezési lehetőséggel. Ez azt jelenti, hogy az AD átalakító nem folyamatosan szolgáltatja a digitalizált eredményeket, hanem kérésre végzi el a konverziót és visszaadja a konvertált értéket. A konverzió sikeres végrehajtását egy flag beállításával jelzi, mely feltétel teljesülését egy feltétel beiktatásával tudunk ellenőrizni. Az egyszeri mintavételezésnek esetünkben két előnyös tulajdonsága van. Az egyik az alacsonyabb fogyasztás, a másik pedig a fent vázolt architektúrábol fakadó igény a mintavételezési csatorna működés közben szükséges változtatására. A mintavételi időt (Ts) így az egyszeri mintavételezések között eltelt idő adta meg. Az AD átalakító konfigurálásához az alábbi regiszterek megfelelő feltöltésére volt szükség [Függelék 6.] [8]: ATD Control (ATDC) Register - Analóg-digitális vezérlő regiszter Ebben a regiszterben lehet az AD konvertert ki- és bekapcsolni (ATDPU), az adatok balra vagy jobbra igazítását, a felbontást (8 vagy 9 bit) és az előjelkezelést beállítani. Itt történik továbbá a mintavételi sebesség felkonfigurálása is, melyre a fent vázolt okok miatt nem volt közvetlenül szükségünk. ATD Status and Control (ATD1SC) – Analóg-digitális státusz és vezérlő regiszter Sok egyéb funkció mellett ez a regiszter szolgál a konverzió sikeres befejeződésének jelzésére. ATD Result Data Register (ATD1RH, ATD1RL) – Analóg-digitális eredmény regiszter A konverzió eredményét ezekben a regiszterekben tárolja el a mikrokontroller. Mivel 8 bites konverziót használtam, csak a kisebb helyiértékű biteket tartalmazó ATD1RL regiszterre volt szükségem. A soros porton való megjelenítéshez a bináris formában kapott mérési eredményeket át kellett alakítanom karakterekké. Ehhez az int2string függvény állt rendelkezésemre, ezt a funkciót tehát nem kellett külön elkészítenem. Mint arról korábban szóltam az egyszeri mintavételezéshez az ütemezést nekem kellett előállítanom. Az időzítés, az analóg- digitális konverzió és a soros port kezelése lehetővé tette a gyorsulás értékek mérését és vizualizálását. 29

19. ábra - A központ optimális működésének állapotai az idő függvényében

Az 19. ábrán látható a csomóponttal végzett gyorsulásmérés. Az adott tengelynek megfelelő küszöbérték átlépésekor jelez ALERT állapotot a modul. A gyorsulásmérőt az 1,5 g mérési tartományba állítottam. A mintavételi idő a gyorsulásmérőre 10 ms, azaz tengelyenként 30 ms volt.

8.3.Soros port használata A fenti ábra is a soros porton küldött mérések felhasználásával készült, így mindenképp említést kell tenni róla. Ez mikrokontrolleres platformok egyik legfontosabb interfésze, mivel a beágyazott eszközök gyakran nem rendelkeznek kijelzővel, vagy egyéb megjelenítővel. Ha a fejlesztés során bármiféle diagnosztikai információt vagy állapotot jelezni akarunk magunknak, akkor a legkézenfekvőbb megoldás, ha egy PC-re csatlakoztatjuk az eszközt és soros porton keresztül szöveges formában elküldjük ezeket az adatokat. Az MC13213 mikrokontroller két soros port egyidejű kezelésére képes [Függelék 7.] [8]. Mindkettő full duplex, tehát egyidejűleg venni és adni is képes. Az adás végét, az adási buffer ürességét és még néhány egyéb paramétert dedikált flagek jeleznek. A baud rate (szimbolum/sec) meghatározza az átvitel sebességét. A vonali kódolás órajelét is ehhez kell igazítani, ezért szükség van ennek

helyes beállítására. A működés során használt baud ratet az alábbi

képlettel kaphatjuk meg:

Baud Rate = BusCLK / (Baud Rate Register * 16) 30

A fejlesztés során 8 MHz-es busz órajelet és 38461 szimbólum/s-os baud ratet használtam. Ennek megfelelően konfiguráltam fel ezt a regisztert, azaz a Baud Rate Register értéke 13 volt.

8.3.1.GSM modem vezérlése soros porton keresztül A GSM modem vezérlése egy nyílt szabványú, soros porton bevitt parancskészlettel, az úgynevezett AT parancsokkal végezhető [14]. Az AT parancsok egyszerű szöveges üzenetek, céljuk, hogy az adott protokoll mélyebb megértése nélkül ugyan, de mégi biztonságosan hajtsunk végre magasszintű utasításokat a modemen. Mivel a saját GSM hardverem nem volt kész a Wavecom Fastrack M1306B elnevezésű ipari GSM modemet [20. ábra] használtam, amely rendelkezik SMA, soros port és tápcsatlakozóval, így egy GSM antenna, egy megfelelő táp és egy SIM kártya segítségével gyorsan fel tudtam éleszteni.

20. ábra - A használt Wavecom Fastrack GSM/GPRS modul

A modemet a próbapanelen összeállított kapcsoláson keresztül az NCB modul soros portjával kötöttem össze. A modem képes az adatátviteli sebességét a hozzá csatlakozó eszközéhez igazítani, így a két eszköz között az NCB-n beállított 38461-es baud rate mellett 8 adatbites, 1 stopbites, paritásbit nélküli, hardveres flow controllal jellemzett kapcsolattal kommunikáltam. Az AT parancsokkal való kommunikáció állapottgépes leírását a dokumentum terjedelmi korlátai miatt nem közlöm. A kommunikáció előtt néhány alapvető konfigurációs lépést el kell végezni. Ilyen többek között a SIM kártya autentikációja, a vételi jelszint ellenőrzése, az SMS központ beállítása és az eszköz regisztrálása a hálózaton. Ezeket nem a mikrokontrollernek kell intéznie, előtte PC-n keresztül is felkonfigurálható. A szükséges beállítások elvégzése után a következő parancsokkal lehet SMS-t küldeni: AT+CMGS=”+36......” 31

A telefonszám után elküldve az Enter-t, a következő karaktert küldi vissza a modem: > Ezzel a jellel vár a küldendő SMS szövegére, ami a következő sorba írandó, text formátumban. A szöveg beírása után a parancsot a hexa 0x1A karakterrel kell lezárni. Az NCB modullal elkészítettem az SMS küldö szubrutint [Függelék 8.].

8.4.Üzenetek küldése és vétele A rádiós üzenetek küldésére és vételére az SMAC alkalmas függvényeit használtam. A Függelék 9-ben található inicializálás után az időzítő függvény belsejébe helyeztem a csomópontokat kezelő függvényeket. A Függelék 10-ben található a program törzse, melyben láható az általam megtervezett 4 byte-os üzenetstruktúrája:

tx_data_buffer[0] = 0xAA; tx_data_buffer[1] = 0xBB; tx_data_buffer[2] = (app_status << 4) | msg_counter; tx_data_buffer[3] = Alert;

A küldést az MCPSDataRequest(&tx_packet) függvénnyel lehet végrehajtani, melynek argumentuma egy pointer, melyet inicializáláskor a tx_data_bufferre állítottam. Az időzítővel a tervezett szerint beállított működést az alábbi ábra szemlélteti:

21. ábra - A csomópont által küldött csomagok a sniffer programban

32

A 21. ábrán jól látható a küldött üzenetstruktúra, és a két másodperc hosszú szünet az adásban. Az egyik másodperc a “csend”, a másik pedig az, amikor a csomópont hallgatózik. Az ábrát a ZigbeeNetworkAnalyzer szoftverből [16] mentettem, amely egy sniffer hardver segítségével képes megjeleníteni a 802.15.4 fizikai, MAC rétegének, valamint a ZigBee jeleit. A harmadik, vételi másodperc elején vételi (RX) állapotba állítottam a modemet az MLMERXEnableRequest függvénnyel [Függelék 11.], amit aztán 16 ms-al később ki is kapcsoltam. Egy csomag beérkezésekor az alsóbb rétegből egy callback függvény hívja meg az üzenet vételét lekezelő függvényt. Az ALERT mezőt kiolvasva megállapítható, hogy az üzenet hordoz e riasztást és ha igen, akkor megtehetők a szükséges lépések annak továbbítására egy másik hálózat felé.

8.5.A sleep mode Az MC13213 [8] sleep módba a ‘stop’ assembly parancssal küldhető megfelelő regiszterek feltöltése mellett. Ilyenkor mikrokontroller kikapcsolja a perifériáit, az aritmetikai egységet, csak a RAM és az I/O portok maradnak aktívak. Sleep módból egy automatikus, előre beállított időzítő (Real Time Interrupt) ébreszti, így a periódikus alvás ébredés biztosítható.

8.6.A szoftver jelenlegi állapota A teljes szoftver fejlesztése még nem fejeződött be, de a csomópont állapotait vezérlő működés, az üzenetek adása, vétele, a gyorsulásmérés és riasztáskezelés, valamint a GSM modem soros porton történő vezérlése készen van. Hátra van még a központ működésének kialakítása, a sleep mód megvalósítása, a gyorsulásmérés előtti SET BALANCE implementálása, a NWK OFF állapot optimalizálása és a teljes rendszer átfogó tesztelése.

33

9.Összefoglalás, kitekintés Munkám során a feladatot egy méhkaptár riasztó célalkalmazás szemszögéből közelítettem meg. Rámutattam, hogy a széleskörben használt ipari szabvány, a ZigBee nem minden vezetéknélküli szenzorhálózat alkalmazáshoz biztosít optimális működést. Javaslatot adtam egy megoldásra és megterveztem a hálózatot, aminek funkcióit hardverközeli C nyelven programozható beágyazott eszközökön implementáltam, melyek egy részének fejlesztésében magam is részt vettem. Fontosnak tartom hangsúlyozni, hogy ugyan a munka alapötletéül egy célalkalmazás szolgált, kutatásom során olyan megoldási javaslatot tettem, ami általános esetben is használható olyan vezetéknélküli szenzorhálózatok tervezése esetén, melyek mindegyik csomópontja telepről üzemel. Jövőbeli terveim között a GSM hardver befejezése és a teljes szoftveres működés elkészítése szerepel. Továbbá szeretném a problémát általánosabban megfogalmazni és arra olyan megoldást adni, ami széleskörűen alkalmazható a vezetéknélküli szenzorhálózatok tervezésében.

34

10.Irodalomjegyzék [1] F. L. Lewis: Wireless Sensor Networks, Smart Environments: Technologies, Protocols, and Applications, New York, 2004 [2] Jamal N. Al-Karaki Ahmed E. Kamal: Routing Techniques in Wireless Sensor Networks: A Survey, IEEE Wireless Communications, 11(6):6-28, December, 2004 [3] IEEE 802.15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs), IEEE Computer Society, 8, September, 2006 [4] ZigBee Alliance: ZigBee Specification, 2007 [5] Xiaojun Lin, Ness B. Shroff, R. Srikant: A Tutorial on Cross-Layer Optimization in Wireless Networks, IEEE Journal on Selected Areas in Communications, August, 2006 [6] Miklós Maróti: Directed Flood-Routing Framework for Wireless Sensor Networks, Springer Berlin, Lecture Notes In Computer Science - Middleware 2004 [7] Hungarian Beekeeping, http://www.freeweb.hu/hunbee/ [8] Freescale Semiconductor: MC1321x, ZigBee Compliant Platform - 2.4 GHz Low Power Transceiver for the IEEE 802.15.4 Standard plus Microcontroller, Technical Datasheet, Rev1.2, May, 2007 [9] Freescale Semiconductor: MMA7260QT - ±1.5g - 6g Three Axis Low-g Micromachined Accelerometer, Technical Datasheet, Rev5, March, 2007 [10] Freescale Semiconductor: SMAC (Simple Media Access Controller) User’s Guide, Rev1.4, October, 2006 [11] SIMCom: SIM300DZ, Hardware Design, ver2.03, October, 2007 [12] Sandia National Laboratories: MEMS Technology Overview, http://mems.sandia.gov/tech-info/mems-overview.html [13] http://en.wikipedia.org/wiki/Path_loss [13] http://sodoityourself.com/max232-serial-level-converter [14] European Telecommunication Standards Institute: Digital cellular telecommunications system (Phase 2+), AT command set for GSM Mobile Equipment (ME), GSM 07.07, ver5.9.0, 1996 [15] Freescale Semiconductor: CodeWarrior Development StudioIDE 5.7 User’s Guide [16] Lengyel Zoltán: ZigBee hálózat analizátor fejlesztése (BME VIK, TDK dolgozat), 2007 [17] Dr. Kolumbán Géza, Tóth Csaba: Beágyazott rendszerek hálózati eszközei, BME VIK tantárgy, előadássorozat, 2008 [18] Jussi Haapola, Chiara Petrioli: Energy Efficient Wireless Sensor Network Protocols, Capturing Ambient Intelligence for Mobile Communications Through Wireless Sensor Networks, IST, Budapest, 2007

35

11.Függelék

Függelék 1. - A központ GSM modemet tartalmazó részének sematikus blokkvázlata

36

Függelék 2. - A központ NCB moduljának sematikus blokkvázlata

Függelék 3. - A központ GSM modemet tartalmazó részének sematikus blokkvázlata

37

Függelék 4. - A központ GSM modemet tartalmazó részének sematikus blokkvázlata

Függelék 5. - Az időzítő inicializálásához szükséges regiszterek feltöltése // Timer init void myTimerInit(void) {



TPM1SC_CLKSA = 1; // BUS CLK kiválasztása



TPM1SC_CLKSB = 0;



TPM1SC_TOIE = 1; // időzítő interrupt engedélyezése



TPM1SC_CPWMS = 0;



TPM1SC_PS = PRESCALER; //órajel leosztása a PRESCALERrel



TPM1MOD = 0x003F; //számláló modulus beállítása

}

38

Függelék 6. - A gyorsulásmérő inicializálásához szükséges regiszterek feltöltése // ADC init void myADCInit(void) {

ATD1C = 0xA8;



ATD1PE = 0b00011100;



ATD1SC = 0x22;



PTBDD_PTBDD2 = DDIR_INPUT;



PTBDD_PTBDD3 = DDIR_INPUT;



PTBDD_PTBDD4 = DDIR_INPUT;



PTBDD_PTBDD5 = DDIR_OUTPUT;



PTBDD_PTBDD1 = DDIR_OUTPUT;



PTBDD_PTBDD0 = DDIR_OUTPUT;



ACCEL_PS = 1;



ACCEL_GSELECT1 = 0;



ACCEL_GSELECT2 = 0;

}

Függelék 7. - A soros port interfész inicializálásához szükséges regiszterek feltöltése // SCI init void mySCIInit(void) {

SCI2C1 = 0x00;



SCI2C2 = 0x2C;



SCI2C3 = 0x00;



SCI2BDH = 0x00;



SCI2BDL = 0x0D;

}

39

Függelék 8. - Az SMS küldés szubrutinja

// SMS küldés soros porton keresztül while (app_status

== WAITING_FOR_GSM_STATUS)

{

(void) SCIgets((char*) "AT+CMGS=”+36303332244”, pp, 2);

while (!SCI2S1_TDRE);



SCI2D = 0x0D;

while (!SCI2S1_TC);



if (pp[0] == '>')



{





















SCITransmitString(“SMS Message”); while (!SCI2S1_TDRE);



SCI2D = 0x1A; while (!SCI2S1_TC);



app_status = STATUS_OK;

} } Függelék 9. - A modem inicializálása

tx_packet.u8DataLength = 4;

tx_packet.pu8Data = &tx_data_buffer[0];

rx_packet.u8DataLength = 16; rx_packet.u8MaxDataLength = 100;



rx_packet.u8Status = 0;









MCUInit();



RadioInit(); app_init();

myADCInit();

// ADC inicializalas - sajat beallitasok: "myInit.h"

myTimerInit(); // Timer inicializalas - sajat beallitasok: "myInit.h” mySCIInit(); // SCI inicializalas - sajat beallitasok: "myInit.h"



(void)MLMESetMC13192ClockRate(0); UseExternalClock(); EnableInterrupts; (void)MLMESetChannelRequest(CHANNEL_NUMBER); (void)MLMEMC13192PAOutputAdjust(MAX_POWER);

40

Függelék 10. - A csomópontok állapotait működtető függvény törzse

interrupt void Timer_1ms (void) { static unsigned long int timer1ms = 0; static unsigned int TaskTimer_60ms = 0; static unsigned int timer = 0; static unsigned int msg_counter = 0; static unsigned int ADC = 0; TPM1SC_TOF = 0; timer1ms++; TaskTimer_60ms++; if (timer1ms >= 3000) { // az 1000 kiadja az 1mp-et timer1ms = 0; timer++; while (!SCI2S1_TDRE); SCI2D = timer; //'\r'; ⁄J SOR while (!SCI2S1_TC); TPM1SC_TOF; } tx_data_buffer[0] = 0xAA; tx_data_buffer[1] = 0xBB; tx_data_buffer[2] = (app_status << 4) | msg_counter; tx_data_buffer[3] = Alert; if ((timer1ms >= 0) && (timer1ms <= 1000)) { if (TaskTimer_60ms == 60) { TaskTimer_60ms = 0; Alert =

0;

LED2 ^= 1; if (MCPSDataRequest(&tx_packet) == SUCCESS) LED2 ^= 1; timer = 0; } }

41

if ((timer1ms >= 2000) && (timer1ms <= 3000)) { if (timer1ms == 2000) { if (MLMERXEnableRequest(&rx_packet, 0) == SUCCESS); } if (timer1ms == 2016) { MLMERXDisableRequest(); } TaskTimer_60ms = 0; } if ((timer1ms > 1000) && (timer1ms < 2000)) { TaskTimer_60ms = 0; } }

Függelék 11. - Üzenetek vételére szolgáló callback függvény

// callback függvény a vételre, a kódban külön void MCPSDataIndication(tRxPacket *rx_packet) {

if (rx_packet->u8Status == SUCCESS)

{





if (rx_packet->pu8Data[3] == 1)





{







app_status = ALERT;





}





}





}

42