BELAMI_H5 ZIGBEE SZENZORHÁLÓZATOK ÉPÍTÉSE ÉS KEZELÉSE

Bay Zoltán

H-1116 Budapest, Fehérvári út 130.

1509 Budapest Pf. 53

Alkalmazott Kutatási

Tel.: (+36-1) 4630-500

Alapítvány

Fax: (+36-1) 4630-505

IKTI

BELAMI_H5 ZIGBEE SZENZORHÁLÓZATOK ÉPÍTÉSE ÉS KEZELÉSE - Műszaki jelentés -

Készítette: Szabó András Nagy Ákos Ruzsás Sándor Vajda Lóránt Török Attila Laborczi Péter

Budapest, 2007.05.17

BelAmI_H5: ZigBee Szenzorhálózatok Építése és Kezelése

TARTALOMJEGYZÉK 1.

BEVEZETŐ ................................................................................................................................................. 4

2.

ALKALMAZÁSI TERÜLETEK ............................................................................................................... 5

3.

A MUNKA KÖRNYEZETÉNEK ISMERTETÉSE................................................................................. 6

4.

3.1

ZIGBEE ALAPÚ SZENZORHÁLÓZATOK ................................................................................................... 6

3.2

AZ OSGI TECHNOLÓGIA ....................................................................................................................... 6

3.3

A MÉRÉSEK SORÁN HASZNÁLT ESZKÖZÖK: ......................................................................................... 10

AZ ELVÉGZETT MUNKA ÉS EREDMÉNYEK ISMERTETÉSE .................................................... 11 4.1

A BUNDLE-EK RÉSZLETEZÉSE ............................................................................................................. 14

4.1.1

A GUI bundle: ............................................................................................................................... 14

4.1.2

Az SQLProcessor bundle működése:............................................................................................. 20

4.1.3

Az XmlParser bundle működése:................................................................................................... 21

4.1.4

A MoteController bundle működése: ............................................................................................ 21

4.1.5

A LogFileMaker bundle működése: .............................................................................................. 22

4.1.6

A TopologyVisualiser bundle működése: ...................................................................................... 22

4.1.7

A ChartCreator bundle működése:................................................................................................ 22

4.1.8

A MessageSender bundle működése: ............................................................................................ 23

4.1.9

Eseménykezelés a programban: .................................................................................................... 24

5.

ELÉRT EREDMÉNYEK ÉS A JÖVŐBENI TERVEK ........................................................................ 27

6.

ÁBRAJEGYZÉK....................................................................................................................................... 28

7.

IRODALOM, ÉS CSATLAKOZÓ DOKUMENTUMOK JEGYZÉKE .............................................. 29

BZAKA-IKTI

AmI Project: H5

3.


1. BEVEZETŐ A dokumentum célja az Ipari Kommunikációs Technológiák Intézetében zajló Zigbee szenzorhálózatok témakörébe tartozó kutatások és fejlesztések aktuális állapotának leírása. Röviden ismerteti azokat a területeket és alkalmazásokat, ahol a kidolgozott rendszert hatékonyan alkalmazni lehet, aztán kitér a rendszertervre illetve a megvalósítási folyamatra, részletesen bemutatva a létrejött alkalmazást. A dokumentum végén a jövőbeni tervek és továbbfejlesztési irányok is bemutatásra kerülnek.

BZAKA-IKTI

AmI Project: H5

4.


2. ALKALMAZÁSI TERÜLETEK Napjainkban egyre nagyobb szerepet kapnak a minket szinte már mindenhol körülvevő intelligens eszközök. Egyre több adatot mérnek, dolgoznak fel és szolgáltatnak az irányunkban. Az adatok mennyisége növekvő mértéket mutat, ezzel együtt kezelésük és menedzselésük is egyre nagyobb problémákat okoz egy bizonyos mérték felett. Ezt a problémát kiküszöbölendő ambiens, intelligens szenzorhálózatok fejlesztése kezdődött meg számos helyen a világban. A szenzorhálózatok napjaink felhasználóinak elvárásai szerint vezeték nélküliek, biztosítva a felhasználóknak az elvárt mobilitást és rugalmasságot. Az intelligens szenzorhálózatok lehetséges felhasználási területei között találhatjuk a közlekedési és forgalomszabályozási feladatokat ahol maguk az autók is terjeszthetik akár egymás között például egy lehetséges forgalomtorlódás kialakulásának lehetőségét. Jelenleg azonban sokkal komolyabb fejlesztések kezdődtek az intelligens otthonok témakörében melyben a Németországi Fraunhofer Intézet és a Kaiserslautern-i Műszaki Egyetem mellett a Bay Zoltán Intézet is részt vesz. Megvalósítandó cél az intelligens támogatott életvitel (AmI Assisted living), ahol a házban található különböző szenzorok adatai alapján történjen a vezérlés, a biztonság ellátása és a távfelügyelet/távvezérlés. Lehetséges más területek raktározás, nyomkövetés, mezőgazdasági megfigyelés és biztonságtechnika. A lehetséges területeknek csak a csomópontokra csatlakoztatható szenzorérzékelők szabhatnak határt.

BZAKA-IKTI

AmI Project: H5

5.


