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

Ve velkých organizacích, s jakými se nejčastěji setkáváme v oblastech energetiky, dopravy, výroby apod., požadavky na zabezpečení s postupem času stále rostou. S tím pochopitelně narůstá potřeba investic do komplexního bezpečnostního řešení ‒ prakticky jediným efektivním způsobem, jak dosáhnout optimálního stavu, je vybudovat jednotné integrované prostředí. Takové prostředí ovšem bývá silně technologicky závislé a není tedy prakticky možné počítat s tím, že se vyhneme částečné (případě kompletní) rekonstrukci stávajícího řešení.

Základním požadavkem, respektive důvodem realizace nového systému je docílit komplexního integrovaného poplachového systému (dále jen IPS) pro všechny provozované technické systémy fyzické ochrany. Druhým logickým požadavkem je sjednocení a sdílení společné databáze uživatelů – a to jak pro poplachové, tak i pro vybrané nepoplachové systémy.

Tvorba společných databází s sebou obvykle přináší představu o propojení všeho se vším a požadavky na neomezené vzájemné ovlivňování jednotlivých systémů. Skutečnost, že zařazení poplachových systémů do IPS s sebou nese požadavek na aplikování pravidel pro kombinované a integrované poplachové systémy, bychom měli brát jako základní „nepsané“ pravidlo. Cílem následujících odstavců nejsou definice funkčních požadavků (kde, kdy, kým a zejména proč bude konkrétní technický systém použit) na jednotlivé systémy, ale stručný přehled základních podnětů, kterými bychom se měli řídit při výběru integrační platformy IPS.

Nejprve se ale na chvíli zastavme u jiného trendu, který má výrazný vliv na samotné vnímání poplachových systémů a hlavně na podobu „šablon“ základních požadavků na jejich integraci – jde o každému dobře známou oblast inteligentních budov.

Inteligentní budovy

Poplachové systémy patří mezi nejrychleji se vyvíjející druh technických prostředků sloužících k ochraně majetku a osob. Je tedy pochopitelné, že požadavky na využívání jejich specifických vlastností se staly jedním ze základních požadavků na provoz každé tzv. inteligentní budovy.

Provoz takovéto budovy (ale také provoz každého areálu, jehož bývá součástí) dnes zajišťuje řada systémů – řízení vytápění, chlazení a vzduchotechnika, řízení osvětlení, řízení energií včetně nouzových generátorů, řízení výtahů, požární signalizace, přístupový systém, zabezpečovací systém, kamerový dohlížecí systém a případně i další systémy.

Málokdo si však uvědomuje, že integrací poplachových systémů do systému řízení inteligentní budovy dochází k zásadnímu rozšíření funkčnosti tohoto komplexního systému o zcela nová pravidla ‒ bezpečnostní.

Inteligentní budova bez poplachových systémů, tj. jen s výše zmíněnými nepoplachovými provozními systémy, je z pohledu integrace založena na otevřenosti – jedná se technicky o velmi liberální prostředí. Naopak v případě poplachových systémů, jakožto bezpečnostního prvku, je již od jejich prapůvodu logicky zakořeněna jistá konzervativnost. I přes masivní rozšíření komunikačních přenosů pomocí IP do všech slaboproudých systémů včetně těch poplachových, a tudíž otevřeným dveřím k jakékoli integraci, by měly inteligentní budovy i tak respektovat tato „nová a cizí“ pravidla založená na bezpečnosti a konzervativnosti.

Způsoby integrace

U každého instalovaného poplachového systému je dnes obecně technicky velice jednoduchá jak dostupnost, tak i sdílení dat prakticky kdekoliv v „lokální i globální“ síti. Fakticky se tak předpokládá (investorem/uživatelem pochopitelně požadovaná) reálná integrace s jinými systémy ‒ ať už bezpečnostními, provozními nebo třeba personálními.

V praxi jde v podstatě o dvě základní problematiky integrace poplachových systémů. Jedná se o způsob (čím) a možnosti (do jaké hloubky) propojení. Jednotlivé technologie v rámci řízení budov (systémy a zařízení) mají sice své výrobce, pokud je ale řídicí jednotka každého autonomního systému vybavena standardizovaným komunikačním rozhraním, lze takřka se stoprocentní úspěšností počítat s faktem, že o sobě systémy budou vědět. A pokud jejich výrobce respektuje mezinárodní standardy, tak by spolu za splnění jistých předpokladů měly také komunikovat. Protože systémů s možností integrace je díky technickému vývoji dnes k dispozici nespočet, můžeme si dovolit tvrdit, že propojit lze vše se vším. Poznatky z reálné praxe k tomuto tvrzení ale pod čarou přikládají základní poznatky:

