A biztonságtechnikai keretrendszer architektúrájának fizikai felépítése és egy mintarendszer
TARTALOMJEGYZÉK 1.
BEVEZETÉS.......................................................................................................................... 1
2.
LOGIKAI FELÉPÍTÉS (ARCHITEKTÚRA) ................................................................................. 2 2.1. AZ ÁTJÁRÓK ÉS A HOZZÁJUK KAPCSOLÓDÓ SZENZOROK ÉS BEAVATKOZÓK .................. 2 2.1.1. SZENZOROK .......................................................................................................... 2 2.1.2. BEAVATKOZÓK ...................................................................................................... 4 2.1.3. SZENZOR ÁTJÁRÓ (GATEWAY) ................................................................................ 4 2.1.4. ÁTJÁRÓ KOMMUNIKÁCIÓS ÁGENS (GCA – GATEWAY COMMUNICATION AGENT) ...... 4 2.2. A KÖZPONTI KOMMUNIKÁCIÓS ÁGENS, AZ ÁRNYÉK KOMMUNIKÁCIÓS ÁGENS ÉS A HOZZÁ TARTOZÓ ÁRNYÉK ÁGENSEK ........................................................................................ 5 2.2.1. KÖZPONTI KOMMUNIKÁCIÓS ÁGENS (CCA – CENTRAL COMMUNICATION AGENT)... 5 2.2.2. ÁRNYÉK KONFIGURÁCIÓS ÁGENS (SCA – SHADOW CONFIGURATION AGENT) .......... 5 2.2.3. ÁRNYÉK ÁGENSEK ................................................................................................. 6 2.3. A MESTERSÉGES INTELLIGENCIA (MI)........................................................................... 6
3.
FIZIKAI FELÉPÍTÉS ............................................................................................................... 7 3.1. A VEZETÉKES SZENZOROK, BÁZISÁLLOMÁS ÉS HÁLÓZATI GATEWAY ............................ 9 3.1.1. AZ ILLESZTŐKÁRTYA FELADATA .............................................................................. 9 3.1.2. AZ ILLESZTŐKÁRTYA FELÉPÍTÉSE ........................................................................... 9 3.1.3. A KÁRTYÁHOZ KAPCSOLHATÓ SZENZOROK ............................................................ 13 3.1.4. A KÁRTYÁHOZ KAPCSOLHATÓ BEAVATKOZÓ ESZKÖZÖK ......................................... 15 3.1.5. ÁTTEKINTÉS: A VEZETÉKESSZENZOROK KIMENETI JELSZINTJEI .............................. 15 3.2. A VEZETÉK NÉLKÜLI SZENZOROK ÉS HÁLÓZATI GATEWAY.......................................... 19 3.2.1. A VEZETÉK NÉLKÜLI BÁZIS ÁLLOMÁS .................................................................... 20 3.2.2. A VEZETÉK NÉLKÜLI SZENZOROK ......................................................................... 22
4.
MŰKÖDÉS ......................................................................................................................... 24 4.1. A VEZETÉKES SZENZOROK ÉS HÁLÓZATI GATEWAY .................................................... 24 4.1.1. AZ ÁTJÁRÓ .......................................................................................................... 24 4.1.2. AZ ÁTJÁRÓ KOMMUNIKÁCIÓS ÁGENS .................................................................... 33 4.2. A VEZETÉK NÉLKÜLI SZENZOROK ÉS HÁLÓZATI GATEWAY.......................................... 34 4.2.1. HÁLÓZAT ÉPÍTÉS(GLOBÁLIS KOMMUNIKÁCIÓ) ...................................................... 37 4.2.2. A DEFINÍCIÓS FÁJL .............................................................................................. 38 4.2.3. A VEZETÉK NÉLKÜLI HÁLÓZATI ÁTJÁRÓ ................................................................ 38 4.2.4. AZ VEZETÉK NÉLKÜLI ÁTJÁRÓ KOMMUNIKÁCIÓS ÁGENS FELÉPÍTÉSE ÉS MŰKÖDÉSE 41 4.3. SOFTWARE SZENZOROK ÉS HÁLÓZATI GATEWAY......................................................... 43 4.3.1. SZOFTVER SZENZOROK ÉS BEAVATKOZÓK ............................................................. 43 4.3.2. SZENZOROK ÉS BEAVATKOZÓK FAJTÁI .................................................................. 43 4.3.3. SZOFTVER SZENZOROK A TERVEZETT RENDSZERBEN .............................................. 44 4.3.4. SZOFTVER SZENZOR ÉS AZ ÁTJÁRÓ KOMMUNIKÁCIÓJA ........................................... 44 4.4. A KÖZPONTI KOMMUNIKÁCIÓS ÁGENS ÉS AZ ÁRNYÉK KONFIGURÁCIÓS ÁGENS ........... 45 4.5. AZ ÁRNYÉK ÁGENSEK ................................................................................................. 48
IRODALOMJEGYZÉK................................................................................................................... 50 MELLÉKLETEK .......................................................................................................................... 52
1. BEVEZETÉS A klasszikus felhasználási módtól eltérően a szenzorhálózatok nagy számú szenzor összekapcsolásával jönnek létre. Ezek térben egymástól különböző helyeken helyezkednek el, és egymással történő kommunikációjuk egy sor olyan területen történő alkalmazást tesz lehetővé, amelyekre korábban speciális hardver elemekre volt szükség. Szenzorok alatt olyan eszközöket értünk, amelyek segítségével a környezetünkből adatokat gyűjthetünk be és ezáltal figyelemmel kísérhetjük azok változását. Fő feladatuk az egyes folyamatok monitorozása, visszacsatolás, valamint a különböző speciális célokból történő adatgyűjtés. A mai rohamosan fejlődő és versenyalapú világban egyre nagyobb az igény az adatok valós-idejű begyűjtésére, értelmezésére, kiértékelésére, és ezek alapján történő minél gyorsabb és hatékonyabb döntéshozatalra. Az adatgyűjtés vezetékes szenzorok használatával több okból is nehézkes. A széles körben való alkalmazhatóságot gátolja a csekély mobilitás, magas telepítési és karbantartási költség, és a kábelezésből adódó nehézségek. Ezek nagy része elkerülhető vezeték nélküli szenzorok használatával. Az általunk tervezett keretrendszer feladata a szenzorokból származó információk összegyűjtése, elemzése, értékelése és a szükséges beavatkozó lépések elvégzése. Az információ a primitívebb szenzorok felől halad a kommunikációs ágensek segítségével a központi kommunikációs ágensen keresztül a mesterséges intelligenciához, amely elemzi a beérkező információkat, és a különböző döntési szabályok alapján utasítja a megfelelő beavatkozó szervet, hogy végezze el a szükséges intézkedéseket.
1
2. LOGIKAI FELÉPÍTÉS (ARCHITEKTÚRA) A biztonsági keretrendszer architektúrájának sematikus leírása a 2.1. ábrán látható. A szenzorok az általuk érzékelt fizikai, logikai, stb. jeleket a szenzor átjárókhoz (gateway) küldik, illetve maguk a szenzorok bázisállomásokon keresztül csatlakoznak is ide. Az átjárókon keresztül a szenzorok a központi kommunikációs ágensben létrehozott árnyék (shadow) ágensekhez kapcsolódnak, amelyek, mint a szenzorok modelljei az összes állapotinformációjukat tartalmazzák. Minden érzékelőnek és beavatkozónak létezik pontosan egy árnyék ágense, ha az átjárójának már kiépített kapcsolata van egy központi kommunikációs ágenssel. A rendszer további részei az eszköz specifikus információkat ezeken az árnyék ágenseken keresztül érik el. A felügyeletet és a megfelelő beavatkozó intézkedések foganatosítását a döntési szabályok alkotta intelligencia végzi. Az általunk tervezett keretrendszer három fő részre bontható. Ezek •
az átjárók és a hozzájuk kapcsolódó szenzorok és beavatkozók
•
a központi kommunikációs ágens, az árnyék konfigurációs ágens, és a hozzá tartozó árnyék ágensek
•
a mesterséges intelligencia (MI).
Minden vezetékes eszköz bázisállomásokon keresztül kapcsolatban van egy átjáróval, a vezeték nélküli eszközök pedig egy általuk létrehozott ad-hoc hálózaton keresztül kapcsolódnak az őket kezelni képes átjáróhoz. Szoftver szenzorok esetén az átjáró az illesztést biztosítja a mérést végző szoftverkomponensek felé. Az átjárókhoz egy-egy kommunikációs ágens kapcsolódik, amelyek a JADE által támogatott middleware szolgáltatások segítségével továbbítják az információt a központi egységben elhelyezkedő központi kommunikációs ágens felé. Az árnyék ágensek dinamikus létrehozását és megszüntetését az árnyék konfigurációs ágens végzi: új szenzor megjelenése esetén létrehozza a megfelelő árnyék ágenst, míg a szenzor eltűnése, meghibásodása esetén az árnyék ágens megszüntetésre kerül. Az alkalmazott ágens-alapú megoldás egyszerű lehetőséget ad az egyes komponensek autonóm viselkedésének implementálására.
2.1.
AZ
ÁTJÁRÓK BEAVATKOZÓK
2.1.1.
ÉS
A
HOZZÁJUK
KAPCSOLÓDÓ
SZENZOROK
ÉS
SZENZOROK
A szenzorok különböző érzékelők, melyek a külvilágból adatokat gyűjtenek. Célunk ezen adatok összegyűjtése, kiértékelése, illetve a szükséges beavatkozó lépések elvégzése. Funkcionálisan háromféle szenzor típust különböztetünk meg: •
Fizikai szenzor (pl.: mozgás (lézeres, térfigyelős), hőmérséklet-, fény-, mikrofon-, füst-, ablaktörés-, ajtónyitás érzékelő, biometrikus azonosítók, stb.) o Vezetékes szenzor (Wired sensor) o Vezeték nélküli szenzor (Wireless sensor)
•
Humán szenzor (pl.: különböző tesztek, jelenléti ív, szabadságolás)
•
Software szenzor (pl.: bejelentkezés figyelő, billentyűzet leütés figyelő, nyomtatás figyelő, adatforgalom figyelő, stb.)
. 2
2.1. ábra. A rendszer logikai felépítése
3
2.1.2.
BEAVATKOZÓK
A különböző beavatkozó szervek segítségével hajtjuk végre a riasztásokat, jelzéseket. Ezek intelligens eszközök, melyek a biztonsági rendszer egyes tulajdonságait változtatják. Ezek típusai lehetnek: kürt, füstelszívó, légkondicionáló, fűtés, tűzoltó rendszer, általános riasztás a személyzetnek, ajtók blokkolása, stb. 2.1.3.
SZENZOR ÁTJÁRÓ (GATEWAY)
Az átjáró az alacsony szintű fizikai eszközök és a magasabb szintű központi kommunikációs ágens között az információ áramlást biztosítja. Feladatai: •
Minden átjáró létrehozza a saját átjáró kommunikációs ágensét.
•
Folyamatosan gyűjti a szenzoroktól az információkat.
•
Továbbítja a központi kommunikációs ágens felé az információkat.
•
Új eszközök érzékelése, adminisztrálása és jelzése a központi kommunikációs ágens felé.
•
Kikapcsolt, meghibásodott eszközök érzékelése, adminisztrálása és jelzése a központi kommunikációs ágens felé.
Eseményei: •
CreateSensor: Utasítja az átjáró kommunikációs ágenst, hogy jelentse a központi kommunikációs ágens felé az új szenzor létrejöttét.
•
MissingSensor: Utasítja az átjáró kommunikációs ágenst, hogy jelentse a központi kommunikációs ágens felé egy szenzor megszűnését, vagy meghibásodását.
•
RequestData: Adott információ lekérdezés kiszolgálása.
2.1.4. ÁTJÁRÓ KOMMUNIKÁCIÓS ÁGENS (GCA – GATEWAY COMMUNICATION AGENT) Az szenzor átjáró ezen keresztül kommunikál a központi kommunikációs ágensekkel. Minden átjáróhoz pontosan egy ilyen kommunikációs ágens tartozik. Feladatai: •
Létrejöttekor beregisztrál a központi nyilvántartásba.
•
Közvetíti az adatokat az átjáró és a központi kommunikációs ágens között
Eseményei: •
RequestData: A beérkezett kérést továbbítja az átjáró felé, majd a visszakapott értéket visszaküldi a kommunikációs ágensnek.
•
CreateSensor: Utasítja a központi kommunikációs ágenst, hogy jelentse az árnyék konfigurációs ágens felé az új szenzor létrejöttét.
•
MissingSensor: Utasítja a központi kommunikációs ágenst, hogy jelentse az árnyék konfigurációs ágens felé egy szenzor megszűnését, vagy meghibásodását.
4
2.2.
A KÖZPONTI KOMMUNIKÁCIÓS ÁGENS, AZ ÁRNYÉK KOMMUNIKÁCIÓS ÁGENS ÉS A HOZZÁ TARTOZÓ ÁRNYÉK ÁGENSEK
2.2.1. KÖZPONTI KOMMUNIKÁCIÓS ÁGENS (CCA – CENTRAL COMMUNICATION AGENT) Kommunikál az átjáró konfigurációs ágensekkel, üzeneteket küld az árnyék konfigurációs ágenseknek, és az árnyék ágenseknek. Minden központi kommunikációs ágenshez egy árnyék konfigurációs ágens tartozik. A biztonsági keretrendszer architektúrájában a fent említett két ágens különválasztást, az általuk ellátott funkciók indokolták. Feladatai: •
Létrejöttekor beregisztrál a központi nyilvántartásba.
•
A környezetében fellehető átjárók felderítése, majd felhasználói igény szerint a kapcsolat felépítése az átjáró kommunikációs ágensen keresztül.
•
Adatgyűjtés az átjárótól: o Request: A felhasználó jelzi az adatkérési szándékát (egyszeri, ciklikus). o Get: Az átjáró küldi minden előzetes kérés nélkül (létrehozás, megszüntetés).
•
Üzenetek továbbítása az átjáró kommunikációs ágens felé, és fogadása az átjáró kommunikációs ágens felől.
•
A felhasználó a központi kommunikációs ágens grafikus felületén keresztül irányíthatja a rendszert, és léphet kapcsolatba vele.
Eseményei: •
CreateShadow: Ha beérkezik egy üzenet az átjáró kommunikációs ágenstől, hogy egy szenzor rákapcsolódott a hálózatra, jelzi az árnyék konfigurációs ágens felé, hogy hozzon létre egy ennek megfelelő árnyék ágenst.
•
KillShadow: Ha beérkezik egy üzenet az átjáró kommunikációs ágenstől, hogy egy szenzor eltűnt, vagy meghibásodott, jelzi az árnyék konfigurációs ágens felé, hogy szüntesse meg, vagy deaktiválja az ennek megfelelő árnyék ágenst.
•
RequestData: Felhasználói igény esetén lekérdezi az árnyék ágenstől valamelyik szenzor vagy beavatkozó állapotát, majd megjeleníti a grafikus felületén. A lekérdezés lehet egyaránt egyszeri, vagy periodikus.
•
GetData: A központi kommunikációs ágens számára egy árnyék ágens jelzi, hogy az általa modellezett fizikai eszköz állapota megváltozott, és kéri ezen új adat megjelenítését a felhasználók számára. Ilyen események bekövetkezhetnek korábbi periodikus lekérdezés eredményeként, vagy bizonyos eszközök (pl. füstérzékelők, ablaktörés érzékelők, stb.) kritikus állapotváltozásának hatására.
2.2.2.
ÁRNYÉK KONFIGURÁCIÓS ÁGENS (SCA – SHADOW CONFIGURATION AGENT)
Adminisztrálja a hozzá tartozó központi kommunikációs ágensén keresztül elérhető szenzorok és beavatkozó szervek árnyék ágenseit. Feladatai: •
Árnyék ágensek létrehozása és főbb tulajdonságainak eltárolása.
•
Árnyék ágens megszüntetése, deaktiválása. 5
Eseményei: •
CreateShadow: Ha üzenetet kap a központi kommunikációs ágenstől egy új szenzor megjelenéséről, létrehozza az ennek megfeleltetett árnyék ágenst.
•
KillShadow: Ha üzenetet kap a központi kommunikációs ágenstől, hogy az egyik szenzor eltűnt, vagy meghibásodott, megszünteti, vagy deaktiválja az ennek megfelelő árnyék ágenst.
2.2.3.
ÁRNYÉK ÁGENSEK
Minden egyes szenzorhoz és beavatkozó szervhez tartozik egy úgynevezett árnyék ágens, mellyel az adott szenzort vagy beavatkozó eszközt modellezzük. Ebben tároljuk a szenzortól lekért adatokat, illetve az azonosításukra szolgáló információkat. Feladata: •
Létrejöttekor beregisztrál a központi nyilvántartásba.
•
A átjáró kommunikációs ágenstől kapott adatok megőrzése, tárolás, és azok továbbítása az MI felé, további számítások céljából.
•
A modellezett eszköz pontos azonosítására szolgál, melyről minden információt tárol az aktuális állapotával együtt.
Eseményei: •
RequestAI: Az intelligencia lekérdezéseit szolgálja ki.
•
SendAI: Kritikus állapot bejelentése, valamilyen feltétel teljesülése esetén.
•
StoreData: Az érzékelő, vagy beavatkozó új állapotról beérkezett adat tárolása, és az új adat továbbítása a központi kommunikációs ágens felé megjelenítés céljából.
•
RequestData: A központi kommunikációs ágenstől beérkezett lekérdezések kiszolgálása.
2.3.
A MESTERSÉGES INTELLIGENCIA (MI)
Szabályrendszereket tartalmaz, monitoroz, döntéseket hoz, utasítja a beavatkozó szerveket. Feladata: •
Az árnyék ágensektől kapott és lekérdezett információkból, az előre definiált szabályrendszerek alkalmazásával döntéseket hoz.
•
Felhasználói interakciót valósít meg (riasztás, jelzés, beavatkozás).
Eseményei: •
RequestShadow: Lekérdezi az árnyék ágensek adatait.
•
GetShadow: Az árnyék ágenstől érkezett adatok megőrzése és felhasználása.
•
Action: Beavatkozás.
6
3. FIZIKAI FELÉPÍTÉS A biztonsági keretrendszer a támadások és fenyegetések széles köre elleni védelmet támogatja, ezért az elérhető szenzorok szélesebb skáláját képes integrálni. Az érzékel jellemző szempontból a szenzorok három csoportba oszthatók: fizikai, logikai és humán szenzorok. Az integrált biztonsági rendszerekben alkalmazható fizikai érzékelők köre igen széles, a tipikus érzékelők a következők: füstérzékelők, hőmérséklet érzékelők, CO2 detektorok, nedvességérzékelők, különféle behatolás- és betörésjelzők, mozgásérzékelők, fényérzékelők, kamerák, tápfeszültség-figyelő, különféle komplex beléptető rendszerek, tárgyi vagy biometrikai azonosító rendszerek. A logikai szenzorok az informatikai veszélyeztetések, támadások jelzésére szolgáló „virtuális” érzékelők. A leggyakoribb logikai érzékelők a jogosultságkezelő rendszerek, hálózati menedzsment eszközök, tűzfalak, de egy komplex védelmi rendszerben ide tartoznak a rendszer-, dokumentum-, workflow- és adatbázis-menedzsment eszközök is. A humán szenzorok alkalmazása manapság még nem tipikus, ezeket csak a nagyon kritikus védelmi rendszerekben alkalmazzák. A statikus „érzékelők” jellemzően kérdőíves (egyszeri vagy ismételt) vizsgálatok és pszichológiai tesztek, míg a dinamikus érzékelők a viselkedéssel, lelkiállapottal összefüggő jellemzőket, „elektronikus viselkedésmintákat”, illetve ezek változását igyekeznek mérni. A viselkedésminták felépítéséhez használhatók a gépelési, nyomtatási, egérkezelési, internetezési szokások, jellemző fájlhozzáférések, programok használata, a login/logout, vagy éppen a munkaidő-beosztási szokások. Elképzelhető még biometrikus jellemzők használata is. A szenzorokat a hozzáférés módja szerint vezetékes, vezeték nélküli, vagy szoftver szenzorokra oszthatjuk. A vezetékes szenzorok csoportja a „hagyományos” érzékelőket foglalja magában, ilyen a biztonságtechnikában jelenleg használt eszközök nagy része, pl. füstjelzők, betörésjelzők, ablaktörés érzékelők, stb. A vezeték nélküli eszközök biztonságtechnikai alkalmazása terjedőben van, különböző vezeték nélküli protokollok alkalmazásával (WiFi/802.11, Bluetooth/802.15.1, vagy Zigbee/802.15.4) A Zigbee szabványt [4] kifejezetten alacsony fogyasztású, viszonylag kis kommunikációs sávszélességű érzékelő eszközök számára fejlesztették ki, így biztonságtechnikai érzékelők számára ideális megoldást kínál. Itt meg kell jegyezni, hogy a vezeték nélküli szenzorok kommunikációs mechanizmusai nem csak az átjáróval való közvetlen információcserét támogatják, hanem a szenzorok önálló ad-hoc hálózat létrehozására is képesek, amelyhez a átjárónak elég egy ponton csatlakozni, így nem szükséges az összes szenzornak az átjáró közelében elhelyezkednie. A szoftver szenzorok olyan komplex hardver-szoftver eszközök, amelyek magas szintű hozzáférést biztosítanak az eszköz eléréséhez (pl. hálózaton keresztül). A logikai és humán szenzorok nagy része szoftver szenzor, ezek egységes elérését az átjárók biztosítják. A beavatkozó szervek skálája a védett objektum jellegétől függően igen széles lehet: pl. zárak, automatikus tűzoltó rendszerek, füstelszívók, hűtő/fűtő rendszerek, különféle riasztók (kürt, távriasztás, telefonhívás).
7
Jade Main container-t és biztonsági másolatait futtató szerverek Vezetékes Vezetékes szenzorok bázisállomás
Vezetékes szenzor átjáró
Jade Szerver
Jade Tükör Szerver
Ágenseket futtató klaszter
Mote Mote 77 Mote 0 Base Mote Mote 57
Vezeték nélküli szenzorok
Vezeték nélküli bázisállomás
Adatmentés, adatbányászat, szabályhalmaz
Vezeték nélküli szenzor átjáró
Software szenzorok Software szenzor átjáró
RIADÓ
Humán szenzor átjáró
Humán szenzorok
3.1. ábra. A rendszer fizikai felépítése 8
3.1.
A VEZETÉKES SZENZOROK, BÁZISÁLLOMÁS ÉS HÁLÓZATI GATEWAY
3.1.1.
AZ ILLESZTŐKÁRTYA FELADATA
Az illesztőkártya feladata, hogy egységes, jól definiált és könnyen használható interfészt teremtsen a számítógép és különböző vezetékes, fizikai szenzorok között. A kártya tervezésénél fontos szempont volt, hogy az minél univerzálisabb legyen, mind a szenzorok, mind a számítógép felé nyújtott interfész szempontjából. 3.1.2.
AZ ILLESZTŐKÁRTYA FELÉPÍTÉSE
Az illesztőkártya részei: Tápegység •
Mikrokontrolleres vezérlő egység
•
kétállapotú bemeneti egységek
•
kétállapotú kimeneti egységek
•
soros, illetve USB illesztőegység
A tápegység Az illesztőkártya tápegysége egy külön panelen foglal helyet. Felépítése a hagyományos, de megbízható áteresztő-stabilizátoros elvet követi. A hálózati feszültség egy biztonsági transzformátor, annak feszöltsége egy kétoldalas egyenirányító hidat táplál. Az így nyert pulzáló egyenfeszültséget két kondenzátor simítja és szűri, majd egy LM78M05 típusú stabilizátor stabilizálja, végül újabb két kondenzátor további szűrést végez. A tápegység az LM78M05 áteresztő stabilizátor révén 500mA-rel terhelhető 5V-os egyenfeszültséget állít elő. Az áramkör túláram és túlmelegedés ellen védett. A mikrokontrolleres vezérlő egység Az illesztőkártya a Microchip PIC16F877A [5-9] típusú mikrovezérlőjére épül. Ez a típus bőséges perifériakészlettel bír (például időzítő, számlálók, A/D átalakítók), amik lehetővé teszik vezetékes fizikai szenzorok széles skálájának egyszerű illesztését. Az mikrovezérlő ezen kívül számos tetszőlegesen felhasználható ki/bemeneti porttal (GPIO), valamint egyéb intelligens eszközökhöz való csatlakozást lehetővé tevő I2C porttal is rendelkezik. A mikrokontroller 20MHz-es órajellel üzemel, így a számítási teljesítménye akár bonyolultabb számításokra is elegendő. Kétállapotú bemeneti egységek A kétállapotú szenzorok a kétállapotú bemeneti egységhez kapcsolódnak. Mind a 16 bemenet feszültségérzékeny, galvanikusan leválasztott, túlfeszültség- és fordított polaritás ellen védett. A bemeneti vonalak feszültségét 2,5V alatt alacsony (L), e fölött magas szintűnek tekintjük, így akár szabvány TTL szintű, akár 12 vagy 24V-os feszültséget adó szenzorokhoz tudunk csatlakozni, megfelelő kiegészítő áramkörrel pedig 4-20mA-es áramhurokhoz is. A galvanikus leválasztásnak köszönhetően nem okoz problémát, ha az egyes szenzorok földpontja nincs azonos potenciálon.
9
3.2. ábra. Egy kétállapotú bemeneti egység kapcsolási rajza A szenzorokat legrosszabb esetben is 1ms gyakorisággal tudjuk lekérdezni, ami a szokásos alkalmazásokhoz bőségesen elegendő, továbbá lehetőség van a szenzorok egy részét megváltozás-triggerelt üzemmódba kapcsolni, ami lehetővé teszi a változások azonnali detektálását. Két bemenet összekapcsolásával lehetőség van arra, hogy az adott szenzor üzemszerű működését is ellenőrizni tudjuk. A kétállapotú kimeneti egységek A kétállapotú kimeneti egységek a kétállapotú beavatkozó eszközök (például kontrollámpa, riasztó) vezérlésére használhatók. Az illesztőkártya 6db kimenettel rendelkezik. Mindegyik kimenet galvanikusan leválasztott, valamint egy-egy visszajelző LED is tartozik hozzájuk, ami teszteléskor lehet hasznos. A kimenetek egy-egy relével vannak megvalósítva, a relé kontaktusainak kivezetésével. Ez a megoldás nyújtja a legnagyobb mértékű flexibilitást, hiszen egy rövidzár-szakadás típusú kimenet segítségével bármilyen eszköz egyszerűen ki- illetve bekapcsolható. A felhasznált relé két egyforma, 32V egyenáramon 2A-rel terhelhető váltóérintkezős kontaktust tartalmaz, amik párhuzamosan vannak kapcsolva a nagyobb terhelhetőség érdekében.
3.3. ábra. Egy kimeneti egység kapcsolási rajza A relé alkalmazásának van egy olyan hátránya, hogy kapcsolási sebessége a félvezetőkhöz képest alacsonyabb, de ez ennél az alkalmazásnál nem jelent hátrányt, mert még így is több nagyságrenddel gyorsabbak a kimenetek, mint amekkora sebességre szükségünk van.
10
A kimenetek - mivel relékről van szó - szakadás-rövidzár típusúak, így például egy fogyasztó (sziréna, kontrollámpa) tápfeszültsége szakítható meg vele. A soros illesztőegység Az illesztőkártya a számítógéppel RS-232 [1, 2] protokoll segítségével tud kommunikálni. Ez talán az egyik leguniverzálisabb soros protokoll; szinten minden számítógép tudja használni. [4] A protokoll nagy előnye az egyszerű megvalósíthatóság, legyen szó akár a mikrokontrolleres, akár a számítógépes oldalról. Mivel a mikrokontroller jelszintje (0 - 5V) eltér a számítógép jelszintjétől (-15..-8 8..15V), szükség volt egy szintillesztő áramkörre is a két eszköz között. Ezt a feladatot a Maxim MAX232 típusú integrált áramköre látja el. Az illesztőkártyához 9600 baud / 1 stop bit / nincs paritás ellenőrzés beállításokkal kell kapcsolódni, de a sebesség akár 115200 baud-ra is növelhető a firmware minimális módosításával. Az illesztőkártya protokollja Az illesztőegység egy egyszerű szöveges protokollt használ a kommunikációra. Minden parancsot egy cr – carriage return karakter zár le. A legegyszerűbb utasítás a VER. A firmware verziószámát adja vissza. Ezzel tudjuk ellenőrizni, hogy a fizikai kapcsolat az illesztőkártya és a számítógép között működik-e (nem szakadt-e a kábel, helyesen vannak-e beállítva a kapcsolat paraméterei). Példa: Számítógép: Illesztőkártya:
VER IO VER 2.5REVG
A CAP utasítással az illesztőkártyán levő, jelenleg elő szenzorokat és beavatkozó eszközöket kérdezhetjük le. A parancs kiadása után a kártya visszaadja az aktuálisan élő szenzorok és beavatkozó eszközök listáját, valamint felépíti a logikai kapcsolatot. Amíg a logikai kapcsolat nem él, az illesztőkártya nem küldi el sem automatikusan, sem kérésre a szenzorok által mért értékeket, valamint a beavatkozó eszközöknek sem tudunk értéket adni. A parancs kiadása után az olyan szenzorok, melyek a mért értékek megváltozásakor automatikusan elküldik az új értéket, megkezdik működésüket, és elküldik aktuális mért értéküket. Példa: Számítógép: Illesztőkártya: Illesztőkártya: Illesztőkártya: Illesztőkártya: Illesztőkártya: Illesztőkártya: Illesztőkártya: Illesztőkártya: Illesztőkártya: Illesztőkártya: Illesztőkártya: Illesztőkártya:
CAP I+08:INT16 O+00:HL O+01:HL O+02:HL O+03:HL O+04:HL O+05:HL I+00:HL I+01:HL I+02:HL I+03:HL SET000 11
Illesztőkártya: Illesztőkártya: Illesztőkártya:
SET010 SET021 SET030
Az első 11 sor felépítése hasonló:
+:. Mindegyik ilyen felépítésű sorban egy szenzor vagy beavatkozó eszköz feléledését közli velünk az illesztőkártya. Itt csak azok az eszközök szerepelnek, amik a kapcsolódáskor élnek. Az első karakter az eszköz ki- illetve bemeneti voltát jelöli. I esetén input eszközről (szenzorról), O esetén kimeneti (beavatkozó) eszközről van szó. A következő karakter egy + jel, ami az eszköz feléledését mutatja. A következő két karakter egy azonosító az eszköz számára. A kimeneti és a bemeneti eszközöknek külön azonosítójuk van, tehát - amint azt a példa is mutatja - létezhet ugyanolyan azonosítójú kimeneti és bemeneti eszköz. Az ezt követő karakternek elválasztó szerepe van, míg a sor többi része az eszköz típusát mutatja. Az illesztőkártya jelenleg két eszköztípust különböztet meg: Ezek a HL és az INT16. A HL kétállapotú eszközt jelent (magas/alacsony bemeneti feszültség), az INT16 pedig egy 16bites számot, amit feszültség mérésére használtunk. Az utolsó 4 sorban látható, hogy a jelenleg élő, állapotukat változás esetén azonnal elküldő szenzorok közlik értéküket, hasonló módon, mint ahogy értéket tudunk adni egy beavatkozó eszköznek. A bevezető SET azonosítja a parancsot, majd a két karakteres azonosító következik, végül az érték, ami HL típusú szenzor esetén 0 vagy 1 lehet. Az erre alkalmas szenzorok értékét a GET paranccsal tudjuk lekérdezni. A lekérdezhető bemenetek értékét a paranccsal tudjuk lekérdezni. A kártya erre egy <SET><érték> formátumú sorral válaszol. Példa: Számítógép: GET08 Illesztőkártya: SET0801AF Tehát a 08-as bemenet (ami egy analóg 16bites bemenet) értéke 0x01AF. A kimenetek értékét a <SET><érték> paranccsal tudjuk beállítani. Erre az illesztőkártya nem válaszol. Példa: Számítógép:
SET031
A szenzorok haláláról egy -: üzenet tájékoztat. Példa: Illesztőkártya:
I-01:HL
Itt a 01-es azonosítójú szenzor haláláról szerezhetünk tudomást. Az USB illesztőegység Mivel a modern számítógépek egy részén már nem található meg alapkiépítésben a soros port, az illesztőkártya USB kapcsolattal is rendelkezik. A kártyán található FT232BL [10] típusú integrált áramkör egy USB-RS-232 átalakító, amely mintegy átjárót képezve a mikrokontroller felé RS-232 kapcsolatot nyújt, a számítógépes oldalon pedig virtuális soros portként viselkedik. Ily módon teljesen transzparens mindkét oldalról nézve.
12
Az USB és a soros porti működés között egy jumperrel lehet átkapcsolni, valamint lehetőség van, leginkább tesztelési céllal, úgynevezett loopback üzemmódra is, amikor a bemenetre adott adatok változatlanul a kimenetre jutnak. 3.1.3.
A KÁRTYÁHOZ KAPCSOLHATÓ SZENZOROK
Kétállapotú szenzorok A kétállapotú szenzorok az illesztőkártya kétállapotú szenzorokat fogadó bemenetére csatlakoznak. Attól függően, hogy figyeljük-e a szenzorok élő voltát, 8, illetve 16 ilyen szenzort tudunk fogadni. A jelenlegi beállításokkal és firmware-rel 8 szenzort tudunk kezelni, és mindegyiknek figyeljük az élő voltát is. Így egy szenzorhoz két bemenetet használunk fel. Ajtónyitás-érzékelő és mozgásérzékelő szenzorok illesztése a kétállapotú bemenetetekre Az egyik legegyszerűbb biztonságtechnikai szenzor a mágneses elven működő ajtónyitásérzékelő, mely a 3.4. ábrán látható. Két egységből, áll, az egyikbe egy reed relé, a másikba pedig egy mágnes van beépítve. A mágnest tartalmazó egységet az ajtóra, a másikat az ajtókeretre kell szerelni. Az ajtó csukott állapotánál a mágnes közel kerül a reed-reléhez, így annak kontaktusai záródnak, nyitott állapotnál pedig nyitnak. Így a reed-relé kontaktusainak kivezetésével egy rövidzár-szakadás típusú szenzorhoz jutunk.
3.4. ábra. SD-8561 szenzor Egy másik kétállapotú szenzor a mozgásérzékelő, mely a 3.5. ábrán látható. A tesztelt típus relés kimenettel rendelkezett, így az ajtónyitás-érzékelőhöz hasonlóan ez is egy rövidzár-szakadás típusú szenzor.
3.5. ábra. ROKONET RK-410PR mozgásérzékelő
13
A rövidzár-szakadás típusú szenzorokat a következő ábra feszültségérzékeny kétállapotú bemenetekhez illeszteni:
szerint
tudjuk
a
3.6. ábra. Egy kapcsolóval modellezett rövidzár-szakadás típusú szenzor illesztése Analóg szenzorok Az analóg szenzorok a mikrokontroller belső 10bites szukcesszív approximációs elven működő A/D átalakítójára köthetők, mely a 0-5V-os tartományba eső feszöltséget 0 és 1024 közti számmá alakítja. Ezt a számot az illesztőkártya 16 bitre kiegészítve adja vissza, 4db hexadecimális számjegyként. Termisztor illesztése az illesztőkártya A/D átalakítójára A termisztor [3] egy olyan kétpólus, aminek elektromos ellenállása a hőmérséklet függvényében változik. A felhasznált típus egy NTC termisztor volt, ami azt jelenti, hogy az ellenállása a hőmérséklet növekedésével csökken. A termosztor ellenállását a következő elrendezéssel mérhetjük:
3.7. ábra. Termisztor illesztése az A/D átalakítóhoz 14
A termisztoron levő feszültség Vcc*R1/(R1+R2), és mivel a mikrokontroller tápfeszültsége egyúttal az A/D átalakító referencia feszültsége, a mért érték 1023*R1/(R1*R2) lesz. A hőmérséklet reciproka és a termisztor ellenállásának logaritmusa között lineáris összefüggés áll fenn, így két pontos hőmérsékleten mért értékből a hőmérséklet kiszámítható. 3.1.4.
A KÁRTYÁHOZ KAPCSOLHATÓ BEAVATKOZÓ ESZKÖZÖK
Kétállapotú beavatkozó eszközök Az illesztőkártyához különböző kétállapotú beavatkozó eszközöket kapcsolhatunk. Ezek elsősorban figyelmeztető illetve jelzőkészülékek (kontrollámpák, szirénák) tudnak ki- illetve bekapcsolni. Ehhez a fogyasztó tápellátásával egyszerűen sorosan kell kapcsolni az adott kimenet reléjének kontaktusát.
3.8. ábra. Egy izzólámpa illesztése a relés kimenethez 3.1.5.
ÁTTEKINTÉS: A VEZETÉKES SZENZOROK KIMENETI JELSZINTJEI
A vezetékes szenzorok lehetnek analóg és kétállapotú kimenetűek. Az analóg érzékelők kimenete feszültség vagy áram-hurok jellegű lehet. A feszültség kimenettel rendelkező eszközök a mért jellemző mértékével arányos feszültségű jelet adnak ki. A rendszer megbízhatóságát jelentősen befolyásolja a szenzor és a jelfogadó egység közötti távolság, valamint a kiépített vezetékrendszer és a csatlakozások minősége. Például a jel-áramkörben lévő bizonytalan kontaktus megváltoztatja az áramkör ohmikus ellenállását, ezzel jelentősen torzítva a jelet a fogadó, feldolgozó oldalon. Az áram-hurok alapú rendszerek a mért jellemző mértékével arányos áramot hajtanak keresztül a jel-áramkörön, amelyet a fogadó oldalon kalibrált, hőmérséklet-kompenzált ellenállással feszültség jellé alakítanak át. Ez a megoldás sokkal érzéketlenebb a jel-áramkör minőségére, mert az áramkör ohmikus ellenállásának esetleges változását az érzékelő automatikusan kompenzálja mindaddig, amíg a tápfeszültség nagysága ehhez elegendő. Ipari adatgyűjtő rendszerekben elterjedt a 4-20 mA tartományban működő érzékelők alkalmazása, például nyomás távadók esetében.
15
A kétállapotú kimenettel rendelkező szenzorok egy része rövidzár-szakadás típusú, amit egy elektro-mechanikus jelfogó (relé) segítségével valósítanak meg. A relé zárja, illetve megszakítja a jel-áramkört, tehát a szenzor passzív elemként viselkedik. Ezen szenzorok jellemző kimeneti paramétere a relé terhelhetősége, alkalmazható maximális feszültség és áram értékek. A kétállapotú érzékelők másik csoportja magas vagy alacsony feszültségű, illetve nagyobb vagy kisebb áramú jelet ad ki állapotának megfelelően. Feszültség kimenet esetén a magas és az alacsony jelszint közötti különbség elegendően nagy ahhoz, hogy a fogadó oldalon a jel-áramkör ohmikus ellenállásának mérsékelt változása ne okozzon hibát a jel értelmezésében. A továbbiakban különböző funkciójú szenzoroknál tipikusan alkalmazott kimeneteket ismertetjük néhány, kereskedelmi forgalomban kapható eszköz példáján keresztül. Mozgásérzékelők Általában „passive-infrared” (PIR) elven működnek. A szenzor a megfigyelt területről az egyes objektumokról érkező infravörös sugárzást érzékeli. Az áthaladó személy eltérő hőmérsékletű, mint a környezete, így megváltozik a sugárzás intenzitása. Léteznek kombinált érzékelők, amelyek a PIR mellett például mikrohullámú radart is alkalmaznak. A mozgásérzékelőknek többnyire relé kimenetűek, de egyes típusoknak aktív kétállapotú jelkimenete is van. Jellemzően szabotázsvédelemmel is rendelkeznek, tehát az érzékelő megbontása is riasztást eredményez. Bosch BLP1-P [28]
3.9. ábra. A Bosch BLP1-P mozgásérzékelő és kimeneti jellemzői
16
Bosch DS 304 PIR [29]
3.10. ábra. A Bosch DS 304 PIR mozgásérzékelő és kimeneti jellemzői Bentel DT800 [30]
Kettős technológiát (mikrohullámú és PIR) alkalmazó detektor Kimenet: Normál esetben zárt állapotú (NC), 100 mA terhelhetőségű szilárd test relé Szabotázsvédelemmel rendelkezik
3.11. ábra. A Bentel DT800 kombinált mozgásérzékelő és kimeneti jellemzői Akusztikus üvegtörés érzékelők Az akusztikus üvegtörés érzékelők mikroprocesszor alapú hangelemző eljárással (Sound Analysis Technology, SAT) működő szenzorok, relé kimenettel. Előre rögzített üvegtörés hangmintákkal hasonlítják össze a környezeti zajokat frekvencia, hangkép és időtartam szerint. Előnye, hogy mennyezetre vagy falra szerelhető, adott hatótávolságon belül érzékeli az üvegtörést, nem kell minden egyes üvegfelületet külön ellátni érzékelővel. Bosch DS 1100 sorozat [31]
3.12. ábra. A Bosch DS 1100 sorozatú akusztikus üvegtörés érzékelő és kimeneti jellemzői
17
Füst- és hőérzékelők, gázérzékelők Ezen mérendő jellemzők folytonosan változnak, így az érzékelők is alapvetően analóg áram-hurok kimenettel rendelkeznek ennek megfelelően. A mért jellemző mértékének növekedésével a jel-áramkör árama is növekszik. Elérve egy bizonyos határértéket, a riasztás bekövetkezik. Mivel ezen szenzoroknak a feladata nem a mért jellemző értékének nyomonkövetése, hanem a kritikus érték túllépése esetén a riasztási állapot kiváltása, így egyes esetekben relé kimenetet is használnak, elsősorban gázérzékelők (pl. szénmonoxid, metán) esetében. Vannak egyedi füst-, hő- és gázérzékelő szenzorok, de elterjedt ezek kombinációja is, integrált szenzorokban. Tipikusan nem egy szenzort alkalmaznak, hanem a megfigyelendő tér nagyságától függően egy-egy zónában akár 30 szenzor is lehet. GFE – H hő és hősebesség érzékelő család [32] Az 3.13. ábra a kétvezetékes, míg a 3.14. ábra a négyvezetékes kábelezést mutatja a Global Fire Equipment hagyományos tűzjelző központjai esetén. Az egyes típusok paramétereit az 1. táblázat tartalmazza.
3.13. ábra. GFE – H hőérzékelők kétvezetékes kábelezése
3.14. ábra. GFE – H hőérzékelők négyvezetékes kábelezése 3.1. táblázat. A különböző GFE – H hőérzékelő szenzor típusok jellemző paraméterei
18
GFE – S fütérzékelő család [33] A Global Fire Equipment egyes füstérzékelő típusainak paramétereit a 3.2. táblázat tartalmazza. 3.2. táblázat. A különböző GFE – S füstérzékelő szenzor típusok jellemző paraméterei
Bosch MAGIC. SENS automatikus határérték érzékelők [34] Optikai (füst), hőmérséklet és kémiai szenzor elemekből felépített kombinált érzékelő család. Az összes érzékelőjelet a belső kiértékelő elektronika folyamatosan dolgozza fel és hangolja össze egymással. Az érzékelők összehangolásával (kombinált érzékelő) lehetséges az érzékelő telepítése ott, ahol kis szemcsés (laza konzisztenciájú) füsttel, gőzzel vagy porral kell számolni. A Bosch MAGIC. SENS családban a 3.3. táblázatban feltüntetett érzékelő kombinációk léteznek. A szenzort és kimeneti paramétereit a 3.15. ábra mutatja. 3.3. táblázat. Bosch MAGIC. SENS szenzor típusok
Riasztás kimenet: Jelző kimenet:
Áramnövelés, (ellenállás kb. 800 Ω). Nyitott kollektor, 3,92kΩ felhúzó ellenállással.
3.15. ábra. Bosch MAGIC. SENS szenzor és kimeneti jellemzői
3.2.
A VEZETÉK NÉLKÜLI SZENZOROK ÉS HÁLÓZATI GATEWAY
A vezeték nélküli hálózatok közül néhány évvel ezelőtt, önálló kutatási területként kiváltak a vezeték nélküli szenzorhálózatok. A technológiai fejlődés hatására egyre nagyobb igények merülnek fel az autonóm szenzorok vezeték nélküli hálózatba kötésével kapcsolatban. Ezeknek képeseknek kell lenniük arra, hogy egymással együttműködve, lokális érzékelés útján, globális érzékelési feladatokat hajtsanak végre. A vezeték nélküli szenzorhálózatok közös jellemzője az alacsony átviteli sebesség, rövid hatótávolság és az eszközök alacsony fogyasztása. Emellett A hálózati eszközök által használt szoftvernek képessé kell tennie a hálózatot önmaga átkonfigurálására, külső beavatkozás 19
nélküli, hosszabb időn keresztüli önálló feladatvégzésre, valamint az esetlegesen bekövetkező váratlan események kezelésére. Mivel szenzor-csomópontok százai, sőt, ezrei vehetnek részt egy-egy alkalmazásban, ezért ezek telepítése és működtetése magas fokú autonóm működést kíván meg a szenzorhálózattól. A vezeték nélküli szenzorhálózatok fejlesztésének célja, hogy homokszem, vagy akár egy porrészecske (mote) nagyságú, egymással kommunikáló érzékelőket készítsünk. Az így létrehozott MEMS (Micro Electro Mechanical Systems) technológián alapuló szenzorok összességét nevezzük Smart Dust-nak [19]. Az elnevezést Kristofer S. J. Pister (University of California) használta először 2001-ben, habár a koncepció már évek óta létezett a Sci-fi világában. Egy ma még elég utópisztikusnak tűnő jövőkép szerint, ezek a közel porszemnyi méretű, a környezettel szoros kapcsolatban álló, intelligens eszközök fogják az életünket kényelmesebbé tenni. A milliméteres nagyságú mote-ok prototípusai már ma is beszerezhetők kutatási célokra, de porszemnyi méretű eszközök ma még nem léteznek. Ezek a részecskék összekapcsolódva automatikusan létrehoznak egy flexibilis, alacsony fogyasztású hálózatot, melynek felhasználási területe a klíma szabályzó rendszerektől a gyógyászatig, vagy akár egészen a szórakoztatóipari eszközökig terjed. Vezeték nélküli szenzorokat manapság már több gyártótól is be lehet szerezni. Annak ellenére, hogy a különböző típusú mote-okat más-más szervezetek fejlesztették ki, ezek főbb elemei megegyeznek. Általában tartalmaznak egy mikrokontrollert, egy kommunikációs egységet, integrált, vagy hozzá kapcsolható szenzor kártya modult. A szenzoregységekről általánosságban elmondhatjuk, hogy egy mai pc-hez képest nagyon kis erőforrásokkal rendelkeznek. Emiatt a mote-ok programozásánál oda kell figyelni, hogy a lehető legkevesebb memóriát használjuk a szoftver fejlesztésekor, és a processzor sem képes akkora teljesítményre, mint amit egy számítógépnél megszokhattunk. A ma kapható mote-ok általában néhány kilobyte operatív memóriával valamint néhány 10 vagy 100 kbájt flash memóriával rendelkeznek. A vezeték nélküli hálózat kialakításához a Crossbow Technology által kifejleszett MICAz eszközöket használtuk, ami egy bázisállomásból (mote0) és a hozzá kapcsolódó többi moteból áll. 3.2.1.
A VEZETÉK NÉLKÜLI BÁZIS ÁLLOMÁS
A bázis állomást egy MIB600 Ethernet Interface Board és MPR2400 (MICAz) alkotja [12, 17]. A 3.9. ábrán látható MICAz a legújabb generációs vezeték nélküli platform (mote) alacsony energiájú szenzorhálózatokhoz a Crossbow Technology-tól. Az MPR2400 2400MHz-2483.5MHz tartományban sugároz rádió jeleket. Amely a Chipcon CC2420-at használja, megfelel a IEEE 802.15.4 –nek, ZigBee ready rádió frekvenciás adó-vevő egy Atmega 128L mikrokontrollerrel integrálva, melyek elhelyezkedés a 3.10. ábrán látható. Van rajta egy 51 pin I/O csatlakozó és soros flash memóriát használ. A MICAz AA típusú táp ellátásra van tervezve [12, 15, 17].
20
3.16. ábra. Az MPR2400 – MICAz standard antennával Mind a bázis állomásnál, mind a különböző mote-oknál az MPR2400-at használjuk, hogy kapcsolatot tudjanak teremteni egymással, valamint ezeknek az azonosítója (mote ID) alapján különböztetjük meg a csomópontokat. A bázisállomás a nullás azonosítót kapta.
3.17. ábra. Az MPR2400/MICAz sematikus blokk diagramja A 3.11. ábrán látható MIB600 Ethernet Interface Board-nak [12, 17] két általános beállítási lehetősége van:
21
•
Ethernet Gateway a mote hálózat számára
•
A mote hálózat programozására és kimeneti tartomány diagnosztikára használható csatorna
A MIB600 tartalmaz többek között egy TCP/IP szervert és egy 51-pin HIROSE konnektort, ezzel kapcsolódik össze az MPR2400-al. Kétféle táp ellátási lehetősége van: •
Külső 5VDC egy AC hálózati adapterből
•
Etherneten keresztüli tápellátás (Power Over Ethernet)
A MIB600 Soros Szerver egy 10 Base-T LAN csatlakozón keresztül tud más eszközökhöz kapcsolódni. Patch kábellel kapcsolódhat egy hub-hoz, vagy egy switc-hez, viszont ha PC-hez szeretnénk csatlakoztatni, akkor cross kábelt kell használnunk. A mote soros TCP/IP szervere az 10002-es porton érhető el. A MIB600 ISP mikrokontrollere 10002es porthoz van csatlakoztatva. Ennek programozásához szükséges, hogy legyen a MIB600nak saját IP címe.
3.18. ábra. MIB600 Ethernet Interface Board 3.2.2.
A VEZETÉK NÉLKÜLI SZENZOROK
A vezeték nélküli szenzoroknak a 3.12.ábrán látható MTS300CA típusú szenzor kártyát használtuk [12, 15, 18]. Ez a típus tartalmaz egy mikrofont, egy hőmérséklet- és egy fénymérőt. A mikrofon képes a körülötte levő zajokat mérni. A mote pedig képes körülötte levő mote-okat észlelni, és ezáltal felépíthető a mote-ok elhelyezkedésének a térképe. A mote-ok működésük során folyamatosan figyelik, hogy mely más mote-ok vannak a hatótávolságukban. Úgy tudják detektálni a körülöttük fellelhető mote-okat, hogy egyidőben kiküld a mote-on elhelyezkedő sounder által egy impulzust és küld egy RF csomagot a rádión keresztül is. A mote a két jel beérkezése között eltelt időből számolja ki a többi mote távolságát.
22
Az MTS300CA-hoz egy MPR2400-as mote-ot csatlakoztatunk, amely ez által tud csatlakozni a többi mote-hoz, így a bázisállomáshoz is.
3.19. ábra. Az MTS300CA szenzor kártya
23
4. MŰKÖDÉS A primitívebb szenzorok jelei bizonyos feldolgozó lépések után eljutnak az MI-ig ahol is egy jól meghatározott szabály rendszer alapján döntés születik arról, hogy miként kell reagálnia a rendszernek az adott szituációra.
4.1.
A VEZETÉKES SZENZOROK ÉS HÁLÓZATI GATEWAY
4.1.1.
AZ ÁTJÁRÓ
Az átjáró feladata a hozzá tartozó bázisállomásra kötött szenzorok és beavatkozó szervek minden adatának tárolása és folyamatosan frissen tartása és a felsőbb rétegek felől érkező lekérdezések kiszolgálása. Az átjárótól a bázisállomás felé irányuló kommunikáció parancsai: •
A "VER" parancs használatával kérdezhető le a bázisállomás firmware verziója. A parancs érkezésekor a bázisállomás a választ a következő formátumban adja meg: "IO VER 2.5REVG". Ebben az "IO VER" jelzi, hogy a bázisállomás a verzióját fogja közölni. Ez után következik a tényleges firmware verzió, mely számokat és betűket egyaránt tartalmazhat.
•
A "CAP" parancs segítségével utasítjuk a bázisállomást arra, hogy válaszul közölje az éppen aktív szenzorok és beavatkozó szervek legfontosabb adatait. A bázisállomás válaszul minden egyes elérhető szenzor esetén egy "I+05:HL" formátumú karakterlánccal válaszol, melynek jelentését az ellentétes irányú kommunikációnál tárgyaljuk.
•
A bináris kimenetek beállítására a "SET" parancs használható. A "SET041" parancsban a "SET" kulcsszó jelzi a feladatot, azaz valamely kimenet állapotának átállítását. A kulcsszó után következő két karakter azonosítja, hogy melyik porton lévő kimenetet akarjuk szabályozni. A többi karakter már a szenzor típusától függ. Bináris kimenetet az "1" karakter esetén magas szintű állapotba, míg "0" esetén alacsony szintű állapotba állítja. Több bites, azaz analóg kimenet esetén négy hexadecimális számjegy adja meg a kimenet beállítandó állapotát.
•
Az analóg bemenetre kötött szenzorok aktuális értéke a "GET" parancs használatával kérdezhető le, mivel ezen szenzorok értékének változása esetén nem jelez automatikusan a bázisállomás. A bázisállomás a "GET" kulcsszóból megállapítja, hogy egy analóg bemenetet kell lekérdeznie. A kulcsszó után szereplő két karakter pedig a bemenet portját azonosítja. Ezek után a bázisállomás egy "SET" paranccsal válaszol, mely a következő pontban van kifejtve. Így például a nyolcas analóg bemeneten lévő szenzor aktuális értékét szeretnénk megtudni, akkor a "GET08" parancsot kell küldenünk a bázisállomásnak.
A bázisállomástól az átjáró felé irányuló kommunikáció parancsai: •
A bemenetek értékének bejelentése a következőképpen történik: "SET087540" vagy "SET021" formátumú karakterlánccal jelez a bázisállomás. A "SET" kulcsszó után lévő két karakter a bemeneti port számát adja meg. Az ezek után következő rész már a szenzortól függ. Az első esetben egy 16 bites szenzor küldte a jelet, így négy darab hexadecimális számjegyet olvashatunk ki. A második 24
esetben egy bináris szenzortól származik a jel. Amennyiben az utolsó karakter "1"-es, akkor a szenzor magas szintű állapotban van. A nulla karakter pedig az alacsony szintű állapotot jelent. •
Szenzor be- és kikötését a következőképpel jelenti be a bázisállomás: "I+08:INT16", "O-02:HL": Az első karakter lehet "I" vagy "O". Az "I" szenzort (input), míg az "O" beavatkozó szervet (output) jelez. A "+" bekötést (születést), míg a "-" kikötést (halált) jelent. A következő két karakter annak a portnak a számát adja meg, amelyiken a szenzort fizikailag elhelyezkedik. A ":" egy szeparáló karakter. A parancs végén található "INT16" azt jelenti, hogy az aktuális porton 16 bites szenzor vagy beavatkozó szerv található. Ha a parancs végén "HL" látható, akkor a porton bináris szenzor vagy beavatkozó szerv található.
A kommunikáció mindkét irányában megtalálható a "SET" parancs. Az egyik irányban a bázisállomás jelenti be a szenzorok állapotváltozásait, míg a másik irányban az átjáró utasítja a bázisállomást, hogy a megfelelő beavatkozó szerv állapotát változtassa meg. A kommunikáció iránya azonban egyértelműen azonosítja, hogy az adott "SET" parancs esetén mit kell végrehajtani. Így a két parancs megkülönböztethető annak ellenére, hogy a nevük és felépítésük megegyezik. A kapcsolat felépítésének folyamata Az átjáró induláskor megvizsgálja, hogy melyik portra csatlakozik a bázisállomás. Megkeresi a nyitott soros illetve USB portokat, majd ezekre egyenként kiírja a "VER" parancsot. Amelyik porton értelmezhető választ kap, azon keresztül érhető el a bázisállomás. A későbbiekben egy új parancs bevezetésével lekérdezhető lesz a bázisállomás neve is. Erre akkor van szükség, ha az átjárót futtató gépre több bázisállomást is akarunk kötni. Így egyértelműen azonosítható lesz a bázisállomás a név alapján. Amennyiben nem érhető el a bázisállomás, akkor ezt közli az átjáró kommunikációs ágenssel. Ezután az átjáró kommunikációs ágens kitörli magát a rendszer regisztrációs adatbázisából, majd megszakítja mind az átjáró, mind a saját működését. Szenzorok és beavatkozó szervek lekérdezése Ha megtalálta a bázisállomást, akkor a "CAP" parancs segítségével lekérdezi az éppen rendelkezésre álló szenzorokat és beavatkozó szerveket. A kapott választ feldolgozza, majd egyenként összehasonlítja a "gateway.xml" és a "sensors.xml"-ben található adatokat a bázisállomás által közölt adatokkal. A "gateway.xml" fájlra példa az 1. mellékletben, míg a "sensors.xml" fájlra példa a 2. mellékletben található. A "gateway.xml" fájlban található a szenzorok, beavatkozó szervek és az átjárók kapcsolatának leírása. Minden szenzorhoz és beavatkozó szervhez három attribútumot adunk meg. A sensorid egy egyértelmű azonosító, mely azonosítja a szenzort vagy beavatkozó szervet, valamint ez teremt kapcsolatot a két xml fájl között. A gateway mező adja meg, hogy az aktuális szenzor vagy beavatkozó szerv melyik átjáróhoz kapcsolódik. A port mező első karaktere jelöli, hogy input (szenzor) vagy output (beavatkozó szerv). A pont egy szeparáló karakter, míg az utolsó kettő azt adja meg, hogy a bázisállomás melyik portján érhető el. A "sensors.xml" fájlban adjuk meg a szenzorok és beavatkozó szervek pontos tulajdonságait. Minden szenzorhoz négy attribútum és egy tag tartozik. A sensorid attribútum a már ismertetett egyedi azonosító. A name mező adja meg a szenzor vagy beavatkozó egység nevét. A type attribútum tárolja, hogy az adott szenzor vagy beavatkozó szerv bináris vagy 16 bites típusú. A service pedig a szenzor által nyújtott szolgáltatást tartalmazza. Bináris szenzor vagy beavatkozó szerv esetén a conversion tag-en belül a két lehetséges állapot leírása 25
található. A high a magas, míg a low az alacsony állapothoz tartozó szöveges leírást tartalmazza. 16 bites szenzor esetén egy fordított lengyel logikával megadott képlet található a conversion tag-ben. Ez adja meg, hogy a 16 bites számból hogyan kell kiszámolni a megfelelő értéket. A fordított lengyel logikát kiértékelő program képes a négy alapművelet végrehajtására, valamint tetszőleges x érték esetén meg tudja határozni ex és ln(x) értékét is. Ezen műveletek és függvények segítségével kellően bonyolult karakterisztikájú szenzorok is illeszthetők a rendszerbe. Ehhez csak a karakterisztika matematikai alakját kell meghatározni, majd ezt fordított lengyel logikájú alakra hozni. Azokra a helyekre, ahova a számolás során a mért érték kerül, egy "X" karakter kell írnunk. Ezen "X" karakter helyére a rendszer mindig az aktuális mért értéket helyettesíti be. Ezek után a program a szenzortól bejövő adatot a meghatározott képlet alapján átszámolja, így a számolás eredménye már tizedes tört alakban jelenik meg. Amennyiben egy, a bázisállomás által bejelentett szenzor vagy beavatkozó szerv nem található meg sem a "gateway.xml" és a "sensors.xml" fájlokban, akkor az átjáró ezt nem tudja figyelembe venni. Az ilyen szenzor vagy beavatkozó szervről túl kevés adatot tudunk. A bázisállomás csak azt tudja megadni, hogy melyik portjára csatlakozik, bemenet vagy kimenet, valamint azt, hogy bináris vagy analóg típusú. Minden más tulajdonság a két xml fájlban van megadva. Ezen kevés adat alapján nem tudjuk megállapítani, hogy a hármas portra csatlakozó, bináris szenzor mit érzékel. Ez lehet ajtónyitást érzékelő, mozgásérzékelő, füstérzékelő, egyszóval bármi. Ha tudjuk az aktuális állapotát, de nem tudjuk, hogy az mit jelent, akkor számunkra az nem értelmezhető. Ha a bázisállomás által küldött és a két xml által tárolt adatok egyeznek, akkor az a szenzor vagy beavatkozó szerv használható lesz. Szenzor esetén lekérdezi a szenzor aktuális állapotát, majd ez után hozzáadja az adatbázishoz. Beavatkozó szerv esetén nem lekérdezzük az értékét, hanem passzív állapotba állítjuk a kimenetet. Ez után adjuk hozzá az adatbázishoz a beavatkozó szervet. Ezekkel a lépésekkel tudjuk biztosítani azt, hogy az átjáró indításakor ne előre megadott adatokkal, hanem a legfrissebb, tehát már használható adatokkal legyen feltöltve az adatbázisa. Szenzor és beavatkozó szerv adatainak frissítése Az átjáró egyik feladata annak megvalósítása, hogy a felsőbb rétegek mindig a legfrissebb, a valóságnak megfelelő adatokkal tudjanak dolgozni. Ezért az átjárónak mindig naprakésznek kell lennie a bázisállomásra kötött szenzorok és beavatkozó egységek állapotával kapcsolatban. Külön kell választanunk a bináris és az analóg típusú szenzorokat. A bináris szenzoroknak két állapotuk van, míg az analóg szenzorok analóg jelet biztosítanak. A bináris szenzorok nagy stabilitással tudják tartani az aktuális állapotukat, míg az analóg szenzorok az általuk érzékelhető legkisebb változás esetén változtatják a kimenetükön lévő jelet. Így a bináris szenzorok állapotváltozásai valószínűleg kevesebbszer következnek be, mint az analóg szenzorok állapotváltozásai. Ezekből következik, hogy az analóg szenzorok esetén nem célszerű minden állapotváltozást jelezni. Ez nagy adatforgalmat eredményezne, és a változás mértéke sok esetben olyan kicsi lenne, mely elhanyagolható mértékű a jelhez képest. Bináris szenzorok esetén az a legcélravezetőbb megoldás, ha a bázisállomás automatikusan továbbítja az átjáró felé a szenzorok állapotváltozásait. Így az átjárónak csak akkor kell frissítenie az adatbázisát, ha a bázisállomás valamely bináris szenzor állapotának megváltozását jelzi. Amíg nem jön újabb jelzés a bázisállomás felől, addig biztosan a legutolsó jelzett állapotban van a bináris szenzor. Így a felsőbb rétegektől érkező kérést nem
26
továbbítja a bázisállomás felé, hanem az adatbázisában lévő értékkel válaszol. Ezáltal az átjáró és a bázisállomás közötti kommunikációs csatornát feleslegesen nem terheljük, valamint a válaszidő is csökken. 16 bites, azaz analóg szenzor esetén a lekérdezéses módszert használjuk. Ennek az a lényege, hogy amikor a felsőbb rétegnek szüksége van egy analóg szenzor aktuális értékére, akkor az átjáró egy lekérdezést küld a bázisállomásnak a "GET" parancs segítségével. Erre a lekérdezésre a bázisállomás az adott analóg szenzor aktuális értékével válaszol. Ezt az adatot az átjáró eltárolja, majd továbbítja a felsőbb rétegek felé. Így minden alkalommal az akkor lekérdezett adatot továbbítja, mely mindig a helyes érték. Az átjáró képes arra is, hogy a felsőbb rétegektől érkező periodikus lekérdezést kiszolgálja. A szenzorok periodikus lekérdezéséért egy külön szál felel a programon belül. Ez a szál saját adatbázissal rendelkezik. Ebben tárolja, hogy melyik szenzort milyen időközönként kell lekérdezni, valamint azt is, hogy az adott szenzort utoljára mikor kérdezte le. Ebből a két adatból és a pontos időből bármikor ki tudja számolni, hogy jelenleg melyik szenzorokat kell lekérdeznie. Amennyiben valamelyik analóg szenzort le kell kérdezni, akkor a már tárgyalt "GET" parancs használatával jelez a bázisállomásnak. Bináris szenzor esetén az adatbázisból kiolvasott értékkel válaszol az átjáró. A szál megvalósítása a 3. mellékletben található. Az adatbázis Az átjáró adatbázisának alapja négy osztály. Külön osztályban tároljuk a bináris szenzorok, az analóg szenzorok, a bináris beavatkozó szervek és az analóg beavatkozó szervek adatait. Az osztályokból létrehozott objektumok tárolják a "sensors.xml"-ben található, az adott szenzorra vagy beavatkozó szervre jellemző tulajdonságokat. Ebből következik, hogy a négy osztály a tárolt adatokban mutat hasonlóságokat, de a megvalósításban lényeges különbségek vannak közöttük. Bináris szenzor esetén a következő adatokat tároljuk. •
Index: Ez a bázisállomáson belüli egyedi azonosítója a bináris szenzornak. Például: "I.06".
•
Name: Ez a bináris szenzor neve. Például egy ajtónyitást érzékelő szenzor estén "entrance door".
•
Type: Ez a bináris szenzor típusa. Az értéke a "BOOL" karakterlánc.
•
High: Ez a bináris szenzor magas szintű állapotát jellemző karakterlánc. Például egy ajtónyitást érzékelő szenzor esetén "opened" szó.
•
Low: Ez a bináris szenzor alacsony szintű állapotát jellemző karakterlánc. Például egy ajtónyitást érzékelő szenzor esetén "closed" szó.
•
Service: Ez a bináris szenzor által nyújtott szolgáltatás leírását tartalmazza. Például egy ajtónyitást érzékelő szenzor esetén "door" szó.
•
Value: Ez a bináris szenzor legfrissebb mért értéke. Ez lehet true vagy false.
Analóg szenzor esetén a következő adatokat tároljuk. •
Index: Ez a bázisállomáson belüli egyedi azonosítója az analóg szenzornak. Például: "I.08".
•
Name: Ez az analóg szenzor neve. Például egy hőmérsékletmérő szenzor estén "temperature1". 27
•
Type: Ez az analóg szenzor típusa. Az értéke az "ANALOG" karakterlánc.
•
Conversion: Ez egy konverziós formula, mely megadja, hogy a szenzor által küldött értékből milyen műveletek segítségével kapjuk meg az emberek által is érthető értéket. Például: 1 0.003236246 0.000394087 X 6553.5 0.1 X * - / l 1.929168 - * + / 273 -
•
Service: Ez az analóg szenzor által nyújtott szolgáltatás leírását tartalmazza. Például egy hőmérsékletmérő szenzor esetén "temperature".
•
Value: Ez az analóg szenzor legfrissebb mért értéke. 32 bites egész szám, mely már a fordított lengyel logika alapján átszámolt értéket tárolja.
Bináris beavatkozó szerv esetén a következő adatokat tároljuk: •
Index: Ez a bázisállomáson belüli egyedi azonosítója a bináris beavatkozó szervnek. Például: "O.03".
•
Name: Ez a bináris beavatkozó szerv neve. Például egy piros, riasztást jelző LED esetén "red alarm LED".
•
Type: Ez a bináris beavatkozó szerv típusa. Az értéke a "BOOL" karakterlánc.
•
High: Ez a bináris beavatkozó szerv magas szintű állapotát jellemző karakterlánc. Például egy piros, riasztást jelző LED esetén "ON" szó.
•
Low: Ez a bináris beavatkozó szerv alacsony szintű állapotát jellemző karakterlánc. Például egy piros, riasztást jelző LED esetén "OFF" szó.
•
Service: Ez a bináris beavatkozó szerv által nyújtott szolgáltatás leírását tartalmazza. Például egy piros, riasztást jelző LED esetén "light signal" szó.
•
Value: Ez a bináris beavatkozó szerv legutolsó beállított értéke. Ez lehet true vagy false.
Analóg beavatkozó szerv esetén a következő adatokat tároljuk. •
Index: Ez a bázisállomáson belüli egyedi azonosítója az analóg beavatkozó szervnek. Például: "O.07".
•
Name: Ez az analóg beavatkozó szerv neve. Például egy légkondicionáló egység estén "airconditioner1".
•
Type: Ez az analóg beavatkozó szerv típusa. Az értéke az "ANALOG" karakterlánc.
•
Service: Ez az analóg beavatkozó szerv által nyújtott szolgáltatás leírását tartalmazza. Például egy légkondicionáló egység esetén "airconditioner".
•
Value: Ez az analóg beavatkozó szerv legutolsó beállított értéke. 32 bites egész szám.
Az osztályoknak létrehozásukkor meg kell adni minden olyan adatot, amit tárolni tudnak. Ezek után a tárolt adatokat nem lehet változtatni. Kivételt képez ez alól a value, mely mindig az aktuális állapotot reprezentálja. Ezért ezt az adatot az átjáróból bármikor tudnunk kell változtatni, hogy az adatbázisban mindig a szenzorok legfrissebb állapota szerepeljen. Mindegyik osztályban megtalálhatók azok a függvények, melyek az adott osztályban tárolt adatok külön-külön történő lekérdezésére szolgálnak. Az egyetlen beállító függvény minden osztályban a value értékét állítja be. Az egyszerűbb tárolás és átláthatóság kedvéért az összes,
28
azonos típusú osztályból származtatott objektumot egy Map-be gyűjtöttük. Így keletkezett négy Map, melyből bármely szenzor vagy beavatkozó szerv bármely adata elérhető és a value adat beállítható, ha a megfelelő lekérdező- illetve beállító függvényeket használjuk erre. Az index a Map kulcsa, míg a kulcshoz tartozó tárolt érték az indexnek megfelelő szenzorhoz vagy beavatkozó szerv létrehozott objektum. A Map-ekből való lekérdezés és adatfrissítés folyamata a megfelelő Map kiválasztásával kezdődik. Ehhez tudnunk kell, hogy a lekérdezendő objektum szenzor vagy beavatkozó szerv, valamint azt, hogy bináris vagy analóg típusú. Ezen adatok alapján a megfelelő Map már egyértelműen kiválasztható. A Map-ből az egyedi azonosító, azaz az index megadásával kérhetjük le a megfelelő szenzorhoz vagy beavatkozó szervhez tartozó objektumot. Ezek után már rendelkezésünkre áll a megfelelő objektum, tehát az objektumhoz tartozó osztályban definiált lekérdező illetve beállító függvények használatával már bármelyik adat lekérdezhető, illetve a value módosítható. Az adatbázis rendelkezik két kereső függvénnyel, melynek feladata az index alapján a szenzor vagy beavatkozó szerv típusának meghatározása. Amennyiben a felsőbb rétegek felől érkezik egy kérés egy meghatározott index-ű objektum bármely értékének bejelentésére, akkor ehhez más adatra nincs szükség, csak az index alapján képes az átjáró a válasz megadására. Az index felépítésében megtalálható, hogy szenzor vagy beavatkozó szervről van-e szó, valamint a bázisállomás megfelelő portja. Azonban az adatbázisból egy adat lekérdezéséhez ezen kívül még szükségünk van arra is, hogy az adott szenzor vagy beavatkozó szerv bináris vagy analóg típusú. Ennek meghatározására használható a két kereső függvény. Az egyik kereső függvény a szenzorokhoz tartozó, míg a másik a beavatkozó szervekhez tartozó Map-ekben keres. Az index alapján eldönthető, hogy a kérés szenzorra vagy beavatkozó szervre vonatkozik. Így a két kereső függvény közül kiválasztható a megfelelő. Ezek után a kereső függvény megvizsgálja a két megfelelő Map-et. Ha a bináris típusú objektumokat gyűjtő Map-ben megtalálható az index, akkor a "BINARY" karakterlánccal tér vissza. Amennyiben az előző feltétel nem teljesül, akkor az analóg típusú objektumokat gyűjtő Map-et vizsgálja meg. Ha ebben megtalálható az index, akkor az "ANALOG" karakterlánccal tér vissza. Ha ebben sem található meg, akkor az "ERROR" karakterlánccal jelzi ezt a hívónak, hogy ilyen index-ű szenzor vagy beavatkozó szerv nem található az adatbázisban. Az osztályok közötti különbségek abból adódnak, hogy minden osztály más-más típusú szenzort illetve beavatkozó szervet kezel. Szenzor esetén a felsőbb rétegek nem változtathatják meg a value adat értékét, mert ebben az esetben az átjáró adatbázisa már nem a szenzor aktuális értékét tárolná. Kommunikáció az átjáró és az átjáró kommunikációs ágnes között Az átjárótól az átjáró kommunikációs ágens felé irányuló kommunikáció event-ekkel történik. Ezeket az event-ek az ős event osztályból örökítettük úgy, hogy a nekünk megfelelő adatokat tudják továbbítani. Ezekkel képesek vagyunk egy új szenzor vagy beavatkozó szerv születésének, egy már létező szenzor vagy beavatkozó szerv halálának valamint a szenzorok állapotváltozásainak jelzésére. •
Szenzor vagy beavatkozó szerv születése esetén adatait eltároljuk az adatbázisban, majd born event-et küldünk az átjáró kommunikációs ágens felé. Ez a born event tartalmazza az újonnan született szenzor vagy beavatkozó szerv azonosítóját. Ezt az azonosítót a következőképpen kapjuk meg. Négy karakterből áll. Az első karakter "I", ha egy szenzor született. Beavatkozó szerv születése esetén az első karakter "O". A második karakter elválasztja az elsőt a többitől. Ez egy "."
29
karakter. Az utolsó két karakter a szenzor vagy beavatkozó egység bázisállomáson elfoglalt portját adja meg. Ezen adatok alapján ez az azonosító mindig egyedi az adott bázisállomáson. Ezt az egyedi azonosítót index néven tároljuk. A szenzor vagy beavatkozó szerv többi adatát az átjáró kommunikációs ágens az index alapján le tudja kérdezni az átjárótól. •
Szenzor vagy beavatkozó szerv halála esetén adatait eltávolítjuk az adatbázisból, majd died event-et küldünk az átjáró kommunikációs ágens felé. Ez a died event tartalmazza a szenzor vagy beavatkozó szerv indexét, típusát és nevét. Azért szükségesek ezen adatok elküldése, mert a died event küldésekor az átjáró adatbázisában már nem érhetők el a szenzor vagy beavatkozó szerv adatai. Ezek alapján viszont az átjáró kommunikációs ágens már képes jelezni a felsőbb rétegek felé a szenzor vagy beavatkozó szerv halálát. Ha előbb, de kevesebb adattal küldenénk died event-et, mint az adatbázisból való törlés, akkor bizonytalan lenne a működés. Mivel a died event megérkezésekor az átjáró már elkezdte a saját adatbázisának frissítését, ezért az átjáró kommunikációs ágens már nem biztos, hogy időben eléri a megfelelő adatokat.
•
Szenzorok állapotváltozásainak jelzése a measure event segítségével történik. Még a measure event küldése előtt az átjáró eltárolja adatbázisában a legfrissebb értéket. Az event elküldi a szenzor index-ét és a legfrissebb mért értéket. Az index segítségével lekérdezhető a szenzor többi adata, míg a legfrissebb mért érték azonnal rendelkezésre áll. Ha nem küldenénk el a legfrissebb értéket, akkor néhány esetben hibás működést tapasztalnánk. Vegyük azt az esetet, amikor egy ajtónyitást érzékelő szenzor esetén hirtelen kinyitjuk, majd becsukjuk az ajtót. Ebben az esetben kettő measure event generálódik. Az elsőben az ajtó nyitott állapotát, míg a másodikban az ajtó zárt állapotát kell jelezni. Ha nem küldenénk el a friss értéket, hanem az adatbázisból olvasnánk ki, akkor gyors változások esetén a measure event feldolgozása esetén hiba következhet be. Megvan az esély arra, hogy a második measure event küldése előtt megváltozott adatbázisból kéri le az adatot az első measure event-et feldolgozó egység. Így mind a két measure event az ajtó becsukását jelzi a felsőbb réteg felé, mely gyakorlatilag nem fordulhatna elő. A measure event megvalósításánál két lehetőségünk adódott. Mivel az érték lehet bináris és 16 bites is, ezért ezt valahogy jeleznünk kellett a felsőbb rétegek felé. Az első lehetőség szerint mind a bináris, mind a 16 bites értéket 16 bites értékként küldtük volna. Ebben az esetben meg kellett volna oldanunk a bináris szám és a 16 bites szám közötti egyértelmű és megfordítható leképezést. Azonban ennek a leképezésnek a meghatározása nem biztos, hogy minden lehetséges jövőbeli szenzortípushoz megadható lett volna. A másik lehetőség az volt, hogy két típusú event-et valósítunk meg. Ebben az esetben külön event segítségével jeleztük volna egy bináris és egy 16 bites szenzor legfrissebb értékét. Így megmaradt a lehetőségünk arra, hogy új típusú szenzorok esetén könnyedén új típusú event-eket örökítsünk. A választás a második lehetőségre esett a jövőbeni fejlesztés segítése céljából.
•
Amennyiben bármilyen hiba lép fel az átjáró működése során, akkor ezt error event-el jelzi az átjáró kommunikációs ágens felé. Az error event tartalmaz egy karaktersorozatot, melyben a hiba leírása található. Az átjáró kommunikációs ágens error event érkezése esetén megvizsgálja a hiba leírását. Amennyiben a hiba bekövetkezése miatt a további működés feltételei már nem adottak, akkor egy jelzést küld a felsőbb rétegek felé, majd terminálja mind magát, mind az átjárót. A felsőbb rétegekben ebből a jelzésből tudják, hogy az átjáró és az átjáró által kezelt 30
szenzorok és beavatkozó szervek többé már nem elérhetőek. A hiba oka sokféle lehet. Nem lehet felépíteni a kapcsolatot az átjáró és a bázisállomás között, ha a soros vagy USB kábel nincs bedugva mind a két oldalon. A már működő kapcsolat esetén ha kihúzzuk a soros vagy USB kábelt, akkor megszakad a kommunikáció, a kapcsolatot újra fel kell építeni. A bázisállomás tápellátásának megszűnése lehetetlenné teszi a további kommunikációt, működést. Ha a "sensors.xml" vagy "gateway.xml" fájl hiányzik, vagy nem a szabványnak megfelelő felépítésű, akkor az átjáró nem tudja feldolgozni a bennük található adatokat, így a szenzorok és beavatkozó szervek tulajdonságai nem érhetőek el. A hiba kiküszöbölése után az átjáró újraindítása után már fel lehet építeni a kapcsolatot a bázisállomással, újra használható lesz a rendszer. Az átjáró kommunikációs ágenstől az átjáró irányába történő kommunikáció három típusba sorolható. •
Az átjáró kommunikációs ágens a megfelelő függvényekkel bármikor elérheti az átjáró adatbázisát lekérdezés céljából. A felsőbb rétegek felé továbbítania kell a szenzorok és beavatkozó szervek tulajdonságait, mert a felsőbb rétegek ezen információk alapján tudják csak feldolgozni a bejövő mérési adatokat. A legfrissebb mért érték elérése kivételesen fontos, hiszen enélkül a rendszer használhatatlan lenne, a felsőbb rétegek nem kapnák meg az aktuális mért értékeket.
•
Az átjárót bizonyos esetekben utasíthatja az átjáró kommunikáció ágens adatbázisának módosítására. Azonban ilyen esetben is nagyon korlátozott joga van. Ha a felsőbb rétegek felől érkezik egy parancs, mely egy beavatkozó szerv állapotának megváltoztatására szólít fel, akkor ezt kezelnie kell az átjáró kommunikációs ágensnek. Ezt pedig csak úgy tudja elérni, hogy felszólítja az átjárót az adatbázisának módosítására, valamint a megfelelő soros vagy USB portra kiküldeti a beavatkozó szerv állapotának módosítására szolgáló parancsot. Ezt veszi a bázisállomás, és módosítja a beavatkozó szerv állapotát. Erre a beavatkozásra külön függvények állnak rendelkezésre, melyet az átjáró kommunikációs ágens meg tud hívni. Ezzel biztosítható, hogy az adatbázis változásai mindig kövessék a bázisállomásra kötött beavatkozó szervek állapotainak változásait.
•
A kommunikáció harmadik típusa a szenzorok periodikus lekérdezését megvalósító szál vezérlése. Minden egyes lekérdezés tartalmaz egy index és egy interval nevű adatot. Az index azonosítja a szenzort, míg az interval azt adja meg, hogy hány másodpercenként kell az adott szenzort lekérdezni. Amennyiben egy új lekérdezés érkezik az átjáró kommunikációs ágenshez, akkor a megfelelő értékkel azonnal válaszol, majd megvizsgálja az interval mezőt. o Pozitív egész szám esetén új periodikus lekérdezésnek tekinti, és frissíti a szál adatbázisát. Ha eddig nem volt érvényben ciklikus lekérdezés az adott szenzorra, akkor egyszerűen hozzáad egy új periodikus lekérdezést jelentő szabályt. Azonban előfordulhat olyan eset is, amikor már volt ciklikus lekérdezés az adott szenzorra. Ekkor a régi ciklikus lekérdezést törli, majd az új interval mező alapján adja hozzá a új lekérdezési szabályt a szál adatbázisához. Így az egymás után érkező periodikus lekérdezések nem egymástól függetlenül valósulnak meg, hanem mindig az utolsó alapján alakul a ciklusidő.
31
o Nulla érték esetén egyszeri lekérdezés érkezett a felsőbb rétegek felől, ezért új szabályt nem ad a szál adatbázisához. Az egyszeri lekérdezésre a választ az interval mező vizsgálata előtt létrehozta az átjáró kommunikációs ágens. Így a szál adatbázisa nem változik, tehát futását sem befolyásolja ez a lekérdezés. o Az interval -1 értéke azt jelenti, hogy az aktuális szenzor periodikus lekérdezésére a továbbiakban nem tart igényt a felsőbb réteg. Ebben az esetben a szál adatbázisából eltávolítjuk a megfelelő szenzor ciklikus lekérdezését jelölő szabályt. Így az interval mező vizsgálata előtt az átjáró kommunikációs ágens által létrehozott válasz volt az utolsó, mely ehhez a szenzorhoz tartozó ciklikus lekérdezéshez tartozott. Azonban a jövőben ezek után is lesz lehetőség periodikus lekérdezés definiálására pozitív egész számot tartalmazó interval mezőjű lekérdezés segítségével. Az átjáró futás közbeni jelzései a felhasználó felé Az átjáró futását csak a bázisállomás jelzései, parancsai és az átjáró kommunikációs ágens tudja befolyásolni. Felhasználói beavatkozást közvetlenül nem kezel, és kimenetén is csak a legfontosabb adatok jelennek meg. Ezért nem szükséges a több erőforrást használó grafikus felület használata, egy egyszerű karakteres felület is elég átlátható. A megjelenített adatok alapján ellenőrizni tudjuk a bázisállomás és az átjáró között lejátszódó kommunikáció lépéseit. Amennyiben valamilyen hibát észlelünk az egész rendszer működésében, akkor az átjáró működést ezen karakteres felület alapján meg tudjuk vizsgálni. Ezek után el tudjuk dönteni, hogy okozhatja-e ezt a hibát az átjáró működése, vagy azt máshol kell keresni. A 4.1. ábra az átjáró karakteres felületét mutatja futás közben. A "Trying port: COM0" típusú sor azt jelenti, hogy az átjáró teszteli azt, hogy a COM0 port létezik-e az adott gépen és a számunkra megfelelő hardware beállításokkal kommunikációra képes-e. A "Stable library" és következő három sort az RXTX library [11] írja ki az első használat során. A "Found port: COM1" típusú sor esetén a vizsgált port létezik, képes kommunikálni a számunkra szükséges hardware beállításokkal és nyitott. Így lehetséges a kommunikáció rajta keresztül. Ez még nem jelenti azt, hogy ezen a porton keresztül érhető el bázisállomás. Jelen esetben a "COM1" és "COM3" port is megfelelő lenne, de értelmezhető válasz csak a "COM4" porton keresztül érkezik. A "Writing "VER" to //./COM1" típusú sor estén az átjáró a megjelenített parancsot küldi a bázisállomás felé a megjelölt porton keresztül. A "Read: IO VER 2.5REVG" típusú sor esetén pedig a bázisállomás küldte a "READ: " után lévő karakterláncot az átjáró felé. Ebben az esetben a firmware verzióját közölte. A "Read: SET087940" sor után következő sorban a nyolcas analóg szenzor 16 bites értékét a program átszámolta egész számmá. Így keletkezett a "26"-ot tartalmazó sor, mely 26ºC-t jelent, mert a nyolcas porton hőmérsékletmérő szenzor található.
32
4.1. ábra. Az átjáró kimenete 4.1.2.
AZ ÁTJÁRÓ KOMMUNIKÁCIÓS ÁGENS
Az átjáróhoz kapcsolódó átjáró kommunikációs ágens a következő feladatokat képes ellátni: •
Indulásakor beírja magát a rendszer regisztrációs adatbázisába.
•
A központi kommunikációs ágenstől érkező kapcsolódási kérést feldolgozza, kiépíti a kapcsolatot, erről nyugtát küld, majd bejelenti a központi kommunikációs ágensnél az összes, a kapcsolat kiépítésekor rendelkezésre álló szenzort.
•
A központi kommunikációs ágenstől érkező kapcsolatbontási kérést feldolgozza, bontja a kapcsolatot. Ez után a központi kommunikációs ágensnek a megfelelő bázisállomáshoz tartozó összes, szenzort modellező árnyék ágenst meg kell szüntetnie, mert ezek már nem érhetőek el. Az átjáró és a bázisállomás közötti kapcsolatot nem bontja le. Az átjáró adatbázisában továbbra is frissülnek az
33
adatok. Így egy későbbi csatlakozási kérelem estén nem kell újra felépíteni a kapcsolatot a bázisállomással. •
Ha egy új szenzor születik, akkor az átjárótól kap egy born event-et, majd küld egy üzenetet a központi kommunikációs ágensnek, ami ennek hatására létrehozza az új szenzort modellező árnyék ágenst. A központi kommunikációs ágenstől válaszul nyugtát kap az árnyék létrejöttéről és eltárolja annak címét.
•
Ha egy szenzor meghal, akkor az átjárótól kap egy died event-et, majd küld egy üzenetet a központi kommunikációs ágensnek, ami ennek hatására megszünteti a szenzort modellező árnyék ágenst.
•
Ha az átjáró és a bázisállomás közti kapcsolat megszakad (pl. kihúzzuk a soros vagy USB kábelt, megszakad a bázisállomás tápellátása vagy egyéb kommunikációs hiba lép fel), akkor egy error event-et kap az átjárótól, melynek hatására üzen a központi kommunikációs ágensnek a hibáról, ami ezután lebontja a kapcsolatot az átjáró kommunikációs ágenssel, és megszünteti a hozzá tartozó árnyék ágenseket. A kapcsolatot záró nyugta megérkezése után az átjáró kommunikációs ágens terminálja az átjárót és önmagát. A hiba megszüntetése után újra elindíthatjuk az átjárót, így újra működőképes lesz.
•
Ha egy bináris szenzor állapota megváltozott, kap egy measure event-et az átjárótól, majd az új értéket elküldi a megfelelő árnyék ágensnek.
•
Kiszolgálja az egyes szenzorok árnyék ágenseitől érkezett lekérdezéseket az adott szenzor aktuális állapotának visszaadásával.
•
A központi kommunikációs ágenstől érkező periodikus lekérdezéseket megvizsgálja, majd ezek alapján vezérli az átjáróban található, periodikus lekérdezést megvalósító szálat.
•
Leállításkor kitörli magát a rendszer regisztrációs adatbázisából.
4.2.
A VEZETÉK NÉLKÜLI SZENZOROK ÉS HÁLÓZATI GATEWAY
A vezeték nélküli eszközök tér hódítása a biztonságtechnikai alkalmazásokban egyre jelentősebb. Ezek a szenzorok intelligens eszközök, mivel a hagyományos mérési funkciókon túl számos egyéb szolgáltatással is rendelkeznek. Ilyen szolgáltatás például az is, hogy az adhoc hálózat kezelését támogató eszközök megtalálhatóak rajtuk, illetve ezek az eszközök konfigurálhatóak, információt szolgáltatnak képességeikről, azonosítják magukat, lekérdezhető az állapotuk, stb. Ezeknek a hálózatoknak már napjainkban is sokféle felhasználási területük van. Egyes projektek kifejezetten kutatási célokat szolgálnak, de emellett megjelentek már néhány helyen a szenzorhálózatokat ipari alkalmazásra gyártó cégek is. A legjelentősebb kutatásokat a témában a kaliforniai Berkeley Egyetemén végzik. A NEST (Network Embedded Systems Technology) projekt keretében nyílt forráskódú kísérleti szoftvereket fejlesztenek szenzorhálózatok számára [20]. Ennek célja, hogy meggyorsítsák a szenzorok területén a fejlesztést, minél jobban kiterjesszék a területen történő kutatásokat. Itt fejlesztették ki a TinyOS [13] operációs rendszert, amelynek segítségével már több szenzorcsaládra fejleszthetünk szoftvert. A TinyOS egy olyan nyílt forráskódú beágyazott operációs rendszer és platform, melyet vezeték nélküli szenzorhálózatokhoz fejlesztettek ki. NesC nyelven írták, és úgy tervezték meg, hogy képes legyen a gyors innováció támogatására, valamint a meglévő 34
memóriakorlátokon belüli működésre. A TinyOS-t a Kaliforniai Berkeley Egyetemen fejlesztették ki az Intel Research közreműködésével. Mostanáig két jelentősebb verziója készült el, az egyik az 1.x (T1) és a 2.x (T2). A T2-es rendszer előnyei az előző verziókkal szemben a megnövelt robosztusság, integrált energia- és erőforrás-menedzsment, valamint egyes fő interfészek újratervezése az egyszerűbb programozhatóság érdekében. A TinyOS applikációkat - a fő rendszerhez hasonlóan – nesC nyelven kell megírni, ami a C programnyelv egy olyan dialektusa, melyet a szenzorhálózatok alacsony memóriakapacitására optimalizáltak. A TinyOS rendszer annyiban különleges, hogy beépített interfészeket, modulokat, valamint szenzor-specifikus konfigurációkat tartalmaz. Ez lehetővé teszi a programozók számára, hogy az írt szoftvereket (amelyek program-specifikus feladatokat látnak el) egymáshoz kapcsolódó modulok összességeként alkossák meg. A biztonsági keretrendszerünkben vezeték nélküli szenzorok céljára a Crossbow Technology által kifejlesztett MicaZ típusú (mote) eszközöket használtunk (lásd 3.12. ábra), melyeken a következő érzékelők találhatóak [12, 18]: •
Hőmérsékletmérő
•
Fénymérő
•
Mikrofon
A vezeték nélküli szenzor átjáró egy speciális hálózati illesztő, ami kapcsolatot teremt a bázisállomással (lásd 3.11.ábra), amelyen keresztül kapcsolódik a vezeték nélküli szenzorhálózat az Ethernet hálózatra. Ezt a vezeték nélküli eszközt egy Java program könyvtárral a TinyOS 1.1 el tudjuk elérni, lekérdezni és működtetni, mely WindowsXP környezetben Cygwin platform alatt fut. A TinyOS telepít egy Cygwin platformot, amit a saját futtatásához hangol [13, 15]. Az átjárót, ami kapcsolatot teremt a különböző szenzorokkal, és adatokat gyűjt tőlük, ezzel a platformmal tudjuk elérni a TinyOs által biztosított SerialForwarder program segítségével, mely a 4.2. ábrán látható.
4.2. ábra. SerialForwarder Ez egy Java alkalmazás mely kapcsolatot teremt a vezeték nélküli átjáró és a PC között. A PC-n a #9001-es portot nyitja meg, és ezen kommunikál a vezeték nélküli átjáró TCP/IP
35
szerverével, mely a #10002-es porton fogadja és küldi az üzeneteket a PC felé. A SerialForwarder-hez kapcsolódik a 4.3. ábrán látható MoteManager és a TreeManager.
4.3. ábra. A TreeManager (bal oldal) és MoteManager (jobb oldal) A MoteManager dolgozza fel számunkra értelmezhető formába a szenzoroktól érkező jeleket és továbbítja az átjáró kommunikációs ágens felé. Az alkalmazáson található egy „Build new tree” gomb, mely segítségével az átjáró megvizsgálja, hogy mely mote-ok érhetőek el és újra megalkotja a szenzor térképet. Tartalmaz továbbá néhány konfigurációs ablakot, illetve a kiválasztott mote-on található jelző ledek és hangszóró be illetve kikapcsolására szolgáló gombokat. Egy xml definíciós fájl tartalmazza a szenzorok azonosításához szükséges adatokat. Ezt be kell töltenünk a TreeManagerbe, mivel ez alapján tudjuk meghatározni, hogy az adott mote-on milyen szenzorok találhatóak és, hogy a mért érték, hogyan számolható át az általunk ismert mértékegységekbe. Továbbá tartalmaz egy 2Ds szenzor térképet, mely megadja, hogy mely mote-ok csatlakoztak a hálózathoz. Ahogy azt már az architektúra logikai felépítésénél láthattuk (lásd 2.1. ábra) mindegyik átjáróhoz csatlakozik egy autonóm átjáró kommunikációs ágens, melynek az a feladata , hogy az átjáró és a központi kommunikációs ágens között megteremtse a kommunikációs csatornát. Célszerűen az átjáró és a hozzá tartozó kommunikációs ágens ugyan azon a helyen található, mivel teljesen összefügg a létezésük. Azaz ha nincs átjáró, akkor a hozzá tartozó kommunikációs ágens sem létezhet. Ahhoz hogy ágensekbe tudjuk szervezni az egész rendszerünket, a Jade programkönyvtárat használjuk. A vezeték nélküli kommunikációs átjáró feladata, hogy a TinyOS [13, 15] és a Jade [14] környezet közötti szakadékot áthidalja. A két program könyvtár szinkronizálását úgy oldottuk meg, hogy a vezeték nélküli kommunikációs ágens egy natív Windows-os környezetben fut, ahol is a Jade minden gond nélkül képes futni, és így a kommunikációs ágens regisztrálni tud az ágensek közé, a vezeték nélküli átjáróhoz pedig egy belső socket kapcsolattal csatlakozik.
36
4.2.1.
HÁLÓZAT ÉPÍTÉS (GLOBÁLIS KOMMUNIKÁCIÓ)
A mote-ok csak azokat a szomszédaikat tartják számon, amelyekkel szülő-gyerek kapcsolatban vannak. Ez azt jelenti, hogy arról fogalmuk sincs, hogy két ugrással arrébb ki fogja venni az üzeneteket. Ha valaki olyan üzenetet szeretne küldeni, amelynek végső állomása a számítógép (gyökér), akkor ezt a lehető legkisebb redundanciával tudja megtenni. Ennek módja, hogy minden mote a szülőjének továbbítja azt, így csak azok kapják meg, akik biztosan kapcsolatban állnak a gyökérrel. A 4.4. ábrán a 3. számú mote küld eredményt a számítógép felé [16].
4.4. ábra. Mérési eredmény küldése a szenzortól a központi számítógéphez. A számítógép-szenzor irányú üzenetküldés már nem ennyire egyszerű. Mivel egy mote nem tudja, hogy a címzett a gyerekein túli szinten a fa melyik ágán található, ezért el kell küldenie mindegyiknek. Ebből következik, hogy a számítógépről jövő bármely üzenet (kivéve a nyugtákat, mert azok csak egy ugráson belül érvényesek) eljut a fa összes leveléhez. Ezt az üzenettovábbító algoritmust „Flood Routing”-nak nevezzük. A 4.5. ábrán látható példában a számítógépről flood routing algoritmussal juttatunk el üzenetet a hálózat minden eleméhez. A nyilak az üzenet útját mutatják a hálózaton belül.
4.5. ábra. Üzenetküldés a központból a szenzorok felé 37
Alkalmazásának legfőbb előnye, hogy egy mote-nak nem kell feltérképeznie a hálózat többi részét, csak amivel közvetlen interakcióban van. Felvetődik a kérdés, hogy az üzenetek ilyen módon való továbbítása nem generál-e feleslegesen túl nagy forgalmat? Mindenekelőtt figyelembe kell venni, hogy ezzel az eljárással mindamellett, hogy nagyban leegyszerűsödik az algoritmus, még sok memóriát is megspórolhatunk, mert nem kell fenntartaniuk külön irányítótáblát (routing table). Tehát ha két szenzor között kapcsolat épül fel, vagy megszakad, akkor erről az egész hálózatot értesíteni kell. A flood routing algoritmussal csak a számítógép által küldött üzeneteket továbbítjuk, és ezeknek száma a mote-számítógép irányú adatforgalommal szemben nagyon csekély. 4.2.2.
A DEFINÍCIÓS FÁJL
A generátor-programhoz használt definíciós fájl egy alapvetően xml formátumú, a szenzorkártyákra és a szenzorokra jellemző specifikus tulajdonságokat, konverziókat, és egyes kódrészleteket tartalmazó fájl. A generátor részben ezt használja fel a kiválasztott szenzorok kódjának megalkotására. Azok a kódrészletek kerültek az xml fájlba, amelyek a generált kódtól függetlenek, azaz minden helyzetben változatlanok maradnak. Ilyen kódok például a keret konfigurációs fájljába kerülő kódok, vagy az egyes szenzorok standard kontrolljával összefüggő kódok egy része (init, start, stop). Azok a kódok, amelyek a generálás körülményeitől függenek (ilyen körülmény például, hogy hány fajta / mennyi szenzort generálunk), vagy információt tartalmaznak a keret fájlbeli műveletekről (tartalmaznak keretbeli változókat, tömböket) nem a definíciós fájlban kerültek tárolásra, hanem magában a keretmodulban. Így tehát a keretmodul tekinthető egy „másodlagos definíciós fájlnak” is, mivel egyes részek innen kerülnek feldolgozásra (make & replace). A definíciós fájl a tervezett szoftverek közül azonban nem csak a generátorral van kapcsolatban, hanem a MoteManager megjelenítő- és kezelőprogram működésében is fontos „adatbázis” szerepet játszik. Ez a fájl tartalmazza ugyanis az egyes szenzorok „dekódolásához” szükséges információkat. A MoteManager önmagában képes lenne fogadni a felprogramozott eszközöktől jövő üzeneteket, felismerné, hogy melyik mote a forrása, azonban a definíciós fájl nélkül nem tudná értelmezni, hogy a kapott érési eredmény az adott mote mely szenzorának eredménye volt, sem azt hogy egy adott mote milyen szenzorokkal rendelkezik egyáltalán. Látható tehát, hogy a definíciós fájl tulajdonképpen az egész alkalmazás-csoport lelke, nélküle a többi program teljesen, vagy többnyire működésképtelen lenne. 4.2.3.
A VEZETÉK NÉLKÜLI HÁLÓZATI ÁTJÁRÓ
A vezeték nélküli bázisállomáshoz (mote0) Ethernet hálózaton kapcsolódott átjáró feladata, a bázisállomáshoz csatlakozó mote-okon található szenzorok minden adatának tárolása és ezek folyamatos karbantartása, a felsőbb rétegek felöl érkező lekérdezések kiszolgálása. Az vezeték nélküli átjáró felépítése A vezeték nélküli hálózati átjáró négy részből áll: •
SerialForwarder: ez egy Java alkalmazás (lásd 4.2 ábra), mely segítségével kapcsolódni tudunk a vezeték nélküli bázis állomáshoz (mote0).
•
MoteManager: ez egy Java alkalmazás (lásd 4.3 ábra), mely négy fő részből áll: o Incomming messages: A felső részben található egy üzenet mező. Ezen jelennek meg a rendszer üzenetek, melyek segítségével nyomon tudjuk követni, hogy mi történt a rendszerünkben. 38
o Connection Config: Ez a panel a MoteManager bal alsó részében található. A kommunikációs protokoll acknowledgement kezelés paramétereinek beállítására szolgál. o Mote Config: Tartalmaz egy „Build new tree” nevű gombot, melyet megnyomva az átjáró újra lekérdezi, hogy milyen mote-ok csatlakoztak a hálózathoz és, hogy azoknak milyen paramétereik vannak. o Actions: Ez a panel a MoteManager jobb alsó részében található és négy gombot tartalmaz, melyek egymás alatt helyezkednek el. A felső három a kiválasztott mote-on található különböző színű (piros, zöld, sárga) jelző ledek kivilágítására, illetve eloltására szolgálnak. A legalsó pedig a kiválasztott mote-on található jelző hangszóró megszólaltatására, illetve kikapcsolására használható •
Tree manager: ez egy Java alkalmazás (lásd 4.3 ábra), mely négy részből áll: o A Tree manager felső részben található egy 2D-os térkép, mely a rendszerhez csatlakozott mote-okat ábrázolja. Ez az ábrázolás nem felel meg a mote-ok tényleges egymáshoz képest való elhelyezkedésének. Ezen a térképen tudjuk kijelölni, hogy melyik az a mote, amelynek valamely szenzorának adataira szükségünk van. A térképen a mote a sorszámával azonosítható. Ez alatt megjelenik egy zöld, vagy egy piros státuszt jelző ikon, attól függően, hogy minden rendben van e mote-al, ha igen, akkor zöld színű az ikon, ha pedig valami probléma van vele (pl.: lemerült az elem), akkor piros színre vált az ikon. A státuszt jelző ikon mellet pedig kis ikonok jelzik, hogy milyen érzékelők találhatóak az adott mote-on. o Available Sensor IDs: Ez a panel Tree manager bal alsó részében található. Egy szöveg mezőt tartalmaz, ahol megjelennek a definíciós XML fájl alapján lehetséges szenzortípusok és azonosítóik. o Selected Mote: Ez egy szöveg mező, amely a Tree manager jobb oldalán található. A kiválasztott mote aktuális állapot adatait írja ki. Azt hogy mi a kiválasztott mote azonosítója, státusza (online/offline), utolsó lekérdezésének időpontját, és a tápjaként szolgáló elemek állapotát. o A Tree manager jobb alsó részén található három gomb: Open definition xml: Ennek segítségével tudjuk betölteni a szenzor definíciós xml fájlt, amely azt tartalmazza, hogy mely szenzorazonosító, milyen szenzort takar, ugyanis a mote csak az azonosítót tárolja és azt lekérdezve, ha nem ismernénk, hogy melyik azonosító milyen érzékelőt jelent, nem is tudnánk vele dolgozni. Toggle Reaction(off): Ezt a gombot ha bekapcsoljuk egyenként át tudjuk helyezni a mote-kat a 2D-os térképen a jobb átláthatóság kedvéért. Ilyen kor a gomb felirata átvált „Toggle Reaction(on)”ra. Arrange Motes: Véletlen szerűen újra rendezi az összes mote-ot a 2D-s térképen.
•
Mote: #id: A Tree manager 2D-os térképén kiválasztva egy mote ugrik fel, ez az ablak, ami a 4.6. ábrán látható. A felső részén minden érzékelőnek megjeleni egy saját fül, amelyet kiválasztva lekérdezhető a kiválasztott érzékelő mérési
39
eredménye. Lehetőség van egyszeri, illetve ismétlődő lekérdezésre, melynél beállíthatjuk, hogy milyen időközönként kérje le a szenzor mérési adatait.
4.6. ábra. A szenzorok mért értékeinek lekérdezésére szolgáló ablak Az vezeték nélküli átjáró működése Először a SerialForwarder-t (lásd 4.2. ábra) kell elindítani a Cyqwin platformon, mely a 4.7. ábrán látható. Miután sikeresen betöltődött ez a TinyOS disztribúció, csatlakozunk Ethernet kapcsolaton keresztül a bázisállomáshoz (mote0). Csatlakozásnál meg kell adni, hogy milyen típusú a bázis állomásunk (pl.: serial, network, stb.) ezután egy „@” karakter következik, majd pedig, hogy mik a bázis állomás csatlakozási paraméterei. Esetünkben mivel mi Ethernetes bázis állomást használunk ezért a „@” karakter után megadjuk hogy mi a bázis állomás ip címe, illetve, hogy melyik porton fogadja az üzeneteket. Tehát ebben a konkrét esetben a következőképpen néz ki a bázis állomás címe: [email protected]:10002 Az átjáró a #9001-es porton küldi, illetve fogadja az üzeneteket a bázis állomástól. Amint sikeresen csatlakoztunk a bázis állomáshoz, indíthatjuk a MoteManager-t, mely egyből indítja Tree manager-t is. Amint elindultak az alkalmazások, lekérdezi a bázis állomástól, hogy melyik mote-ok csatlakoztak a rendszerhez, illetve, hogy azokon milyen szenzorok helyezkednek el. Miután betöltöttük az XML definíciós fájlt a Tree manager-be, már azonosítani is tudja az érzékelőket az átjáró. Mikor elindul a MoteManager összegyűjti az összes, a bázisállomás által elérhető szenzor paramétereit, melyeket folyamatosan frissít az elérhető szenzorok listájával együtt. Miután sikeresen létrejött az átjáró el kezdi figyelni a #9009-es portot, hogy jön e azon valamilyen üzenet, mivel a vezeték nélküli átjáró kommunikációs ágens ezen a porton keresztül fog csatlakozni az átjáróhoz. Amint észleli, hogy csatlakozási kérelem jön a kommunikációs ágens felöl, elfogadja azt kiépíti a kapcsolatot, és ha ez sikerült ez, akkor nyugtát küld vissza a sikeres kapcsolódásról. Ezután pedig elküldi a szenzorok és azok paramétereinek listáját az átjáró kommunikációs ágensnek.
40
4.7. ábra. A szenzorok mért értékeinek lekérdezésére szolgáló ablak Amikor egy mote-ot üzembe helyezünk, az inicializálási folyamat után elküld egy üzenetet, amelyben jelzi, hogy csatlakozni szeretne a hálózathoz. Ezekre az üzenetekre addig nem érkezik válasz, amíg nem kapcsoljuk be a MoteManagert. Amikor ezt megtesszük, a program a nullás című mote–on keresztül lehetővé teszi a többieknek, hogy csatlakozzanak hozzá (ő lesz az így felépített fa gyökere). Egy már fában lévő mote-hoz csatlakozás a következőképpen zajlik: •
A csatlakozni kívánt szenzor elküldi a 255-ös címre a csatlakozási kérelmet. Ezt az üzenetet minden mote feldolgozza aki hallotta, de nem küldenek rá nyugtát.
•
Nyugta helyett egy olyan üzenetet küldenek neki, amelyben tudatják, hogy ők képesek az üzeneteit eljuttatni a gyökérhez.
•
Mikor a csatlakozni kívánó mote ezen üzenetek közül a legelsőt meghallja, akkor üzenet küldőjét fogja közvetlen szülőjének tekinteni. Ha mindegyik üzenet elveszik (vagyis a mote egyiket sem hallja meg), akkor 5 másodperc múlva előről próbálkozik.
•
A következő lépés, hogy egy üzenetben kéri a szülőjét, hogy vegye fel a gyerekei közé. Ez nagyon lényeges, mert egy mote csak a saját gyerekeitől (vagy a szülőjétől) fogadja el az üzeneteket (néhány speciális típus kivételével). Erre már nyugtát vár, és ezen kívül egy másik üzenetet is küld a számítógépnek, amelyben tudatja, hogy most már ő is a fa része és várja a további utasításokat.
4.2.4.
AZ VEZETÉK NÉLKÜLI ÁTJÁRÓ KOMMUNIKÁCIÓS ÁGENS FELÉPÍTÉSE ÉS
MŰKÖDÉSE
Alapvetően két fő részre bontható ez az ágens. Az egyik az, amelyik kezeli az átjáró felé irányuló kommunikációt, a másik pedig az, amelyik a központi kommunikációs ágenssel tartja a kapcsolatot. Ennek a segítségével sikerül áthidalni a TinyOS [13, 15] és a Jade [14] programkönyvtárak közötti különbözőségeket.
41
Miután sikeresen létrejött az átjáró elindul a hozzá tartozó kommunikációs ágens. Első lépésben egy inicializáló rész fut le, ami két részre bontható: •
Kiépíti a socket kapcsolatot az átjáró felé. Mivel fizikailag egy helyen célszerű elhelyezni őket és az átjáró a #9009 porton várja az átjáró kommunikációs ágens csatlakozását ezért az a „localhost” #9009-es portjához kapcsolódik. Ezzel megteremtettük közöttük a kommunikációs csatornát.
•
Ezután pedig beregisztrál a számára megfelelő Jade nyilvántartási rendszerbe, mely egy különálló szerveren található, ahogy az a 3.1. ábrán látható.
Ezután öt viselkedési szál indul el, amelyek fogadják a mindkét irányból érkező kéréseket és válaszokat és továbbítják azokat a megfelelő helyre. •
Az első szál az átjáró felöl érkező üzeneteket kezeli. Ahogy létrejön az átjáró és a kommunikációs ágense között a kapcsolat, az átjáró elküldi neki az összes az általa elérhető szenzorokat és azt a kommunikációs ágens eltárolja. Amikor az átjáró érzékeli, hogy új szenzor csatlakozott a hálózathoz, vagy esetleg kiesett valamelyik már korábban csatlakozott érzékelő, akkor erről értesítést küld a kommunikációs ágensnek, amely frissíti az adatait és ha már csatlakozott hozzá egy központi kommunikációs ágens akkor jelzi felé a változásokat.
•
A második szál központi kommunikációs ágens csatlakozási kérelmét kezeli. Ha szabad az átjáró kommunikációs ágens, azaz nincs hozzá kapcsolódva egy másik központi kommunikációs ágens, akkor kapcsolódhat hozzá a kérelmet indító központi kommunikációs ágens, különben visszautasítást kap. Ahogy létrejön a kapcsolat közöttük, azt átjáró kommunikációs ágens elküldi a hozzákapcsolódott átjáró által elérhető szenzorok paramétereit a következő formában: o Sensor Name: Az érzékelő neve, amely a mi esetünkben – mivel az MTS300CA mote-ot használtuk a vezeték nélküli hálózatunkban – lehet Temperature (hőmérséklet mérő), Light (fény mérő) és Microphone (mikrofon). o Port index: Ebben a paraméterben küldi el az átjáró kommunikációs ágens, hogy melyik mote-on (pl.: mote5, mote 7, stb.) találhatóak a szenzorok és hogy mi az azonosítójuk. o Type: Az érzékelő típusa, mely lehet: ANALOG, BOOL és DIGITAL.
•
A harmadik szál kezeli a központi kommunikációs ágens felöl érkező kéréseket. Amikor kijelölünk egy szenzort a központi kommunikációs ágensben, akkor az küld egy lekérdezést az átjáró kommunikációs ágensnek, ami tovább küldi a lekérdezést az átjárónak. Mikor az átjáró lekérdezte a kiválasztott érzékelő aktuális értékét, elküldi a kommunikációs ágensének, az pedig tovább küldi a központi kommunikációs ágensnek, ahol megjelenik a kiválasztott szenzor mérési értéke.
•
A negyedik szál hiba esetén, küld egy üzenetet a hibáról a központi kommunikációs ágensnek, ami lebontja a kapcsolatot az átjáró kommunikációs ágenssel, és megszünteti a hozzátartozó árnyék ágenseket. A kapcsolatot záró nyugta megérkezése után az átjáró kommunikációs ágens terminálja az átjárót és önmagát. A hiba megszüntetése után újra elindíthatjuk az átjárót, így újra működőképes lesz.
42
•
Az ötödik szál pedig az árnyék ágensek létrejötte után AGREE-vel adja vissza a nevüket.
4.3. SOFTWARE SZENZOROK ÉS HÁLÓZATI GATEWAY 4.3.1.
SZOFTVER SZENZOROK ÉS BEAVATKOZÓK
A szoftver szenzorok olyan speciális programok, amelyek a számítógépes rendszerekből gyűjtik az információt. Az információ lehet a felhasználó tevékenysége (belépés, nyomtatás, ...), a telepített szoftverek és szolgáltatások állapota (leállt, túlterhelt, …) vagy a számítógépes eszközök állapota. Ezek a programok tartalmazhatnak beavatkozókat is, amelyek a rendszer tulajdonságainak megváltoztatására szolgálnak. Ilyen tulajdonság lehet például: egy felhasználó nyomtatásának megtiltása, egy szolgáltatás leállítása vagy újraindítása, egy számítógép kitiltása a hálózatról. 4.3.2.
SZENZOROK ÉS BEAVATKOZÓK FAJTÁI
A felhasználói tevékenységet egy szoftver szenzor többféle úton is figyelemmel kísérheti. Az egyik lehetőség, hogy a programok naplófájljait elemezzük. Ekkor a szenzor általában csak a tevékenység befejezése után értesül róla. Ezeket a szenzorokat könnyű megvalósítani, nem kell a meglévő programokhoz hozzányúlni. A hátránya, hogy a tevékenységet nem tudjuk megszakítani, amiatt hogy a szenzor csak a befejezéskor értesül róla. A másik lehetőség, hogy a felhasználói programokba építjük bele a szenzort és a beavatkozót. Ez nyilvánvalóan sokkal nehezebb feladat, de ennek segítségével maximálisan kontrollálható a felhasználói tevékenység. Általában nincs szükség arra, hogy megszakítsunk egy tevékenységet, mert vagy már előtte ellenőrizve lett a jogosultság, vagy elegendő a további tevékenységek tiltása. Így a legtöbb esetben az első megoldás is megfelelő. Néhány lehetőség a szoftver szenzorok és beavatkozók felhasználására: •
Külső eszközök (pl. USB), letiltás és engedélyezés központilag.
•
Floppy, CD, DVD olvasás és írás felügyelete, központi engedélyezése vagy letiltása.
•
Nyomtatóhasználat felügyelete.
•
Fizikai betörés esetén a bejelentkezések letiltása, érintett személyek értesítése.
•
Időszakhoz (pl. munkaidő) kötött bejelentkezés.
•
Számítógépek, felhasználók, csoportok központi engedélyezése és letiltása.
•
Támadás esetén a riasztáshoz szükséges erőforrások, csatornák felszabadítása és lefoglalása.
•
Dokumentumok megnyitásának és nyomtatásának központi engedélyezése, és bizonyos körülményekhez (idő- vagy térbeli korlátokhoz) kötése.
•
Felhasználók biometrikus jellemzőinek figyelése (pl. gépelési, billentyűzet / egérhasználati szokások), és szükség esetén azonosítás kérése, vagy illetékesek értesítése.
•
Tárolóeszközök (pendrive, HDD) azonosítójának bevonása a biztonsági szolgáltatásokba.
•
Szolgáltatások (webszerver, levelezőszerver, vírusirtó, tűzfal) állapotának felügyelete, normálistól eltérő viselkedés esetén riasztás. 43
•
Hálózati forgalom figyelése, gyanús forgalom esetén a számítógép kitiltása a hálózatról.
Nyomtatás figyelő (CUPS alapon) [26, 27] és számítógépes bejelentkezés figyelő (PAM alapon) [21 - 25] szoftver szenzort készítettünk, ennek megvalósítása a csatolt mellékletben található meg. 4.3.3.
SZOFTVER SZENZOROK A TERVEZETT RENDSZERBEN
A szoftver szenzorok és beavatkozók az un. szoftver átjárón keresztül kapcsolódnak a rendszerbe. Ezek az átjárók olyan speciális programok, amelyek a szenzoroktól jövő információt eljuttatja a központi kommunikációs ágensnek. Valamint a rendszerből jövő beavatkozó jelet elküldi a megfelelő szoftver beavatkozónak. A szenzorok hálózati TCP/IP protokollal kommunikálnak az átjáróval. Egy szenzor egy átjáróval tartja a kapcsolatot, egy átjáróhoz több szenzor és beavatkozó tartozhat. Minden szoftver szenzort futtató gépen fut egy átjáró program is ami növeli a rendszer megbízhatóságát. Ahol ez valamilyen okból nem megoldható, ott a szenzorok és a beavatkozók egy távoli átjárón keresztül kapcsolódnak a rendszerhez. 4.3.4.
SZOFTVER SZENZOR ÉS AZ ÁTJÁRÓ KOMMUNIKÁCIÓJA
Minden szoftver szenzorhoz tartozik egy konfigurációs fájl, ami tartalmazza az elsődleges átjáró elérhetőségét (IP cím, port) és további tartalék átjáró elérhetőségét arra az esetre, ha az elsődleges nem elérhető. A szenzor program induláskor megpróbál csatlakozni az elsődleges átjáróhoz, ha ez nem sikerül, akkor próbálkozik egy tartalék átjáróval. Ha megszakad a kapcsolat az átjáró és a szenzor között, akkor ugyanúgy próbál újracsatlakozni, mintha most indult volna el, azaz először mindig az elsődleges átjárót próbálja elérni. A szenzor és az átjáró XML üzeneteket küld egymásnak TCP protokollon. A szenzor kapcsolódásának menete: 1. A szenzor felépít egy TCP kapcsolatot az átjáróval. 2. A szenzor elküld egy XML üzenetet az átjárónak, az üzenet tartalmazza a szenzor azonosító adatait. 3. Az átjáró létrehoz egy árnyékágenst a szenzornak, majd létrehoz neki egy saját TCP kommunikációs csatornát (egy új portot hoz létre). Válaszban megküldi az új kommunikációs csatorna paramétereit. 4. A szenzor lebontja a TCP kapcsolatot, majd felépíti az új kommunikációs csatornát. Minden szenzorhoz külön kommunikációs csatorna tartozik. A szenzorok adott időközönként egy információ nélküli XML üzenetet küld el az átjárónak, ezzel jelezve, hogy még él. Amennyiben az átjáró nem kap ilyen üzenet, megszünteti a szenzorhoz tarozó árnyék ágenst és lebontja a TCP kapcsolatot a szenzorral. A szenzor a begyűjtött információkat egy XML üzenetben elküldi az átjárónak. Az átjáró ezt feldolgozza, majd továbbküldi a szenzor árnyék ágensének. Ily módon kerül be a rendszerbe egy szoftver szenzor által mért jel. A tervezéskor fontos szempont volt, hogy az átjáró független legyen a szenzoroktól. A szenzor a rá jellemző adatokat elküldi kapcsolódáskor az átjárónak, úgy, mint: azonosító, figyelt jelek, a mért jelek típusa (egész szám, valós szám, szöveg). Amikor a szenzor elküld egy információt az átjárónak, megadja a saját azonosítóját, továbbá a mért jel azonosítóját és annak értékét. Egy üzenetben a szenzor több jel értékét is elküldheti.
44
4.4. A
KÖZPONTI KOMMUNIKÁCIÓS ÁGENS ÉS AZ ÁRNYÉK KONFIGURÁCIÓS ÁGENS
A központi kommunikációs ágens és az árnyék konfigurációs ágens funkciói annyira közel állnak egymáshoz, hogy megvalósítás szempontjából egy ágensben egyesítettük a funkcióikat, így értékes rendszererőforrásokat spórolhatunk meg. A továbbiakban a két ágenst egyben, központi kommunikációs ágensként hívjuk majd. A központi kommunikációs ágensen keresztül vezérelhető a rendszer és nyerhetőek ki a szenzorok adatai. Mivel a felhasználók ezen az ágensen keresztül tudnak kapcsolatba lépni a rendszerrel, ezért az ágens nem csak a Jade keretrendszer szintaktikájának megfelelő parancssoros módon indítható el, hanem egy egyszerű, a hétköznapi felhasználók számára is átlátható kezelőfelületen keresztül is. Ez az indító ablak a 4.8. ábrán látható. A központi kommunikációs ágens létrehozásához mindössze két információra van szükségünk. Az első, és legfontosabb a Jade rendszer Main container-ének címe, ami a példa esetében a localhost. Ez a 127.0.0.1-es IP címet helyettesíti, ami az éppen használt számítógép címe. A második megadandó paraméter a létrehozandó ágens neve, amely tetszőleges lehet, jelen esetben például „CentralAgent1”. Ez után a „Create” gombra kattintunk, és el is indul a központi kommunikációs ágens. Ha az ágenst le szeretnénk állítani, azt a „Kill” gombbal tehetjük meg.
4.8. ábra. A központi kommunikációs ágens grafikus felhasználói felülete Mivel a Jade rendszer Java alapokon nyugszik, ezért támogatott ágensek létrehozása és vezérlése Java alkalmazásokból. Ebben az esetben is ezt használtuk, az ágenst létrehozó forráskód megtalálható a 4. mellékletben. Inicializálás során az ágens beregisztrál a Jade platform DF ágenséhez, ennek segítségével közzéteszi létrejöttét a többi ágens számára. A központi kommunikációs ágensen keresztüli felhasználói interakció megkönnyítése érdekében az ágens egy grafikus felülettel rendelkezik, amelyet a 4.9. ábrán láthatunk. Az ágens inicializálásakor a regisztrálás mellett másik fő feladata ennek a kezelőfelületnek a megjelenítése.
45
4.9. ábra. A központi kommunikációs ágens grafikus felhasználói felülete Az ablak két részre oszlik, felső része a rendszerüzenetek megjelenítésére, az elérhető átjárók lekérdezésére és adminisztrálására szolgál, az alsó pedig konkrét szenzorok aktuális értékeinek lekérdezésére, és a szenzorok mért értékeinek megjelenítésére. A „Ping” gomb megnyomásának hatására a rendszer lekérdezi a DF-től az elérhető átjárókat, majd megjeleníti azokat az „Available gateways” címkéjű listában.. Ez után a listából a felhasználó kiválaszthatja, hogy melyik átjárókhoz kíván kapcsolódni, majd a „Connect” gomb megnyomásával kezdeményezheti a kapcsolat kiépítését. Az ágens ekkor a kiválasztott átjárók kommunikációs ágenseinek üzenetet küld, amelyben jelzi kapcsolódási szándékát. Erre az üzenetre a központi kommunikációs egység 3-féle választ kaphat, amelyek mindegyikéről tudomást szerezhetünk a rendszerüzeneteket megjelenítő „System messages” címkéjű mezőben. A lehetséges esetek a következőek: •
A kapcsolódási szándékot az átjáró kommunikációs ágens elfogadja, és kiépíti kapcsolatát a központi kommunikációs egységgel. Ekkor a kapcsolódás sikeres, és a kapcsolat kiépül a két ágens között.
•
Ha az elérni kívánt átjáró már csatlakozva van a központi kommunikációs egységhez, erről az átjáró kommunikációs ágense egy tájékoztató üzenetet küld vissza válaszként. Bár a kapcsolódás ebben az esetben sikertelen, a kapcsolat a átjáróval már ki van építve.
•
Amennyiben az adott átjáró már csatlakozva van egy másik központi kommunikációs egységhez, akkor az átjáró kommunikációs ágense tájékoztatja a kapcsolatot kezdeményező központi kommunikációs ágenst, hogy az átjáró már másnak a vezérlése alatt áll. Ekkor a kapcsolódás sikertelen, és a átjáróval sem létezik kapcsolat.
46
A központi kommunikációs ágens mind az elérhető, mind a kapcsolódott átjárók karbantartására Vector tárolókat használ. A sikeresen kapcsolódott átjárók a „connected gateways” címkéjű listába kerülnek. Ha egy átjáróval a felhasználó bontani szeretné a kapcsolatot, kiválaszthatja ebből a listából, majd a „Disconnect” gomb megnyomásával a kapcsolat bontásáról egy üzenet kerül elküldésre az kiválasztott átjáróknak, majd az összeköttetés megszűnik. Minden átjáró miután kapcsolatba lépett egy központi kommunikációs egységgel, bejelenti annak aktuálisan elérhető szenzorait, azaz minden egyes szenzorról egy bejelentő üzenet érkezik az átjáró kommunikációs ágensétől. Amennyiben a kapcsolat kiépítése után az átjáróhoz újabb szenzorok csatlakoznak, azokról az átjáró kommunikációs ágens szintén ilyen bejelentő üzenetekkel jelez. Ezen üzenetek egy előre meghatározott üzenetsablonra illeszkednek, amely egységes, legyen szó akár vezetékes, vezeték nélküli, vagy software szenzorokat használó átjáróról. Ennek az egységes interfésznek a használatával a központi kommunikációs egységnek nem kell tudnia, hogy az üzenetben szereplő szenzor milyen átjáróhoz csatlakozik, így azok átlátszóvá válnak a felső rétegek számára. Szintén ezt az interfészt használjuk akkor, ha egy szenzor valamilyen okból beszünteti működését (például kikapcsoljuk, kikötjük, meghibásodik, stb.). Ekkor az átjáró kommunikációs ágens a korábban bejelentett szenzor megszűntéről tájékoztatja a központi kommunikációs egységet. Ez a folyamat szintén független az átjáró típusától. Minden beérkezett bejelenő üzenet hatására, azok előre definiált mezőinek felhasználásával a központi kommunikációs ágens létrehoz egy árnyék ágenst, amellyel az adott szenzort, mint fizikai eszközt modellezzük a rendszerben. A árnyék ágens létrehozása után a szenzor a kezelőfelületen is megjelenik, az ablak bal alsó részében a felhasználók fa nézetben böngészhetnek az átjárók és azok szenzorai között. Amennyiben egy szenzor megszűnéséről érkezik üzenet a központi kommunikációs ágens feladata az adott szenzort modellező árnyék ágens megszüntetése, és a szenzor eltávolítása a kezelőfelületből. Az árnyék ágensek megszüntetéséről abban az esetben is gondoskodni kell, ha a felhasználó bontja a kapcsolatot valamelyik átjáróval. Ekkor minden, a kiválasztott átjáróhoz kapcsolódó szenzor árnyék ágensét is meg kell szüntetnie a központi kommunikációs egységnek. Amennyiben valamelyik kapcsolódott átjáró kommunikációs ágense hibát jelez a központi kommunikációs ágensnek, a helyes működés fenntartása érdekében meg kell semmisíteni minden, a hibás átjáróhoz tartozó szenzor árnyék ágensét, majd nyugtázni kell az átjáró kommunikációs ágense felé ennek megtörténtét. Erre azért van szükség, mert a nyugtával jelezzük, hogy a központi egység minden olyan tevékenységet elvégzett, amelyek szükségesek ahhoz, hogy a hibás átjáró ne okozzon további hibákat a rendszer működésben. Ezeknek a karbantartó tevékenységeknek a segítségével a rendszer képes mindig naprakész információval szolgálni az elérhető szenzorokról. Minden árnyék ágens létrehozásáról egy nyugta kerül elküldésre a megfelelő átjáró kommunikációs ágensének, amelynek segítségével az új árnyék ágenst közvetlenül hozzárendeljük a fizikai szenzort működtető átjáróhoz. Ez azért előnyös, mert így a továbbiakban nincs szükség a központi kommunikációs egység üzent közvetítő szerepére, a mérési eredmények közvetlenül jutnak az árnyék ágensekhez, ez gyorsabb, és kisebb adatforgalmat igénylő működést eredményez. Ha a felhasználó kiválasztja valamelyik szenzort annak adatai és utolsó mért értéke azonnal megjelennek a grafikus felületen. Amennyiben a szenzor állapotát a felhasználó nyomon szeretné követni, az aktuális mérési eredményt a „Get” gomb megnyomásával újra lekérdezheti. Az „Interval” mező kitöltésével lehetőség nyílik periodikus lekérdezésre is. A lekérdezési időintervallum másodpercekben való megadása után a kiválasztott szenzor adatait 47
a rendszer ezentúl automatikusan megjeleníti, a megadott időközönként. Amennyiben az „Interval” mezőbe 0-t ír a felhasználó, az jelenti az egyszeri lekérdezést, a -1-es értékkel pedig jelezheti, hogy a kiválasztott szenzor adatainak periodikus lekérdezésére a jövőben nem tart igényt. A lekérdezések vezérlésére egy szintén egységesített, a lekérdezéseket szolgáló üzenetformátumot használunk. Ennek segítségével a lekérdezések során is transzparens maradhat az egyes eszközök kapcsolódási módja, hiszen az a mért adatok szempontjából jelentéktelen. Mind a periodikus, mind az egyszeri lekérdezések ezt az egységes formátumot használják az ágensek közötti kommunikáció során. A központi kommunikációs ágens a szenzorok aktuális mérési eredményére vonatkozó igényét a megfelelő árnyék ágensek felé továbbítja, amelyek ezen információ beszerzése után a szenzor aktuális állapotával válaszolnak. Egyes szenzorok, (például mozgásérzékelők, ajtónyitás érzékelők, stb.) esetében különös jelentősége lehet, ha megváltozik a szenzor állapota, és szükséges lehet erről azonnal értesíteni a felsőbb rétegeket, hogy meghozhassák a megfelelő döntéseket. Ekkor az átjáró kommunikációs ágense az egységes, lekérdezések kiszolgálására szolgáló üzenetformátumot használva azonnal értesíti a szenzornak megfelelő árnyék ágenst, hogy a mért érték megváltozott. Az árnyék ágens ezt jelzi a központi kommunikációs ágens felé, és az új érték azonnal kiíródik.
4.5. AZ ÁRNYÉK ÁGENSEK Az árnyék ágensek arra szolgálnak, hogy a fizikai egységeket, azaz minden egyes szenzort és beavatkozó egységet modellezzék a rendszerben. Erre azért van szükség, mert így az egyes egységek megjelennek a rendszermodellben, és adataik a szoftveren belül elérhetők. Minden egyes fizikai egységhez pontosan egy árnyék ágens tartozik, amennyibe az átjáró, amelyhez az egység csatlakozva van kapcsolatban áll egy központi kommunikációs egységgel. Míg az átjáró nincs csatlakozva semmihez, a hozzá kapcsolt szenzorok és beavatkozók modelljei nem léteznek, hiszen szükség sincs rájuk. Az árnyék ágensekkel jelenleg négyféle eszközt tudunk modellezni, bináris szenzorokat, analóg szenzorokat, bináris beavatkozókat, és analóg beavatkozókat. Ezek az árnyék ágensek minden lényeges információt letárolnak az adott eszközről. A tárolt adatok a következők: •
lastValue: Bináris eszközök esetén egy boolean változó, amelynek értéke szenzorok esetében az utolsó mért érték, amely minden esetben az aktuális érték, beavatkozó szervek esetében pedig az eszköz jelenlegi állapota. Analóg eszközök esetén a mező értéke egy int változóban van tárolva, amely szenzorok esetén az utolsó mérési eredmény, beavatkozó eszközök esetén pedig az utolsó beállított jelszintet tartalmazza.
•
Index: Az adott eszköznek az átjárón belüli egyedi azonosítója.
•
Service: Az eszköz által nyújtott szolgáltatás leírását tartalmazza egy karakterláncban.
•
Type: Ez a bináris eszközök esetén értéke a "BOOL" karakterlánc, analóg eszközök esetén pedig az "ANALOG" karakterlánc.
•
Confidence: Az adott eszköz megbízhatósági értéke, melyet a következtetésekhez használunk fel.
48
Az árnyék ágensek karbantartásnak legfontosabb motívuma, hogy mindig naprakész, valósághű információval szolgáljanak. Az egyetlen időfüggő adat az utolsó mért érték, tehát a lastValue. Ezek frissítéséről az átjárók gondoskodnak, kommunikációs ágensükön keresztül. Az ágens többi adatát a központi kommunikációs ágenstől kapja létrejöttekor, hisz ezek a paraméterek az ágens működése során állandóak, nem változnak az idő fuggvényében. Az árnyék ágensek lastValue adattagjának frissítése több esetben is megtörténhet, előzetes kérésre válaszként, vagy automatikusan. Az adatok frissítése szintén a központi kommunikációs ágens esetében taglalt, lekérdezéseket kiszolgáló egységes üzenetformátumot használja, tehát átjárófüggetlen. Tekintsük át milyen módokon frissülhet egy árnyék ágens adatbázisa: •
Ha a központi kommunikációs ágens egy egyszeri kérést intéz egy árnyék ágenshez az utolsó mérési eredményre vonatkozóan, akkor az árnyék ágens előbb megkéri az átjáró kommunikációs ágensét, hogy küldje el az adott szenzor aktuális állapotát, majd amint megkapja a választ frissíti saját adatbázisát, és az eredménnyel kiszolgálja az egyszeri lekérdezést.
•
Ha a központi kommunikációs ágens periodikus lekérdezést intézett egy árnyék ágenshez, ez az átjáró kommunikációs ágensén az átjáró felé továbbítódik. Ezután az átjáró a meghatározott időközönként lekéri az árnyék ágens által modellezett eszköz aktuális állapotát, majd egy automatikus üzenetet küld erről az árnyék ágens felé. A saját adatbázisának frissítése után az árnyék ágens tájékoztatja a központi kommunikációs ágenst az új adatról, ami ezt megjeleníti a grafikus felületén a felhasználók számára.
•
Ha egy kritikus állapotú szenzor (például mozgásérzékelő, ajtónyitás érzékelő, stb.) állapota megváltozik, erről az átjáró azonnal üzenetet küld a szenzor árnyék ágensének, ha az létezik. Amennyiben igen, akkor a saját adatbázisának frissítése után az árnyék ágens tájékoztatja a központi kommunikációs ágenst az új adatról, ami ezt megjeleníti a grafikus felületén a felhasználók számára.
A lekérdezések kiszolgálása mellett az árnyék ágensek másik jelentős feladata a mesterséges intelligencia számára adatok biztosítása. A mesterséges intelligenciával rendelkező ágensek előre meghatározott szabályrendszerek alapján hozott döntéseinek alapját az árnyék ágensektől rendszeresen begyűjtött mérési eredmények jelentik.
49
IRODALOMJEGYZÉK [1]
Putman, Byron W: RS-232 Simplified, Englewood Cliffs, New Jersey: Prentice-Hall, Inc, 1987, ISBN: 0-13-783499-3
[2]
EIA Standard RS-232-C: Engineering Department, Electronic Industries Association.
[3]
Dr. Wersényi György: Híradástechnikai alkatrészek, Széchenyi István Egyetem Távközlési Tanszék, 2004
[4]
A. K. Ray and K. M. Bhurchandi, Advanced microprocessors and peripherals: architecture, programming and interfacing. New Delhi: Teta McGraw-Hill Pub.Co, 2000
[5]
C. J. Bergquist, Guide to PICMICRO microcontrollers. Indianapolis, Ind.: Prompt Publications, 2001.
[6]
D. W. Smith, PIC in practice. Oxford: Newnes, 2002.
[7]
H. W. Huang, PIC microcontroller: an introduction to software and hardware interfacing. Clifton Park, N.Y.: Thomson/Delmar Learning, 2005.
[8]
J. Zygmont. Microchip: an idea, its genesis, and the revolution it created. Cambridge, Mass.: Perseus Pub, 2003.
[9]
M. Predko, Programming and customizing PICmicro microcontrollers. New York: McGraw-Hill, 2001.
[10]
FTDI Chip: FT232 Designers Guide, Version 2.0
[11]
http://rxtx.org/
[12]
http://www.xbow.com/Products/productdetails.aspx?sid=156
[13]
http://www.tinyos.net/
[14]
http://jade.tilab.com/
[15]
Getting_Started_Guide_7430-0022-07_A
[16]
MoteView_Users_Manual_7430-0008-04_B
[17]
MPR-MIB_Series_Users_Manual_7430-0021-07_B
[18]
MTS-MDA_Series_Users_Manual_7430-0020-04_B
[19]
http://robotics.eecs.berkeley.edu/~pister/SmartDust/
[20]
http://webs.cs.berkeley.edu/nest-index.html
[21]
http://www.kernel.org/pub/linux/libs/pam/
[22]
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/
[23]
http://pam-mysql.sourceforge.net/
[24]
http://tldp.fsf.hu/HOWTO/User-Authentication-HOWTO-hu/
[25]
Pere László, GNU/LINUX rendszerek üzemeltetése I. - II., Kiskapu, 2005.
[26]
von Hagen, Jones: Linux bevetés közben – Második küldetés., Kiskapu, 2006.
[27]
http://www.cups.org
[28]
http://fe0wap86.bosch.de/intershoproot/eCS/Store/all/ST_NA/lit1/ISM-BLP1P_DataSheet_huHU_F2422115595.pdf
[29]
http://fe0wap86.bosch.de/intershoproot/eCS/Store/all/ST_NA/lit1/DS304_DataSheet_huHU_F18484562 03.pdf
[30]
http://bentelsecurity.com/pdf/en/DT800.pdf
[31]
http://fe0wap86.bosch.de/intershoproot/eCS/Store/all/ST_NA/lit1/DS1101i_InstallationGuide_enUS_F3 549764491.pdf
50
[32]
http://www.globalfire.pt/application/files/products/24/GFE-H%20_Manual.pdf
[33]
http://www.globalfire.pt/application/files/products/24/GFE-S_SH%20_Manual.pdf
[34]
http://fe0wap86.bosch.de/intershoproot/eCS/Store/all/ST_NA/lit1/MAGICSENSConven_DataSheet_hu HU_T1723939083.pdf
51
MELLÉKLETEK 1. Melléklet
port="I.05" port="I.06" port="I.08" port="O.00"
sensorid="move1"/> sensorid="door1"/> sensorid="temp1"/> sensorid="LED0"/>
52
2. Melléklet <sensors> <sensor sensorid="move1" name="Movement sensor" type="BOOL" service="movement"> Moving. Not moving. <sensor sensorid="door1" name="Entrance door" type="BOOL" service="door"> opened closed <sensor sensorid="temp1" name="Temperature1" type="ANALOG" service="temperature"> 1 0.003236246 0.000394087 X 6553.5 0.1 X * - / l 1.929168 - * + / 273 -
53
3. Melléklet private TreeMap<String,Long> getMap; //A String a szenzor azonosítója, a Long pedig a lekérdezés periódusa. private TreeMap<String,Long> lastGet; //A String a szenzor azonosítója, a Long pedig az utolsó lekérdezés ideje. … while (true) { if (!getMap.isEmpty()) { it=getMap.keySet().iterator(); for (;it.hasNext();) { next=it.next(); if (System.currentTimeMillis()-lastGet.get(next)>getMap.get(next)) { //if (pontos_idő-utolsó_lekérdezés>lekérdezés_periódus) { sOut.writetoport("GET"+next.substring(2)); //Soros portra küldi a megfelelő parancsot. lastGet.put(next,System.currentTimeMillis()); //Utolsó lekérdezés frissítése. } } } try { Thread.sleep(500); } catch (InterruptedException ex) { ex.printStackTrace(); } }
54
4. Melléklet Ágensek Java alkalmazásokból történő létrehozásának szintaktikája: //szükséges csomagok import jade.core.Runtime; import jade.core.Profile; import jade.core.ProfileImpl; import jade.wrapper.*; ... //változók private Runtime myRuntime; private Profile myProfile; private ContainerController myContainerController; private AgentController myAgent; ... //a változók inicializálása myRuntime=Runtime.instance(); myProfile=new ProfileImpl(); myContainerController=myRuntime.createAgentContainer(myProfile); myAgent=null; ... //Ágens létrehozása Object args[] = new Object[]; try { myAgent = myContainerController.createNewAgent("AgentName", "centralagent.CentralAgent",args); myAgent.start(); ... } catch (StaleProxyException ex) { ex.printStackTrace(); } ...
55
5. Melléklet PAM A PAM (Pluggable Authentication Modules; Csatlakoztatható Azonosítási Modulok) egy olyan függvénygyűjtemény, amik nagyban megkönnyítik a program fejlesztők életét. Régebben mikor egy programnak szüksége volt arra, hogy azonosítson egy felhasználót, akkor kiolvasta az /etc/passwd fájlból a szükséges információkat. Ha átakartak térni egy másfajta azonosítási rendszerre, akkor minden programba bele kellett írni az új azonosítási módot és újra kellett fordítani, hogy tudja használni az új rendszert. Az ilyen problémák elkerülésére fejlesztették ki a PAM-t, ami egy olyan szabványos felületet ad a programoknak amit használhatnak, hogy nem kell tudniuk, hogy hogyan is zajlik az azonosítás a háttérben. Így ha megváltozik az azonosítási módszer, akkor csak egy új PAM modult kell beállítani, vagy egy régebbit átkonfigurálni és minden program fogja tudni használni az új rendszert, ami támogatja a PAM-t. A PAM-t nem csak egy egyszerű bejelentkezésnél lehet használni, hogy azonosítson egy felhasználót, hanem bármilyen programból lehet kérni azonosítást. A mai Linux disztribúciók gyakorlatilag mindegyike tartalmazza a PAM-t, ha alapból nem is telepítette volna fel, egyszerűen feltelepíthető. PAM konfigurálása A PAM konfigurálása régebbi rendszereknél az /etc/pam.conf fájlban történik. Új rendszereknél már különbontották ezeket a beállításokat programok szerint és ezek a beállítások az /etc/pam.d/ könyvtárban vannak. Itt találhatóak a beállító fájlok a programokhoz, minden programnál a program nevével megegyező fájlban vannak tárolva az adott programhoz tartozó beállítások. A beállító fájlokban soronként egy-egy biztonsági modul használatára vonatkozó információk vannak. Az egyes sorok a következő oszlopokat tartalmazzák: 1) A szolgáltatás neve amire vonatkozik az adott sor. Ez az oszlop csak a pam.conf állomány használata esetén van, a másik módszernél ez felesleges, mivel a fájl neve már maga a szolgáltatás neve. Ha egy alkalmazás hitelesítést kér, de nem található ilyen névre beállítás, akkor a PAM az other szolgáltatásnevet használja, ezért fontos, hogy ez is le legyen kezelve és ne legyen ez egy biztonsági rés a rendszerben. 2) A modul felhasználási módját, típusát adja meg. Milyen jellegű hitelesítési feladatra kell. Használható kulcsszavak: a) auth – felhasználó azonosítása b) account – adott szolgáltatás elérhető-e a felhasználó számára c) session – nemcsak a szolgáltatás előtt, hanem közben és után is szerepet játszanak. Pl.: felhasználó belépésének, kilépésének naplózása. d) password – felhasználó azonosításához használt adatok módosításakor (pl. jelszóváltoztatáskor) kapnak szerepet. 3) A modul fontosságát adja meg, vagyis az adott PAM modul sikeres végrehajtása szükséges vagy elégséges-e a szolgáltatás igénybe vételéhez. Használható kulcsszavak: a) required – A szolgáltatás igénybevételéhez a modul sikeres lefutása szükséges. Ha sikertelenül fut le a modul akkor a szolgáltatást nem lehet igénybe venni, de a felhasználó erről csak a többi modul lefutása után értesül.
56
b) requisite – Ezek is elengedhetetlenek a szolgáltatás igénybevételéhez, viszont ha nem sikeres akkor erről a felhasználó azonnal értesül. c) sufficient – Ilyen modul lefutása elégséges a szolgáltatás igénybevételéhez. Ekkor már nincs szükséges más modulok lefutására. d) optional – Ilyen igénybevételéhez.
modul
sikeres
lefutása
nem
szükséges
a
szolgáltatás
4) A modul neve elérési úttal és a modul esetleges kapcsolói. A disztribúciók alapból tartalmaznak modulokat, amikkel sok feladat elvégezhető, de persze saját modulokat is lehet írni és használni. Néhány, fontosabb modul leírással: •
pam_deny.so – Ez a modul mindig sikertelenül fut le, de mást nem csinál.
•
pam_permit.so – Ez a modul mindig sikeresen fut le, de mást nem csinál.
•
pam_warn.so – Naplóbejegyzések készíthetők ezzel a modullal. Csak auth és password módban használható.
•
pam_unix.so – Szokásos unixos hitelesítési eljárást valósítja meg. Ez auth, account, session, és password módokban használhatóak.
•
pam_cracklib.so – A felhasználótól új jelszót kér be és ellenőrzi, hogy az új jelszó elég bonyolult-e. Password módban használható.
•
pam_mail.so – Leellenőrzi, hogy van-e olvasatlan levele a felhasználónak és ha van akkor üzenetben értesítési.
•
pam_lastlog.so – Ez a modul a /var/log/lastlog fájlba naplózza a be- és kijelentkezéseket és üzenetben értesíti a felhasználót az utolsó bejelentkezésről.
•
pam_motd.so – Megjeleníti az /etc/motd fájlt (paraméterrel megváltoztatható a fájl neve, elérési útja) tartalmát. Ebben általában üdvözlő üzenet szokott lenni. Session módban használható.
•
pam_securitty.so – A modul a rendszergazda számára csak azokról a terminálokról engedélyezi a bejelentkezést, amik fel vannak sorolva a /etc/securetty fájlban. Auth módban használható.
•
pam_nologin.so – Tiltja a felhasználók számára a bejelentkezést, ha az /etc/nologin fájl (paraméterrel megváltoztatható a fájl neve, elérési útja) létezik. Ilyenkor csak a rendszergazda léphet be.
•
pam_limits.so – Ezzel a modullal korlátozásokat adhatunk meg az erőforrásokra, így megvédhetjük a rendszert, hogy a felhasználói programok túlterheljék.
PAM-MySQL A PAM-MySQL egy nyílt forráskódú projekt. Egy olyan PAM modul, ami egy MySQL adatbázisból veszi az azonosításhoz szükséges adatokat. Így lehetőség van arra, hogy egy központi adatbázisban tároljuk a felhasználói adatokat és így már nem csak egy jelszót tudunk tárolni egy felhasználóról, hanem egyéb más adatokat is ami az adott felhasználóhoz tartozik. Így nem kell különböző rendszerekhez készíteni külön adatbázisokat, mikor ugyan azokat az adatokat használják a programok az azonosításhoz. A modulnak paraméterként lehet megadni azokat az információkat mint pl: adatbázis elérési cím, kapcsolódási név, jelszó stb. Főbb paraméterek: 57
•
user – a MySQL adatbázishoz való kapcsolódáshoz használt felhasználó név
•
passwd – a MySQL adatbázishoz való kapcsolódáshoz használt jelszó
•
host – a MySQL server elérési címe
•
db – az adatbázis neve, amiben majd keresni kell az azonosításhoz szükséges nevet, jelszót
•
table – a tábla neve az adatbázisban
•
usercolumn – oszlop neve a táblában ami tartalmazza az azonosításnál használandó felhasználó nevet
•
passwdcolumn – a jelszó oszlop neve, amit használ az azonosításnál, kódolt is lehet
•
crypt – a jelszó oszlop kódolásának fajtáját adja meg
•
where – egyéb feltételt lehet még megadni
Példa a modul használatára az ssh programhoz: auth required pam_mysql.so user=pam passwd=pampwd \ host=192.168.100.2 db=pam table=users usercolumn=username \ passwdcolumn=password crypt=0 account sufficient pam_mysql.so user=pam passwd=pampwd \ host=192.168.100.2 db=pam table=users usercolumn=username \ passwdcolumn=password crypt=0 Ezzel a modullal könnyen megoldható, hogy ha csak egy egyszerű név–jelszó azonosítást akarunk elvégezni adatbázisból. A where kulcsszó után megadhatunk olyan feltételeket amik egyszerűen bemásolódnak az SQL lekérdezésbe, így még kifinomultabb azonosítást lehet készíteni. Például ha van egy olyan mezője is annak az adatbázistáblának (ahol van a felhasználó név az egyik oszlopban, egy másikban meg a jelszó), hogy 'ssh' amiben ha az ssh szolgáltatáshoz tatozó jog van beírva, tehát az '1' van ott, akkor van joga a felhasználónak használni, ha '0' akkor nincs. Ha most ezt is bele akarjuk tenni a pam_mysql tesztelésben akkor kibővíthetjük az előbbi sorokat úgy, hogy: „auth required … where=ssh=1” „account sufficient … where=ssh=1” Viszont ennek a módszernek van egy olyan hátránya, hogy minden szolgáltatáshoz amit le akarunk kezelni akkor létre kell hozni egy mezőt a táblában. Így egy olyan megoldást kerestem ami megoldja, hogy ne kelljen a táblát felesleges (redundáns) adatokkal feltölteni. Így létrehoztam az alábbi táblákat a MySQL-ben a 'pam' nevű adatbázisba: 'users' tábla – felhasználók adatai Mező név
Leírás
ID
Egyedi azonosító (elsődleges kulcs)
username
Felhasználó név
58
Felhasználó jelszó
password
'services' tábla' – szolgáltatások (programok) adatai Mező név
Leírás
ID
Egyedi azonosító (elsődleges kulcs)
servicename
Szolgáltatás (program) neve
'user_service' tábla – 'users' és a 'services' közti kapcsolatokhoz Mező név
Leírás
ID
Egyedi azonosító (elsődleges kulcs)
UID
Felhasználó azonosító (külső kulcs)
SID
Szolgáltatás azonosító (külső kulcs)
Ezekkel a táblákkal már jobban testre szabhatjuk az azonosítási rendszert. Ha ezeket a táblákat akarjuk használni akkor a PAM_MySQL által használandó SQL így nézne ki: SELECT Password FROM `users` AS u INNER JOIN `user_service` \ AS us ON u.ID=us.UID INNER JOIN `services` AS s ON s.ID = \ us.SID WHERE u.username="root"; Sajnos erre nincs lehetőség PAM_MySQL-ben. Mivel nem lehet generálni egy ilyen összetett sql lekérdezést, még a where kulcsszó használatával sem a konfigurációs fájlban, így azt a megoldást választottam, hogy készítek egy tárolt eljárást a MySQL-ben ami letudja tesztelni, akár több adatbázistáblából, hogy van-e jogosultsága az adott felhasználónak az adott szolgáltatáshoz. A tárolt eljárás 2 paramétert kap. Az első a felhasználó név, a 2. a szolgáltatás neve. Visszatérési értéke 1. ha létezik ilyen kapcsolat az adatbázisban, 0 ha nem. CREATE FUNCTION `chkusrservice`( p_username VARCHAR(100), p_servicename VARCHAR(100) ) RETURNS int(1) BEGIN DECLARE t_UID INT DEFAULT 0; DECLARE t_SID INT DEFAULT 0; DECLARE AID INT DEFAULT 0; SELECT ID INTO t_UID FROM `users` WHERE username=p_username; if t_UID > 0 then SELECT ID INTO t_SID
59
FROM `pam`.`services` WHERE servicename=p_servicename; if t_SID > 0 then SELECT COUNT(ID) INTO AID FROM `pam`.`user_service` WHERE ( (UID=t_UID) AND (SID=t_SID) ); if AID > 0 then return 1; else return 0; end if; else return 0; end if; else END
return 0; end if;
A tárolt eljárás használatára egy példa: SELECT password FROM `users` WHERE ( (username="root") AND \ (chkusrservice("root","ssh")=1) ); Így már akkor bármilyen felhasználót hozzá tudunk rendelni bármilyen szolgáltatáshoz és csak a megfelelő kapcsolatokat kell létrehozni az adatbázisban. A probléma most ott van, hogy ezt a tárolt eljárást kéne használnia a pam_mysql modulnak is. A beállításainál van egy 'where' paraméter, ahova egyéb feltételeket lehet megadni. Ha hozzáadjuk azt, hogy ”... where=chkusrservice(user,"ssh")=1” (előtte a user változónévvel adta át az aktuális felhasználó nevét) gondolhatnánk, hogy működni fog, de mégse, ugyan is a 'where' utáni részt mindenféle feldolgozás nélkül átmásolja az SQL lekérdezésbe, így az előbbi példa egy olyan SQL lekérdezést generál, hogy: SELECT password FROM `users` WHERE (username="root") AND \ (chkusrservice(user,"ssh")=1 ); Ez így egy hibás lekérdezés, mivel ilyenkor nem helyettesíti be a 'user' helyére a where utána az aktuális felhasználó nevet, hanem megmarad az 'user' ként. Ezért sikertelen lesz az azonosítás is. Ezért módosítanom kellett a pam_mysql forrását is, hogy úgy dolgozza fel a 'where' utáni részeket, hogy az azonosításnál tudja használni a tárolt eljárást. A PAM_MySQL forrásában (pam_mysql.c) a 'pam_mysql_format_string()' nevű függvény dolgozza fel a pam beállítófájlból kapott paramétereket. Mikor kiolvassa az aktuális felhasználó nevet, akkor azt lementem egy char* típusú változóba: char* username; // user nev tarolasa … case 's': { const char *val = va_arg(ap, char *); username = (char*)calloc(strlen(val), sizeof(char)); strcpy(username, val); } …
60
A pam beállításoknál a 'where' paraméternél így akkor már elég átadni csak az adott szolgáltatás (program) nevét. A forrásban azt is módosítani kellett, ahol a 'where' kulcsszó utáni részt dolgozza fel: … case 'S': { const char *val = va_arg(ap, char *); // WHERE osszerakasa: const char* sqlwhere = makewhere(username, val); if ((err = pam_mysql_str_append(pretval, sqlwhere, strlen(sqlwhere)))) { goto out; } … A 'makewhere' függvény az egy új függvény amit beleírtam a forrásba. Ennek a feladata, hogy összeállítsa a megfelelő szintaxisát az SQL 'where' részének:. char* makewhere(char* usr, const char* prg){ const char* storedprocname = "chkusrservice"; char* wherestr; int len=0,tmplen; len = strlen(storedprocname); wherestr = (char*)calloc(len+3,sizeof(char)); len += 3; // tarolt eljaras neve bemasolasa strcpy(wherestr , storedprocname); wherestr[len-3] = '('; wherestr[len-2] = '"'; wherestr[len-1] = '\0'; // user nev hossz kiolvasasa tmplen = strlen(usr); wherestr=(char*)realloc(wherestr,(len+tmplen+3)*sizeof(ch ar)); len = len+tmplen+3; strcat(wherestr , usr); wherestr[len-4] = '"'; wherestr[len-3] = ','; wherestr[len-2] = '"'; wherestr[len-1] = '\0'; // prg nev hossz kiolvasasa tmplen = strlen(prg); wherestr=(char*)realloc(wherestr,(len+tmplen+4)*sizeof(ch ar)); len = len+tmplen+4; strcat(wherestr , prg); wherestr[len-5] = '"'; wherestr[len-4] = ')'; wherestr[len-3] = '='; wherestr[len-2] = '1'; wherestr[len-1] = '\0'; return wherestr; } Végül a PAM beállítófájlt úgy kellett módosítani, hogy: auth required pam_mysql.so user=pam passwd=pampwd \ host=192.168.100.2 db=pam table=users where=ssh \ usercolumn=username passwdcolumn=password crypt=0 61
account sufficient pam_mysql.so user=pam passwd=pampwd \ host=192.168.100.2 db=pam table=users where=ssh \ usercolumn=username passwdcolumn=password crypt=0 Így akkor már sikeresen működik az azonosítás egy MySQL adatbázisból. Ebben a példában most csak a felhasználó név és egy szolgáltatás név van csak összekapcsolva. A tárolt eljárásban viszont sokkal összetettebb dolgokat is lehetne vizsgálni. Például, hogy mikor történik az azonosítási kísérlet vagy egy naplózás egy másik adatbázis táblába, vagy akár, hogy honnan kapcsolódik a felhasználó. További lehetőségek •
Az azonosítási rendszerhez további funkciók kapcsolása, pl: naplóbejegyzés készítése adatbázisba vagy a hozzáférés helyének korlátozása.
•
A biztonsági keretrendszerhez módosítások elvégzése.
•
Egy felhasználóbarát program írása arra, hogy az adatbázisban található felhasználó – szolgáltatás kapcsolatot könnyen megadható legyen.
•
Bizonyos funkciók automatizálása pl: egy új felhasználóhoz létrehozásánál a megfelelő jogok megadása (kapcsolatok létrehozása az adatbázisban)
•
Annak vizsgálata, hogy a tervezhető modulok közül melyiket lehet megvalósítani ezzel a módosított modullal.
való
kapcsolódáshoz
esetleg
szükséges
62
6. Melléklet CUPS: Common UNIX Printing System A CUPS rendszer egységes megoldást nyújt Linux rendszereken a nyomtatók kezeléséhez, és a legtöbb Linux disztribúció része. A CUPS rendszert böngészőből a http://127.0.0.1:631 címen érhetjük el. Ezen a felületen tudunk nyomtatókat hozzáadni, meglévő nyomtatók jellemzőit módosítani, illetve nyomtatókat törölni. Új nyomtató hozzáadásához a CUPS démonnak futnia kell (cupsd), ha nem fut, akkor el kell indítani. Ha fut a démon, akkor a http://127.0.0.1:631 címen elérhető felületen a „Do Administration Tasks” menüpontot, majd az „Add printer” opciót kiválasztva megadhatjuk a nyomtató nevét, helyét, leírását, legördülő listákból kiválaszthatjuk, hogy hova csatlakozik a nyomtató, ki a gyártó, és melyik típus melyik meghajtóját kívánjuk használni. A CUPS működését konfigurációs fájlokban tudjuk szabályozni. Ezek a fájlok felsorolás szinten (a későbbiekben részletesen is): •
passwd.md5: Jelszóállomány
•
cupsd.conf: Főként a jogosultságokkal kapcsolatos beállításokat tartalmazzák
•
printers.conf: A nyomtatók beállításai (Alapértelmezett nyomtató, korlátok, leírás, stb...)
•
access_log: A nyomtatóelérési kísérleteket, és azok eredményét rögzíti
•
error_log: A nyomtatással kapcsolatos hibák naplózása
•
page_log: A sikeres nyomtatások naplózása
•
A fenti fájlok részletes tartalmát a következő fejezetekben mutatjuk be.
A passwd.md5 fájl jelentősége, tartalma Ahogy azt a neve is sugallja, jelszavakat tartalmaz md5 kódolással. Akkor hasznos, ha nem minden felhasználó jogosult nyomtatásra, csak adott felhasználók. Jelszavas nyomtatáshoz két lehetőség kínálkozik. Az egyik, kevésbé jó megoldás a szabványos Linux jelszavak használata, amikor a PAM modulok segítségével történik az azonosítás. Ez azért nem a legjobb, mert így mindenki tud nyomtatni, akinek van jelszava, tehát érdemi korlátozást nem jelent, legfeljebb azt tudjuk vele elkerülni, hogy egy felhasználó nevében más nyomtasson. A másik megoldás viszont amellett, hogy ezt is megvalósítja, a nyomtatásra jogosult személyek körét is be tudja határolni. Ennek a módszernek a lényege, hogy a rendszerjelszavaktól független nyomtatási jelszavakat adnak meg a nyomtatásra jogosul felhasználók, és ezzel tudják magukat azonosítani nyomtatás előtt. A jelszó megadása az „lppasswd” utasítással történik, a következő formában: # lppasswd -a [felhasználónév] A fenti utasítást root-ként kell kiadni, majd megadni, és megerősíteni a felhasználó jelszavát. Ezután a passwd.md5 fájlban egy új sor jön létre az alábbi formában: Linuxuser:root:123456789abcdefghijklmnopqrstuvw
63
Ahol Linuxuser a felhasználónév, 123...uvw pedig a jelszóból md5 kódolással képzett karaktersorozat. Módosítás a fentihez hasonlóan lehetséges, a „-a” nélkül, törléshez pedig a „-a” helyett „x” kapcsolót kell használni. A készülő keretrendszerben a nyomtatóelérés szabályozása történhet úgy, hogy minden nyomtatásra jogosult felhasználónak megadjuk a jelszavát, és akit le szeretnénk tiltani, annak a felhasználónevét egy bizonyos karakter, vagy egy karaktersorozat beszúrásával elérhetetlenné tesszük. Pl. ha a --BANNED-- előtagot a fájlban beszúrjuk a név elé, akkor az illető felhasználónevét nem fogja megtalálni a rendszer, viszont az előtag törlése után a nyomtatás újra lehetséges lesz, és ez egy olyan karaktersorozat, amely nagy valószínűséggel nem fordul elő valós felhasználónevekben. A folyamat automatizálására elég egy kis programot írni, amely kap egy felhasználónevet, és ha azelőtt szerepel az előtag, akkor kiveszi, ha nem szerepel, akkor elé teszi (1. ábra). Biztosabb megoldás, ha a program másik paraméterként azt is megkapja, hogy tiltani vagy engedélyezni akarjuk a felhasználót, így azt kiindulási állapottól függetlenül tudjuk, hogy milyen állapotba került a felhasználó (2. ábra). Ha olyan előtagot választunk, ami szerepelhet felhasználónévben, akkor fennáll annak a veszélye, hogy a felhasználó megváltoztatja a felhasználónevét (elé teszi a tiltó előtagot, ha ismeri), és így a felhasználónév egyezni fog, tehát tud nyomtatni engedély nélkül. Ezt két módon tudjuk kiküszöbölni: vagy olyan előtagot használunk, amely nem szerepelhet felhasználónévben, vagy a letiltással egy időben a jelszót ellenőrző kódot is megváltoztatjuk úgy, hogy abból engedélyezéskor az eredeti karaktersorozat visszaállítható legyen. Ilyen célra két, adott helyen szereplő karakter felcserélése, vagy a kódszó megfordítása megfelelő, és egyszerűen elvégezhető.
1. ábra. Felhasználók állapotai, és lehetséges állapotátmenetei egy paraméter esetén
2. ábra. Felhasználók állapotai, és lehetséges állapotátmenetei egy paraméter esetén A cupsd.conf fájl tartalma és jelentősége A „Linux bevetés közben” c. könyvben (lásd: forrásjegyzék ) a cups.conf fájl lehetőségei közül csak egy töredéket mutattak be, csak azokat a részeket, amik az IP cím alapján történő engedélyezést – letiltást szolgálják. Ezeken túl még sok más beállítási lehetőség kínálkozik, köztük sok olyan, ami számunkra is hasznos lehet.
64
Az IP cím szűréssel kapcsolatos lehetőségek bemutatásához nézzünk meg a fájl egy lehetséges tartalmát: LogLevel info Port 631 Order Deny,Allow Deny From All Allow From 127.0.0.1 AuthType Digest Order Deny,Allow Deny From All Allow From 127.0.0.1 AuthType Digest Order Deny,Allow Deny From All Allow From 127.0.0.1 AuthType Digest
Az első két sorban a naplózás jellemzőit, és a portot állíthatjuk be. Ezután egy-egy „location” szakaszon belül adhatjuk meg a jellemzőket. A „location / ” az általános beállításokra vonatkozik. Egy szakasz beállításait felül lehet írni, ha az adott szakasznál szűkebb körre vonatkoztatunk egy új szakaszt. Például egy „/printers” szakasz felülírja a „/” szakasz beállításait, de a „/printers/Beta” felülírja a „/printers” beállításokat. A beállítások nem öröklődnek tovább. Az egyes szakaszokon belül az „Order” rész adja meg, hogy mi legyen a beállítások sorrendje. „Deny, Allow” esetén először a letiltottakat adjuk meg, és utána megadhatunk kivételeket, akik mégis elérhetik az eszközt. „Allow, Deny” esetén ez fordítva van. Az engedélyezetteket „Allow From” után adjuk meg, a letiltottakat „Deny from után”, amik lehetnek IP címek, domain nevek, None vagy All érték, IP/netmask érték, @LOCAL, vagy @IF(name), ahol name egy interface neve. Az Auth Type rész az azonosítás típusát adja meg: „Digest” érték esetén a passwd.md5 fájlból. Néhány további lehetőség, ami hasznos lehet a továbbiakban: •
AccessLog path/file-%s: A naplófájl helye, ahol path: az útvonal, fájl: a fájl neve. A -%s opcionális, ha alkalmazzuk, akkor a fájl neve tartalmazni fogja a szerver nevét a „-%s” helyen. Az alapértelmezett érték: /var/log/cups/access_log. Speciális érték: AccessLog syslog, ebben az esetben a rendszernaplóba kerülnek a bejegyzések.
•
ErrorLog és PageLog: Naplófájlok helye, hasonlóan a fent leírtakhoz.
•
MaxClients n : Egy időben maximum n kliens csatlakozhat a szerverhez. Alapértelmezett érték: 100.
•
MaxClientsPerHost n: Egy-egy állomásról legfeljebb n felhasználó csatlakozhat egyszerre. Alapértelmezett értéke: a MaxClients érték.
65
•
MaxCopies n: Legfeljebb n darab másolta készíthető egy feladatról. Alapérték: 100
•
MaxJobs n: A memóriában lévő feladatok maximális száma: n. Ha betelt, akkor a régi, már elkészült munkákat törli a memóriából, ha nincs ilyen, akkor nem fogad új munkát. Ha az n értéke 0, akkor a funkció ki van kapcsolva, ez az alapértelmezett érték is.
•
MaxJobsPerPrinter n: Munkák maximális Alapértelmezett érték: 0 (kikapcsolva)
•
MaxJobsPerUSer n: Munkák maximális Alapértelmezett érték: 0 (kikapcsolva)
•
MaxLogSize n: Naplófájlok maximális mérete. Alapértelmezett érték: 1048576 byte (1 MiB). Ha n=0: kikapcsolva. Ha a naplófájl eléri a megadott méretet, akkor a rendszer átnevezi filename.O névre (ahol filename a naplófájl neve), és új, üres naplót indít.
•
Timeout n: A timeout értéket n másodpercre állítja. Alapérték: 300
száma száma
(n) (n)
nyomtatónként. felhasználónként.
A printers.conf fájl feladata, beállítási lehetőségei A printers.conf fájl további lehetőségeket biztosít a nyomtatók beállítására. Egy lehetséges tartalom: Info HP PSC 1215 Location Home DeviceURI usb://Hewlett-Packard/psc%201200%20series?serial=CN43PG1088T0 State Idle Accepting Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 Info Virtualis kamu nyomtato Location Home DeviceURI usb://Hewlett-Packard/psc%201200%20series?serial=CN43PG1088T0 State Idle Accepting No JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0
Minden nyomtatóhoz tartozik egy szakasz, amiben a beállításait meg lehet adni. Egy „DefaultPrinter”, és bármennyi „Printer” szakasz lehet, ahol a nyitó tag-ben meg van adva a nyomtató neve, amelyre vonatkoznak a beállítások. Beállítási lehetőségek: •
Accepting: értéke „Yes” vagy „No” lehet, utóbbi esetben nem fogad munkákat a nyomtató.
•
AllowUser és DenyUser: az utánuk megadott felhasználónevet, vagy neveket fogadja/utasítja el a nyomtató. Egyszerre csak egyik használható!
•
ErrorPolicy: Hiba esetén hogy viselkedjen a nyomtató. Értékei: 66
•
abort-job – elvetés,
•
retry-job – újra
•
stop-printer: leállítja a nyomtatót, de a munkát megtartja későbbi kinyomtatásra
•
Info: Szöveges információ adható meg a nyomtatóról
•
KLimit: A munka maximális mérete kilobyte-ban.
•
Location: Szöveges információ adható meg a nyomtató fizikai elhelyezkedéséről.
•
PageLimit: Nyomtatható oldalak korlátozása
Az access_log fájl tartalma A hozzáféréseket naplózza kiterjesztett "Common Log Format" formátumban (több webes eszköz is használja ezt a formátumot). Felépítése: host group user date-time "method resource version" status bytes ipp-operation ipp-status •
host: IP cím, vagy „localhost”
•
group: tartalma mindig „-”
•
user: hitelesített felhasználó neve, vagy „-”, ha nem történt hitelesítés
•
date-time: dátum, idő „[DD/MON/YYYY:HH:MM:SS +ZZZZ]” formátumban
•
method: GET, OPTIONS, PUT vagy POST
•
resource: erőforrás neve
•
version: erőforrás verziója
•
startus: HTTP státusz. Pl.:
•
200: elvégezve,
•
401: Nem hitelesítve. Hitelesítés szükséges!
•
404: A fájl, vagy erőforrás nem elérhető
•
stb...
•
bytes: a kérés mérete bájtokban
Néhány példa: localhost - root [18/May/2007:17:33:44 +0200] "POST / HTTP/1.1" 200 72 localhost - - [18/May/2007:17:35:49 +0200] "POST / HTTP/1.1" 401 0 localhost - root [18/May/2007:16:27:03 +0200] "GET /printers/Alfa HTTP/1.1" 200 3471
A page_log naplófájl A nyomtatókra küldött oldalakról szolgáltat információt. Általános formátuma: printer user job-id date-time page-number num-copies jobbilling
67
•
printer: a nyomtató neve
•
user: felhasználónév
•
job-id: a munka azonosítója
•
date-time: dátum és idő
•
page-number: oldalak száma
•
num-copies: másolatok száma (mindig 1)
Néhány példa: Albert root 1 [15/Apr/2007:19:30:15 +0200] 1 1 - localhost Albert oiboy 8 [16/Apr/2007:08:55:45 +0200] 1 1 – localhost Berci root 9 [16/Apr/2007:10:46:33 +0200] 1 1 - localhost
Az error_log naplófájl A hibákról ad információt. Formátuma: level date-time message •
level: a sor típusa. Néhány példa:
•
E: Normál hibaüzenet
•
I: Információs üzenet
•
W: Figyelmeztető (warning) üzenet
•
X: Vészhelyzeti
•
date-time: dátum, időpont
•
message: Szöveges üzenet a hiba okáról, tartalmazza a munka azonosítószámát is, ha munkához köthető.
Példák: I [16/Apr/2007:11:06:16 +0200] Full reload complete. E [16/Apr/2007:11:06:16 +0200] StartListening: Unable to bind socket I [18/May/2007:17:30:52 +0200] Started backend /usr/lib/cups/backend/usb (PID 4638) for job 20. W [16/Apr/2007:11:14:33 +0200] [Job 17] Media tray empty! X [16/Apr/2007:08:41:08 +0200] No valid Listen or Port lines were found in the configuration file!
Program IP cím szerinti szűréshez Az alábbi program a cupsd.conf fájl bejegyzéseit módosítja a kapott paraméterek alapján (ha kell). #include #include #include #include
<stdio.h> <stdlib.h> <string.h>
int empty(char* line) // Érdekes-e számunkra a sor? { if (strlen(line) == 0) return 1; if (line[0]!= 10) return 0; return 1;
68
} void generate(char sample[512], char mode[32]) { char line[1024]; int towrite=0, ok=0; FILE *f=fopen("/etc/cups/cupsd.conf", "r"); FILE *f2=fopen("/etc/cups/cupsd_tmp.conf", "a"); while(fgets(line,500,f)) { if (towrite && line[0]=='<') { if (!strcmp(mode, "HostEnable") && ok==0) { printf("%s", sample); fprintf(f2, "%s", sample); } printf("\n"); fprintf(f2, "\n"); return; } if (towrite) { if (!strcmp(mode, "HostDisable") && strcmp(line, sample)) { printf("%s", line); fprintf(f2, "%s", line); } if (!strcmp(mode, "HostEnable")) { printf("%s", line); fprintf(f2, "%s", line); if (!strcmp(line, sample)) ok=1; } } if (!strcmp(line, "\n")) towrite = 1; } fclose(f); return; } int main(int argc, char **argv) { char line[1024], sample[512], headsample[512]; FILE *f_old=fopen("/etc/cups/cupsd.conf", "r"); FILE *f_new=fopen("/etc/cups/cupsd_tmp.conf", "w+"); int in=0, ok=0, printer=0; strcpy(sample, "Allow From "); strcat(sample, argv[2]); strcat(sample, "\n"); strcpy(headsample, "\n"); in=0; while(fgets(line,500,f_old)) { if (line[0] != '#' && !empty(line)) { if (line[0]=='<' && line[1]!='/') //1. feltétel {
69
printf("\n"); fprintf(f_new, "\n"); if (!strcmp(argv[3], "All") || !strcmp(headsample, line)) { in=1; ok=0; printer=1; }
} if (!strcmp(argv[1], "HostEnable")) //2. feltétel { if(in==1 && !strcmp(sample, line)) ok=1; if(in==1 && ok==0 && line[0]=='<' && line[1]=='/') { printf("%s", sample); fprintf(f_new, "%s", sample); }; printf("%s", line); fprintf(f_new, "%s", line); } if (!strcmp(argv[1], "HostDisable")) //3. feltétel { if(in==0 || strcmp(sample, line)) { printf("%s", line); fprintf(f_new, "%s", line); } } if (line[0]=='<' && line[1]=='/') in=0; //4. feltétel
} } if (printer == 0) { printf("\n%s", headsample); fprintf(f_new, "\n%s", headsample); fclose(f_old); fclose(f_new); generate(sample, argv[1]); } system("mv -f /etc/cups/cupsd_tmp.conf /etc/cups/cupsd.conf"); system("service cupsd restart"); //cups restart return 0; }
A program 3 paramétert kap: Mód, IP cím, Nyomtatónév. A Mód lehet „HostEnable” vagy „HostDisable”. A program „Deny, Allow” módszert feltételez, tehát a konfigurációs fájlban először mindenkit letiltunk, és Allow sorokkal engedélyezzük az IP címeket. A futás elején a sample változóba eltároljuk azt a sort, amire szükségünk van: az „Allow” + IP cím sort. HostEnable esetén ezt szúrjuk be, ha még nincs, HostDisable esetén pedig ezt töröljük az adott nyomtató blokkjából. Azt, hogy melyik blokkban kell figyelnünk, a headsample változóban tároljuk. Ezután a konfigurációs fájlt soronként beolvassuk (while ciklus), és ha nincs kikommentezve, és nem üres a sor, akkor megvizsgáljuk: 1. feltétel: Ha a sor egy blokk nyitó tag-je, és ez a fejléc a 3. paraméterben megadott nyomtatóhoz tartozik, vagy a 3. paraméter ALL, akkor az in változót 1-re állítja, jelezve, hogy ebben a blokkban (is) kell figyelni, és printer változót is 1-re,
70
jelezve, hogy talált olyan blokkot, ahol változtatni kell, de az ok változó 0 értéket kap, ami azt jelenti, hogy még nem történt változtatás a blokkban. 2. feltétel: HostEnable esete: o Ha engedélyezni akarunk, és az aktuális sor épp az, amit be akarunk szúrni, akkor az ok változót 1-re állítjuk.; o Ha figyelt blokkban vagyunk (in = 1) még nem találtuk meg a keresett sort (ok =0), de már a blokk végéhez értünk (záró tag), akkor beillesztjük az engedélyező sort ( sample sztringet a tmp fájlba írjuk). Majd ezek után a beolvasott sort kiírjuk a tmp fájlba. 3. feltétel: HostDisable esete: Minden sort átírunk a tmp fájlba, ha nem vagyunk figyelt blokkban, vagy a beolvasott sor nem egyezik meg a sample értékkel. 4. feltétel: Ha záró tag-et találunk, akkor az in változót 0-ra állítjuk. A while ciklus után, mikor minden sort beolvastunk már, megvizsgáljuk, hogy volt-e olyan blokk, amiben a változtatást végre tudtuk hajtani. Ha nem (a printer változó 0), akkor kiírja a tmp fájlba a headsample változóban lévő nyitó tag-et, és legenerálja hozzá a blokk tartalmát a generate függvény meghívásával. A generate függvény megkapja, hogy tiltást, vagy engedélyezést kell csinálni, és a keresett sort, majd az általános blokk tartalmát bemásolja az új tag mögé, és engedélyezés esetén beilleszti a sample változót is, majd záró tag-gel lezárja a blokkot, és visszatér. Amikor a tmp fájlt sikeresen összeállítottuk, a program kicseréli a copsd.conf fájlt az összeállított tmp fájlra, és a cups újraindításával életbe lépteti a változásokat.
71