3. A MUNKA KÖRNYEZETÉNEK ISMERTETÉSE 3.1

ZIGBEE ALAPÚ SZENZORHÁLÓZATOK Legjellemzőbb tulajdonságuk az önszerveződés (ad-hoc hálózatok) ezáltal az

érzékelési terület jóval nagyobb területre terjeszthető ki, mint a hagyományos esetekben ahol az összes csomópontnak közvetlenül kellett rálátnia a bázisállomásra. Esetünkben megoldott, hogy egy távoli csomópont átküldhesse a saját mérési adatait is a többi csomópont segítségével a bázisállomásra. Az ad-hoc hálózatok nem rendelkeznek központi adminisztrációval, így elkerülhető egy csomópont kiesése okozta összeomlás, mivel intelligensen önmagától képes új topológiát kialakítani a hálózat. Tetszőleges időpontban beés kicsatlakozhatnak a hálózatba. A topológia változására a hálózat képes automatikusan reagálni. Az egyes csomópontoknak adott hatósugárral bírnak és mivel nem biztos, hogy a bázisállomás hatósugarában vannak egy adott algoritmus segítségével a többi csomópont által meghirdetett üzenetek alapján szülőt választ és így biztosított a csomópontról csomópontra (hop-by-hop routing) történő átvitel. Mivel több csomóponton keresztül is haladhat egy üzenet ilyenkor ezek átjátszóállomásként üzemelve működnek. 3.2

AZ OSGI TECHNOLÓGIA Az OSGi Alliance hozta létre az Open Services Gateway initiative néven azt a közös

szolgáltatás platformot, amelynek a célja, hogy a sok különböző gyártó és fejlesztő egy közös megoldást találjon az interoperabilitás azaz az átjárhatóság és együttműködés kérdésére. Feladata, hogy a hálózati technikák egy közbenső rétegeként (lásd 1. ábra) kifelé csak szabványosított szolgáltatásokat biztosítsunk másoknak, és ők csak ezt lássák. Az, hogy a szolgáltatást belül mi hogyan valósítjuk meg az számukra érdektelen. A külvilággal való kommunikációra szabványosított interfészeket hozunk létre és ezeken kapunk kéréseket és biztosítunk szolgáltatást.

BZAKA-IKTI

AmI Project: H5

6.


1. ábra : Az OSGi rétegbeli elhelyezkedése

Az OSGi lényegét a framework biztosítja hiszen ez definiálja az alapszolgáltatásokat (Log, Configuration management, Preferences, Http Service (runs servlets), XML parsing, Device Access, Package Admin, Permission Admin, Start Level, User Admin, IO Connector, Wire Admin, Jini, UPnP Exporter, Application Tracking, Signed Bundles, Declarative Services, Power Management, Device Management, Security Policies, Diagnostic/Monitoring and Framework Layering.), amelyeket a mi programunk minden egyes része, csomagja használni fog, természetesen csak azokat amire szüksége van de vannak kötelezően előírt megvalósítandó részek is. A framework öt rétegből áll: biztonsági, modul, életciklus, szolgáltatás és aktuális szolgáltatások alrétegekből. A framework megvalósítja a teljes, dinamikus komponens modellt, ami nagy hiányossága a Java virtuális gépnek és környezetnek. Az alkalmazások és komponensek, amit itt csomagnak (bundle) hívnak távolból telepíthetőek, indíthatóak, megállíthatóak, kicserélhetőek (természetesen csak azonos interfész esetén) és felfüggeszthetők anélkül, hogy bármit is újra kellene indítanunk.

BZAKA-IKTI

AmI Project: H5

7.


2. ábra: Life cycle menedzsment

Az egyes csomagokat fizikailag Jar fájlok valósítják meg, amelyek tartalmazzák az adott csomag összes osztályát, annak működéséhez szükséges összes külső fájlt és egyéb külső csomagokat. A dinamikus komponens modell hatalmas előnye ennek a környezetnek, hiszen addig futó szolgáltatásokat nem kell leállítanunk, amivel rengeteg idő, munka és pénz spórolható meg. Ezt a szolgáltatást a framework életciklus (life cycle) menedzsmentje biztosítja [1][2][3]. Az activator lefutásával regisztráljuk a szolgáltatásunkat a framework-be a BundleContext tárolja ezeket és ha valakinek szüksége van egy szolgáltatásra az itt nézheti meg milyen szolgáltatások vannak már regisztrálva. Kötelezően megvalósítandó minden csomag esetén az interfész, ebben adhatjuk meg, hogy csomagunk milyen függvényeit milyen paraméterekkel kívánjuk felajánlani használatra más csomagoknak. Az egyes csomagokban ahol fel kívánunk használni egy más csomagbeli szolgáltatást akkor importálnunk kell az adott csomagot és csak utána válik hivatkozhatóvá válik a használandó függvénye. A

BZAKA-IKTI

AmI Project: H5

8.

