Nejnavštěvovanější odborný web
pro stavebnictví a technická zařízení budov
estav.tvnový videoportál

Monitorovací a řídicí systémy – integrační platforma IPS (2. část)

Druhý díl článku k tématice technologií, které poskytují celou řadu provozních údajů o budovách, využitelných pro řízení jejich provozu. Proto je žádoucí soustředit je pod jedno sjednocující grafické prostředí.

První část článku o platformě IPS naleznete ZDE.

Nepoplachové rozhraní

Technické systémy vykonávající funkce sloužící pro ochranu života anebo majetku mají v obsahu svých systémových a aplikačních norem dosti obdobné „základní“ provozní požadavky.

Sloučíme-li (dle ČSN CLC/TS 50398 „integrujeme“) víc těchto systémů do jednoho funkčního celku, logicky se předpokládá, že dojde k přenosu těchto požadavků i na jejich společnou integrační platformu. Zadávací podmínky konkrétních výběrových řízení, ale také projektová dokumentace, body s obchodně pojatým vyjmenováním jednotlivých detailů takřka vždy obsahují. Co se ale v praxi bohužel ani nepožaduje, je „proces ověření systémové kompatibility se zachováním podmínek připojitelnosti nestandardních komponentů systému“ (kompatibilita ‒ schopnost komponentů systému spolupracovat s jinými komponenty stejného systému).


Bavíme-li se o jednotlivých poplachových systémech, i u těch zcela autonomních se můžeme setkat s termínem „komponent“. Pro další odstavce bude vhodné popsat si možné významy tohoto pojmu:

© Fotolia.com
© Fotolia.com
  • systémový komponent (dle ČSN CLC/TS 50131-7 jde o jednotlivé díly, jako ústředna, moduly, detektory, ovladače, napájecí zdroje, sirény, komunikátory atd., které, jsou-li spolu sestaveny, vytvářejí poplachový zabezpečovací a tísňový systém – I&HAS),
  • ostatní komponent (dle ČSN CLC/TS 50131-7 jde o komponenty jiných systémů, které mohou být kombinovány nebo integrovány s I&HAS za předpokladu, že to negativně neovlivní funkci jednotlivých komponentů I&HAS, například signalizační LED tablo).




Poznámka: Pro poplachové systémy v obecné rovině také platí, že v případě, kdy neexistuje norma pro komponent systému, je povoleno použít komponent, u něhož není stanoven stupeň zabezpečení nebo třída prostředí ‒ za těchto okolností bude stupeň zabezpečení systému dán stupněm zabezpečení komponentu nejnižšího stupně, u kterého je stupeň zabezpečení stanoven. Je potřeba také připomenout, že stupně zabezpečení v totožném významu od 1 (nízké riziko) do 4 (vysoké riziko) platí jak pro I&HAS = poplachové zabezpečovací a tísňové systémy, tak pro VSS = video dohledové systémy (včetně CCTV), ale také pro ACS = systémy kontroly vstupu.

U autonomních a zejména u integrovaných poplachových systémů je doplňkovým komponentem, který se pohybuje na pomyslné hraně významu „systémový/ostatní“, výše zmiňovaná integrační platforma – tedy ono počítačové pracoviště se speciálním programovým vybavením. Několik málo zmínek o připuštění si myšlenky na jeho začlenění do skladby poplachových systémů nalezneme napříč většinou základních norem.

Nejzajímavější zmínku směrem k pochopení problematiky nasazování monitorovacích/řídicích systémů nalezneme v ČSN EN 50131-3, kde se objevuje zkratka ACE (Ancillary Control Equipment neboli doplňkové/pomocné ovládací zařízení). Také je zde popsán termín „nepoplachové rozhraní“ – a to jako vnější zařízení poplachového zabezpečovacího systému používané k vykonávání některých nebo všech funkcí pomocného ovládacího zařízení (například počítač nebo osobní digitální asistent).

