Biztonságtechnikai és ipari felügyeleti vevőkészülék. Maximum 5 csatornára bővíthető, kombinált felügyeleti vevő, többféle vevőkártyákkal, telefonvonali-, GSM voice-, és GSM SMS alapú kommunikációkra, RS-232 és USB-s kimenetekkel, belső tápegységgel, backup akkumulátor csatlakoztatási lehetőséggel, belső puffer-memóriával.
Javasolt:
- biztonságtechnikai, vagyonvédelmi felügyeleti rendszerekre,
- tűzjelző központokat felügyelő központok számára,
- ipari berendezések távfelügyeletére.
1. SeAlarm távfelügyeleti rendszer
A távfelügyeleti rendszerünk alapját az SGR-402 jelű, maximális kiépítettségében 4+1 csatornás vevőközpontunk, vagy a 2 csatornás SGR-201, valamint a mellé telepített számítógépen futó SeAlarm felügyeleti szoftver képezik. Alapkiépítésben is a készülék tartalmaz mind telefonvonali, mindpedig GSM voice alapú, ipari GSM modult tartalmazó vevőkártyát is. Az SGR-402 tovább bővíthető speciális vevőkártyákkal, így pl. DTMF bemenettel rendelkező, rádiós átvitelű vevő kimenetének illesztésére alkalmas vevőkártyát, vagy SMS fogadására alkalmas GSM modult tartalmazó interface kártyát is.
Az SGR-402 négy+egy vonalas központi GSM vevőkészülék Az egyszerre 4 vonalat lekezelni képes asztali kivitelű készülék hálózatról üzemel, üzemeltetéséhez egy 12V/20W-os hálózati tápegység tartozik. A készülék hátlapján akkumulátor bemenet is található abból a célból, hogy az állomás hálózatkimaradás esetére is még működőképes maradjon. A készülék hátoldalán található soros porti kimenet egy számítógéphez csatlakozik, szabványos RS-232 soros porton 9600,N,8,1 a leggyakrabban használt beállítás mellett.
AzSGR-402 vevő vonali vevőkártyái adatátviteli kompatibilitás megfontolásokból már kizárólag DTMF Contact ID formátumú vételre felkészített egyvonalas vevőkártyák, melyek szabványos RJ csatlakozóval felszerelt, villám és túlfeszültség ellen védett bemenetekkel rendelkeznek. A felügyeleti rendszer logikájából fakadóan célszerű a telefonvonalakat a PBX elve szerint kapcsoltatni, így a központok egyetlen számra való felprogramozhatósága mellett, a hívások egyidejűségi elve alapján lényegesen növekszik a felügyeleti rendszer terhelhetősége. Míg egyetlen vonal esetében 100 rákötés, két vonalnál már csak 500-600 felett alakul ki a túlterheltség, három telefonvonal mellett a rendszer akár 2000 rákötést is bátran elvisel.
Az SGR-402 GSM voice alapú, Contact ID vételre felkészített ipari GSM modult tartalmazó vevőkártyákat is képes fogadni. A vevőkártyák vételi formátuma és protokolja is 100%-ban megegyezik a telefonvonaliéval, így ezek nemcsak egymás mellett, de egymás helyett is használhatóak. A vevőkészülékre opcionálisan felszerelherő kétnormás GSM antennák csavaros SMA csatlakozókkal vannak felfogatva, és ezáltal könnyen felcsavarozhatóak. Gyengébb térerővel rendelkező helyeken a doboz tetejére helyezett antennák helyett a biztosabb vétel érdekében célszerűbb felragasztható külső antennákat, vagy a készülékek immobilis volta miatt az antennák lecserélhetők koax kábelen kivezetett fix irányítottságú dipol antennákra. Ezekkel az antennákkal a legszélsőségesebb esetekben mindkét normán kiváló térerő, így kiváló GSM vétel érhető el. A készülék hátlapjén tatlálható SUBD9-es csatlakozó a számítógéppel összekötendő RS232-es port csatlakozója. A szélső Mini XLR csatlakozó a saját backup akku, a középső MiniXLR pedig a 12V/20VA-es külső hálózati dugasztáp csatlakozója, és amely táplálása a mellette lévő kapcsolón keresztül kapcsolható. Biztonsági okokból a vevő tápfeszültség bemenete rövidzár és túlfesz. védelemmel is ellátott, külön földelést nem igényel, az RS232 csatlakozás adta földelés számára elegendő. Ajánlatos a vevőkészüléket a hozzá csatlakoztatott számítógéppel együtt szünetmentes tápról üzemeltetni, mivel áramszünet esetén is hiába rendelkezik a vevő saját 16 mélységű esemény-pufferrel és saját backup akkumulátorral, a bejött események dekódolása és feldolgozása hiányában a felügyeleti rendszer gyakorlatilag működésképtelen.
A készülék előlapján található 4x20 karakteres, és háttárvilágítással is rendelkező LCD kijelző a bejött Contact ID alapú karaktersorozatot mutatja, nemcsak a rendszer működésének ellenőrzése céljából, hanem részben az esetlegesen hibás üzenet, vagy pedig üzenet-töredék is szükség esetén információt adhasson.
A vevőkészülék soros kimenete konfigurálható. Ennek megfelelően saját protokolja mellett átállítható pl. az egyik legelterjedtebb protokol, a SurGard basic protokolra is. Így nemcsak az SGR-xxx sorozatú vevőkészülékeinkhez kifejlesztett SeAlarm felügyeleti szoftverünkkel, hanem más tetszőleges, de legalább ezen fentebb említett protokolt felismerő felügyeleti szoftverekkel is üzemeltethető.
A felügyeleti rendszer használata megfelelő szoftver nélkül elképzelhetetlen, a felügyeletre beérkezett jelzéseket nem elég megjeleníteni, megfelelően fell is kell azokat dolgozni, melyhez elengedhetetlen a megfelelő, részletes és jól kitöltött adatbázis megléte. Így a felügyeleti szoftver biztosítja a beérkezett jel azonnali megjelenítését, értelmezését, a hozzá tartozó intézkedési lista megjelenítését, az esemény és intézkedés folyamatos és pontos naplózását. A vevőegységek mellett elhelyezett számítógépen felügyeleti szoftver mellett futhat más kiegészítő szoftver vagy annak modulja, mely regisztrálja a beérkezett és kimenő telefonhívásokat, rögzíti a beszélgetéseket, a beszélgetések idejét. A szoftver megmutatja a hívó félre jellemző intézkedési utasításokat és regisztrálja azokat.
A jó felügyeleti szoftver regisztrálja a diszpécsereket is. Időről időre automatikusan megkeresi és ellenőrzi a beérkezett tesztkódokat, meglétüket vagy hiányukat, leellenőrizve ezzel a készülékek működőképességét. Lehetőséget biztosít az adatbázis módosítására, az intézkedési tervek megtekintésére, esetleges módosítására, a megtett intézkedések és egyéb bejegyzések utólagos megtekintésére. A beérkezett események alapján létrejött méretes adatbázisban lehetőséget ad különféle események szűrésére, gyors keresésére, nyomonkövetésére és listáztatására is.
2. A SeAlarm felügyeleti szoftver általános leírása
A SeAlarm felügyeleti szoftver az elmúlt 12 évben különféle biztonságtechnikai szoftverek, felügyeleti rendszerek és diszpécser szolgálatok számára megírt szoftvereken szerzett tapasztalatok és tanulságok alapján íródott, megfelelően összpontosítva a rendszer biztonságára, és adatvédelmére is egyaránt. A rendszerben az események nyugtázása a kezelőszemélyhez vannak rendelve. A szolgálat átvételekor a rendszerbe bejelentkezik a diszpécser. A rendszer a kijelentkezést csak úgy engedi, ha legalább egy személy az adott rendszerben dolgozik. Az események egy fő ablakban futnak. Ez azonnal mutatja a beérkezett azonosító számát, az előfizető nevét, a jelzés jellegét, a beérkezés dátumát és pontos idejét, az esemény zónaszámát és csoportkódját. Ugyanakkor feljegyzésre kerül a jelzés beérkeztekor, ha az nyugtázást igénylő jelzés, annak nyugtása, illetve a nyugtázás időpontja, és a diszpécser neve is. A kinyílt intézkedési ablak tartalmazza a klienshez tartozó, legfontosabb tudnivalókat, és ezen instrukciók hatására a diszpécser megkezdi a megfelelő intézkedést, ennek meglétét pedig egy felnyíló ablakban szintén regisztrálja. A szoftver lehetőséget nyújt különféle listák megtekintésére is. Ezen listák jórészét, így például a névsor szerint rendezett kliensek listája is a diszpécserek számára azonnal megtekinthető, meggyorsítva ezzel is a munkájukat a név szerinti keresésben. A diszpécsernek lehetősége nyílik egy-egy pácienshez tartozó eseménylistát generálni vagy kinyomtatni, mely adott esetben hasznos információt hordozhat. A szoftver széles körben módosítható paramétereket és adatbázist tartalmaz. Szabadon felvehetők különféle kódtáblák, események, eseménycsoportok és eseménykódok is, hozzájuk rendelve a megfelelő wav hangjelzést és intézkedési utasításokat. Mindezekkel a szoftver bármikor szabadon kíbővithető. Számtalan egyéb listáztatási funkciókkal is rendelkezik a szoftver. Megjelenítheti az egy-egy emberhez tartozó eseményeket egy megadott idő intervallumban, kilistáztatható egy adott eseményhez (pl. orvoshívás) tartozó kliensek listája, szintén adott idő intervallumon belül. Lehetőség van a beérkezett tesztkódok ellenőriztetésére is, ami megbízható képet ad a rendszer egyes elemeinek működőképességeiről. Egy nagyobb kiterjedésű és ügyfélszámú rendszer hibamentes üzemeltetése ma már enélkül szinte elképzelhetetlen.
3. A SeAlarm felügyeleti szoftver telepítése
A SeAlarm szoftver telepítés telepítő CD-ről történik. A szoftver minimális háttér igénye Microsoft XP operációs rendszer alatt futó gép minimum 256MB memóriával, 1280x1024-es felbontású képernyővel, 40GB merevlemezzel, 1 db soros port bemenettel. Ajánlott kiépítése nagyobb rendszerben 1GB memória, mellett 80GB merevlemezzel.
A szigorú értelemben vett szoftveren felül telepíteni kell a számítógépre a dotnet.fx keretrendszert és a hálózatos futtatás érdekében a MSDE SQL szervert létrehozó szoftvert, majd a gép újraindítása után telepíthető a SeAlarm monitoring szoftver. A szoftver telepítése után a Config.exe fájl indításával létre kell hozni egy un alap-adatbázist amely az adattáblák, az eseménytáblák, a nyelvi beállítások és a kódtáblák feltöltését jelenti. A beállítások ablakban még néhány további fontos paraméter is beállítható, így a soros port és annak sebessége. Itt állítható az SQL szerver helye, fixIP címe (ez lehet ezen a gépen is, ekkor localhost), a neve és a hozzáférési jelszó. A konfigurálás menete az adatbázis törlése, utána pedig annak létrehozása, majd az adattáblák létrehozása következik. Az elvégzett beállítások elmentése után, az így létrejött kódtáblákkal már elindíthatóvá válik a felügyeleti szoftver, és már a szoftverből tovább folytatható az adatbázis feltöltése. A program első elindítása előtt ellenőrizni kell, ész szükség esetén beállítani a Sealarm.cfg file-ban a néhány paramétert.
Sealarm_SqlTimeOut=20 SQL Timeout értéke (512MB memória esetén 30-ra venni)
Sealarm_CommTimeout=60 Kommunikációs TimeOut riasztás (0=kikapcsolt)
Sealarm_SerialServer=1 Soros porti vevő (SGR-402) esetén
Sealarm_TcpServer=0 GPRS üzem, TCP szerver esetén
Sealarm_TcpPort=1234 GPRS üzem esetén TCP port száma
Sealarm_TcpLogging=0 Mindig 0 !
Sealarm_TcpTestCode=606 Mindig 606 !
Sealarm_FastTestCode=600 GPRS Testcode TimeOutTCP másodpercben
Sealarm_TcpTimeOutA=30 TCP connection, NoData-TimeOut
Sealarm_TcpTimeOutB=15 TCP connection AfterData-TimeOut
Figyelem! A megfelelő rendszerismeret mellett a feketén jelzett paraméterek szabadon állíthatók, a kékkel jelzettek állítása alapos körültekintést igényel. A pirossal jelzett paraméterek állítása a rendszer működőképességét veszélyeztetik !
4. A szoftver adatbázisa
A felügyeleti szoftver natív módjában, az 1280x1024-es felbontásban (ablakban) fut. Ennél kisebb képernyőfelbontás melletti használata igen kényelmetlen lesz, nagyobb felbontás mellett pedig a képernyőn, vagy képernyő egyes részein kihasználatlan területek keletkeznek, az ott láthatóvá vált háttér esetleg zavaró lesz. A képernyő könnyen átlátható, bal oldala tartalmazza a bejött eseményeket, jobb oldalon az intézkedésekkel és egyéb adatokkal kapcsolatosak látszanak.
A felügyeleti szoftver elindítása után ajánlott annak belső felkonfigurálása. Ezeket az alábbiakban leírt sorrend alapján célszerű majd elvégezni, így az első ablak kinyitásával a rendszeridő beállítása javasolt. Ebben a menüablakban látható a felhasználó váltás ablak is, ahol a rendszergazda és a diszpécserek a megfelelő jelszókkal ki-, és bejelentkezhetnek.
Az eseménybázisok adattábla kitöltése vagy bővítése lesz az adatbázis műveletek legelső feladata. Itt kell (ha éppen szükséges) az adott lakás-, és ipari biztonságtechnikai események körét bővíteni az újabb eseménytípusokkal. Minden esemény egy-egy típusba sorolható, melyek azonos tulajdonságokkal jelennek meg, így pl. kiválasztható szinekkel, hangjelzéssel, és itt jelölhető meg intézkedést igénylő eseménynek.
A későbbiekben minden egyes esemény egy-egy itt definiált típusba sorolandó be. A későbbiekben pedig minden egyes típushoz minden egyes kliensnél külön-külön intézkedési utasítás adható meg. Az adatbázis átgondolt, logikus, részletes, és helyes kitöltése igen fontos feladat, ennek megfelelő részletességgel és pontossággal fog információt adni a szoftver egy-egy esemény beérkezésekor. Az ügyfelek ablakban az újabb kliensek vehetők fel. Itt kell kitölteni adataikat melyek intézkedést igénylő esemény beérkezése esetén azonnal előjönnek. A kliens adatadain túlmenően ki kell nyitni és kitölteni az egyes eseménytípusok esetén beérkező intézkedési terveket, így külön betöréskor külön tűz esetén és külön a pánik esetére is. A riasztás beérkeztekor pontosan annyira részletes intézkedési utasítást fogunk majd kapni, amennyire részletesen kitöltöttünk az intézkedési utasításokat itt a kezdetben. Ide tartoznak majd az egyes ügyfelekhez tartozó objektum típusok is, melyek hasznos információt adhatnak azonnal a jelzés forrásáról. Az objektum típusok köre szabadon bővíthető, és pontosítható annak érdekében, hogy a jelzés forrása is "kategorizálható" legyen. Lényeges, hogy az egyszer már felvett, és rendszerbe állított objektumtípust sem, (így más adatelemekhez hasonlóan) ne töröljük le, mert ez az adatbázisban nem várt eredményt, így adatvesztést hozhat. A beérkezett Contact ID alapú események mindegyike tulajdonképpen egy-egy kód lesz, melynek jelentését és tulajdonságait a kódtáblában definiáljuk, valamint öröklik a besorolt eseménytípusokhoz rendelt tulajdonságokat és intézkedési feladatokat egyaránt. Új esemény felvételekor meg kell adni az új esemény kódját, nevét és a típusát. A megadott eseménytípus fogja az adott eseményhez a megfelelő intézkedési utasítást hozzárendelni, amely ezenkívül meghatározza majd a beérkezett jelzés megjelenítése színét, hangját, és az intézkedési igényét is egyaránt. Az alaptáblázatban szereplő események a szabványt teremtő SIA és ADEMCO jelzései, így ezek módosítása nem célszerű, mivel a riasztóközpontokba beépített jelzések kódjai is egyben ugyanezek. A kódtábla viszont szabadon tovább bővíthető, így az új jelzések felvitelének sincs semmiféle akadálya.
A szabványos Ademco - Contact ID kódtábla logikus felépítésű, az események jól elhatárolt csoportokban vannak. Gyakori hiba az újabb kódok felvitele esetén, hogy adott eseményt későbbi alkalmakkor újra és újra, de már más-más kód alatt, sőt külön esemény-csoportban visznek fel, mely később az intézkedési lista hazárdját vonja maga után, az adott események nem a legmegfelelőbb intézkedési utasításokkal kerülnek megjelenítésre.
A beérkezett események beérkezésükkor két-három új paraméterrel egészülnek ki: így a beérkezésük időpontjával, esetleges nyugtázásuk időpontjával, valamint a nyugtázáskor bejelentkezett azaz a nyugtázó diszpécser nevével. A menüpont lehetőséget ad az újabb diszpécserek felvételére teljes névvel, jelszóval és login névvel. Hozzá-rendelhető rendszergazda funkció, vagy korlátozható csak adminisztrációs tevékenységekre, mint pl. az új kliensek felvétele, és a különféle listák elkészítése, kinyomtatása, stb. Mindezt a megosztott, hálózatos funkciónak köszönhetően lehetséges a diszpécsergéptől távol, a hálózatban egy másik gépen is elvégezni.
Az adatbázis menüablakban egy menüpont lehetőséget biztosít a bejövő események egy részének törlésére. Ezt igen elővigyázatosan kell kezelni, mivel az el nem mentett, de letörölt események már nem állíthatók vissza. Az események törlését megelőzően célszerű először az eseménybázist a megfelelő menüpontban először elmenteni.
5. A SeAlarm listáztatási funkciói
A felügyeleti rendszer napra kész üzemeltetése és nyomonkövetése szempontjából döntően fontos az adatbázis és az eseménybázis, ezáltal a kiválasztott adatelemek gyors és sokrétű listáztathatósága. A leggyakrabban használt funkció az események listáztatása, mely célszerűen időben beállítható kezdő és beállítható befejező dátumig történik. Az eképp megadott lista tovább szűkíthető a csak listát kérő ügyfelekre, vagy csak a listában kiválasztott ügyfelekre. Az index lista még tartalmazza az összes ide tartozó, beérkezett eseményt, mely azonban még tovább szűkíthető az itt kiválasztható eseménytípusokra, vagy pl. a nyitás-zárásokra egyaránt. Az így előállt lista kinyomtatható képernyőre, installált nyomtatóra, vagy akár fájlba is.
Az ügyfeleknél telepített biztonságtechnikai eszközök, a riasztóközpontok üzemképességének ellenőrzésére a tesztkódok figyeltetésével nyílik lehetőség. A már beérkezett automatikus tesztkódok megmutatják mely rendszerek az üzemképesek, és hiányuk pedig megmutatja melyikek estek ki a rendszerből. Az adott ügyfélkör felsorolása megmutatja honnan mikor érkezett az utolsó érvényes tesztkód, mely időnek bele kell esnie az ügyfél felvételekor deklarált tesztkód időközbe, mely a kialakult gyakorlat szerint a telefonos hálózatok esetében magán ügyfeleknél általában 1 hét, kiemeltebb ügyfeleknél rendszerint 1 nap szokott lenni. A GSM voice alapon üzemeltetett hálózatok esetében a kör egymás közti ingyenes hívás lehetőségével élve célszerű a tesztkód időközt mindenhol 1 napra egységesíteni. Az ennél gyakoribb tesztkód igény irreális a hagyományos riasztóközpontok jórészénél be sem állítható, illetve a gyakori tesztkód özön pedig feleslegesen terheli le a felügyeleti rendszer telefon vagy GSM vonalait.
A tesztkódokon felül hasznos információt adhat az ügyfélkörtől beérkezett különféle események közül a legutolsó, az un. legutolsó események listája is. Néhány speciális, kommunikációs szempontból kritikus esetben, pl. viharban, vagy áramszünet után, amikor igen sok téves jelzés érkezik, kiszűrhetők a rosszul telepített, vagy bizonytalan rendszerek, riasztóközpontok, mely ezáltal lehetőséget teremt a rendszer ügyfeleinél telepített eszközei olcsóbb, gyorsabb karbantartására.
A leggyakrabban kért lista a nyitás-zárás lista, melyet általában az intézmények, üzletek azaz a nem magán jellegű ügyfelek szoktak kérni. A nyitás-zárás lista elkészítésének egyik előfeltétele a nyitás-zárás riportok beérkezése, vagyis a riasztó-központok eképp történő felprogra-mozása. A kinyitott ablak felkínálja a kilistáztatni kívánt időszak kezdő és befejező dátumát. Az így beállított időszak így minden, későbbiekben kiválasztandó ügyfélre ugyanaz lesz, vagyis pl. elkészülhet egy október hónapra vonatkozó nyitás-zárás lista. Azoktól az esetlegesen (pl. tévesen) kijelölt ügyfelektől, akiktől nem érkezett nyitás-zárás jelzés az adott időszakban, mert pl. a riasztóközpont nem volt felprogramozva erre, a nyitás-zárás lista nem fog tartalmazni értékelhető felsorolást, mivel az ilyen kóddal szereplő események sem érkeztek, érkezhette be tőlük. A nyitás-zárás lista jó kontrollja a kommunikációs vonalaknak, mivel egy nyitás vagy zárás "kimaradása" a rendszer kommunikációs hibáira szokott utalni, melybe természetesen a szolgáltató is beletartozik.
Intézmények esetében külön kérés szokott lenni a nyitottság ellenőrzése. Az intézmények esetében pl. esti időpontban, 22 órakor történt listázás, és annak ellenőrzése figyelmeztethet arra, hogy egyes intézményekben elfelejthettek zárni, így pl. a riasztóközpontot beélesíteni. De mivel ezen események létrejöttének oka sokféle lehet, így ezen események lekezelése, az intézkedés is mindig telefonon történik, a rendszer kinyitott állapota okának lekérdezése, kiderítése céljából.
5. A SeAlarm mentési funkciói
A felügyeleti szoftver hálózati üzemétől függetlenül is rendelkezik különféle adatbeállítási-, és eseménymentési- és visszatöltési funkciókkal. Az adatmentések helye lehet a merevlemez, de célszerű inkább a merevlemezen kívül, külső meghajtón (így pl. egy pendrive-ot) kijelölni, mert a számítógép esetleges károsodás esetén sem vesznek el így az adtok, részben pedig gépcsere esetén egyszerűbb lehet a rendszer újraindítása. A törzsadatok mentése csak a cél maghajtó kijelölését igényli, az eseménybázis mentésekor meg kell adni a kimentendő időszakot is. A mentés, persze nem korlátozódik csak az adatokra, külön elmenthetők a beérkezett események is. Az törzsadatok mentéseket és az eseménybázis elmentését célszerű mindig egyszerre elmenteni, mert általában mindkét adathalmaz folyamatosan gyarapszik, és a sok-sok közbülső elmentett állapotból származó mentések közül csak az egyidőben elmentett adat- és eseményhalmaz páros lesz a ténylegesen is összetartozó, és egymáshoz illeszkedő adatpáros. A nem "összetartozó" adat-, és eseménybázisból nem lehet visszaállítani a tényleges állapotot. A törzsadatok és az eseménybázis visszatöltése is ebben az ablakban végezhetők el. A régebben elmentett törzsadatok és események visszatöltésekor a mentés korábbi helyét, azaz az adathordozó helyét itt kell megadni. A visszatöltés esetén fokozottan kell ügyelni a törzsadatok és az elmentett eseménybázis összetartozására is, mert pl. a még fel sem vett ügyfelektől be-érkezett "adat" nem várt eseményt okozhat a monitoron, illetve egészen téves kiírások és összefüggések jelenhetnek meg, súlyosabb esetben a program futása is leállhat. Kritikus helyzetben célszerű a legutoljára kimentett, és még tudottan jó és helyes törzsadatbázist
betölteni, majd ehhez választani a törzsadatoknál régebbi, de ezen belül a lehető legújabb eseménybázist választani, melyet a szoftver még hibajelzés nélkül elfogad.
Általában javasolt, hogy egy monitoring rendszernek csak egyetlen rendszergazdája legyen, mivel másik rendszergazda által nem-, vagy csak nem megfelelően dokumentált adatmozgatások mellett a különböző időpontokban keletkezett mentésekből származó adatbázisok összekeveredésének veszélye áll fent.
6. A szoftver GPRS üzemmódja
A felügyeleti szoftver TCP protokol szerinti vételre is alkalmas, ahol a hálózaton, vagy a GPRS üzemmódban "feladott" jelzések vétele folyhat. A GPRS üzemmódban feladott jelzések szerkezete összetettebb, de persze tartalmazza mindazon információkat is, melyeket a Contact I formula is tartalmaz, ebben az értelemben tehát adatvesztés esete nem áll fent.
A GPRS üzemmódban a szoftver működése csaknem teljes mértékben megegyezik a soros porton keresztül, az SGR-402 vevőtől kapott adatok alapján, Contact ID kódtáblás működésével. A számítógép fixIP címére, és adott porton beérkezett üzenet a kompati-bilitás megőrzése és a könnyebb kezelhetősége érdekében szabványos Contact ID alapú üzenetté konvertálódik át, majd a továbbiakban ennek megfelelő eseményként kerül be az eseménylistába, és kezelődik le a továbbiakban. Így a rendszer működése ettől a ponttól kezdve nagyjából megegyezik az előzőekben leírtakkal. Néhány apróbb eltérés adódik az alábbiak szerint:
A sealarm.cfg file javasolt tartalma az alábbi lesz:
Sealarm_SqlTimeOut=20 SQL Timeout értéke (256MB memória esetén 30-ra venni)
Sealarm_CommTimeout=0 Kommunikációs TimeOut riasztás (0=kikapcsolt)
Sealarm_SerialServer=0 Soros porti vevő (SGR-402) esetén
Sealarm_TcpServer=1 GPRS üzem, TCP szerver esetén
Sealarm_TcpPort=1234 GPRS üzem esetén TCP port száma
Sealarm_TcpLogging=0 Mindig 0 !
Sealarm_TcpTestCode=606 Mindig 606 !
Sealarm_FastTestCode=600 GPRS Testcode TimeOutTCP másodpercben
Sealarm_TcpTimeOutA=30 TCP connection, NoData-TimeOut
Sealarm_TcpTimeOutB=15 TCP connection AfterData-TimeOut
Megjegyzés: Pirossal jelzett paraméterek itt fix paraméterek.
Állításuk a rendszer működőképességét veszélyeztetik !
Copyright © 2010 Maxteam Kft. Minden jog fenntartva. |
Designed by Maxaviv Kreatív Stúdió - www.maxaviv.hu |