BelAmI_H5: ZigBee Szenzorhálózatok Építése és Kezelése csomagok közötti esemény figyelést a ServiceListener-ek valósítják meg. Ezek egy bizonyos esemény bekövetkezése esetén üzenetet küldenek a framework-nek. A másik csomagban szűrőket tudunk definiálni, hogy az általunk kívánt esemény üzenetét elkapjuk és ezt feldolgozva valamilyen választ adhatunk rá vagy elindíthatunk valamit. Az általunk írt programban a grafikus felhasználói felületen végrehajtott események hatására például egy gomb lenyomására hajtódik végre egy szolgáltatás meghívása egy szövegdobozból kiolvasott időpont paraméter meghívásával. A grafikus felület tehát összefogja és keretet biztosít a különböző paraméterek beállításának és ezek átadásával történik az egyes szolgáltatások meghívása. Ezek

a bejövő paraméterekkel végrehajtják a feladatukat és visszaadják a

feldogozott eredményeket akár panelként, fájlként a grafikus felületnek.

BZAKA-IKTI

AmI Project: H5

9.


3.3

A MÉRÉSEK SORÁN HASZNÁLT ESZKÖZÖK:

IBM ThinkCentre PC WindowsXP operációs rendszerrel IBM ThinkPad T42P noteszgép WindowsXP operációs rendszerrel IBM ThinkPad T60 noteszgép WindowsXP operációs rendszerrel Minden számítógépen megtalálható volt az ingyenes Eclipse JAVA fejlesztői környezet és az Eclipse-hez fejlesztett OSGI szolgáltatás platform. A GUI szerkesztésre a Jigloo editorját használtuk. Crossbow eszközök [5]: •

1db MIB520 USB interfész kártya + USB kábel,

•

5 db MPR2400CA programozó kártya

•

4 db MTS310 szenzor kártya

•

1 db Crossbow Stargate

•

LinkSys router

3. ábra: MPR2400CA programozó kártya

BZAKA-IKTI

AmI Project: H5

4. ábra: Crossbow Stargate

10.


4. AZ ELVÉGZETT MUNKA ÉS EREDMÉNYEK ISMERTETÉSE A használt Crossbow eszközök mind a ZigBee Alliance által létrehozott filozófián alapuló eszközök. Ezek a 802.15.4 fejlesztői szabványon alapulnak amelyneka a célja, hogy egy alacsony költségű, flexibilis, alacsony fogyasztású otthoni kis adatmennyiségű, ad-hoc önszerveződő hálózatot tudjunk megvalósítani. Nagyon felkapottak azok a rádiós szenzor hálózatok, amelyek a ZigBee szabványon alapulnak (ezek a típusú hálózatok most törnek be a piacra és valószínüleg a Bluetooth-nál sokkal nagyobb körben el fognak terjedni). Az intézetben kialakított szenzorhálózati struktúra több rétegű (lásd 5. ábra).

5. ábra: A szenzorhálózati struktúra

A legalsó szinten helyezkednek el maguk a csomópontok (node-ok), amelyekre egy 51 pólusú csatlakozósor segítségével különböző környezeti paramétereket mérni képes szenzorlapkákat tudunk csatlakoztatni. Esetünkben az MTS310 típus hőmérsékletet, fényt, hangnyomásszintet és a saját akkumulátorainak a tápfeszültségét képes mérni. Minden egyes csomópontra feltöltöttük az USB-s interfészkártya segítségével az XMesh programot, amely képes felépíteni az önszerveződő hálózatot és ezen a szenzorkártya által mért adatokat elküldeni. A csomópontokat a folyósón és különböző szobákba helyeztük el. A következő szintet a Stargate jelenti, amely gateway-ként viselkedik az IP hálózat felé. A Stargate-en helyezkedik el egy csomópont, ami a bázisállomás, mivel ez fogadja a szenzorhálózatok felől

BZAKA-IKTI

AmI Project: H5

11.

BelAmI_H5: ZigBee Szenzorhálózatok Építése és Kezelése érkező nyers adatcsomagokat. Az átjáró maga egy PC-ként is értelmezhető, mivel egy beágyazott Linux fut rajta. Így lehetőségünk nyílik a CF kártyáról programokat futtatni, amelyek segítségével a nyers adatokat feldolgozhatjuk és szabványos formában (például: XML folyamként) továbbíthatjuk az IP hálózatba. Futtathatunk rajta SQL adatbázis szervert (például: PostgreSQL), ami a mért értékeket elmenti a CF kártyára így azok bármikor lekérdezhetővé válnak. Az átjáró a szobában található útválasztóra volt kötve és ezen keresztül voltak elérhetőek az kliens számítógépnek. Első célunk az volt, hogy a megvalósított kliens oldali felhasználói monitorozó és vezérlő programot annak nagyfokú mérete és bonyolultsága miatt egy szabványosított szolgáltatási platformra ültessük. Az ablakos felületű, könnyen kezelhető programunk a Stargate által küldött XML adatfolyam feldolgozásán és SQL adatbázis lekérdezéseken alapul, ezekből nyerjük ki a szenzorok által mért értékeket, melyeket a felhasználó számára emészthető formájú struktúrává alakítunk (grafikonok készítése, SQL adatbázis tartalmának kiíratása Excel fájlba, mérési értékek email-ben vagy SMS-ben történő elküldése megadott címre, szenzorok egymás közti kommunikációs útvonalainak gráf-szerű kirajzolása, később részletesen lesz szó mindegyik funkcióról). A programunk továbbá képes arra is, hogy a mért értékek előre definiált határérték átlépése esetén figyelmeztető üzenetet küldjön email vagy SMS formájában, vagyis felügyeleti funkciókkal is rendelkezik. Mindezeken kívül kétirányú kommunikáció is megvalósítható a stargate és a program között, vagyis XML formában parancsokat

