Komplex ipari, vagyonvédelmi, biztonságtechnikai felügyeleti szoftver, limitált és limitálatlan verziókban. Távolról elérhető, több kezelő felülettel. Hálózatban működtethető, többszintű jogosultságokkal. Bármilyen riport, lekérdezés, adatbázis operáció megvalósítható. A teljes mértékben az ügyfél által hozzáférhető SQL adatbázis egyedileg fejleszthető, szabadon a megrendelő, vagy felkérés esetén fejlesztőink által. Windows operációs rendszer alatt futtatható szoftver teljeskörű vételi forma, protokol, és adatbázis konfigurálási lehetőségekkel. Beépített GPRS és HSUPA vételi modullal együtt! Bank technikában használt szuper biztonságos kapcsolattal (nem szabotálható rendszer, online működőképesség ellenőrzés miatt azonnali intézkedést tesz lehetővé).
Alkalmazása
- biztonságtechnikai, vagyonvédelmi felügyeleti rendszerekre
- ipari, telephelyi központoknak: biztonsági, vagyonvédelmi, technikai monitoring célokra
- lakossági riasztó rendszerekhez, kiemelten biztonságos kapcsolattal
- szakképzettséget nem igénylő otthonról felügyelhető szabadtéri területek (mezőgazdasági öntözési földek; Reklám felületek, neoncsövek online ellenőrzése akár mobil telefonról)
- ital automaták, Liftek, Hűtőraktárak, Hőközpontok, Táfűtési hálózatok távfelügyelete, távleolvasása
1. 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.
2. 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 !
3. 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.
4. 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 |