• pokud dvě libovolná zařízení používají stejné rozhraní a komunikační protokol, ještě to neznamená, že spolu budou komunikovat (kompatibilita ≠ interoperabilita),
• pokud pro zařízení s některým z těchto rozhraní existuje uznávaný technický standard pro vzájemnou komunikaci, zajišťuje to pouze konformitu produktů metodou testování a certifikace těchto zařízení,
• obvykle nelze předpokládat, že půjde automaticky o „Plug-and-Play“.

Aby byla naplněna alespoň základní očekávání, měly by pro všechny úrovně integrace platit minimální obecné podmínky. Primárně by měl být znám výrobce a typ integrovaného zařízení (pokud výrobce nebo typ integrovaného zařízení není znám, měla by být potvrzena klauzule o nutnosti spolupráce výrobce/distributora/dodavatele integrovaného zařízení) a sekundárně upřesněn konkrétní typ, počet a význam integrovaných datových bodů. Naopak by ale neměla platit podmínka, že musí být poskytnut komunikační protokol (tento požadavek je vzhledem k autorským právům, know-how a rivalitě některých výrobců naprosto nesmyslný – shoda na firemně neutrálním protokolu je však nezbytná).

Integrovaný poplachový systém

Požadavky vznášené na provoz v inteligentních budovách se v mnohém podobají standardním požadavkům na IPS. Díky znalostem skladby a požadavků na provoz jednotlivých funkčních celků (aplikací):

• I&HAS/HAS – řada norem ČSN EN 50131
  (Intrusion and hold-up systems/Hold-up systems),
• ACS/EACS – řada norem ČSN EN 50133 a ČSN EN 60839
  (Access control systems/Electronic access control systems),
• CCTV/VSS – řada norem ČSN EN 50132 a ČSN EN 62676
  (Closed circuit television/Video surveillance systems),
• SAS – řada norem ČSN EN 50134
  (Social alarm systems),
• ATS/ATSN – řada norem ČSN EN 50136
  (Alarm transmission systems/Alarm transmission service network),
• FPS/FDAS – řada norem ČSN EN 54
  (Fire protection system/Fire detection and fire alarm system),
• ARC/MARC – řada norem ČSN EN 50518
  (Alarm receiving centre/Monitoring alarm receiving centre),
• CCF – ČSN CLC/TS 50398
  
• (Central control facility)

jsme schopni takovéto systémy navrhnout, zrealizovat, validovat, provozovat i servisovat.

O integrovaném systému, který chceme provozovat, máme obvykle zcela jasné představy – tedy alespoň co se teorie týká. Z praktického hlediska ale takřka vždy tápeme. Toto tvrzení se zakládá na faktu, že definovat obecné věty o přínosu nového a moderního systému, jako jsou například:

• zvýšení bezpečnosti areálu díky jednotné, přehledné a flexibilní integrační platformě,
• možnost optimalizace manuálních a zautomatizovaných operací,
• vyšší efektivita práce ostrahy – uživatelsky orientované prostředí,
• možnost vzájemné verifikace poplachů,
• zjednodušení administrace a přehledu,
• možnost flexibilní delegace povinností,
• jednotná a komplexní dokumentace,

zvládne de facto každý absolvent základního školení s „certifikátem“ na libovolný integrační produkt. Pro vznášení požadavků na základní funkční požadavky integrační platformy to zvládneme i bez školení. Jsou totiž dány podněty, které takřka vždy vycházejí z veřejně dostupných katalogových listů:

• vícevrstvá architektura klient‒server (multiple client),
• otevřená systémová architektura,
• provoz na běžně dostupném vybavení,
• podpora průběžné replikace databází,
• podpora redundance,
• podpora libovolného počtu aktivních signalizačních prvků,
• provoz bez omezení z hlediska počtu současných výstražných událostí,
• variabilní grafické uživatelské rozhraní (přizpůsobení dle potřeb jednotlivých pracovišť a uživatelů),
• podpora interaktivních map,
• import grafických podkladů,
• podpora vícemonitorového zobrazení,
• podpora libovolného počtu uživatelských úrovní atd.

Pravděpodobně jediným požadavkem, který lze předem objektivně určit, je ve všech případech požadavek na rozsah. Vzhledem k dostupnosti stavební dokumentace a znalosti současného provozu bývá k dispozici relativně přesný požadavek na počet klientských uživatelů včetně prioritizace úrovně jejich přístupu.