továbbíthatunk

az

egyes

szenzorok

felé.

(szenzorokon

levő

led-ek

ki/bekapcsolása, pillanatnyi állapotlekérdezés) A szolgáltatási platformra ültetéshez a már meglévő program egyes funkcióit jól szét kellett választani és ezeket, mint szolgáltatásokat kellett tudnunk biztosítani egy grafikus felhasználói interfészen keresztül. Ennek a szolgáltatás-biztosítás alapú gondolatmenetnek kiválóan megfelel az említett OSGI keretrendszer. A programunk struktúrája jól követhető az alábbi ábra alapján (6. ábra).

BZAKA-IKTI

AmI Project: H5

12.


6. ábra: A programunk általános blokkvázlata

Mint látható, minden egyes funkcióért egy külön bundle felelős, melyek egymás közti kommunikációja az OSGI framework-ön belül történik, vagyis a framework ezt nagyrészt elrejti előlünk. A felhasználóval való kommunikációért a GUI bundle a felelős, ami azt jelenti, hogy a felhasználó az ablakos felületen keresztül éri el a program nyújtotta szolgáltatásokat. A stargate-tel való kommunikáció két részre osztható: Mint fentebb említettük, a Stargate egyrészről XML-ekben küldi a szenzorok aktuális mérési értékeit: ezek fogadását, feldolgozását, és továbbítását a program többi bundle-je felé az XML Parser bundle végzi; másrészről a Stargate a beérkező mérési eredményeket idő szerinti sorrendben egy SQL adatbázisban tárolja, az ebből való lekérdezést, adatstruktúra-konverziót és továbbítást az SQL Processor bundle végzi. A MoteController bundle a GUI bundle-től kapott információk alapján XML-eket állít össze és továbbít a stargate-felé, lehetővé téve a szenzorok vezérlését az ablakos felületről. A LogFile Maker bundle a megadott határok és szűrési feltételek mellett az SQL Processor által az adatbázisból lekérdezett információkat Excel fájlba írja ki. A TopologyVisualiser bundle a beérkező XML folyam alapján rekonstruálja a szenzorok egymás közti adattovábbítási útvonalait, és ezt gráf-szerűen megjeleníti az ablakos felületen. A ChartCreator bundle az XML folyam és az adatbázis alapján egyaránt képes diagramot készíteni, ezt fájlba kiírni, vagy megjeleníteni. Végül a MessageSender bundle végzi a GUI bundle által kért email vagy SMS-ek létrehozását és ezek továbbítását az SMTP szerveren vagy az SMS átjárón keresztül.

BZAKA-IKTI

AmI Project: H5

13.

BelAmI_H5: ZigBee Szenzorhálózatok Építése és Kezelése 4.1

A BUNDLE-EK RÉSZLETEZÉSE

4.1.1

A GUI bundle: A GUI (Graphical User Interface) a program grafikus kezelői felülete. Ezen a kezelői

felületen keresztül érhető el az összes funkció. Működés közben a következő képen látható:

7. ábra: A kezelői felület (GUI)

A GUI látható és nem látható összetevői a következők: •

a főkeret

•

a menüsor az indító gombokkal és a logoval

•

az E-mail és telefonszám beviteli mező

•

a lapokra osztott funkció mező

•

a szöveges kimeneti mező

•

a topológia megjelenítő mező

•

a beállítások megadására szolgáló ablak

BZAKA-IKTI

AmI Project: H5

14.

BelAmI_H5: ZigBee Szenzorhálózatok Építése és Kezelése A bundle összetevőit külön osztályokban valósítottuk meg ezek az alábbiak: 1. Activator 2. ChartCreatorJPanel 3. ChartDisplayFrame 4. DirectAccessJPanel 5. EmailOrSMSInputPanel 6. IMotaAppMainFrame 7. MainMenuBar 8. MoteAppMainFrame 9. MoteControllerJPanel 10. RuntimeChartCreatorJPanel 11. SettingsPanel 12. VariableContainer 13. VehicleAccesJPanel 14. WarningAccessJPanel

Ezek az osztályok a az alábbi feladatokat látják el: 1. Activator: A bundle elindulásakor fut le automatikusan. Megkeresi és beregisztrálja, ezzel önmaga számára elérhetővé és használhatóvá teszi a futó bundle-eket. Figyeli a bundle-ek regisztrációs üzeneteit és ha épp működni kezdő bundle-t talál akkor azt azonnal regisztrálja. 2. ChartCreatorJPanel: Erről a panelről érhető el a GUI grafikon készítő funkciója:

8. ábra : A grafikon készítő panel

BZAKA-IKTI

AmI Project: H5

15.

