TECHNICKÁ INFORMACE
Obsahuje popis datové komunikace systémů EZS, EPS pomocí internet
protokolu s využitím SIA DC-09.
Navrhuje novou metodu autentizace nešifrované zprávy z objektového
zařízení.
Stanovuje požadavky na kvalitu komunikačních sítí pro přenos zpráv.
Navrhuje novou výstupní datovou strukturu z přijímače DPPC typu
DOM-XML (vhodná pro další zpracování na webových stránkách a v databázích). Umožňuje rychlé předávání zpráv zásahovým jednotkám všemi
typy datových sítí (do 1- 2sekund).
Popisuje ověření parametrů zařízení na analyzátoru TSY – ARG – 09.
© T Security září 2013
Informace pro uživatele
Tato TI byla vypracována pro usnadnění orientace v předmětné oblasti a pro uplatnění některých technických
řešení, která nejsou v citovaných dokumentech obsaženy.
Citované podklady
SIA DC-03-1990.01 Security Communications – Digital Communications Standard - “SIA Format” Protocol - for
Alarm System Communications
SIA DC-04-2000.05 Digital Communications Standard - SIA 2000 Protocol for Alarm System Communications
SIA DC-05-1999.09 Digital Communication Standard - Ademco ® Contact ID Protocol - for Alarm System
Communications
SIA DC-07-2001.04 SIA Digital Communications Standard – Receiver-to-Computer Interface Protocol (Type 2)
– for Central Station Equipment Communications
SIA DC-09-2007 SIA Digital Communication Standard – Internet Protocol Event Reporting
CLC/FprTS 50136-9 Alarm systems - Alarm transmission systems and equipment - Part 9: Requiiremets for
common protocol for alarm transmission using the Internet protocol
ČSN EN 50131-1 Poplachové systémy – Poplachové zabezpečovací a tísňové systémy - Všeobecné požadavky
ČSN EN 50131-6 Poplachové systémy – Poplachové zabezpečovací a tísňové systémy - Napájecí zdroje
2
TNI 33 4592
1
Předmět technické informace
Datová komunikace poplachových a nepoplachových systémů pomocí internet protokolu a požadavky na kvalitu
komunikačních sítí pro přenos zpráv.
2 Obecně
Hlavní cíle tohoto dokumentu:
Stanovuje požadavky na zabezpečený přenos zpráv ze střežených objektů na přijímací centra (PC).
Stanovuje požadavky na komunikační prostředí a to jak ve střeženém objektu, tak na přijímací straně.
Rozšiřuje přenášené informace z objektových vysílačů o parametry popisující kvalitu přípojných sítí, jejich dostupnost a průchodnost.
Nabízí parametry pro kontrolu kvality datových sítí použitých pro přenos zpráv.
Rozšiřuje možnost zpracovat pozdě doručené zprávy z důvodu poruchy komunikační cesty.
Přidává možnost změny komunikačních parametrů vysílače povelem z přijímače při potvrzení kontrolní
zprávy.
Rozšiřuje zdroje synchronizace času o NTP servery.
Popisuje pravidla pro tvorbu a použití šifrovacích klíčů.
Navrhuje cestu vedoucí k zajištění způsobu komunikace ATS 5 a ATS 6 (stupeň zabezpečení 3 a 4 dle
ČSN EN 50131-1).
Dokument obsahuje návod na zkušební postupy při testování funkcí vysílačů a přijímačů.
Tento dokument podrobně popisuje protokol a související podrobnosti při odesílání zpráv z vysílacího zařízení
k přijímacímu centru (PC) s využitím Internet protokolu (IP). Je třeba zdůraznit, že se počítá s využitím veřejného internetu pro přenos zpráv od vysílacího zařízení v objektu k přijímači PPC.
Tento dokument je určen pro výrobce ústředen poplachových i nepoplachových systémů, komunikačních jednotek a přijímačů PC pro zajištění kompatibility všech použitých prvků.
3 Citované dokumenty
Tato technická normalizační informace respektuje všechny důležité normy používané pro datovou komunikaci.
Zejména SIA DC-03, SIA DC-04, SIA DC-05, SIA DC-07, SIA DC-09, FIPS Publication 197 (AES), NIST Special
Publication 800-38A: Recommendation for Block Cipher Modes of Operation.
Dle zvyklostí CENELEC je dokument tvořen jako nadstavba již existujících technických norem a předpisů.
4 Využití
4.1 Poplachové aplikace
Tato technická normalizační informace může být využita v následujících oblastech se souvisejícími soubory
evropských norem, které se používají pro určité typy poplachových systémů:
-
Poplachové systémy – Poplachové zabezpečovací a tísňové systémy;
Poplachové systémy – CCTV sledovací systémy pro použití v bezpečnostních
aplikacích;
EN 50133
Poplachové systémy – Systémy kontroly vstupů pro použití v bezpečnostních
aplikacích;
EN 50134
Poplachové systémy – Systémy přivolání pomoci;
EN 50136
Poplachové systémy – Poplachové přenosové systémy a zařízení;
CLC/TS 50398
Poplachové systémy – Kombinované a integrované systémy - Všeobecné požadavky;
EN 54
Elektrická požární signalizace;
Přenos informací určujících zdroje verifikace událostí (video záznam, audio záznam, atd.).
EN 50131
EN 50132
4.2 Nepoplachové aplikace
Aplikace přenosů, které nejsou uvažovány především k ochraně života, majetku a prostředí, například:
-
informace o teplotě
stavu vody
provozu na dálnicích;
3
TNI 33 4592
-
správa energetiky;
správa budovy;
osvětlení.
4.3 Priority
Všeobecně by měly být použity následující priority:
-
Priorita 1 Poplachové signály týkající se např. požárního poplachu k ochraně života nebo napadení
osob.
Priorita 2 Poplachové signály týkajících se ochrany majetku nebo ochrany proti nedovolenému vniknutí do objektu.
Priorita 3 Poplachové signály o ostatních poplachových systémů.
Priorita 4 Poruchové signály ze systémů ochrany života a majetku.
Priorita 5 Poruchové signály z ostatních poplachových systémů.
Priorita 6 Informace z nepoplachových systémů.
5 Termíny, definice a zkratky
5.1 Termíny a definice
Pro účely této technické normalizační informace platí následující termíny a definice:
5.1.1
AES (advanced encryption standard)
metoda utajení elektronicky přenášených dat
5.1.2
ACK (acknowledgement)
potvrzení správného přijetí vyslané zprávy.
5.1.3
BTS (base transceiver station)
retranslační stanice v síti mobilního operátora
5.1.4
BW (band width)
šířka přenášeného pásma
POZNÁMKA Zajištění dostatečně širokého přenosového pásma je nejdůležitějším parametrem pro přenos zpráv veřejným
datovým prostředím. Na vysílací a přijímací straně se potřebná šíře pásma zajistí následovně:
IP v. 6 službou QoS nebo technickým zařízením
IP v. 4 technickým zařízením (Band width manager)
5.1.5
BWM (band width manager)
nástroj k zajištění dostatečné šíře pásma
5.1.6
CBC(cipher block chaining)
šifrování metodou řetězení bloků (CBC) je způsob utajení, jehož základem je spojování bloků textu zprávy s již
dříve zašifrovanými bloky.
5.1.7
CIR (Committed Information Rate) – je garantovaná minimální průchodnost sítě (commitment = [smluvní]
závazek). Rychlost se udává v bitech za sekundu nebo v bajtech za sekundu a je odsouhlasená sítí
FrameRelay (technologie přepínání paketů WAN) pro přenos informací za normálních podmínek.
5.1.3
CRC (cyclic redundancy check)
cyklický redundantní součet je speciální algoritmus, používaný k detekci chyb během přenosu či ukládání dat.
5.1.6
Číslo zařízení (device number)
jednoznačná identifikace technického zařízení a jeho výrobce.
5.1.7
DNS (domain naame system)
hierarchický systém doménových jmen, který je realizován servery DNS a protokolem stejného jména, kterým si
vyměňují informace.
4
TNI 33 4592
5.1.8
DPPC(dohledové poplachové přijímací centrum)
centrum s trvalou obsluhou, do nějž jsou podávány informace týkající se stavu jednoho nebo více poplachových
systémů
5.1.9
DSL(digital suscriber line)
technologie, která umožňuje využít stávající vedení telefonu nebo kabelové televize pro vysokorychlostní přenos dat
5.1.10
DUH (device unhandled)
značí, že přijímač není vybaven potřebnou funkci pro řádné zpracování přijaté zprávy.
5.1.11
IP adresa (internet protocol)
unikátní identifikační číslo určující směr komunikace
5.1.12
LAN (local area network)
počítačová síť, která pokrývá malé geografické území (např. domácnosti, malé firmy).
5.1.13
MAC adresa (media access control)
jednoznačně identifikuje technické zařízení vysílající nebo přijímající zprávy
5.1.14
NAK (negative acnowledgement )
odmítnutí zprávy z důvodu chyby ve formátu zprávy, nesprávného časového údaje, nebo chybného CRC
5.1.15
NTP (network time protocol)
protokol pro synchronizaci vnitřních hodin počítačů po paketové síti s proměnným zpožděním.
5.1.16
QoS (quality of service)
v informatice termín používaný pro rezervaci a řízení datových toků v telekomunikačních a počítačových sítích,
které používají přepojování paketů
5.1.17
RSP (response)
odpověď na přijatou zprávu obsahuje rozšiřující sekvenci dat nebo povel pro využití v objektovém zařízení
5.1.18
SL (signal level)
síla signálu přístupového bodu datové radiové sítě (GPRS, LTE atd.) naměřená na anténě vysílače objektového zařízení
5.1.19
TCP (transmission control protocol )
spojově orientovaný protokol pro přenos toku bajtů na transportní vrstvě se spolehlivým doručováním
5.1.20
TTI (test time interval)
časový interval pro odesílání kontrolní zprávy komunikační jednotkou. Slouží ke kontrole spojovací cesty mezi
IP vysílačem a IP přijímačem.
POZNÁMKA Časový interval testu odesílaného ústřednou EZS (případně jejích podsystémů) nebo ústřednou EPS, může
mít vyšší hodnotu než interval testu odesílaný komunikační částí těchto zařízení.
5.1.21
UDP (user data protocol)
protokol transportní vrstvy orientovaný na zprávy, jednodušší protokol založený na odesílání nezávislých zpráv
5.1.22
WAN (wide area network)
počítačová síť, která pokrývá rozlehlé geografické území (například síť, která překračuje hranice města, regionu
nebo státu). Největším a nejznámějším příkladem sítě WAN je síť Internet.
5.1.23
BTS (Base transceiver station ) základnová stanice celulární sítě
5
TNI 33 4592
5.2 Definice mající mimořádnou důležitost
5.2.1 Garantovaná šíře pásma pro přenos dat
Tato vlastnost označuje nejmenší možnou šíři pásma (CIR), kterou poskytovatel pro komunikaci uživatele v celé
své síti vyhradí a ponechá volnou za všech okolností, i když ji uživatel nebude využívat.
V případě garantovaného přenosového pásma může aplikace zahájit komunikaci okamžitě a její interaktivita
závisí pouze na způsobu využití linky uživatelem.
Tato vlastnost se někdy nesprávně zaměňuje s minimální dosažitelnou rychlostí linky dosahované sdílením
přenosového pásma mezi více linkami. Rozdíl spočívá zejména v interaktivitě linky (rychlost reakce aplikací).
5.2.2 Garantovaná agregace
Agregace je poměr, jakým je zahušťován datový tok v uzlu, kde se linky jednotlivých uživatelů sdružují do společného, přenosového kanálu. Jedná se tedy o sdílení společného přenosového pásma zpravidla s omezením
maximální přenosové rychlosti na podíl šířky společného přenosového kanálu. Tato technika se používá zejména pro levné linky, protože poskytovatel nemůže zaručit garantované přenosové pásmo ani minimální dosahovanou rychlost. Jistým pozitivním momentem je okolnost, že maximální dosažitelná rychlost agregovaných linek
je vždy nižší než rychlost společného přenosového kanálu, což alespoň snižuje riziko vyčerpání celkového přenosového pásma uživateli s velkými nároky na objem přenášených dat.
6
Zařízení určená do střežených prostor
Označuje všeobecně skupinu elektronických zařízení použitých v terénu a majících schopnost odeslat informace o vzniklých událostech poplachovému přijímacímu centru.
POZNÁMKA Poplachové systémy jsou typickými příklady pro tuto skupinu zařízení.
Tato zařízení včetně prostředků na komunikační cestě jsou vybavena záložním napájecím zdrojem o potřebné
kapacitě dle ČSN EN 50131-6.
POZNÁMKA To zn. modemy, směrovače, BWM, FW, WIFI, AP mají záložní zdroj s kapacitou o stejném počtu hodin jako
zařízení pZS nebo EPS (dle EN 50131 tab. 23).
6.1 Protokoly UDP (User Datagram Protocol ) a TCP (Transmission Control Protocol )
Objektová zařízení a přijímače dohledového centra mohou používat pro přenos zpráv o událostech v objektu
UDP nebo TCP protokol, případně mohou využívat oba protokoly. Pokud přijímač umožňuje zpracovat oba protokoly, může přijímač automaticky přepínat zpracování příchozí zprávy na správný protokol, aniž by bylo potřeba provádět změnu nastavení přijímače. V případě, že objektové zařízení umožňuje komunikovat oběma protokoly, pak vhodný protokol můžeme vybrat manuálně, nebo technik může nastavit doručování zprávy jedním
protokolem s možností přepnout na jiný, pokud je to nutné.
POZNÁMKA Pokud objektové zařízení používá pouze jeden protokol, pak je vhodnější UDP protokol.
6.2 Klasifikace objektových zařízení – třídy A,B,C
POZNÁMKA (AAAAAA - nejlepší hodnocení) (CCCCCC - nejhorší hodnocení)
6.2.1 Způsob připojení objektového zařízení k internetu
A: Dvě nezávislé komunikační cesty s garantovanou šířkou pásma v přístupové síti. Tím rozumíme:
1) Dvě připojení k internetu v oddělených kabelech přivedených k různým poskytovatelům internetu (např.
xDSL nebo optický kabel).
2) Jedno připojení k internetu je realizováno pomocí kabelového vedení, druhé připojení je bezdrátové připojení. Obě připojení mají garantovanou šířku pásma.
B: Jedno připojení k internetu je kabelové s garantovanou šíří pásma, druhé připojení je bezdrátové, tj. bez
garance šíře pásma a bez garance dostupnosti datového „slotu“ v místě přípojného bodu, ale s možností připojování se na více než jeden přípojný bod.
C: Jedno připojení pomocí bezdrátové sítě s možností připojování se na více než jeden přípojný bod.
POZNÁMKA Připojení pomocí bezdrátové sítě s využitím jednoho přípojného bodu lze použít pouze pro nástrahová zařízení.
6.2.2 Utajení dat - šifrování metodou CBC
A : AES 192, nebo AES 256 lze použít v kategorii přísně tajné
B: AES 128 lze použít v kategorii obyčejné
6
TNI 33 4592
C: otevřená zpráva
6.2.3 Autentizace zdroje zpráv
A: ve zprávě je použita MAC adresa
B: ve zprávě je použito číslo fyzického výrobku - number
C: identifikace zdroje – pouze IP nebo číslo SIM
6.2.4 Čas vzniku zprávy
A: zpráva obsahuje časovou značku, určující vznik události v ústředně a zařazení události do fronty zpráv
určených k odeslání.
C: zpráva neobsahuje časovou značku.
6.2.5 Nastavení času komunikační jednotky
A: Komunikační část objektového zařízení nebo celá ústředna jsou schopny synchronizovat svůj čas přesným
zdrojem času typu NTP server. Nastavení času postačuje 1x v týdnu a při přechodu z letního na zimní čas.
B: Komunikační část objektového zařízení je schopna synchronizovat svůj čas s IP přijímačem DPPC (po přijetí NAK odpovědi na kontrolní zprávu ).
C: čas objektového zařízení lze nastavit pouze manuálně.
6.2.6. Protokoly transportní vrstvy použité k odesílání zpráv
A: UDP nebo TCP (TCP se rozumí s vyřešeným způsobem zajištění volného místa v tabulkách směrovačů při
existenci poškozených a řádně neukončených spojení)
B: TCP bez schopnosti zajistit volné místo pro přenos zpráv v tabulkách posledního směrovače před DPPC
C: SMS zpráva je použita jako nouzové řešení. SMS zpráva se odesílá bez CRC
POZNÁMKA některé hodnoty CRC nelze doručit pomocí SMS, jsou v kolizi se služebními znaky
Začátek a konec SMS zprávy je ohraničen závorkami ( ).
7
Požadavky na přenos zpráv
7.1 Komunikační prostředí
Tato norma je určena pro libovolné síťové prostředí využívající Internet protokol (IP), zahrnující mimo jiné
Ethernet, 802.11x, CDMA 1x, LTE, GPRS. Základním předpokladem při průchodu zpráv mezi různými typy sítí
je zajistit neporušenost zpráv.
Použitá zařízení by měla být schopna pracovat jak v místní síti (LAN), tak v rozsáhlé síti (WAN).
7.2 Kontrola kvality přípojné sítě
7.2.1 Kontrola kvality připojení objektových vysílačů k internetu
Třída 1: po odeslání 100 kontrolních zpráv v pětisekundových intervalech, by mělo být 95 došlých potvrzení
zprávy přijato do 1 sek. od odeslání zprávy. 2 potvrzení mohou chybět
Třída 2: 90 přijatých potvrzení do 1 sek., 6 potvrzení může chybět
Třída 3: 80 přijatých potvrzení do 1 sek., 10 potvrzení může chybět
7.3 Kontrola kvality připojení IP přijímačů dohledových center k internetu
Třída 1: po odeslání 5000 kontrolních zpráv by mělo být 4995 došlých potvrzení přijato do 1 sek., 5 potvrzení
může chybět
Třída 2: 4950 došlých potvrzení přijato do 1 sek., 20 potvrzení může chybět
Třída 3: 4800 došlých potvrzení přijato do 1sek., 140 potvrzení může chybět
7.4 Tabulka potřebné šíře pásma pro IP / UDP protokol
Interval kontrolní zprávy 10 min při neagregované obousměrné šířce pásma a respektování náhodné kumulace
zpráv v době zvýšeného provozu.
7
TNI 33 4592
Šířka pásma [kb/s]
počet klientů DPPC
64
400
128
1200
512
5000
1024
10000
Při využití TCP protokolu se volí šíře pásma dvakrát větší.
7.5 IP Adresy
Přijímač dohledového centra je umístěn na statické adrese. Objektové zařízení může využívat dynamickou nebo statickou IP adresu, může mít možnost odesílat určité události na předem určené adresy.
Objektové zařízení může mít možnost použít DNS (adresa doménového serveru). U instalací odpovídajících
požadavkům této technické normalizační informace není dovoleno používat DNS.
7.6 Komunikační sekvence
Při použití UDP:
K odeslání zprávy je použit jednoduchý způsob komunikace - vyslaná zpráva / potvrzení zprávy.
Při použití TCP:
Objektové zařízení naváže spojení s přijímačem, vyšle zprávu obsahující událost z objektu nebo kontrolní komunikační zprávu, přijímač ji potvrdí a objektové zařízení spojení ukončí.
7.7
Doporučené časové intervaly kontrolních zpráv dle ČSN EN 50131-1 ed. 2
xDSL - hlavní komunikační cesta -
T4 M4 D4
Sítě 3G, GPRS - záložní komunikační cesta -
T3 M4 D4
GSM - záložní hlasová komunikační cesta -
T2 M4 D4
SMS - nouzová komunikační cesta -
T2 M4 D4
7.8 Šifrování
Objektové zařízení oznamuje použití AES šifrování při odesílání zprávy. Použití šifrování je dobrovolné. Zpracování šifrovaných zpráv by mělo být pro přijímače dohledového centra povinné.
7.8.1 Norma pro šifrování
Požadavky pro použití AES šifrování jsou dány normou „Federal Information Processing Standards Publication
197“ dostupnou na „National Institute of Standards and Technology“.
Šifrování zpráv používá metodu šifrování zpráv po blocích, jak je popsáno v „NIST Special Publication 800-38A
(2001 Edition)“. Dle ČSN EN 50131-1 metoda AES šifrování splňuje požadavky I3 a S2
7.8.2 Značení šifrovaných zpráv
Šifrované zprávy jsou označeny hvězdičkou, jak je popsáno v kapitole 8.1.4.1 této normy.
7.8.3 Šifrované části zprávy
V případě použití šifrování zpráv jsou šifrovány pouze data, časová značka a doplňující znaky. Šifrování začíná
prvním znakem po ‚[‘ v datové části zprávy a končí před posledním znakem zprávy <CR>
Šifrovaná část zprávy je označena barevně:
<LF><crc16><0LLL>
<"*id protokolu"><seq><Rrcvr><Lpref><#idk>[<pad>|...data...][x…data…]<časová značka>
<CR>
7.8.4 Doplněk zprávy pro šifrování po blocích (Padding)
Pokud použijeme šifrování při přenosu zpráv, pak je zpráva doplněna pseudonáhodně vygenerovanými daty
(pad) tak, aby počet znaků šifrované oblasti byl násobek 16.
8
TNI 33 4592
7.8.5 Prostor pro vložení pseudonáhodných dat
Do oblasti pro šifrování se započítávájí znaky po ‚[‘ v datové části, tj. pole pseudonáhodných znaků, vlastní data
a časovou značku (timestamp). Koncový znak zprávy <CR> nepatří do této skupiny a není šifrován.
7.8.6 Pseudonáhodná data
Pseudonáhodná data v jednotlivých zprávách by se měla lišit. Data mohou být v rozsahu binárních hodnot 0255, kromě ASCII znaků ‚|‘ (124, 0x7C), ‘[‘ (91,0x5B), ‘]’ (93, 0x5D).
7.8.7 Pole pseudonáhodných znaků (pad)
Pokud je zpráva určena k šifrování, pole pseudonáhodných dat je vloženo za ‚[‘ a zakončeno koncovým znakem
‚|’. Počet znaků tohoto pole se stanoví tak, aby celkový počet znaků určených k šifrování (od prvního znaku
tohoto pole až po poslední znak časové značky) byl násobek šestnácti.
Pokud má zpráva právě šestnáct znaků, je do zprávy vloženo šestnáct pseudonáhodných znaků.
Znak ,|’ ukončující pole pseudonáhodných znaků je součástí všech šifrovaných zpráv. Tento koncový znak se
nesmí objevit ve zprávě po jejím dešifrování, přestože znak ‚|’ většinou odděluje identifikační číslo od zbytku
zprávy.
7.8.8 Šifrovací klíč
Objektová zařízení obvykle používají šifrovací klíče o délce 128,192 nebo 256 bitů. Použitý klíč je stejný jak u
objektového zařízení, tak u přijímače (nejen obsah, ale i délka klíče).
7.8.9 Požadavky na přijímač dohledového centra
Přijímač pracuje se všemi třemi typy šifrovacích klíčů, rovněž zpracovává i zprávy nešifrované. Klíče jiné délky
mohou být přidány do této normy v budoucnu.
Každý port přijímacího centra přijímá a následně zpracovává šifrované zprávy s použitím nejméně jednoho šifrovacího klíče určeného pro objektová zařízení komunikující na určenou IP Adresu / port.
Je také možné využít více klíčů s individuálním využitím pro jednotlivé objekty nebo skupiny objektů.
7.8.10 Požadavky na objektová zařízení
Má-li se u objektového zařízení využívat šifrování, mělo zařízení by být schopné uchovávat soukromé klíče
délky 128, 192, 256 bitů dle volby výrobce.
7.8.11 Obsah šifrovacího klíče
Pro vytváření soukromých nebo skupinových klíčů je nejlépe použít pseudonáhodný proces. Klíč je pak soubor
nul a jedniček. Použití nějaké slovní fráze (binárně vyjádřené ASCII) je nezodpovědné.
7.8.12 Šifrování zpráv řetězením bloků (CBC)
Šifrované části zprávy používají šifrování po blocích, jak popisuje kapitola 6.2 NIST Special Publication 800-38A
(vydané v roce 2001). Pro tento typ protokolu inicializační vektor (IV) jsou samé nuly, stejně tak vkládané znaky
jsou rozdílné pro utajení zpráv.
7.8.13 Kódování
V šifrované části zprávy je každý byte zakódován pro vysílání do dvou ASCII znaků (0-9,
hexadecimální hodnotu šifrovaného bytu.
8
A-F) vyjadřujících
Zprávy
Objektové zařízení vysílá dva druhy zpráv: události a kontrolní zprávy (supervize).
Přijímače vysílají pouze jeden typ zprávy a to potvrzovací zprávu, která může být: ACK, NAK, RSP nebo DUH.
8.1 Zprávy obsahující událost v objektu
Formát zprávy obsahující událost je odvozen od SIA protokolu (DC-07-2001.04) popsaném v SIA Digital Communications Standards – Receiver-to-Computer Interface Protocol (Type 2).
Formát odesílané zprávy:
<LF><crc16><0LLL>
<"id protokolu"><seq><Rrcvr><Lpref><#idk>[<pad>|...data...][x…data…]<časová značka>
<CR>
9
TNI 33 4592
8.1.1 Nový řádek (LF)
ASCII znak pro nový řádek.
8.1.2 Kontrolní součet (CRC16)
CRC16 se počítá z části zprávy začínající prvními uvozovkami ID protokolu a končící před posledním znakem
CR.
To je prostřední řádka v obrázku uvedeném výše. Podrobný popis je uveden v dokumentu DC-07-2001.14. Pokud je zpráva šifrována, CRC se vypočte až po provedení šifrování.
Pro výpočet CRC16 (polynom 0x8005) se doporučuje metoda č.2, t.j. využití tabulky dle DC-07-revize 2013.
Hexadecimální hodnota CRC se vyjadřuje čtyřmi ASCII znaky.
8.1.3 Délka zprávy (0LLL)
Tento údaj o délce je tvořen znakem „0“ (ASCII nula) po němž následují 3 hexadecimální číslice (v ASCII) udávající délku zprávy. Počítají se stejné znaky jako při výpočtu CRC, jak je popsáno v 8.1.2.
8.1.4 Označení použitého formátu zprávy ("id protokolu" - ID Token)
Pole ”id protokolu” obsahuje označení formátu použitého v datové části zprávy a sdělení o použití šifrování.
Uvozovací znaky jsou součástí zprávy.
8.1.5 Označení šifrované zprávy
Pokud je pro data a časovou značku použito šifrování, „id protokol“ je upraveno tak, že je do něho za
uvozovací znak a před první písmeno názvu vložen ASCII znak ‘*’.
POZNÁMKA Např. nešifrovaný SIA DCS paket použije označení "SIA-DCS" a šifrovaný paket použije "*SIA-DCS".
8.1.6 Číslo zprávy
Objektové zařízení označí každou zprávu zařazenou do fronty k odeslání číslem zprávy. Přijímač číslo zprávy
vloží do potvrzení zprávy.
Objektové zařízení nenavyšuje číslo zprávy při opakovaném vysílání zprávy z důvodu poruchy komunikace
nebo nepřijetí potvrzení zprávy od přijímače.
Bez ohledu na to, zda je zpráva potvrzena, odmítnuta nebo nepoužita, navyšuje objektové zařízení číslo sekvence v další zprávě.
Pokud číslo zprávy dosáhne 9999, pak následující číslo zprávy je 0001. Další informace jsou v sekci 7.1.5 DC07-2001.04.
Čísla segmentů dle dokumentu DC-07 se v tomto protokolu nepoužívají.
8.1.7 Identifikační označení objektového zařízení (Rrcvr, Lpref, #idk)
Každé objektové zařízení může obsahovat až tři vzájemně se doplňující identifikační názvy.
8.1.7.1 Číslo objektového zařízení (#idk ,#id - identifikační číslo objektu)
Identifikační číslo je nejdůležitější označení, je vždy programováno do objektového zařízení a slouží k jeho identifikaci. Identifikační číslo se ve zprávě vyskytuje dvakrát, jednou v záhlaví zprávy (idk - zde se nikdy nešifruje),
podruhé v datové části zprávy (id - zde by mělo být šifrováno).
#idk – identifikuje komunikační jednotku, #id – identifikuje ústřednu nebo její části
Identifikační číslo je složeno z ASCII znaku "#", následovaného 3-16 ASCII znaky z oboru hexadecimálních
čísel. Toto není v souladu s protokolem DC-07.
V některých speciálních aplikacích informace obsažená v #idk sekci nemusí obsahovat identifikační číslo, které
se nachází v datové části zprávy. Např. výrobce může jako identifikační číslo použít MAC adresu.
8.1.7.2 Předčíslí identifikačního čísla (číslo linky - Lpref )
Toto předčíslí se programuje v objektovém zařízení jako rozšíření identifikačního čísla.
Tato sekce se skládá z ASCII znaku ‚L‘, následovaného 1-6 HEX ASCII číslicemi, jako předčíslí identifikačního
čísla. Pokud objektové zařízení využije tohoto předčíslí, bude v této sekci nastavena hodnota „L0“.
Tato sekce odpovídá číslu linky přijímače, jak je uvedeno v protokolu DC – 07.
8.1.7.3 Číslo přijímače (Rrcvr)
V některých případech je pro další rozšíření identifikace možné kromě identifikačního čísla a předčíslí použít
číslo přijímače. Tímto číslem přijímače se mohou oddělit přijímače pro různé typy událostí. Např. událost
„POŽÁR“ může být směrována na určený přijímač.
10
TNI 33 4592
Použití je dobrovolné, číslo přijímače se skládá ze znaku ASCII "R", následovaného 1-6ti HEX ASCII znaky.
Pokud objektové zařízení nepotřebuje vysílat číslo přijímače, nemusí v této sekci být vysíláno nic (ani „R“ nebo
„R0“).
Tato sekce je ve shodě s číslem přijímače protokolu DC-07.
8.1.7.4 Způsob zpracování dat přijímačem
LD data ve zprávě budou zpracována v dekadické soustavě
(zona 111 = zona 111)
LE data ve zprávě budou zpracována v oktalové soustavě
(zona 111 = zona
73)
LF data ve zprávě budou zpracována v hexadecimální soustavě (zona 111 = zona 273)
8.1.8 Datová sekce zprávy nebo datová sekce s vloženými pseudonáhodnými znaky
- [Data] nebo [<pad>|Data]
Všechna data vysílaná ve zprávě včetně "[" a "]" jsou ASCII znaky. Formát zprávy závisí na použitých ID názvech.
Pokud je identifikační číslo součástí zprávy (v naprosté většině zpráv), nachází se identifikační číslo na začátku
datového pole, před ním je znak "#", zakončeno je oddělovačem "|". Identifikační číslo je složeno z 3-16 ASCII
znaků z oboru hexadecimálních čísel. Viz příloha A v DC-07-2001.04 popisující datové pakety různých druhů
Poznámka: v sekci 8.1.9 je popsána datová sekce a časová značka při použití šifrování zprávy.
Část datové sekce <pad> použitá při šifrování je objasněna v 7.9 .
8.1.9 Rozšiřující datové pole [x…data…]
Tato část umožňuje objektovému zařízení přidat ke zprávě další informace, včetně jednoho nebo více těchto
datových polí.
Využití tohoto pole je pro objektová zařízení dobrovolné.
Přijímač je schopen přijmout a řádně zpracovat zprávu obsahující rozšiřující datová pole
Toto pole začíná znakem ASCII „[", následovaným jedním ASCII znakem (datovým identifikátorem), který označuje obsah datového pole. Datový identifikátor je velké písmeno ASCII znak v rozsahu „G" až „Z". Pole je ukončeno znakem „]". Vyjímku tvoří autentizace zprávy.
Autentizace zprávy
(hash)
A
Datový otisk zprávy (hash) ověřuje
12 ASCII znaků
správnost zprávy
(0-9, A-F nebo a-f)
Čas vzniku zprávy
H
Čas vzniku zprávy může být rozdílný od časové značky
ASCII
H13:59:58,08-21-2013
MAC adresa
M
MAC adresa objektového vysílače
ASCII znaky
M001AE9E4278B
A6F2348C99335DF38
(0-9, A-F nebo a-f)
Verifikace události
V
Informace o audio nebo video záznamu souvisejícím s událostí
obsaženou ve zprávě
Windows 1250,
UTF8, UTF8-URL
Vhttp:\\videoserver.cz/
34AC4DE3446
Alarm text
I
Text upřesňující alarmovou událost
Windows 1250
I detektor PIR na konci
chodby
UTF8, UTF8-URL
Adresa objektu
Název objektu
S
O
Označení polohy střeženého objektu (zde se rozumí adresa)
Windows 1250
Označení nebo jméno objektu
Windows 1250
UTF8, UTF8-URL
S 11002 Praha, Haštalská 1
O budova ÚNMZ
UTF8, UTF8-URL
Sekce objektu
Místnost - kancelář
L
R
Upřesňuje část objektu, kde došlo
k události obsažené ve zprávě
Windows 1250
Určuje konkrétní místo události
Windows 1250
UTF8, UTF8-URL
UTF8, UTF8-URL
11
L třetí podlaží
R k77 - kancelář pana
ředitele
TNI 33 4592
Programování
P
Bude použito k interaktivní spolupráci s přijímačem
ASCII
*)
Upřesnění události
X
Upřesňuje polohu, rozsah, souřadnice atd.
ASCII
*)
Upřesnění události
Y
ASCII
*)
Upřesnění události
Z
ASCII
*)
Informace o kvalitě
komunikačního
spojení
Q
ASCII
QS15/453A,C533
Určuje sílu signálu celulární sítě
v místě objektového vysílače a
čísla BTS, na kterých je vysílač
registrován
síla signálu 15,
registrováno na
BTS 453A,C533
Spouštěč alarmové
události
Tx
Určuje typ detektoru, který oznámil
vznik alarmové události
TF požární detektor
TG detektor plynu
TW detektor vody
TS senzor teploty,
tlaku, vlhkosti
TC kontakt
TM manuální spuštění
Poznámka: *) tento parametr se řídí národními předpisy, zvyklostmi, parametry výrobce nebo rozhodnutími
oprávněného servisního technika.
Uvozovací znaky rozšiřující datové sekce (A,H, M,V…) jsou vyjádřeny hodnotami Windows 1250.
8.1.9.1 Datová sekce obsahující MAC adresu („M")
Pokud je datovým identifikátorem písmeno "M", pak data obsahují MAC adresu objektového zařízení.
Dvanáct ASCII znaků (0-9, A-F) určuje MAC adresu v hexadecimální notaci.
8.1.9.2 Potvrzovací data („V")
Pokud je datový identifikátor „V", pak data obsahují audio nebo video informaci vztahující se k odesílané zprávě
o události v objektu. Data nesmí obsahovat znaky „[", “]" nebo "|". Toto datové pole bude přesně definováno
v budoucích verzích této normy.
Obvyklé využití je pro předání IP adresy video serveru v objektu.
[Vhttp:\\videoserver.com], [Vhttp:\\80.0.0.1:84]
8.1.9.3 Vzdálené programování parametrů objektového zařízení
Data obsahují zprávu použitelnou pro programování nebo jiné interaktivní operace objektového zařízení
s přijímačem. Data nesmí obsahovat znaky „[", "]" nebo "|".
Tyto povely mohou být součástí potvrzení kontrolní zprávy „RSP“ nebo samostatné zprávy typu „SET“.
Formát zprávy:
„RSP“[ #idk|“značka výrobce zařízení“ZZCCnnnn]
nebo starší způsob
„RSP“[ #idk|NZZCCnnnn]
„SET“[ #idk|“značka výrobce zařízení“ZZCCnnnn]
nebo starší způsob
„SET“[ #idk|NZZCCnnnn]
N…..značí novou zprávu
ZZ….je povel vysílaný přijímačem objektovému zařízení
CC…povel ke konkrétní akci
nnnn…..je zóna, kód, parametr zařízení
značka výrobce zařízení může být 3-7 ASCII znaků
12
TNI 33 4592
Příklad: …… #1234[#1234|”JA102”ZZRC07] … povel k sepnutí releového kontaktu č. 7
8.1.10 Časová značka (razítko - timestamp)
Časová značka by měla být vložena do šifrované zprávy, a může být vložena i do nešifrované zprávy. Tato část
zprávy je určena k ochraně proti falešným zprávám generovaným z jiných zdrojů (message playback). Časová
značka říká, kdy byla informace o události v objektu zařazena do fronty k odeslání zpráv dohledovému centru,
může indikovat čas významně rozdílný od skutečného výskytu události. Časová značka může být odvozena od
GMT (světový čas na nultém poledníku) nebo lokálního času.
Format značky je: <_HH:MM:SS,MM-DD-YYYY>. „Špičaté závorky“ nejsou součástí vysílané zprávy, ale podtržítko, dvojtečka, pomlčka, čárka do zprávy patří. Jednotlivá čísla jsou doplněna nulou, rok je vyjádřen čtyřmi
číslicemi, takže časová značka má vždy pevnou délku 20 znaků.
Přijímač DPPC porovná přijatou časovou značku se svým časem odvozeným od GMT. Šifrované zprávy přicházející s rozdílným časem od GMT o více než +20/-40 sek. jsou odmítnuty NAK paketem obsahujícím
správný čas přijímače DPPC. Dovolená časová odchylka může být v přijímači nastavitelná.
Objektové zařízení zprávu znova šifruje a odesílá s opravenou časovou značkou dle obsahu NAK paketu.
POZNÁMKA objektové zařízení může opravit svůj čas dle časového údaje v NAK paketu.
8.1.11 Zpracování opožděné zprávy (při poruše komunikační cesty)
Přijme-li se opakovaně zpráva o vzniklé události v objektu, má-li zpráva správný kontrolní součet, správnou
strukturu a časovou značku mimo povolenou toleranci, potvrdí se při opakovaném přijetí taková zpráva „ACK“.
Zpráva je označena jako zpožděná a postoupena k dalšímu zpracování. V tomto případě je vhodné nastavit
sudý počet opakování zpráv vysílaných objektovým zařízením.
8.1.12 Návrat vozíku (CR)
ASCII znak pro „návrat vozíku“ – posunout kurzor na začátek řádku.
8.2 Zpráva kontrolující spojení
Obvykle jsou objektové zařízení a přijímač nastaveny tak, aby prováděly kontrolu spojení. Pokud je toto podporováno a umožněno, objektové zařízení periodicky posílá kontrolní zprávu (NULL message) přijímači dohledového centra. Přijímač odpoví potvrzovací zprávou typu ACK.
Pokud přijímač dohledového centra podporuje tuto funkci, interval kontrolní zprávy může být nastavitelný
v rozsahu od 120 sek. do 1200 sek. Pokud v tomto intervalu není přijata žádná zpráva, je dohledovému centru
(DPPC) nahlášena ztráta spojení.
Objektové zařízení může zastavit odesílání kontrolních zpráv, pokud má takovou funkci. Po obdržení povelu
k obnovení vysílání bude opět odesílat kontrolní zprávy v pravidelných intervalech. Je rovněž přípustné nulovat
časovač příjmu kontrolních zpráv, pokud objektové zařízení vyšle jakoukoliv jinou zprávu. Čas příjmu kontrolních zpráv může být proměnný v souladu s přijímačem.
8.2.1 Kontrolní zpráva (NULL)
Objektové zařízení posílá buď šifrované, nebo otevřené zprávy umožňující kontrolovat spojení mezi objektem a
dohledovým centrem (DPPC). Přijímač tohoto centra potvrzuje tuto zprávu.
8.2.1.1 Nešifrovaná kontrolní zpráva
<LF><CRCA><0LLL>
<"NULL"><0000><Rrcvr><Lpref><#idk>[]<časová značka>
<CR>
Časová značka je dobře použitelná u otevřených zpráv.
8.2.1.2 Nešifrovaná kontrolní zpráva obsahující informaci o síle pole GPRS signálu a označení
dostupných BTS
<LF><CRCA><0LLL>
<"NULL"><0000><Rrcvr><Lpref><#idk>[QS15/453A,C533 ]<časová značka>
<CR>
13
TNI 33 4592
V uvedeném příkladu je objektové zařízení zaregistrováno na dvě BTS s číselným označením 453A a C533
(hexa). Síla signálu v místě objektového zařízení je15 od BTS uvedené jako první.
8.2.1.3 Nešifrovaná kontrolní zpráva obsahující informaci o časovém intervalu mezi kontrolními
zprávami
<LF><CRCA><0LLL>
<"NULL"><0000><Rrcvr><Lpref><#idk>[TI03 ]<časová značka>
<CR>
8.2.1.4 Nešifrovaná kontrolní zpráva obsahující informaci o místním času v místě objektového zařízení
<LF><CRCA><0LLL>
<"NULL"><0000><Rrcvr><Lpref><#idk>[H03:04:05, 08-21-2013 ]<časová značka>
<CR>
8.2.1.5 Šifrovaná kontrolní zpráva
<LF><CRCA><0LLL>
<"*NULL"><0000><Rrcvr><Lpref><#idk>[<pad>]<časová značka>
<CR>
Pokud “ID token“ je "*NULL" u šifrované kontrolní zprávy, pak je nutné vložit časovou značku a použít doplnění
náhodnými znaky.
8.3 Potvrzení zprávy
Pokud přijímač dohledového centra přijme zprávu o události v objektu, pak na ni odpoví potvrzovací zprávou.
8.3.1 Pozitivní potvrzení přijetí zprávy (ACK)
Na bezchybně přijatou zprávu přijímač odpoví odesláním paketu s pozitivním potvrzením:
<LF><CRCA><0LLL>
<"ACK"><seq><Rrcvr><Lpref><#idk>[]
<CR>
Po přijetí šifrované zprávy odpovídá přijímač také šifrovaným ACK:
<LF><CRCA><0LLL>
<"*ACK"><seq><Rrcvr><Lpref><#idk>[<pad> ]< časová značka >
<CR>
POZNÁMKA časová značka, pole pad a upravené ID "*ACK" jsou součástí ACK zprávy.
8.3.1.1 Pozitivní potvrzení přijetí zprávy (RSP) s požadavkem na změnu komunikačního parametru
objektového zařízení
<LF><CRCA><0LLL>
<"RSP"><seq><Rrcvr><Lpref><#idk>[#idk|“značka výrobce“NZZCCnnnn]< časová značka >
<CR>
N…..značí novou zprávu
ZZ….je povel vysílaný přijímačem objektovému zařízení
CC…povel ke konkrétní akci
nnnn…..je zóna, kód, parametr zařízení
14
TNI 33 4592
8.3.1.2 Pozitivní potvrzení přijetí šifrované zprávy (ACK) s požadavkem na změnu komunikačního parametru objektového zařízení
<LF><CRCA><0LLL>
<"*RSP"><seq><Rrcvr><Lpref><#idk>[<pad>#idk|NZZCCnnnn]< časová značka >
<CR>
8.3.2 Odmítnutí zprávy (NAK)
Pokud je v přijaté šifrované zprávě nesprávný časový údaj, přijímač vyšle paket obsahující negativní potvrzení a
časovou značku se správným časovým údajem:
<LF><CRCA><0LLL><"NAK"><0000><R0><L0><A0>[]< časová značka ><CR>
Zpráva typu NAK se nešifruje.
8.3.3 Zprávu nelze potvrdit (DUH)
Pokud přijímač není schopen řádně přijmout a zpracovat zprávu, pak odešle odpověď typu DUH:
<LF><CRCA><0LLL>
<"DUH"><seq><Rrcvr><Lpref><#idk>[]
<CR>
8.3.4 Na chybné CRC přijímač neodpovídá
9
Chyby při zpracování
Při komunikaci mezi objektovým zařízením a přijímačem mohou vznikat nejrůznější chyby. Postup při obsluze
některých chyb je popsán dále:
9.1 Čekání na odpověď
Objektové zařízení může čekat na odpověď po dobu stanovenou pro opakované odeslání zprávy. Pokud odpověď není přijata ve stanovené době, bude zpráva odeslána opakovaně. Doporučený čas pro opakované vysílání
je 20 sekund, doporučené číslo pro počet opakovaného odesílání zpráv je 3. Čas čekání pro opakované vysílání může být nastavitelný v rozsahu 5-60 sekund. Počet opakování může být rovněž nastavitelný.
9.2 Záporná odpověď (NAK)
Pokud objektové zařízení obdrží NAK odpověď, pak nastaví správný čas a opakovaně odesílá zprávu dle nastaveného počtu opakování. Doporučený počet opakování je 3, ale toto číslo může být měnitelné.
9.3 Odpověď na zprávu jíž přijímač neporozuměl (DUH)
Pokud objektové zařízení obdrží DUH odpověď, pak zprávu opakovaně odešle dle nastaveného počtu opakování nebo okamžitě signalizuje chybu.
9.4 Chyby zaznamenané přijímačem dohledového centra
9.4.1 Nesprávná časová značka
Pokud časová značka ve zprávě od objektového zařízení neprojde testem popsaným v příloze C.1.3.10, pak
přijímač odpoví zprávou typu NAK doplněnou o časovou značku popsanou v 8.1.9.
9.4.2 Nesprávný kontrolní součet
Přijímač zprávu vykazující chybu kontrolního součtu zahodí a neodpovídá na ni.
9.4.3 Nepodporované části zprávy
Pokud přijímač přijme celkem správně naformátovanou zprávu, která ale obsahuje nepodporované sekce (např.
neznámý typ „id“), tak odpoví „DUH“.
10
Ochrana proti útokům typu „playback“ – autentizací objektového zařízení
Část zprávy označenou jako číslo přijímače (viz 8.1.6.3) je možno využít k velmi rychlému a účinnému vyhodnocení pravosti zprávy. Těchto šest znaků (R123456) se využije k identifikaci zdroje zprávy. Tyto pozice jsou
15
TNI 33 4592
určeny k upřesnění přijímače (prefix). Čísla na těchto místech jsou hexadecimální, takže nám poskytují
11 390 625 kombinací. Poskládají-li se tyto kombinace náhodným způsobem do tabulky, mohou se hodnoty
z této tabulky vkládat do odesílaných zpráv. Tak se získá další skrytý „klíč“, kterým je pořadí v použité tabulce.
Tento údaj znají pouze vysílací a přijímací strana.
Pokud by řazení čísel v takové tabulce chtěl „hacker“ odhalit, trvalo by to při desetiminutovém intervalu mezi
kontrolními zprávami, mnoho let. Při použití šifrování AES a časové značky, nelze úspěšně falešnou zprávu
vytvořit. Z pohledu optimálních požadavků na paměť objektových zařízení a relativně malý výkon procesorových
jednotek těchto zařízení, můžeme využít dále popsané řešení.
Vytvoří se tabulku o 4464 položkách. Tabulku se vyplní náhodně vybranými kombinacemi z množiny obsahující
více než 11 milionů prvků. Při intervalu mezi kontrolními zprávami 10 minut, postačí taková tabulka objektovému
zařízení na jeden měsíc. Při odpojení objektového zařízení z důvodu opravy nebo dlouhotrvající ztráty spojení,
vyšle se na tomto místě zpráva o přechodu na jinou tabulku (např.: „RESET02“). To znamená, že se přechází
na tabulku č.2 a začínají se používat prvky od pořadí č.1. Každá další tabulka prodlužuje dobu potřebnou pro
rozkrytí pořadí čísel tabulky o jeden měsíc.
Z uvedeného formátu vyplývá možnost použití 225 tabulek, což znamená, že nedojde k opakování tabulek dříve
než za 18 let. Pro 225 použitých tabulek se vyčerpá pouze 10% prvků z nabízené množiny. Číslo tabulky může
pro přijímací stranu znamenat i číslo použitého šifrovacího klíče. Obsah tabulek určuje technické centrum provozovatele DPPC. Stejné tabulky může používat větší množství objektových zařízení. Pořadí právě použité
hodnoty z tabulky je u každého objektového zařízení jiné.
Efektivního využití s ohledem na velikost použité paměti procesoru se dosáhne tak, že se použije pouze jedna
tabulka o velikosti 28 kB a další potřebné tabulky se vytvoří např. rotací sloupců nebo řádků téže tabulky. Stejná
pravidla musí platit i na přijímací straně.
Po dohodě s výrobcem zařízení, lze tabulky vložit do zařízení přímo ve výrobě. Obsah tabulek může změnit
servisní technik. Výběr tabulky či její přeskupení je náhodný proces, který je signalizován přijímací straně povelem RESETta.
Tabulka - příklad
Pořadí
R[1]
R[2]
R[3]
R[4]
R[5]
R[6]
0001
1
B
2
C
D
E
0002
6
9
1
A
1
2
..
4464
..
F
5
D
4
A
3
Příklad použití hodnoty č. 1 z tabulky ve zprávě SIA-DCS:
003D"SIA-DCS"0001R1B2CDELF#9999[#999A|Nri01^sklad^/CL923^Novák Karel^]
Tento způsob ochrany proti „falešným zprávám“ je velmi jednoduchý, lze ho snadno aplikovat i v malých procesorech používaných v jednoduchých ústřednách. Pro ulehčení práce lze tabulky vygenerovat nějakou matematickou funkcí. Pro přijímač DPPC přibývá pouze jedna povinnost a to pamatovat si poslední přijaté číslo přijímače nebo jeho pořadí v příslušné tabulce. To jsou jednoduché funkce nenáročné na čas procesoru. Velkou výhodou tohoto principu je, že pro rozpoznání falešné zprávy není zprávu třeba předem dešifrovat. Může být smazána okamžitě po zjištění nesprávného údaje v čísle přijímače.
Porovnání s návrhem CENELEC (CLC/FprTS 50136-9 ) lze dosáhnout vyšší bezpečnosti, není tu velmi riskantní proces „nabíjení“ objektových zařízení z DPPC šifrovacími klíči za provozu. Tzv. pseudonáhodná čísla uvedená na začátku zprávy v protokolu CEN nemohou být považována za pseudonáhodná, neboť každá následující zpráva má číslo o 1 větší. Takové číslo je snadno předvídatelné.
11
Použití VPN tunelu
Pro zajištění ochrany dat, kdy se nepoužije šifrování vlastní zprávy (AES dle 6.2), může se použít VPN tunel
s použitím protokolu IPsec. Nejsnáze se takové zabezpečení realizuje pomocí tzv. „bezpečnostních bran“
s využitím protokolu ESP. Dle údajů výrobců bezpečnostních bran bývá počet tzv. simultánně běžících tunelů
max. 80 z 200 nadefinovaných tunelů. Z toho vyplývá, že při použití VPN tunelu musí existovat záložní cesta
pro odesílání zpráv přijímači DPPC.
Samotný protokol AH není dostatečně účinný. V případě, že přenášený paket je v průběhu cesty z provozních
důvodů rozdělen na části, vytváří se prostor pro změnu či vložení určité části dat. Pro úplnost je dále uveden
stručný popis protokolů.
16
TNI 33 4592
11.1 Protokoly IPsec
Bezpečnostní záhlaví určuje, jaká část IP datagramu je zabezpečená a jaké metody jsou pro zabezpečení použity. Existují dva protokoly pro zabezpečení IP datagramů:
- protokol AH
- protokol ESP
Protokol AH (Authentication Header) zajišťuje autentizaci odesílatele a příjemce, integritu dat v hlavičce a
ochranu proti opakování relace. Jeho služby jsou však omezené pouze na záhlaví IP datagramu, ale nezajišťují
už šifrování přenášených dat. V případě zabezpečení protokolem AH je bezpečnostní záhlaví AH vloženo za IP
záhlaví.
Protokol ESP (Encapsulating Security Payload) nejenže zajišťuje autentizaci odesílatele a příjemce a integritu
dat v záhlaví IP datagramu, ale navíc umožňuje šifrovat přenášená data. Protokol ESP vkládá do IP datagramů
kromě zabezpečovacího záhlaví ESP i zápatí ESP .
17
TNI 33 4592
Příloha A
Šifrování metodou řetězení bloků (CBC)
Šifrování metodou řetězení bloků (CBC) je způsob utajení, jehož základem je spojování bloků textu zprávy s již
dříve zašifrovanými bloky. CBC potřebuje IV (inicializační vektor) propojit s prvním blokem textu. Inicializační
vektor nemusí být utajený, avšak nesmí být snadno předvídatelný: generování inicializačního vektoru je diskutováno v části C[NIST800-38A]. Integrita inicializačního vektoru je chráněna a je diskutována v části D
[NIST800-38A].
POZNÁMKA
převzato od NIST Special Publication 800-38A - 2001 Edition
Obrázek 1 - Použití metody CBC je zobrazeno v následujícím diagramu:
Při CBC metodě šifrování je první vstupní blok (určený k šifrování) vytvořen funkcí „exklusive-OR“ mezi prvním
blokem textu a inicializačním vektorem. Pak se provede šifrování prvního vstupního bloku, jehož výsledkem je
první šifrovaný výstupní blok. Výstupní blok se operací XOR propojí s druhým blokem textu, čímž se vytvoří
druhý vstupní blok pro šifrování, následně se provede šifrování druhého vstupního bloku, čímž se vytvoří druhý
šifrovaný výstupní blok. Tento druhý šifrovaný výstupní blok je opět operací XOR propojen s dalším blokem
textu, aby se vytvořil další vstupní blok pro šifrování. Každý další blok textu je pomocí operace XOR propojen
s posledním šifrovaným výstupem, čímž se vytvoří nový vstupní blok. Opět je provedeno šifrování každého
vstupního bloku a vytvořen další šifrovaný blok.
Při použití CBC dešifrování je nejdříve dešifrován první šifrovaný blok, pak z výsledného výstupního bloku tohoto dešifrování pomocí operace XOR s inicializačním vektorem (IV) dostaneme první blok původního textu.
Následně je dešifrován druhý blok a výsledný výstupní blok po použití operace XOR s prvním šifrovaným blokem dává druhou část původního textu. Obecně k získání libovolné části původního textu (kromě první), se
provede dešifrování příslušného bloku a s jeho výsledkem se provede operace XOR s předchozím šifrovaným
blokem.
Při CBC šifrování je každý vstupní blok (kromě prvního) šifrovací funkce odvislý od výsledku šifrování minulého
bloku, takže šifrovací funkce nelze provádět současně.
Při dešifrování metodou CBC jsou vstupní bloky (šifrované bloky) pro dešifrování okamžitě dostupné, takže
vícenásobné dešifrování se může provádět současně.
18
TNI 33 4592
Příloha B
Příklady použití s následujícími parametry
seq: 9876
rcvr: 579BDF
pref: 789ABC
idk: 12345A
POZNÁMKA idk je stejné pro komunikátor a ústřednu, což platí u jednoduchých, nedělitelných ústředen, jinak mohou mít
komunikátor a ústředna, případně ústředny rozdílné id)
U šifrovaných zpráv, je CRC označen jako "xXXXX" neboť CRC se počítá až po šifrování
Znaky, které nejsou typu ASCII se zobrazují v závorkách "<…>", při použití hexadecimálního způsobu vyjádření
(např. "x79BD").
Příklady jsou psány do dvou řádek z důvodů přehlednosti, avšak zpráva je vyslána jako jeden řetězec znaků.
Některá pole jsou zdůrazněna pro lepší čitelnost textu.
B.1 Požár, Zóna 129, SIA DC-04 Formát, nešifrováno, bez časové značky
<x0A><EC34>0031"SIA-DCS"9876R579BDFL789ABC#12345A
[#12345A|NFA129]<x0D>
B.2 Požár, Zóna 129, Contact ID DC-05 Formát, nešifrováno, bez časové značky, Group 0
<x0A><0DD3>0036"ADM-CID"9876R579BDFL789ABC#12345A
[#12345A|1110 00 129]<x0D>
B.3 Požár, Zóna 129, SIA DC-04 Formát, nešifrováno, časová značka
<x0A><91EA>0045"SIA-DCS"9876R579BDFL789ABC#12345A
[#12345A|NFA129]_13:14:15,02-15-2006<x0D>
B.4 Požár, Zóna 129, SIA DC-04 Formát, šifrováno
Následuje zpráva do které je před šifrováním, do oblasti od „[„ až po ukončovací znak <x0D>, je vloženo 13
náhodných znaků
<x0A><CRCA>0064"*SIA-DCS"9876R579BDFL789ABC#12345A
[<x56C2482DF2318B364722F318D0>|#12345A|NFA129]_13:14:15,02-15-2006<x0D>
B.5 Požár, Zóna 129, SIA DC-04 Formát, nešifrováno, bez časové značky, MAC adresa x1234567890AB
<x0A><6A8F>0042"SIA-DCS"9876R579BDFL789ABC#123456A
[#123456A|NFA129][M1234567890AB]<x0D>
B.6 Narušení Zóna 65, Contact ID DC-05 Formát, šifrováno, Blok 2, MAC adresa x1234567890AB,
potvrzení dat (v budoucnu)
<x0A><CRCA>005B"*ADM-CID"9876R579BDFL789ABC#12345A
[<x4D32FC2B>#12345A|1130 02 065][M1234567890AB][Vanydata]<x0D>
B.7 Odkódován blok 2, Uživatel 3, SIA DC-04 Formát, nešifrováno, bez časové značky
<x0A><9DD9>0032"SIA-DCS"9876R579BDFL789ABC#12345A
[#12345A|Nid3OG2]<x0D>
19
TNI 33 4592
Příloha C
Doporučené postupy při testování výrobků
Doporučeným postupem k ověření správné funkce vyvíjeného zařízení je použití simulátoru. Nejlepší k odhalení
nesprávných úvah při vývoji je, když simulátor vytvoří zcela rozdílný tým pracovníků než ti, co dělají vývoj zařízení.
C.1 Testování objektového zařízení
C.1.1 Simulátor přijímače
V případě testování objektového zařízení je vhodné použít simulátor přijímače. Simulátor přijímače může být
aplikace spuštěná na PC umožňující komunikaci s objektovým zařízením pomocí IP protokolů. Simulátor přijímače by měl umět zobrazit následující sekce z přijaté zprávy dle této normy:
• číslo zprávy (seq)
• číslo přijímače (rcvr)
• předčíslí (pref)
• objektové číslo (idk)
• pad znaky
• datovou část zprávy (…data…)
• rozšiřující data (x…data…)
• časovou značku
Simulátor kontroluje CRC, délku zprávy a je schopen dešifrovat zprávu.
C.1.2 Testování
Pro příjem zpráv z testované jednotky (UUT) se použije simulátor přijímače, který umožňuje manuální ověření
zpráv. Při testování se porovnává každá část datového pole vyslaná objektovým zařízením s odpovídající částí
zprávy zobrazenou simulátorem. Správně spočtený kontrolní součet (CRC) a správně určená délka zprávy jsou
kontrolovány u každé odeslané zprávy.
C.1.3 Způsob testování
Tato část doporučuje parametry pro testy objektového zařízení:
C.1.3.1 Označení (viz 4.2)
• ověří se, zda zařízení je nositelem jednoho z těchto označení: "SIA IP Reporting (UDP-2006)", "SIA IP Reporting (TCP-2006)" nebo "SIA IP Reporting (UDP/TCP-2006)"
• ověří se, zda zařízení je schopno splnit podmínky hodnocení AAAAAA - CCCCCC
• použijte simulátor přijímače k ověření správné funkce IP protokolu (TCP, UDP nebo jiný) při vysílání zpráv
C.1.3.2 IP Adresy (viz 5.2)
• IP adresy jsou programovatelné manuálně
C.1.3.3 Šifrování (viz 5.4) (pokud je podporováno objektovým zařízením)
• zadá se šifrovací klíče do objektového zařízení a do simulátoru přijímače
• vysílají se všechny typy zprávy podporovaných v DC-07 šifrovaně a ujištění o správném dešifrování simulátorem přijímače
• odešle se 5 zpráv, zkontroluje se, zda datová sekce „pad“ neobsahuje žádný příkaz (v takovém případě je
nutné zásadně odlišit zprávu a vkládané náhodné znaky do sekce „pad“)
• ověří se, že znaky "[", "]" a "|" nejsou součástí „pad“ sekce datové oblasti
• změní se šifrovací klíč v objektovém zařízení a zjistí se, zda zpráva byla dešifrována chybně
• opakují se testy s použitím šifrování pro šifrovací klíče různých délek
C.1.3.4 Šifrování pomocí spojování bloků
• pokud objektové zařízení umožňuje vytvořit zprávu obsahující 3 šifrované bloky (délka větší než 32 znaků),
odešle se stejná zprávu třikrát a zkontroluje se, zda prostřední část zprávy je vždy rozdílná
20
TNI 33 4592
C.1.3.5 Název formátu
• zkontroluje se, zda testovaná jednotka generuje správný název použitého formátu zprávy dle DC-07
• zkontroluje se, zda v případě použití šifrování, název formátu začíná "*"
C.1.3.6 Číslo zprávy
• v případě, že simulátor odmítne přijmout první odeslanou zprávu, zkontroluje se, zda objektové zařízení odešle při druhém pokusu zprávu se stejným číslem sekvence
• odešle se zpráv a kontroluje se, zda se číslo sekvence navyšuje v každé zprávě
• vysílají se postupně zprávy tak, aby se ověřilo postupné navyšování čísla zprávy až k 9998, 9999, 0001, 0002
C.1.3.7 Identifikace objektového zařízení
Kontrolují se zprávy přijaté simulátorem přijímače při nastavení následujících parametrů objektového zařízení
(tyto parametry nesmí být mimo možnosti objektového zařízení).
• rcvr = 0
• rcvr = 1234
• rcvr = FFFFFF
• "R" = 0
• pref = 0
• pref = 1234
• pref = FFFFFF
• idk = 0
• idk = 123456
• idk = 01234567879ABCDEF (může být zkrácena dle metody uvedené v DC-04 )
• idk = FEDCBA9876543210 (může být zkrácena dle metody uvedené v DC-04)
C.1.3.8 Zpráva
Pokud je objektové zařízení vybaveno šifrováním zpráv, odešlou se všechny typy zpráv popsaných v DC-07, u
každé události zkontrolujte správnost obsahu datového paketu
• kontroluje se, zda nedochází k chybám při vysílání, případné chyby indikují citlivost dat na šifrování
• pokud minulý test proběhl správně, opakuje se test na vybraných událostech bez šifrování (asi na 10% zpráv)
C.1.3.9 MAC Adresa
• vyšle se 5 zpráv obsahujících MAC adresu a ověřte, zda všechna datová pole byla správně vyslána a to včetně MAC adresy
C.1.3.10 Časová značka
• ověří se, zda časová značka obsahuje hodnoty GMT a neobsahuje místní čas
• nastaví se nesprávný čas a ověřte, zda objektové zařízení nastaví správně časovou značku dle času obsaženého v NAK odpovědi od simulátoru přijímače
C.1.3.11 Kontrolní zpráva
• povolí se vysílání kontrolních zpráv a ověří se správný formát zprávy
• povolí se šifrování a opět se zkontroluje správný formát zprávy
• ověří se, zda interval vysílání kontrolní zprávy je v souladu s dokumentací objektového zařízení
• ověří se možnost měnit interval vysílání kontrolní zprávy programově
C.1.3.12 ACK zpráva
• potvrdí se, že objektové zařízení neopakuje vysílání zprávy po přijetí ACK
• opakuje se totéž při použití šifrování
C.1.3.13 NAK zpráva
• v případě, že simulátor přijímače odpoví zprávou NAK, zkontroluje se opakované vyslání zprávy objektovým
zařízením (bez navýšení čísla zprávy) . Počet opakovaných vysílání by mělo být sudé číslo.
21
TNI 33 4592
• zařadí se do vysílací fronty objektového zařízení větší počet zpráv a nastaví se simulátor přijímače tak, aby
odpovídal pouze NAK zprávy – kontroluje se, zda objektové zařízení po obdržení zprávy NAK zruší nepotvrzenou zprávu a bude odesílat zprávu následující ve vysílací frontě
• zjistí se, zda NAK zpráva (nikdy se nešifruje) je správně přijata objektovým zařízením nastaveným do šifrovacího módu (pokud je zařízením podporován)
• zdokumentuje se chování objektového zařízení při ukončení vysílání zpráv po přijetí více NAK odpovědí
C.1.3.14 DUH Zpráva
• v případě vyslání zprávy typu DUH simulátorem přijímače zkontroluje se, zda objektové zařízení neopakuje
vysílanou zprávu
• zdokumentuje se chování objektového zařízení při ukončení vysílání zpráv po přijetí více DUH odpovědí
C.1.3.15 Odpověď nebyla odeslána
• zabrání se simulátoru přijímače v odpovídání na zprávy odeslané objektovým zařízením a kontroluje se, zda
objektové zařízení odešle zprávu opět v rozmezí 5 – 60 sekund
C.2 Testování přijímače dohledového centra
C.2.1 Simulátor objektového zařízení
Při testování přijímače dohledového centra se použije simulátor objektového zařízení. Může to být aplikace
běžící na PC, která využívá vlastností PC a možnosti IP propojení s přijímačem dohledového centra. Simulátor
objektového zařízení vytváří zprávu složenou z následně popsaných částí:
• číslo zprávy (seq)
• číslo přijímače (rcvr)
• předčíslí (pref)
• identifikační číslo (idk)
• doplňující znaky (pad)
• typy událostí uvedené v dokumentu DC-07
• data ve zprávě (…data…)
• MAC adresa
• časová značka
Simulátor počítá CRC, délku zprávy a vytváří šifrované zprávy. Schopnost generovat zprávy s nesprávným
CRC je zde nezbytná.
C.2.2 Testovací proces
Simulátor objektového zařízení se používá k vysílání zpráv k testované jednotce (UUT). Při každém testu jsou
data každého vyslaného datového pole porovnávána s daty přijatými přijímačem dohledového centra.
C.2.3 Způsob testování
Tato část obsahuje doporučení pro testování jednotlivých parametrů přijímače:
C.2.3.1 Označení
• ověří se, zda zařízení je označeno jedním z následujících typů "SIA IP Reporting (UDP-2006)", "SIA IP Reporting (TCP-2006)" nebo "SIA IP Reporting (UDP/TCP-2006)"
• pomocí simulátoru objektového zařízení se ověří, zda přijímač je schopen přijímat zprávy pomocí IP protokolu
(TCP, UDP nebo TCP/UDP).
C.2.3.2 IP Adresy
• ověří se možnost manuální změny IP adresy přijímače
C.2.3.3 Šifrování
• nastaví se na simulátoru objektového zařízení použití šifrovacího klíče
• pro každý typ zprávy uvedené v dokumentu DC-07 se vyšle šifrovaná zpráva a ověří se, zda ji přijímač přijal
správně.
• změní se šifrovací klíč objektového zařízení a zjistí se nesprávné dešifrování zprávy
• opakuje se skupina šifrovacích testů (10%) pro všechny klíče rozdílné délky
22
TNI 33 4592
C.2.3.4 Šifrování metodou řetězení bloků
• simulátorem objektového zařízení se odešle zpráva delší než 3 šifrované bloky (delší než 32 znaků) a zkontroluje se správné dešifrování přijímačem
C.2.3.5 CRC
• vyšle se k přijímači zpráva s nesprávným CRC a zkontroluje se, zda tato zpráva zůstala bez odpovědi
C.2.3.6 ID označení
• od každého typu zprávy uvedené v dokumentu DC-07 se vyšle otevřenou zprávu a zjistí se, zda ji přijímač
zpracoval správně
C.2.3.7 Číslo zprávy ( )
• simulátor objektového zařízení vyšle zprávu o 3 blocích a s jedním zvláštním blokem vloženým do sekvence
třeba: 1,2,1,3 – ověří se, zda přijímač složí a dekóduje zprávu správně
• simulátor objektového zařízení vyšle zprávu o 3 blocích a s jedním zvláštním blokem vloženým do sekvence
třeba: 9995, 9996, 9995 (extra), 9997 – ověří se, zda všechny 3 zprávy byly přijaty jen jednou
• vysílají se zprávy simulátorem objektového zařízení a kontroluje se, že číslo zprávy je přijímačem řádně zvyšováno od 9998, 9999, 0001, 0002
C.2.3.8 Identifikace objektu
Vyšlou se zprávy ze simulátoru objektového zařízení a kontroluje se potvrzení správného přijetí zpráv při vložení následujících ID parametrů do zpráv:
• rcvr = 0
• rcvr = 1234
• rcvr = FFFFFF
• bez pole "R" (žádné číslo přijímače)
• pref = 0
• pref = 1234
• pref = FFFFFF
• idk = 0
• idk = 123456
• idk = 01234567879ABCDEF (může být zkráceno dle metody uvedené v DC-04 )
• idk = FEDCBA9876543210 (může být zkráceno dle metody uvedené v DC-04)
C.2.3.9 Zprávy
• při použití šifrování odešle se simulátorem objektového zařízení 5 zpráv od každého typu uvedeného v DC-07,
přičemž v každém vzorku jsou použity jiné parametry
• kontroluje se, zda nedochází k chybám při vysílání, případné chyby indikují citlivost dat na šifrování
• pokud předešlý test za použití šifrování proběhl dobře, zopakuje se bez použití šifrování
C.2.3.10 MAC Adresa
• vyšle se zpráva obsahující MAC adresu
• zkontroluje se správné zpracování všech částí zprávy
• zaznamená se zpracování MAC adresy přijímačem
C.2.3.11 Ověření dat
• vysílají se zprávy obsahující další vložená data sloužící k ověření správnosti dat obsažených ve zprávě a kontroluje se, zda všechny bloky dat obsažené ve zprávě byly správně zpracovány (včetně vložených dat).
C.2.3.12 Programově využitelná vložená data
• vysílají se zprávy obsahující další programově využitelná vložená data a kontroluje se, zda všechny bloky dat
obsažené ve zprávě byly správně zpracovány (včetně vložených dat).
23
TNI 33 4592
C.2.3.13 Časová značka
• simulátorem objektového zařízení se vyšle šifrovaná zpráva s časem o 25 sekund vyšším, než je čas přijímače, kontroluje se, zda přijímač odmítne zprávu pomocí NAK odpovědi obsahující čas přijímače
• simulátorem objektového zařízení se vyšle šifrovaná zprávu s časem o 45 sekund nižším, než je čas přijímače, kontroluje se, zda přijímač odmítne zprávu pomocí NAK odpovědi obsahující čas přijímače
C.2.3.14 Kontrolní zpráva
• nastaví se interval vysílání kontrolní zprávy na 50 sekund, na přijímači se nastaví požadavek přijmout kontrolní
zprávu každou minutu, kontroluje se bezchybnost tohoto testu po dobu 24 hodin
• odpojí se simulátor objektového zařízení a zkontroluje se oznámení přijímače o poruše komunikace do 60
sekund
• ověří se, že interval pro kontrolu kontrolní zprávy může být nastaven v rozsahu 120 sekund až 1200 sekund.
• ověří se kontrolou kódů nebo jinými prostředky, že interval kontrolní zprávy je správně nastaven v přijímači
• ověří se správná funkce kontrolních zpráv v režimu šifrování i v režimu použití otevřených zpráv
C.2.3.15 DUH Zpráva
• v případě, že objektové zařízení odešle zprávu správného formátu, ale s formátem rozdílným od typů zpráv
uvedených v DC-07, zkontroluje se, zda přijímač dohledového centra odpověděl zprávou DUH
C.2.3.16 Odpověď nebyla odeslána
• simulátoru přijímače se zabrání v odpovídání na zprávy odeslané objektovým zařízením a kontroluje se, zda
objektové zařízení odešle opakovaně alespoň jednu zprávu a to v rozmezí 5 – 60 sekund
24
TNI 33 4592
Příloha D
Šifrovací klíče
Tato technická specifikace používá pro šifrování pevné soukromé klíče, aby se vyhnula systémovému používání
veřejných klíčů. Doporučení pro práci se soukromými klíči jsou:
• vývojem takového systému, zejména části vývoje šifrovacích klíčů, by se mělo zúčastnit jen málo pracovníků
• funkce zařízení jsou upraveny tak, aby pouze odpovědné osoby mohly vkládat šifrovací klíče do objektových
zařízení nebo přijímačů dohledového centra, není přípustné vložené klíče z těchto zařízení zpětně číst
• popis použitého způsobu šifrování je uveden v čl. 5.1 NIST Special Publication 800-38A
25
TNI 33 4592
Příloha E
Garantovaná šíře pásma (BWM)
26
TNI 33 4592
Příloha F
Doporučené uspořádání při dělení šířky pásma na vstupu DPPC
Neagregované pásmo 32 Mb/s se dělí mezi IP přijímač DPPC, kamerové dohledové centrum s 5 PC a dalších
20 PC pro ostatní pracovníky firmy
27
TNI 33 4592
Příloha G
Synchronizace času
28
TNI 33 4592
Příloha H
Komunikace s využitím VPN tunelu
29
TNI 33 4592
Příloha I
DC-07 Názvy použitelných protokolů (informativní příloha)
Tento seznam označení komunikačních protokolů je převzat z dokumentu SIA DC-07 a je závazný při řešení
případných sporů mezi tímto dokumentem a DC-07
SIA-PUL
SIA-PUL
ADM-CID
ADM-41E
ADM-42E
ADM-HS
DSC-43
FBI-SF
ITI-I
SCN-S8
SCN-S16
SCN-S24
SCT
SES-SS
SIA-DCS
SIA-S2K
SK-FSK1
SK-FSK2
Generic Pulse Codes
Acron Super Fast
Ademco Contact ID
Ademco 4-1 Express
Ademco 4-2 Express
Ademco High Speed
43 DSC 4-3
FBI Super Fast
ITI Standard
Scancom 4-8-1, 5-8-1, 6-8-1
Scancom 4-16-1, 5-16-1, 6-16-1
Scancom 4-24-1, 5-24-1, 6-24-1
Scantronics Reserved
Sescoa Super Speed
SIA DCS
SIA 2000
Silent Knight FSK1
Silent Knight FSK2
30
TNI 33 4592
Příloha J
Vzdálené ovládání objektového zařízení.
ANSI / SIA DC-09 se rozšiřuje o příkazy dálkového ovládání, což může být významné např. v následujících
situacích:
- Otevření únikových východů z dálnic, tunelů, odblokování barier při mimořádných událostech
- Otevírání dveří bezpečnostních trezorů
- Ovládání vstupních bran do chráněných částí budov
- Aktivace a deaktivace vzdálených bezpečnostních zařízení
- Aktivace a deaktivace únikových východů
- Ovládání hasicích zařízení
- Aktivace a deaktivace vzdálených zařízení požární signalizace
- Ovládání zařízení pro identifikaci osob a vozidel
Tato příloha popisuje možnosti využití protokolu DC-09 pro ovládání objektových zařízení dálkově odesílanými
příkazy přijímačem dohledového centra. Příkazy jsou odesílány jako odpověď na kontrolní zprávu (NULL) místo
obvyklé potvrzovací zprávy (ACK). Odesílat takové příkazy jako odpověď na jiný typ zprávy se nedoporučuje.
Pokud objektové zařízení není vybaveno potřebnými funkcemi pro zpracování těchto příkazů, odpoví zprávou
„DUH“.
Formát zprávy:
<LF><CRC><0LLL>
<"RSP"><seq><Rrcvr><Lpref><#acct>[#acct|Ndata]<CR>
Při použití šifrování bude mít zpráva následující strukturu:
<LF><CRC><0LLL>
<"*RSP"><seq><Rrcvr><Lpref><#acct>[<pad>|šifrovaná data]<šifrovaná časová značka><CR>
V datovém poli ([#acct|"data]), písmeno následující po "|" ukončujícím „acct“ je znak určující výrobce zařízení.
Pro identifikaci výrobce můžeme použít 3-7 ASCII znaků vložených mezi uvozovky (např. “Equipco“). Nelze
použít znaky uvozovky (“) a ’|’. Toto datové pole identifikuje výrobce zařízení stejně jako jsou identifikovány
typy použitých komunikačních protokolů uvnitř zprávy.
Příklad 1:
- <LF>CRCA002A"RSP"0001L2#621[#621|"EQUIPCO"RZS23.5,YX7]<CR>
- CRCA ….kontrolní součet (není počítán)
- 002A….. délka zprávy
- RSP……vzdálený povel
- 0001……číslo zprávy
- L2………prefix linky
- #621…...id komunikátoru
- “ EQUIPCO“ .. identifikace výrobce zařízení (7 znaků)
- RZS23.5,YX7…konkrétní příkaz specifikovaný výrobcem zařízení
Příklad 2: Starší formát zprávy (používaný v Evropě)
- <LF>CRCA001F"RSP"0001L2#345[#345|NZZCCnnnn]<CR>
- N identifikace výrobce starším způsobem
- NZZCCnnnn….formát zprávy určený výrobcem
- N…nová zpráva
- ZZ je fixní kód indikující vzdálený povel vyslaný přijímačem dohledového centra objektovému zařízení
- CC je kód činnosti pro určitou akci dle příslušného projektu nebo plánu servisního technika
- nnnn…číslo zóny (musí odpovídat fyzickému vstupu nebo výstupu, např. kontaktu relé)
Pokud chceme použít vzdálené povely pro řízení objektových zařízení, musíme zkrátit interval kontrolních zpráv. Interval odesílání kontrolních zpráv může být proměnný.
Vzdálené povely vkládáme do odpovědí na kontrolní zprávy (NULL). Potvrzení typu „RSP“ musí být
objektovým zařízením považováno za potvrzení „ACK“ kontrolní zprávy.
Objektové zařízení potvrdí přijetí vzdáleného povelu změnou příslušného parametru nebo svého
stavu, což se projeví při odesílání nové zprávy o události ve střeženém objektu.
31
TNI 33 4592
Příloha K
32
TNI 33 4592
Příloha L
33
TNI 33 4592
Příloha M
Doporučená DOM – XML struktura pro výstupní formát dat z přijímače DPPC
Jako výsledek zpracování dat přijímačem dohledového centra je vhodné použít jednotný formát datového
výstupu pro následné zpracování v databázi, webových stránkách, uložení do archivu atd..
V současné době se jeví optimální pro následná využití přijatých dat struktura XML. Do této struktury lze
velmi snadno implementovat rozšiřující datové sekce definované v tomto dokumentu. Struktura typu XML je
zpracovatelná všemi běžně použitelnými programy včetně internetových prohlížečů. Doporučené typy jazykových konvencí mohou být v ČR: Windows 1250, UTF-8, UTF8-URL. Je nutné vyvarovat se použití služebních
znaků uvnitř textů rozšiřujících datových sekcí (< / >). Struktura je dále rozšiřitelná dle potřebných požadavků.
Struktura může být rozšířena i o informace z databáze objektů uložené v přijímači.
Příklad:
<event type=”!Alarm”>
<tim tz=”LT Praha”>12:30:40, 08-28-2013</tim>
Zde vložíme informaci o čase přijetí zprávy
Použijeme lokální čas nebo čas GMT
<msg ptc=”ADM-CID”>1234|1110 02 005</msg> Určuje název použitého protokolu
<idn>1234</idn>
Identifikační čislo sekce vzniku události
<blk>02</blk>
Blok vzniku události
<zon>005</zon>
Zóna vzniku události
<etx lang=”W1250”>Požár v zóně</etx>
Text popisující událost používá znaky Win 1250
<obj>Budova firmy ..</obj>
Přejímáme text z rozšiřující sekce [O Budova..]
<str>Město, ulice, číslo popisné</str>
Přejímáme text z rozšiřující sekce [S Město, ..]
<lat> druhé podlaží</lat>
Přejímáme text z rozšiřující sekce [L druhé .. ]
<rom>místnost č.24</rom>
Přejímáme text z rozšiřující sekce [R místnost .]
<int>detektor ve skladu chemikálií</int>
Přejímáme text z rozšiřující sekce [TF detektor ..]
<vis>http:// 10.0.20.30:5566</vis>
Adresa kamery nebo videoserveru [V http:……]
<xps> 15* 11’ 22”E 50* 11’ 22”N</xps>
Souřadnice GPS nebo metry od.. [X…
]
<yps>30 metrů vpravo od brány</yps>
Souřadnice GPS nebo metry od.. [Y…
]
<not>Pozor, odpojit plyn</not>
Upozornění zásahové jednotce
<not>Servisní technik tel:+420 </not>
Informace o servisu z databáze přijímače
</event>
Příklad - příchozí zpráva z objektového zařízení:
<0xA>CRCADDDD”ADM-CID”R0L0#1200[#1234|1110 02 005][O Budova firmy ..][S Město ulice číslo popisné] [L druhé podlaží][TFdetektor ve skladu chemikálií][………]_10:20:30,08-30-2013<0xD>
Využití takového struktury umožňuje velmi rychlé předání důležitých informací zásahové jednotce v čase 1-2
sekundy od přijetí zprávy.
34
Download

Informace o využití protokolu SIA DC-09 - T