Lze ale s takovýmto výčtem požadavků efektivně zrealizovat funkční IPS? V případě, že je pečlivě zpracována bezpečnostní analýza rizik nebo její audit, máme ten nejlepší předpoklad, že investice bude efektivní ve smyslu optimalizace reálných rizik. Nicméně druhým, neméně podstatným, předpokladem jsou systémově funkční požadavky ‒ a ty jsou, jak již bylo v úvodu uvedeno, silně technologicky závislé. Zde je potřeba mít štěstí na výběr integrátora, tj. projektanta a realizátora pod jednou střechou. Mělo by být zcela běžné, že investor bude integrátorem v průběhu návrhu (designu) IPS předem informován o úskalích, která mohou provázet použití nové technologie – tedy nejen o rizicích spojených s ochranou osobních údajů, jak je dnes populární, ale také s možností navýšení nákladů spojených s provozem, údržbou, dalším případným rozšířením systému apod.

V praxi to pak znamená, že v úvodu technické části projektu (etapa studie/systémového designu) budou vypracovány dokumenty sloužící jako podklad pro výběr jednotlivých technologií IPS, například formou „checklistu“. V rámci toho by mimo jiné měly být řešeny zásadní otázky, jako jsou stupeň zabezpečení jednotlivých poplachových systémů, úrovně přístupu, přenosový systém atd., případně konfigurace a ergonomie řídicího pracoviště (velínu). K sestavení takových dokumentů nám mohou posloužit nebo být alespoň dobrou inspirací oborové technické normy, které „konečně“ po delší stagnaci zaznamenaly pozitivní změny a rozšíření.

I přes široké spektrum technických norem v oboru poplachových systémů se najdou oblasti, které nejsou normativně řešeny, a trhu nezbývá než je řešit po svém, tedy proprietárně. Největší absenci standardizace najdeme u perimetrických detekčních systémů (PIDS), které si „bohužel“ doposud nezasloužily ani čárku (v rámci ČSN/EN). Již na pomyslném druhém místě najdeme právě oblast integrace. V současné době je k dispozici pouze základní definice všeobecných požadavků (typy konfigurací) ‒ „výrobková“ standardizace integračních platforem a přenosových systémů zcela chybí.

Software

Jak již v samotném úvodu zaznělo, cílem realizace nového IPS je docílit komplexní integrace se sdílenou databází, a to v rámci jednotného integrovaného prostředí.

Po přečtení předchozích odstavců bude pravděpodobně každému zcela jasné, že pouze s využitím ovládacích panelů (klávesnic) nelze tohoto stavu dosáhnout. Doba i provozovatelé si žádají „supersystém“ – ať už mu budeme říkat jakkoli, takřka vždy půjde o systém vybavený počítačovým pracovištěm se speciálním programovým vybavením.

Současná podoba integračních platforem již opustila historickou podobu „pouhé“ jednotné vizualizace/monitoringu. Vedle této základní vlastnosti se dnes již u téměř všech integračních platforem stále více využívá také možnost vzdáleného zákaznického/individuálního nastavování a programování jednotlivých parametrů připojených systémů.

Může se jednat jak o programování technické (změna technických parametrů a chování technologií), tak i o daleko častější programování provozní (změna provozních veličin a parametrů neovlivňujících zásadně chování připojených technologií).

Vliv integračních platforem, nejen na bezpečnost objektu, je velký a platí, že jejich nasazování v praxi nestojí na pouhé instalaci hotového systému z „krabice“. Takřka vždy se jedná více o implementaci než prostou instalaci. Z těchto důvodů poskytuje většina výrobců nástroje pro rozšiřování či modifikování funkcionalit svého systému třetími stranami. Tato cesta otevírá možnost doplnit funkcionalitu, jež není přímo řešena výrobcem, implementátorem řešení, a přizpůsobit tak systém požadavkům investora a provozovatele. Zde se mluví o dodávce tzv. SDK (Software Development Kit), nebo o poskytnutí popisu API (Application Programming Interface). Detaily k možnostem participace třetích stran na finální funkcionalitě produktu dávají jednotliví výrobci k dispozici po podepsání tzv. NDA smlouvy (Non-Disclosure Agreement) – tedy dohody, že znalosti předané výrobcem budou použity jen na dohodnuté účely. Nejde zde pouze o bezpečnost, ale i vlastní funkcionalitu a v neposlední řadě také zachování dobrého jména samotného produktu.