BelAmI_H5: ZigBee Szenzorhálózatok Építése és Kezelése 3. ChartDisplayFrame: Ez az osztály a mérési grafikonok keretezését végzi. Átveszi a ChartMaker által készített JPaneleket és egy lapozható keretben megjeleníti őket a képernyőn. 4. DirectAccessJPanel: Ezen a részen lehet a mote-okhoz közvetlenül hozzáférni. Itt egy legördülő menüből kiválaszthatjuk a kívánt node sorszámát az épp működők közül, majd egy másik menüből a mérni kívánt mennyiséget, esetünkben a Temperature, Voltage, Light, Volume, All values értékek egyikét.

9. ábra: A közvetlen hozzáférés panel

5. EmailOrSMSInputPanel: Ezen a panelen megadhatjuk a telefonszámot ahova SMS-t illetve az e-mail címet ahova e-mailt akarunk küldeni. A checkboxokban kiválaszthatjuk, hogy melyik küldési szolgáltatást akarjuk igénybe venni. A beállítás sikeréről visszajelzést kapunk.

10. ábra : A telefonszám és email cím beviteli panel

6. IMotaAppMainFrame: A bundle interfésze, ahol a szolgáltatásait definiálja. 7. MainMenuBar: Ez a menüsort megvalósító osztály. Innen lehet elérni a beállítások panelt, valamint elindítani az XML feldolgozást, valamint a topológia megjelenítést. A menüsor jobb szélén az alapítvány emblémája látható.

11. ábra: A főmenű sáv

BZAKA-IKTI

AmI Project: H5

16.

BelAmI_H5: ZigBee Szenzorhálózatok Építése és Kezelése 8. MoteAppMainFrame: Ez a fő keret. Alapvetően jobb- és baloldalra bomlik. Jobb oldalon a topológia megjelenítés helyezkedik el:

12. ábra: A topológia megjelenítő panel

9. MoteControllerJPanel: Ezen a részen a mote-ok felé irányuló műveletek végezhetők. A két megvalósított parancs a mote-okon elhelyezett ledek villogtatása és a beállítások lekérdezése.

13. ábra: Mote vezérlő panel

BZAKA-IKTI

AmI Project: H5

17.

BelAmI_H5: ZigBee Szenzorhálózatok Építése és Kezelése A lekérdezésre érkezett válasz:

14. ábra: Mote lekérdezésre adott válaszpanel

10. RuntimeChartCreatorJPanel:

A

folyamatosan

frissülő

grafikonok

készítésének

elindításáért felelős egység. Itt egy kezdeti időponttól megvalósuló SQL lekérdezés után létrejött, folyamatosan frissülő grafikon az eredmény.

15. ábra: SQL lekérdezésen alapuló grafikon készítése a mért értékekből

BZAKA-IKTI

AmI Project: H5

18.


16. ábra: A mért hőmérsékleti adatok megjelenítése egy grafikonon

11. SettingsPanel: Ez az osztály valósítja meg a funkciók paneljeit összefogó lapozható részt. 12. VariableContainer: Ennek az osztálynak a példányában tárolódnak a működéshez szükséges változók. 13. VehicleAccesJPanel: Ezen a részen van megvalósítva a lánctalpas autó működésének demonstrációjára szolgáló panel:

17. ábra: A lánctalpas autó vezérlésére szolgáló panel

14. WarningAccessJPanel: Ezen a panelon be lehet állítani két határértéket, egy mote sorszámot és egy mérési formát. A Start gombra kattintva egy programfutási szál jön létre,

BZAKA-IKTI

AmI Project: H5

19.

BelAmI_H5: ZigBee Szenzorhálózatok Építése és Kezelése ami a beállítások szerint e-mail vagy SMS-t küld, ha a szenzoron mért érték kilép a korlátok közül.

18. ábra: Figyelmeztető üzenetet küldő panel

4.1.2

Az SQLProcessor bundle működése:

Az SQLProcessor bundle interfészében definiált szolgáltatások: •

setSQLQuerryParameters: Feladata az SQL adatbázis lekérdezéséhez szükséges általános paraméterek beállítása, úgymint szerver IP, szerver Port, adatbázis-név, felhasználó, és jelszó.

•

dataQuerryInList: Feladata végrehajtani az SQL lekérdezést a megadott kezdeti és végérték között, szűrési feltételként pedig meg kell adni a választott szenzor ID-t.

•

dataQuerryIn2DArray: Feladata végrehajtani az SQL lekérdezést a megadott kezdeti és végérték között, és konverzió kétdimenziós sztring-többé.ú

•

dataQuerryInResultSet: Feladata végrehajtani az SQL lekérdezést a megadott kezdeti és végérték között, visszatérési érték pedig ResultSet.

•

NodeIdQuerryInList: Feladata végrehajtani az SQL lekérdezést a megadott kezdeti és végérték között, visszatér azon szenzorok listájával melyek a megadott értékek között jelen voltak a rendszerben.

BZAKA-IKTI

AmI Project: H5

20.

BelAmI_H5: ZigBee Szenzorhálózatok Építése és Kezelése 4.1.3

Az XmlParser bundle működése:

Az XmlParser bundle interfészében definiált szolgáltatások: •

setServerHost: Feladata beállítani a Stargate IP címét és portját az XML stream fogadásához.

•

startParsingXmlDataStream: Feladata elindítani az XML csomagok érkezését figyelő szálat.