Podstatnější než popis pojmu je zde příloha zabývající se použitím nepoplachových rozhraní. Je to jeden z mála komplexněji pojatých komentářů k použití osobního počítače v oblasti poplachových systémů. Je zde připuštěna možnost zdvojení ovládání poplachového zabezpečovacího a tísňového systému, pochopitelně při splnění jednoznačných podmínek s odkazy na jejich nutnost být ekvivalenty k požadavkům, které splňuje jak sama ústředna poplachového systému, tak systémová zařízení uživatelských vstupů (například ovládací klávesnice). Jako základní ze zde vznesených požadavků lze směrem k programovému vybavení počítačových pracovišť považovat požadavky na:

  • oprávnění (přístup do komunikačního softwaru nepoplachového rozhraní musí být obdobně jako přístup k funkcím vlastní ústředny na přístupových úrovních 2, 3 a 4 omezen – a to včetně potvrzení ústřednou),
  • ověření (iniciace komunikace mezi nepoplachovým rozhraním a poplachovým zabezpečovacím a tísňovým systémem musí obsahovat ověření ekvivalentní k normou danému ověření ústřednou),
  • indikace (je-li použit dispečerský signalizační panel/tablo, mohou být pro bezpečnostní personál indikace dostupné bez omezení. V tomto případě by měl být všeobecně přístup k tomuto panelu omezen dle specifických potřeb instalace, například instalací ve vnitřní místnosti bezpečnostního personálu v klíčem uzamčené skříni. Za splnění těchto podmínek může být nepoplachové propojení považováno jako ekvivalentní systémovému zobrazovacímu panelu).

Normy

Technické normy jsou předpokladem technického pořádku v daném oboru na příslušné úrovni, tedy například celosvětově, mezinárodně, národně, v rámci určitého sdružení zájemců apod. Ačkoliv technická normalizace se sama o sobě nemusí zdát zajímavá, výsledky tohoto procesu hrají důležitou roli v našem každodenním životě. Normy mají bezprostřední vliv na to, že fungují jak ty nejjednodušší výrobky, tak i složitější systémy ‒ například poplachové.

Byť vývoj technické normy zůstává plně pod záštitou nezávislé, v řadě zemí i privátní normalizační organizace, velmi výrazně se prostřednictvím technické normalizace uplatňuje veřejný zájem. Z hlediska spotřebitelů/uživatelů je u aktuálně probíraného tématu na prvním místě potřeba zdůraznit aspekty bezpečnosti a kvality, z širšího úhlu pohledu je to pak transparentnost trhu a podnikání, srozumitelnost, finanční a technická dosažitelnost řešení.

Proč tato „spotřebitelská“ odbočka? Jednoduše proto, že ačkoli jsme několik předchozích stran věnovali technickým systémům, které vykonávají funkce sloužící pro ochranu života anebo majetku, reálná praxe je spíše o nesrozumitelnosti a technicky nedosažitelných řešení.

Ačkoli některé z výše uvedených citací poukazují na možnost použít integrační platformu, žádná z platných norem sama o sobě nenastavuje pravidla tak, aby nedegradovala vlastnosti připojených technologií. Můžeme ale norem použít jako odrazového můstku pro stanovení přijatelného stupně jistoty za předem stanovených podmínek. Nejjednodušeji pomocí již zmiňovaného „checklistu“ ‒ dokumentu, který poslouží jednak jako podklad pro výběr jednotlivých prvků poplachových systémů, tak i pro stanovení podmínek provozování jednotné integrační platformy se sdruženým pohledem na bezpečnost. Oproti obvyklým funkčním požadavkům na jednotlivé systémy (kde lze norem využít v plném rozsahu) je zde vhodné stanovit také obsah zkoušek reálné „demo sestavy“ formou akceptačních testů.

Je zcela jasné, že by součástí takovéhoto materiálu měl být samostatný list zabývající se doplňkovými/pomocnými ovládacími zařízeními a nepoplachovým rozhraním jakožto vnějším zařízením používaným k vykonávání některých (obvykle spíše všech) funkcí pomocného ovládacího zařízení – tedy osobním počítačem a jeho speciálním programovým vybavením.

Kompatibilita v praxi

Výrobci a dodavatelé jednotlivých komponent poplachových systémů jsou si vědomi potřeby doložit, že pouze jejich výrobek je pro dané řešení tím nejvhodnějším. Jde ale převážně o nerelevantní doklady/materiály. Kvalita techniky používané v oblasti poplachových systémů obvykle bohužel netrápí distributory a ani montážní firmy ‒ a zákazník se pochopitelně o tom, jak se prokazuje, nedozví už vůbec nic (čestné prohlášení v takovémto případě opravdu nestačí). V podstatě u každého výrobku/prvku je možné získat odborně vypadající doklady, vytvořené třetí stranou, se slovy: „Zařízení je homologováno, atestováno, schváleno, posouzeno, vyzkoušeno, certifikováno.“ Vyjma certifikátů vydaných akreditovaným certifikačním orgánem jde až na malé výjimky o „bezvýznamný“ list papíru. A to se bavíme pouze o technice, tedy o HW, který je hmatatelný a prakticky měřitelný.

