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) 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 TECHNOLÓGIAI ÁTTEKINTÉS ZIGBEE ALAPÚ SZENZORHÁLÓZATOK AZ OSGI TECHNOLÓGIA A MÉRÉSEK SORÁN HASZNÁLT ESZKÖZÖK: A KIDOLGOZOTT RENDSZER 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 ELÉRT EREDMÉNYEK ÉS A JÖVŐBENI TERVEK ÁBRAJEGYZÉK IRODALOM, ÉS CSATLAKOZÓ DOKUMENTUMOK JEGYZÉKE BZAKA-IKTI 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 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 illetve a támogatott életvitel (Assisted Living) témakörökben, melyben a Németországi Fraunhofer Intézet és a Kaiserslautern-i Műszaki Egyetem mellett a Bay Zoltán Alkalmazott Kutatási Közalapítvány Ipari Kommunikációs Technológiák Intézete is részt vesz. Megvalósítandó cél az intelligens támogatott életvitel (Ambient 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 5.

6 3. TECHNOLÓGIAI ÁTTEKINTÉS Ebben a fejezetben röviden ismertetésre kerül a kidolgozott rendszer főbb technológiái. Így az olvasó megismerkedhet a Zigbee szenzorhálózati vezetéknélküli technológiával, illetve a rendszer elkészítésének keretrendszerével, az OSGi alapjaival. A fejezet végén bemutatásra kerülnek a bemutatott rendszer egyes építőelemei. 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 technológiák egy közbenső rétegeként (lásd 1. ábra) kifelé csak szabványosított szolgáltatásokat biztosítsanak másoknak, és ők csak ezt lássák. Az, hogy a szolgáltatás a rendszeren belül hogyan kerül megvalósításra, az a külső felhasználó számára érdektelen. A külvilággal való kommunikációra szabványosított interfészek jönnek létre és ezeken kap a rendszer kéréseket és biztosít szolgáltatásokat. BZAKA-IKTI 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 (ilyenek pl.: 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.). Ezeket az alapszolgáltatásokat a mi programunk minden egyes része, csomagja használni fog. A szabványban definiált framework öt rétegből áll: biztonsági, modul, életciklus, szolgáltatás és aktuális szolgáltatások. BZAKA-IKTI 7.

8 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 2. ábra: MPR2400CA programozó kártya 3. ábra: Crossbow Stargate BZAKA-IKTI 8.

9 4. A KIDOLGOZOTT RENDSZER 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 amelynek célja, hogy egy alacsony költségű, flexibilis, alacsony fogyasztású, 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 4. ábra). 4. á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-nek nevezett speciális ipari PC jelenti, amely gyakorlatilag gateway-ként (átjátszó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 é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 BZAKA-IKTI 9.

10 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). Az alkalmazás 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 (5. ábra). Mint az ábrán is 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 továbbiakbn a rendszert alkotó modulokat bundle -öknek nevezzük (ez az elfogadott OSGi megnevezésük). 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. BZAKA-IKTI 10.

11 5. ábra: A programunk általános blokkvázlata A Stargate-tel való kommunikáció két részre osztható: a Stargate egyrészről XML csomagokban 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 bundleje felé az XML Parser bundle végzi; 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 csomagokat á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 11.

12 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ó: 6. á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 logóval 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 12.

13 A bundle összetevőit külön osztályokban valósítottuk meg: Activator ChartCreatorJPanel ChartDisplayFrame DirectAccessJPanel OrSMSInputPanel IMotaAppMainFrame MainMenuBar MoteAppMainFrame MoteControllerJPanel RuntimeChartCreatorJPanel SettingsPanel VariableContainer VehicleAccesJPanel 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: 7. ábra : A grafikon készítő panel BZAKA-IKTI 13.

14 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. 8. á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. 9. á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ó. 10. ábra: A főmenű sáv BZAKA-IKTI 14.

15 8. MoteAppMainFrame: Ez a fő keret. Alapvetően jobb- és baloldalra bomlik. Jobb oldalon a topológia megjelenítés helyezkedik el: 11. á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. 12. ábra: Mote vezérlő panel BZAKA-IKTI 15.

16 A lekérdezésre érkezett válasz: 13. á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. 14. ábra: SQL lekérdezésen alapuló grafikon készítése a mért értékekből BZAKA-IKTI 16.

17 15. á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: 16. á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 17.

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

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

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

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

22 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 kerül. Megvalósításra kerül egy UPnP közvetítő eszköz. Ennek a funkciója, hogy XML üzenetekkel tudjuk vezérelni a nem UPnP módon menedzselhető szenzorhálózati csomópontokat. BZAKA-IKTI 22.

23 6. ÁBRAJEGYZÉK 1. ábra : Az OSGi rétegbeli elhelyezkedése á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 23.

24 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: BZAKA-IKTI 24.