•

stopParsingXmlDataStream: Feladata leállítani az XML csomagok érkezését figyelő szálat.

•

parseResponseXml: Feladata elindítani azt a szálat mely figyeli a XML csomag érkezését, mely a MoteController bundle által küldött csomagra válaszként érkezik.

•

getPacketVector: Metódus, mely arra szolgál, hogy a beérkezett XML csomagokat tároló listát elérhetővé tegye a program többi bundle-je számára.

•

getResponsePacket: Metódus, mely arra szolgál, hogy a MoteController bundle által küldött csomagra érkezett válasz csomagot elérhetővé tegye a program többi bundle-je számára.

4.1.4

A MoteController bundle működése:

A MoteConroller bunlde interfészében definiált szolgáltatások: •

sendToggleLedRequest: Feladata egy olyan XML összeállítása a megadott paraméterek alapján, melyet a stargate-hez elküldvén az továbbít a megfelelő szenzor felé, és szenzoron levő led-ek egyikét be-, vagy kikapcsolja.

•

sendConfigQuerry: Feladata egy XML csomag összeállítása a megadott paraméterek alapján, ezt a stargate-hez elküldvén az továbbít a megfelelő szenzor felé, és az válaszként egy olyan XML csomagot küld, mely tartalmazza a szenzor pillanatnyi mérési értékeit és egyéb tárolt paramétereit.

BZAKA-IKTI

AmI Project: H5

21.


A LogFileMaker bundle működése:

A LogFileMaker bunlde interfészében definiált szolgáltatások: •

writeSQLToLogFile: Hívás után az SQLProcessor bundle-höz fordul, mely lekérdezést hajt végre a megadott kezdeti és végértékek alapján és a visszaadott adatbázist e metódus excel fájlba kiírja a megadott fájlnévre és elérési útra.

4.1.6

A TopologyVisualiser bundle működése:

A TopologyVisualiser bundle interfészében definiált szolgáltatások: •

setDisplaySize: Feladata a megadott paraméterek alapján beállítani a rajzolási ablak méreteit.

•

newVisualisation: Feladata egy új vizualizáció elindítása. Ennek hatására az eredeti rajzolási ablak és a belső változók törlődnek (feltéve ha volt, vagyis ha ez nem az első elindítás), és a beérkező XML csomagok alapján elkezdi a kirajzolni kívánt gráf felépítését.

•

getJApplet: Feladata, hogy a rajzolási ablakot elérhetővé tegye a többi bundle számára (jelen esetben ezt a GUI bundle fogja használni).

4.1.7

A ChartCreator bundle működése:

A ChartCreator bundle interfészében definiált szolgáltatások: •

createChartsFromSQLToJPG: Feladata, hogy végrehajtasson egy SQL lekérdezést az SQLProcessor bundle-lel, a megadott kezdeti és végértékek alapján a megadott szenzor ID-ra vonatkozó szűrési feltétellel, a kapott adatok alapján létrehozzon egy diagramot, és ezt a kívánt fájlnév és elérési út alapján elmentse.

•

createChartsFromSQLToJPanel: Feladata, hogy végrehajtasson egy SQL lekérdezést az SQLProcessor bundle-lel, a megadott kezdeti és végértékek alapján a megadott szenzor ID-ra vonatkozó szűrési feltétellel, a kapott adatok alapján létrehozzon egy diagramot és ezt egy ablakra ráhelyezze, mely így elérhetővé válik a program többi bundle-je felé ( jelen esetben ezt a GUI bundle fogja használni).

BZAKA-IKTI

AmI Project: H5

22.

BelAmI_H5: ZigBee Szenzorhálózatok Építése és Kezelése •

updateChartsFromXmlToJPanel:

Feladata,

hogy

az

XmlParser

bundle

által

feldolgozott csomagok alapján frissítse a kívánt diagramokat, vagyis az új értékeket hozzáfűzze az eredetihez.

4.1.8

A MessageSender bundle működése:

A MessageSender bundle interfészében definiált szolgáltatások: •

setEmailAddressingParameters: Feladata a megadott paraméterek alapján beállítani az SMTP szerver email küldéséhez szükséges paramétereit.

•

setSMSGatewayParameters: Feladata a megadott paraméterek alapján beállítani az SMS Gateway sms küldéséhez szükséges paramétereit.

•

setSMSPhoneNumber: Feladata a megadott paraméter alapján beállítani az sms küldéshez szükséges telefonszámot.

•

sendMeasurementResultMessage: Feladata, hogy a legutoljára érkezett XML csomagból létrehozza a kívánt üzenetet email, SMS vagy mindkettő formájában és ezeket az előzőleg beállított SMTP szerveren, vagy SMS gateway-en keresztül elküldje.

•

sendWarningMessage: Feladata, hogy riasztás esetén (ami akkor történik, ha a beállított szenzor adott mérési értéke túllép egy előre beállított határt- GUI bundle gondoskodik erről) létrehozza a kívánt üzenetet email, SMS vagy mindkettő formájában és ezeket az előzőleg beállított SMTP szerveren, vagy SMS gateway-en keresztül elküldje.

BZAKA-IKTI

AmI Project: H5

23.