Aby to nevyznělo úplně negativně ‒ výhodou takovýchto dokladů, u ústředen a řídicích jednotek, je sestava komponentů, pro kterou daný doklad platí. Obvykle jde o druhý list každého dokladu – odstavec „Ústředna je testována/certifikována s následujícími komponentami“. Je tak alespoň možné ověřit, jestli a jak se počítá s doplňkovými/pomocnými ovládacími zařízeními a také s využitím nepoplachového rozhraní.

Podrobnější zmínku si zaslouží vlastní „programovací“ nástroje dodávané k řídicím jednotkám a ústřednám. Jde-li o klasický servisní nástroj, předpokládá se, že jako jednoúčelový nemůže nijak uškodit – tedy že nemůže degradovat vlastnosti jednotlivých technologií/systémů. Zapomíná se zde na fakt, že každý systém je možné nevhodně naprogramovat – a to jak neúmyslně, tak také cíleně. V tomto případě se nebude jednat o sabotáž, ale o snahu splnit přání zadavatele. Tedy nastavit systém přesně podle jeho přání – mnohdy v rozporu s požadavky norem. Existuje málo takových systémů, které v případě, že nastavení jednotlivých vlastností neodpovídá bezpečnostním účelům daného zařízení, programátora/servisního technika jednoznačně upozorní, že jím nastavené parametry nejsou v souladu s normou, na základě které proběhlo jejich „posouzení“.

Trochu jiné je to však v případě, kdy je oním speciálním programovým vybavením vlastní monitorovací a řídicí systém nasazený jako integrační platforma. Z obecných obchodně laděných materiálů se můžeme dozvědět nejen jak je modulární a škálovatelný, ale také že nemá limity co do rozsahu instalace a především že splní všechny požadavky i těch nejnáročnějších uživatelů. To vše aniž je předem známe – možnosti provozu totiž primárně určují jejich výrobci a zákazník se obvykle přizpůsobí.

Už z informací o přehledu dostupných bezpečnostních a automatizačních systémů (desítky až stovky), se kterými každý takovýto jednotlivý program počítá, je celkem jasné, že žádné dvě instalace nebudou identické. Je tedy zcela na místě požadovat k jednotlivým připojitelným zařízením techničtější informace jako například:

  • přehled povinných a volitelných funkcí specifikovaných v souvisejících normách,
  • přehled doplňkových funkcí společně s informací, jestli (ne)mohou ovlivnit správný provoz povinných funkcí (pokud jsou tyto další funkce poskytnuty k užívání, nesmí ovlivnit shodu s požadavky v souvisejících normách),
  • popis konfigurace/í jednotlivých funkcí, které by měly vliv na snížení deklarovaného stupně bezpečnosti,
  • funkční popis hlavních programových modulů, včetně stručného popisu každého modulu a úkolů, které zajišťuje.

Položme si otázku. Máme je od svého dodavatele k dispozici? Máme v ruce něco víc než katalogový list doplněný ujištěním v předložené cenové nabídce? Při prokazování tzv. podpory integrace je takto obvykle ‒ jako jediným podepsaným dokladem ‒ deklarován případný vývoj datového rozhraní pro integrace do software třetích stran a také schopnost zajistit nezbytnou technickou podporu pro jeho vývoj. A máte od výrobce alespoň informace o jeho vývojovém týmu, včetně detailů o způsobu poskytování technické a projektové podpory? U nadnárodních společností díky jejich způsobu podnikání jistý stupeň jistoty existuje, jak je to však u drobných, úzce specializovaných společností?

Vytvoření již zmiňovaného „checklistu“ pro takovýto zákaznicky laděný produkt je úkolem takřka neřešitelným – žádný odborný subjekt s puncem nezávislosti není k dispozici a hlavně o něj není zájem. Větší organizace, státní i soukromé, ho již mají zahrnutý ve svých bezpečnostních směrnicích. Vycházejí sice převážně z monitoringu vlastních chyb a mají tak omezené možnosti volby, ale i to je lepší než nic.

Závěr

Podmínky realizace a bezpečného provozu integračních platforem jsou normativně splnitelné při znalosti a respektování existujících zavedených norem několika oborů. Těch oborů, jejichž technologie požaduje zákazník sdružit do jediného obslužného a přehledového „místa“.