Na našem trhu se lze setkat s celou řadou tuzemských („česko-slovenských“) integračních platforem – vyjmenujme si alespoň ty nejznámější: A2D, Alvis, APACS, C4, ECC, Eliwin, Integra, LATIS SQL, MCT-S, MrGuard.

Existují však nástroje k rozlišení (ne)kvalitního produktu, (ne)kvalitního distributora či (ne)vhodnosti jednotlivého produktu pro konkrétní řešení? Po pravdě lze říci, že ne ‒ neexistují.

Jestli je IPS, který si za asistence svých odborných konzultantů zvolíte, pro vás z technického a provozního hlediska tím nejvhodnějším – stejně tak jestli je jeho dodavatel schopen operativní a trvalé podpory, se pozná až v průběhu vlastního provozu. Tedy nějaký čas po podepsání všech předávacích protokolů.

V odstavcích týkajících se inteligentních budov jsme se zmínili o minimálních podmínkách platných pro všechny typy integrací. Stačí to však u poplachových systémů – tedy u technologií, které nejsou určeny pro klasický (komerční) provoz, ale které slouží k ochraně majetku a osob? Je opět na místě přiznat, že ne ‒ nestačí. Je jen na zadavateli, jestli si najde inspiraci u jiných technických oborů s přesnými pravidly.

---

Klíčové pojmy článku

IPS – integrovaný poplachový systém (integrated alarm system). Systém mající jedno nebo více společných zařízení, alespoň jedním z nichž je poplachová aplikace.
Poznámka 1: Poplachový přenosový systém se nepovažuje za součást integrovaného poplachového systému.
Poznámka 2: Jednoúčelové systémy připojené pouze přes jednosměrný výstup zařízení bez jakéhokoli přenosu dat, např. relé, nejsou považovány za součást integrovaného poplachového systému (ČSN CLC/TS 50398; článek 3.23).

ČSN CLC/TS 50398; Poplachové systémy – Kombinované a integrované systémy – Všeobecné požadavky
Tato česká technická norma uvádí všeobecné požadavky a typy struktur kombinovaných a integrovaných poplachových systémů. Norma má zajistit integraci jedné nebo více aplikací do jednoho integrovaného systému. Tento dokument poskytuje další informace týkající se prvotního návrhu (projektu) systému, plánování, instalace, předávání, provozu a údržby (servisu) kombinovaného a integrovaného systému. Tato norma specifikuje požadavky na poplachové systémy, které jsou kombinovány nebo integrovány s jinými systémy, které mohou a nemusí být poplachovými systémy. Definuje požadavky týkající se pravidel integrace s cílem zdůraznit význam jednotlivých aplikačních poplachových norem a objasnit případné rozpory. (datum vydání 1. 10. 2009)

Poplachová aplikace (alarm application) – aplikace určená na ochranu života, majetku nebo prostředí, jako: poplachový zabezpečovací a tísňový systém, systém přivolání pomoci, poplachový systém výtahů, poplachový systém vlivů prostředí, uzavřené televizní okruhy používané pro účely zabezpečení a dohledu, systém kontroly vstupu, elektrická požární signalizace.
Poznámka 1: Tento seznam může být rozšiřován tak, aby navazoval na obsahovou náplň CLC/TC79 a CEN/TC72.
Poznámka 2: Příkladem poplachového systému vlivů prostředí může být systém varování před únikem toxické odpadní vody nebo přetečení zásobních nádrží. (ČSN CLC/TS 50398; článek 3.3).

Nepoplachové systémy (non-alarm application) – systémy určené k ovládání a jejichž primární funkcí není ochrana života, majetku nebo prostředí.
Poznámka: Například topení a větrání (ventilace); řízení energetických systémů; správa budovy; osvětlení (ČSN CLC/TS 50398; článek 3.26).

Aplikace (application) – zařízení využívané pro specifické účely. Poznámka: Jedná se například o detekci a výstrahu v případě požáru, ovládání osvětlení atd. (ČSN CLC/TS 50398; článek 3.10).

Aplikační norma (application standard) – norma stanovící požadavky pro instalaci a provoz aplikace (ČSN CLC/TS 50398; článek 3.11).

Integrita (integrity) – schopnost aplikace plnit funkce, pro něž je konstruována, včetně odolnosti vůči vlivům, které by mohly ovlivnit její správnou funkci (ČSN CLC/TS 50398; článek 3.24).

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