Eseménykezelés a programban:

A programban használt események és ezeknek kezelését három csoportra lehet osztani: •

Bundle-ök közti interakció (események segítségével egyszerű, tartós összekötés mentes üzenetváltás lehetséges két Bundle között)

•

Bundle-ön belüli eseménykezelés (itt most a javax.swing package által nyújtott automatizált eseménykezelést értjük)

•

OSGI saját automatizált eseményei

Bundle- ök közti interakció: Az OSGI keretrendszer (lásd 3.2 –es pont) jól körülhatárolja azokat a lehetőségeket, melyekkel a bundle-ök közti interakció megvalósítható. Ezzel biztosítja a modularitást, mely szükséges ahhoz, hogy a szolgáltatások külön-külön is menedzselhetőek legyenek, mely alappillére

az

egész

rendszer

globális

menedzsmentjének.

Ezt

a

filozófiát

(és

programozástechnikai kötöttségeket) szem előtt tartva a bundle-ök közti interakció megvalósításakor a következő szempontokra figyeltünk: •

Bundle által nyújtott szolgáltatások annak interface-ében definiálva vannak, más Bundle-ből

csak

az

interface-en

keresztül

hívunk

meg

szolgáltatásokat

(programozástechnikailag: Bundle bármely osztályának metódusait csak az interfaceen keresztül lehet meghívni.) •

Közvetlen

metódushívást

egyáltalán

nem

használtunk,

így

elkerülhető

a

változóátadással járó összedrótozás ( ugyanis a Java a változóra mutató pointert ad át, melyen ha változtatunk a hívó fél oldaláról, változás történik a hívott oldalon is). •

Eventek segítségével kommunikálhat két Bundle amennyiben a küldő fél egyben EventAdmin is, vagyis joga van a Framework-ön keresztül Event-öt küldeni. Ekkor az üzenni kívánó fél megfogalmaz egy üzenetet ( programozástechinkailag: létrehoz egy Event példányt adott néven, adott tulajdonságokkal (properties)), és azt a Frameworkön keresztül elküldheti. Mindazon Bundle-ek, akik EventHandler-ek is egyben, figyelhetik a küldött üzeneteket, és azok közül megadott tulajdonságúakra (properties) reagálhatnak. Ilyen módon például Xml csomag érkezésekor az XmlParser bundle Event-et küld a többi Bundle felé, hogy jelezze az új csomag érkeztét. Erre a TopologyVisualiser Bundle reagál, és frissíti a hálózat topológiáját.

BZAKA-IKTI

AmI Project: H5

24.

BelAmI_H5: ZigBee Szenzorhálózatok Építése és Kezelése Bundle-ön belüli eseménykezelések: Az eseménykezelés azonban nem csak Bundle-közi interakcióban játszik szerepet, hanem egy adott Bundle belső működésében is. A javax.swing csomag osztályai lehetőséget nyújtanak ablakos keretrendszerek készítésére, az alapoktól (pl JFrame- egy ablak létrehozása) kezdve legördülő menükig, fejlécekig; széles választékát nyújtják a formázásnak, testreszabásnak, stb. Minthogy a készített programunk ablakos felületű, a csomag nyújtotta lehetőségeket mi is kihasználtuk. Ehhez kapcsolódik, hogy az egérkezelés szintén beépített funkcióként jelenik meg, és a mozgatás, bal-jobb kattintás teljesen automatizálva van; kifelé eseményként látjuk mindezt. Amikor egy gombra kattintunk, automatikusan esemény küldődik, nekünk csak azzal kell foglalkoznunk, hogy ki legyen az, aki ezt figyeli és mit reagáljon rá. Néhány példa a teljesség igénye nélkül, ahol ez konkrétan megjelenik: •

WindowEvent: mindazon történések, melyek az ablak nagyításával, kicsinyítésével, bezárásával, tálcára helyezésével, stb kapcsolatosak WindowEvent- ként szereplnek ( vagyis pl. teljes képernyőre váltáskor automatikusan WindowEvent küldődik.) Az ablak megjelenítéséért felelős MoteAppMainFrame-ben erre egy listener van definiálva, mely pl. az ablak bezárásakor szükséges teendőket elvégzi.

•

ActionEvent: Egérkattintáskor automatikusan megvizsgálódik, hol klikkeltünk, és amennyiben olyan helyen, ahol erre külön figyelőt helyeztünk el (ActionListener), ActionEvent

küldődik

a

Listener

számára,

amire

különböző

reakciókkal

válaszolhatunk.

BZAKA-IKTI

AmI Project: H5

25.

BelAmI_H5: ZigBee Szenzorhálózatok Építése és Kezelése OSGI Framework, bundle, és szolgáltatás események: Az OSGI keretrendszer saját, beépített eseménykezeléssel is rendelkezik, melyek küldése csakúgy, mint az előző pontban említett események teljesen automatizáltak. A felhasználó dolga a figyelők (FrameworkListener, BundleListener, ServiceListener) elhelyezése. 3 féle eseménytípus tartozik ide: •

Framework Events: A Framework működésével, életciklusával kapcsolatos történések, módosulások létrejöttével automatikusan ilyen Event küldődik. Többnyire több Framework egymás közti kommunikációjára használják, a mi programunk nem használja.

