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

Átírás

1 Bay Zoltán Alkalmazott Kutatási Alapítvány IKTI H-1116 Budapest, Fehérvári út Budapest Pf. 53 Tel.: (+36-1) Fax: (+36-1) 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,

2

3 TARTALOMJEGYZÉK 1. BEVEZETŐ ALKALMAZÁSI TERÜLETEK A MUNKA KÖRNYEZETÉNEK ISMERTETÉSE ZIGBEE ALAPÚ SZENZORHÁLÓZATOK AZ OSGI TECHNOLÓGIA A MÉRÉSEK SORÁN HASZNÁLT ESZKÖZÖK: AZ ELVÉGZETT MUNKA ÉS EREDMÉNYEK ISMERTETÉSE A BUNDLE-EK RÉSZLETEZÉSE A GUI bundle: Az SQLProcessor bundle működése: Az XmlParser bundle működése: A MoteController bundle működése: A LogFileMaker bundle működése: A TopologyVisualiser bundle működése: A ChartCreator bundle működése: A MessageSender bundle működése: Eseménykezelés a programban: ELÉRT EREDMÉNYEK ÉS A JÖVŐBENI TERVEK ÁBRAJEGYZÉK IRODALOM, ÉS CSATLAKOZÓ DOKUMENTUMOK JEGYZÉKE BZAKA-IKTI AmI Project: H5 3.

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

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

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

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

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

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

10 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 4. ábra: Crossbow Stargate BZAKA-IKTI AmI Project: H5 10.

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

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

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

14 4.1 A BUNDLE-EK RÉSZLETEZÉSE 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 é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.

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

16 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. OrSMSInputPanel: Ezen a panelen megadhatjuk a telefonszámot ahova SMS-t illetve az címet ahova t 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 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.

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

18 A lekérdezésre érkezett válasz: BelAmI_H5: ZigBee Szenzorhálózatok Építése és Kezelése 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.

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

20 ami a beállítások szerint 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 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.

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

22 4.1.5 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 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) 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.

23 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 A MessageSender bundle működése: A MessageSender bundle interfészében definiált szolgáltatások: set addressingparameters: Feladata a megadott paraméterek alapján beállítani az SMTP szerver 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 , 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 , 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.

24 4.1.9 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.

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

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

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

28 6. ÁBRAJEGYZÉK 1. ábra : Az OSGi rétegbeli elhelyezkedése ábra: Life cycle menedzsment ábra: MPR2400CA programozó kártya ábra: Crossbow Stargate ábra: A szenzorhálózati struktúra ábra: A programunk általános blokkvázlata ábra: A kezelői felület (GUI) ábra : A grafikon készítő panel ábra: A közvetlen hozzáférés panel ábra : A telefonszám és cím beviteli panel ábra: A főmenű sáv ábra: A topológia megjelenítő panel ábra: Mote vezérlő panel ábra: Mote lekérdezésre adott válaszpanel ábra: SQL lekérdezésen alapuló grafikon készítése a mért értékekből ábra: A mért hőmérsékleti adatok megjelenítése egy grafikonon ábra: A lánctalpas autó vezérlésére szolgáló panel ábra: Figyelmeztető üzenetet küldő panel BZAKA-IKTI AmI Project: H5 28.

29 7. IRODALOM, ÉS CSATLAKOZÓ DOKUMENTUMOK JEGYZÉKE [1] OSGi Service Platform Core Specification Release 4 version [2] OSGi Alliance honlapján található dokumentumok: [3] OSGi Alliance Developer Site: [4] OSGi Tutorial Step by step introduction to OSGi programming: [5] Crossbow website: [6] UPnP-Based Sensor Network Management Architecture: BZAKA-IKTI AmI Project: H5 29.