Zamyslíme-li se tedy závěrem nad tím, že u tak klíčového systémového prvku, jako jsou monitorovací a řídicí systémy nasazované jako integrační platforma integrovaných poplachových systémů (IPS), je k dispozici jediný normativní standard (základní definice všeobecných požadavků a typů struktur kombinovaných a integrovaných poplachových systémů – ČSN CLC/TS 50398) a žádné jiné nezávislé a mezinárodně uznávané „vodítko“, nabízí se otázka, o jaké systémy se to vlastně jedná.


Klíčové pojmy článku

PZTS – poplachový zabezpečovací a tísňový systém (intrusion and hold-up alarm system = I&HAS): kombinovaný systém určený k detekci poplachu vniknutí a tísňového poplachu (ČSN EN 50131-1 ed. 2; článek 3.1.40).

EACS – elektronický systém kontroly vstupu (electronic access control system = EACS) / systém kontroly vstupu (access control system = ACS): Elektronický systém kontroly vstupu poskytující oprávněným osobám nebo entitám vstup do a/nebo opuštění zabezpečeného prostoru a zamítající vstup a/nebo odchod neoprávněným jedincům nebo entitám (ČSN EN 60839-11-1; článek 3.63).

VSS – dohledový videosystém (video surveillance system = VSS): systém skládající se z kamerového vybavení, úložiště, monitorovacího a souvisejících zařízení pro účely přenosu obrazu a ovládání. Poznámka: Systémy CCTV jsou součástí obecnějšího pojmu „VSS“ (ČSN EN 62676-1-1; článek 3.1.24).

FDAS – systém elektrické požární signalizace (fire detection and fire alarm system = FDAS): skupina komponentů zahrnujících ústřednu, která, pokud je uspořádána ve stanovené(-ých) konfiguraci(-ích), je způsobilá detekce a indikace požáru a vydání signálu pro příslušné úkony (ČSN EN 54-1, článek 3.1.20).

Literatura

  • ÚNMZ (Úřad pro technickou normalizaci, metrologii a státní zkušebnictví), www.unmz.cz
  • ČSN CLC/TS 50398
    Poplachové systémy – Kombinované a integrované systémy – Všeobecné požadavky
  • ČSN CLC/TS 50131-7
    Poplachové systémy – Poplachové zabezpečovací a tísňové systémy – Část 7: Pokyny pro aplikace
  • ČSN EN 550131-3
    Poplachové systémy – Poplachové zabezpečovací a tísňové systémy – Část 3: Ústředny
  • ČSN EN 50131-1 ed. 2
    Poplachové systémy – Poplachové zabezpečovací a tísňové systémy – Část 1: Systémové požadavky
  • ČSN EN 60839-11-1
    Poplachové a elektronické bezpečnostní systémy - Část 11-1: Elektronické systémy kontroly vstupu – Požadavky na systém a komponenty
  • ČSN EN 62676-1-1
    Dohledové videosystémy pro použití v bezpečnostních aplikacích – Část 1-1: Systémové požadavky – Obecně
  • ČSN EN 54-1
    Elektrická požární signalizace – Část 1: Úvod
  • ALARM FOCUS (Odborný časopis se zaměřením na problematiku bezpečnostních technologií), ISSN 1805-9007, ev. č. MK ČR E 21161
 
Komentář recenzenta Ing. Jan Vidim

Článek přehledně shrnuje požadavky na integrovaný poplachový systém ve vztahu k platným normám. Tyto vazby si řada projektantů ani provozovatelů neuvědomuje, a proto je dobře, že jsou zde uvedeny. Autor správně zdůrazňuje určitou konzervativnost poplachových systémů z hlediska inteligentních budov; na tuto vlastnost se dnes často zapomíná - a přitom bezpečnost a robustnost by měly být základními vlastnostmi IPS. Cílová skupina čtenářů by nejspíše uvítala několik konkrétních příkladů integrace jednotlivých systémů. Autor je neuváděl možná proto, aby text zůstal firemně nezávislý, nicméně ke srozumitelnosti textu pro provozovatele budov by významně prospěly. Příspěvek je velmi užitečným východiskem a rozcestníkem pro všechny, kteří jsou postaveni před úkol sestavit zadání pro výběr dodavatele IPS, nebo pro projektanty firem, zabývajících se systémovou integrací.

English Synopsis
Monitoring and control systems - integration platform for alarm systems (part 2)

Each technology equipping today's modern buildings, facilities or campuses, provides a variety of operational data - alarms, status variables and operating parameters, which can effectively help in managing their operations. Therefore it is absolutely logical step to focus them into one unified graphical environment.

 
 
Reklama