•

Bundle Events: A bundle életciklusával kapcsolatos történések, módosulásokra való reakció eszköze, szintén nem használjuk.

•

Service Events: Sokban hasonlít az előzőre, ám ez szolgáltatáscentrikus, vagyis a szolgáltatás életciklusában való változásokkor küldődik. Ennek három fajtája van: o Szolgáltatás regisztrálásakor ServiceEvent.REGISTERED típusú esemény küldődik, ennek hatására szerezhet tudomást a többi szolgáltatás, hogy mely új szolgáltatás került be a rendszerbe, és minderre reagálhat. (pl. SQLProcessor szolgáltatás

regisztrálódott,

ennek

hatására

esemény

küldődik,

és

LogFileMaker tudomást szerez minderről – innentől az SQL excel táblába logolásért felelős LogFileMaker elérhetővé teszi szolgáltatásait, melyek az SQL

feldolgozásáért

felelős

SQLProcessor

inaktív

állapotában

nem

elérhetőek). o Szolgáltatás megváltozásakor ServiceEvent.MODIFIED típusú esemény küldődik. (nem használjuk) o Szolgáltatás megszűnésekor ServiceEvent.UNREGISTERING típusú esemény küldődik ( hasonlóan a regisztrációnál említett példához: SQLProcessor szolgáltatás

megszűnésekor

a

LogFileMaker

megszűnteti

saját

szolgáltatásainak elérhetőségét, hiszen adatbázis hiányában ezek nem hajthatóak végre).

BZAKA-IKTI

AmI Project: H5

26.


5. ELÉRT EREDMÉNYEK ÉS A JÖVŐBENI TERVEK A program előző változata részt vett a múlt novemberben tartott Mobil Show2006-on, mint az intézet ambiens technológiáját bemutatató mintaprogram. Az új változatot a 2007 május 10. és 11. között tartott BelAmI Semi-Annual German-Hungarian Joint Workshop-on mutatkozott be. Jövőbeni tervünk a felhasználói grafikus interfész látványosabbá, illetve kezelhetőbbé tétele és a vezérlési funkciók kiterjesztése a szenzorokra. Ezen kívül elkezdődött a Stargate-en található szerver oldali program tervezése, hogy a meglévőt leválthassuk, illetve új funkciókkal bővíthessük. Ezt UPnP (Universal Plug and Play) alapokra akarjuk helyezni. Megvalósítanánk egy UPnP közvetítő eszközt ezt BOSS-nak hívják (Bridge of the Sensors) [6]. Ennek a funkciója, hogy XML üzenetekkel tudjuk vezérelni a nem UPnP módon menedzselhető szenzorhálózati csomópontokat.

BZAKA-IKTI

AmI Project: H5

27.


6. ÁBRAJEGYZÉK 1. ábra : Az OSGi rétegbeli elhelyezkedése............................................................................... 7 2. ábra: Life cycle menedzsment................................................................................................ 8 3. ábra: MPR2400CA programozó kártya................................................................................ 10 4. ábra: Crossbow Stargate....................................................................................................... 10 5. ábra: A szenzorhálózati struktúra......................................................................................... 11 6. ábra: A programunk általános blokkvázlata......................................................................... 13 7. ábra: A kezelői felület (GUI) ............................................................................................... 14 8. ábra : A grafikon készítő panel ............................................................................................ 15 9. ábra: A közvetlen hozzáférés panel...................................................................................... 16 10. ábra : A telefonszám és email cím beviteli panel............................................................... 16 11. ábra: A főmenű sáv ............................................................................................................ 16 12. ábra: A topológia megjelenítő panel .................................................................................. 17 13. ábra: Mote vezérlő panel .................................................................................................... 17 14. ábra: Mote lekérdezésre adott válaszpanel......................................................................... 18 15. ábra: SQL lekérdezésen alapuló grafikon készítése a mért értékekből .............................. 18 16. ábra: A mért hőmérsékleti adatok megjelenítése egy grafikonon ..................................... 19 17. ábra: A lánctalpas autó vezérlésére szolgáló panel ........................................................... 19 18. ábra: Figyelmeztető üzenetet küldő panel......................................................................... 20

BZAKA-IKTI

AmI Project: H5

28.


7. IRODALOM, ÉS CSATLAKOZÓ DOKUMENTUMOK JEGYZÉKE [1]

OSGi Service Platform Core Specification Release 4 version 4.0.1

[2]

OSGi Alliance honlapján található dokumentumok: http://www.osgi.org/

[3]

OSGi Alliance Developer Site: http://www2.osgi.org/Main/HomePage

[4]

OSGi Tutorial Step by step introduction to OSGi programming: http://www.knopflerfish.org/tutorials/osgi_tutorial.pdf

[5]

Crossbow website: www.xbow.com

[6]

UPnP-Based Sensor Network Management Architecture: http://www.ishilab.net/icmu2005/papers/117390-1-050228235605.pdf

BZAKA-IKTI

AmI Project: H5

29.

BELAMI_H5 ZIGBEE SZENZORHÁLÓZATOK ÉPÍTÉSE ÉS KEZELÉSE

Recommend Documents