Alarmes automatiques

Transmissions scurises d'alarmes sur IP

Complment technique la Rgle de prescription

Etablissement Cantonal dAssurance, Division Prvention

Avenue du Gnral Guisan 561009 PullyTlphone +41 58 721 21 21prevention@eca-vaud.chwww.eca-vaud.ch
Edition :

Etablissement cantonal d'assurance contre l'incendie et les lments naturels du Canton de Vaud
Division Prvention
Avenue du gnral Guisan 56
1009 Pully
+41 58 721 21 21
prevention@eca-vaud.ch
Dcembre 2009
Etablissement cantonal d'assurance contre Police cantonale Fribourg
l'incendie et les lments naturels du canton de Vaud

Transmission scurise d'alarmes sur IP

Complment technique la Rgle de prescription

Ce document a pour objectif de clarifier certains points de la Rgle de prescription v1.5 de

dcembre 2009, potentiellement sujets interprtation, afin de garantir une implmentation
uniforme du protocole DC-09 par les diffrents constructeurs et assurer linteroprabilit entre
produits.
Il permet en outre didentifier plus clairement les paramtres requis et optionnels dcrits dans la
rgle de prescription, et de les situer soit dans le datagramme DC-09, soit dans les en-ttes IP ou
TCP/UDP, voire mme pour certains de les dduire dautres paramtres transmis et donc de les
exclure de la transmission elle-mme.
Plusieurs scnarios sont illustrs entre la transmission dun vnement par un transmetteur client
et les diverses possibilits de quittancement par le rcepteur, ainsi que le contrle de ligne et
lenvoi de commandes.

Ce complment technique est appliqu par les centres officiels de traitement dalarmes suivants:

VD CTA 118

FR CEA 112 117 118

Version 1.5 Dcembre 2009

Cette version remplace et annule toutes les prcdentes.

Complment technique la Rgle de prescription Page 3/27

Version 1.5 Dcembre 2009
Sommaire

1 Domaine d'application .............................................................................................................6

1.1 Conventions dcriture........................................................................................................6
1.2 Terminologie.......................................................................................................................6
2 Dfinitions.................................................................................................................................7
2.1 DC-09 de base ...................................................................................................................7
2.2 DC-09 extensions...............................................................................................................7
2.3 Autre...................................................................................................................................7
2.4 Format dentre ..................................................................................................................7
2.5 Code de critre...................................................................................................................7
2.6 Cryptage.............................................................................................................................7
3 Architecture ..............................................................................................................................8
3.1 Modle global .....................................................................................................................8
3.2 Exemple d'implmentation n1...........................................................................................8
3.3 Exemple d'implmentation n2...........................................................................................9
3.4 Exemple d'implmentation n3...........................................................................................9
3.5 Remarques gnrales sur l'implmentation .....................................................................10
4 Principe et squence de la transmission.............................................................................11
5 Paramtres requis et optionnels ..........................................................................................13
6 Types de messages ...............................................................................................................15
6.1 Messages dvnement (alarme feu) ...............................................................................15
6.1.1 Prcisions sur le champ data..................................................................................................16
6.1.2 Prcisions sur les champs x.data ...........................................................................................16
6.1.3 Balises dfinies pour les champs x.data ................................................................................16
6.1.4 Dclencheur dalarme (Trigger) ..............................................................................................17
6.1.5 Arborescence Synthse.......................................................................................................18
6.1.6 Exemples de message en DC-09 (selon ANSI/SIA DC-09:2007) ..........................................19
6.2 Messages de quittancement ............................................................................................20
6.2.1 Quittancement positif (ACK) ...................................................................................................20
6.2.2 Quittancement ngatif (NAK) ..................................................................................................21
6.2.3 Quittancement dincapacit (DUH) .........................................................................................21
6.2.4 Messages de supervision (NULL) ..........................................................................................22
7 Envoi de commande ..............................................................................................................23
7.1 Commandes simples........................................................................................................23
7.2 Processus denvoi de la commande et de quittancement ................................................24
8 Scnarii ...................................................................................................................................25
8.1 Scnario 1 Alarme feu envoye au CTA et ACK...........................................................25
8.1.1 Escalade en cas de non rponse ...........................................................................................25
8.2 Scnario 2 Message avec code non support et DUH .................................................25
8.3 Scnario 3 Message avec horodatage incorrect et NAK...............................................26
8.4 Scnario 4 Alarme inondation au CTA via centre de transit..........................................26
8.5 Scnario 5 Commandes distance ..............................................................................26

Complment technique la Rgle de prescription Page 4/27

Version 1.5 Dcembre 2009
9 En-ttes IP, TCP et UDP.........................................................................................................27
9.1 En-tte IP .........................................................................................................................27
9.2 En-tte TCP......................................................................................................................27
9.3 En-tte UDP .....................................................................................................................27

Complment technique la Rgle de prescription Page 5/27

Version 1.5 Dcembre 2009
 1 Domaine d'application

Ce document a pour objectif de clarifier certains points de la Rgle de prescription v1.3 de juillet
2009, potentiellement sujets interprtation, afin de garantir une implmentation uniforme du
protocole DC-09 par les diffrents constructeurs et assurer linteroprabilit entre produits.
Il permet didentifier plus clairement les paramtres requis et optionnels dcrits dans la rgle de
prescription, et de les situer soit dans le datagramme DC-09, soit dans les en-ttes IP ou
TCP/UDP, voire mme pour certains de les dduire dautres paramtres transmis et donc de les
exclure de la transmission elle-mme.

1.1 Conventions dcriture

Les conventions dcriture suivantes sont appliques dans le prsent document, dans les
diffrents chapitres dcrivant les datagrammes DC-09 :
Si un paramtre est requis il est inscrit en gras.
Les paramtres optionnels sont inscrits en orange.

1.2 Terminologie
TR : Transmetteur (ou PE, Premises Equipment).
CSR : Systme de rception (Central Station Receiver).
CTA : Centre de Traitement des Alarmes (centre officiel).
CT : Centre de Transit (tous types dalarmes).

Complment technique la Rgle de prescription Page 6/27

Version 1.5 Dcembre 2009
 2 Dfinitions

Les dfinitions suivantes sappliquent en particulier aux en-ttes de colonnes du tableau du

chapitre 5.

2.1 DC-09 de base

Paramtres dfinis du standard ANSI/SIA DC-09:2007 en ltat.

2.2 DC-09 extensions

Paramtres transmis dans les champs dextension de donnes (x.data). Les donnes dextension
sont identifies par des balises spcifiques (cf. 6.1.3).

2.3 Autre
Paramtres pas transmis dans les champs de donnes du datagramme DC-09 mais ailleurs (par
exemple dans len-tte IP), voire pas transmis du tout mais dduits du code de critre transmis.

2.4 Format dentre

Format ou codage dorigine des donnes transmettre. Le format dentre est spcifi dans le
champ "id" du datagramme DC-09. Les autres champs sont repris tels quels dans le datagramme
DC-09.
Important: Pour simplifier limplmentation, le prescripteur a dcid de ne supporter quun seul
format dentre au niveau de son systme de rception, en loccurrence le format SIA-DCS. Le
prescripteur se rserve le droit de supporter ultrieurement dautres formats dentre selon
lvolution des standards.

2.5 Code de critre

Code de 2 caractres (pour le SIA-DCS), identifiant un vnement spcifique (p.ex. FA, Fire
Alarm). Une liste des codes supports par le prescripteur sera publie sparment.
Le code de critre est suivi dune adresse sur 4 chiffres (toujours complte, soit par ex. 0004),
appele "zone", correspondant ladresse de contact du code de critre.

2.6 Cryptage
Le prescripteur demande que les donnes qui lui sont adresses soient cryptes. Toutefois, la
mthode de cryptage est laisse libre, pour autant que les pr-requis soient respects (cf. Rgle
6.7.1). Le cryptage doit tre fait au niveau des datagrammes DC-09.
Dans le cas d'une communication crypte, le prescripteur ne demande pas de fonction de
hachage. Si la transmission est non crypte, le hachage est obligatoire.

Complment technique la Rgle de prescription Page 7/27

Version 1.5 Dcembre 2009
 3 Architecture

3.1 Modle global

Le principe global de transmission des alarmes automatiques est prsent sur la figure suivante:
Transmission via un centre de transit
Transmission directe

Pour obtenir les explications dtailles de cette figure, se rfrer la Rgle de prescription.

3.2 Exemple d'implmentation n1

La figure suivante schmatise un exemple d'implmentation de la transmission. Ce schma
propose une implmentation possible de la transmission des alarmes automatiques pour une
entreprise ne dsirant pas effectuer la rception et le traitement des alarmes techniques. Dans ce
cas, l'Oprateur propose une solution "cl en main".
Transmission via un centre de transit

Complment technique la Rgle de prescription Page 8/27

Version 1.5 Dcembre 2009
 3.3 Exemple d'implmentation n2
La figure suivante schmatise un exemple d'implmentation de la transmission. Ce schma
propose une implmentation possible de la transmission des alarmes automatiques pour une
entreprise dsirant grer ces propres transmetteurs, mais mandate une socit externe pour
effectuer la rception et le traitement des alarmes techniques.
Transmission via un centre de transit
Transmission directe

3.4 Exemple d'implmentation n3

La figure suivante schmatise un exemple d'implmentation de la transmission. Ce schma
propose une implmentation possible de la transmission des alarmes automatiques pour une
entreprise dsirant grer de bout en bout la transmission des alarmes.
Transmission via un centre de transit
Transmission directe

Complment technique la Rgle de prescription Page 9/27

Version 1.5 Dcembre 2009
 3.5 Remarques gnrales sur l'implmentation
Dans certains cas, il est tout fait envisageable que le rseau priv de l'entreprise et ses accs
Internet soient utiliss pour transmettre les alarmes aux diffrents centres officiels (exemple 3.4).
En effet, plusieurs services peuvent transiter sur un mme rseau IP. Dans ce cas prcis, la
socit en question devient elle-mme oprateur d'alarme au sens des Directives
Organisationnelles.
Le serveur d'alarme (ou systme de gestion des alarmes) peut tre situ l'intrieur mme de
l'entreprise, lui permettant de traiter les critres techniques ncessaire au bon fonctionnement de
l'entreprise et de ses installations. Il est galement envisageable de confier cette tche un
prestataire externe (exemple 3.3). Dans ce cas, le prestataire externe reoit et traite les alarmes
techniques, mais ne gre pas administrativement les clients (raccordements).
Les transmetteurs envoient leurs informations l'Oprateur, au(x) Centre(s) de traitement officiels
ou au Systme de gestion des alarmes (d'aprs les exemples en dessus), les critres techniques
sont traits sur place. En ce qui concerne les critres tactiques, un renvoi automatique doit tre
effectu vers le centre officiel correspondant.

Complment technique la Rgle de prescription Page 10/27

Version 1.5 Dcembre 2009
 4 Principe et squence de la transmission

Le schma suivant illustre le cas dune centrale domestique multifonctions qui transmet ses
vnements par des contacts secs ou par RS232 un transmetteur qui gnre les datagrammes
correspondants et les envoie au(x) destinataire(s) respectif(s) dans le format appropri :

1 = feu -> FA
2 = inondation -> WA
3 = effraction -> BA
4 = pas utilis Adresses IP
publique et
2 dynamique IP fixe publique

1
pt
C-0 9 cr y
[1] [2] D
3 [3'] D
C-09
cryp
t
[2'] DC-0
9 crypt
IP fixe publique
Centrale
domestique

Critres feu -> IP Rcepteur pompier Si critres pompiers:

Critres eau -> IP Rcepteur pompier IP fixe publique
Critres effraction -> IP Rcepteur autre
Critres techniques -> IP Rcepteur autre

Y compris adresses d'escalation:

si pas OK (R1, R2, ..)

Partie client Partie centres officiels / oprateurs

[1] : Message en sortie de la centrale domestique, par contacts ou via RS232, protocoles
divers.
[2] : Message format en DC-09, encapsul dans un datagramme IP et crypt: choix du centre
officiel (prescripteur).
[2] : Mme message que [2], mais renvoy au rcepteur redondant, car aucune rponse du
systme de rception Rcepteur 1 na t obtenue.
[3] : Mme message que [2] (et [2']) mais renvoy sur une voie alternative, car aucune rponse
des systmes de rception sur la voie primaire n' t obtenue.
[3] : Mme message que [3], mais renvoy au rcepteur redondant sur une voie alternative, car
aucune rponse du systme de rception Rcepteur 1 na t obtenue.

Complment technique la Rgle de prescription Page 11/27

Version 1.5 Dcembre 2009
[4] : Message en format autre, protocole selon oprateur, doit respecter les directives du
prescripteur pour les critres transfrer (critres pompiers).
[4']: Mme message que [4], mais renvoy au rcepteur sur une voie alternative, car aucune
rponse du systme de rception Rcepteur 1 na t obtenue.
Message [4] retransmis automatiquement par loprateur dalarmes, car lalarme
concerne est une alarme tactique traite par le centre officiel.
La retransmission n'est pas reprsente, mais respecte le mme squencement que
prcdemment: [2], [2'], [3] et [3'].

Remarques:
Le squencement prsent est valable pour une alarme Feu.
Si l'Oprateur d'alarmes reois et traite les alarmes Effraction ou les critres techniques, savoir
pannes de la centrale domestique, dconnection du transmetteur, informations techniques sur
l'tat des systmes du btiment, ces alarmes sont traites sur place et aucune retransmission n'a
lieue.

L'Oprateur d'alarmes peut avoir la fonction de:

Centre de transit pour tout les types d'alarme (Feu, Effraction et technique) : reois toutes les
alarmes, traite une partie d'entre elle et retransmet de manire automatique si besoin est.
Dans ce cas, il gre administrativement les clients.
Centre de rception et traitement : reois et traite uniquement les alarmes Effraction et/ou
technique.

Dans le premier cas, le centre de transit a, la fois une fonction d'Oprateur d'alarme et de
gestionnaire administratif des clients (raccordements). Dans le deuxime cas, l'Oprateur
d'alarmes est uniquement un centre de traitement des alarmes, il ne s'occupe pas de la gestion
administrative des clients et de leurs raccordements.

Complment technique la Rgle de prescription Page 12/27

Version 1.5 Dcembre 2009
 5 Paramtres requis et optionnels

Paramtres requis et optionnels selon Rgle de prescription et correspondance avec le standard DC-09 ou autre.
DC-09 DC-09 Longueur /
Paramtres requis (cf. Rgle, 6.2.1) Autre Commentaire
de base extension format
Numro d'vnement, unique seq 4 chiffres Un numro par vnement (0001-9999)
Identifiant de message (incrmental) data
Critre dalarme: feu | pollution | effraction | etc. data 2-3 car. hex Caractres hexadcimaux 0-9, A-F
Gre par rcepteur selon code de
Priorit: haute | normale | basse (P0 | P1 | P2) Pas transmis
critre
Etat de lalarme: active | quittance | rtablie | TEST data Code de critre spcifique
Adresse IP de lmetteur En-tte IP
Adresse IP du destinataire En-tte IP
Identifiant du transmetteur (p.ex. n de srie) #acct #+3-16 car. hex Ev. reprise du n AlarmNet (si existant)
Format d'origine du message (cf. formats approuvs) "id" cf. DC-07 SIA-DCS selon liste du prescripteur
Date et heure de l'vnement x.data 20 caractres Format _HH:MM:SS,MM-DD-YYYY
Date et heure de transmission timestamp 20 caractres Format _HH:MM:SS,MM-DD-YYYY
DC-09 DC-09 Longueur /
Paramtres optionnels (cf. Rgle, 6.2.2) Autre Commentaire
de base extension format
Port source (metteur) En-tte TCP/UDP Paramtrable
Port de destination (destinataire) En-tte TCP/UDP Paramtrable
Adresse MAC du transmetteur x.data Mxxxx M+12 car. hex Prvu pour contrle de substitution
Identifiant du destinataire Rrcvr R+1-6 car. hex (pas utilis)
Texte de lalarme (description ou commentaire) x.data Iccc..cc I+c caractres Directive du prescripteur (I pourr Info)
Nom du site d'o provient l'alarme (texte ou code) x.data Sccc..cc S+c caractres Directive du prescripteur (S pour Site)
Btiment d'o provient l'alarme (texte ou code) x.data Occc..cc O+c caractres Directive du prescripteur (O pour Object)
Directive du prescripteur (L pour
Lieu du site d'o provient l'alarme (texte ou code) x.data Qccc..cc L+c caractres
Location)
Local d'o provient l'alarme (code alphanumrique) x.data Rccc..cc R+c caractres Directive du prescripteur (R pour Room)
Dclencheur dalarme (n dtecteur ou poussoir) x.data Tccc..cc T+c caractres Directive du prescripteur (T pour Trigger)
Coordonnes x (115000 205000) x.data Xnnnnnn X+6 chiffres Directive du prescripteur
Coordonnes y (490000 590000) x.data Ynnnnnn Y+6 chiffres Directive du prescripteur
Coordonnes z (altitude) x.data Znnnn Z+1-4 chiffres Directive du prescripteur

Complment technique la Rgle de prescription Page 13/27

Version 1.5 Dcembre 2009
Information du type dalarme (pompiers | police | technique):
Le type dalarme sera dduit du code de critre, mais linformation ne sera pas transmise pour
viter dventuelles incohrences.

Information de priorit:
Conformment au point 4.6 de la rgle de prescription, les messages dalarme sont prioritaires par
rapport aux autres informations.
Cette exigence sapplique avant tout au systme de rception (CSR) qui doit traiter les alarmes
avant le reste. La gestion de la priorit nest pas requise au niveau du transmetteur (TR) compte
tenu du temps trs court lors dun envoi squentiel et de la faible probabilit de survenance
simultane dun critre dalarme (urgent) et dun critre technique (non urgent). La priorit sera
dtermine par le systme de rception en fonction du code de critre transmis mais aucune
information de priorit (code ou texte) ne sera transmise pour viter dventuelles incohrences.

Information de voie de transmission utilise:

Mme chose pour linformation de voie de transmission utilise, qui na pas besoin dtre
transmise. Elle sera dtecte par le TR et le systme de rception.

Informations supplmentaires (optionnelles, cf. Rgle, section 6.2.2):

Les informations ci-aprs, peuvent tre transmises optionnellement ou sur exigence expresse de
lAutorit comptente (liste non exhaustive):
Adresse texte de lmetteur ou identifiant, peut tre directement tire de la base de donnes
selon le numro de dossier.
Image, audio et/ou vido associe un vnement, pour la leve de doute dans le cas
dobjets prsentant des risques accrus, notamment pour les tablissements publics ou trs
frquents, ou encore des ouvrages difficiles daccs (par exemple les tunnels).
Informations complmentaires, notamment des descriptifs et tats de stock pour des locaux
abritant des matires dangereuses.

Complment technique la Rgle de prescription Page 14/27

Version 1.5 Dcembre 2009
 6 Types de messages

6.1 Messages dvnement (alarme feu)

Transmis gnralement par le transmetteur client (PE Premises Equipment).
Syntaxe pour les messages dvnement, selon ANSI/SIA DC-09:2007 (transmis sans saut de
ligne):

<LF><CRC><0LLL>
<"id"><seq><Rrcvr><Lpref><#acct>[<pad>|data][x.data]<timestamp>
<CR>

LF Caractre ASCII Line Feed (0A en hexadcimal).

CRC Contrle de redondance cyclique (somme de contrle, voir plus bas).
LLL Longueur du message (3 digits hexadcimaux, prcds par le caractre zro).
"id" Code identifiant le format dentre (cf. Token dans DC-07-2001.04).
seq Numro de squence (0001-9999, pas incrment lors dun renvoi).
rcvr Identifiant du rcepteur, si utilis (1-6 digits hexadcimaux, prcds dun R).
pref Prfixe (1-6 digits hexadcimaux, prcds dun L).
acct Identifiant du transmetteur (3-16 digits hexadcimaux, prcds par un #).
pad Caractres de remplissage (uniquement quand le message est crypt).
data Champ de donnes, libre, sans limite de longueur, syntaxe selon format dentre.
x.data Paramtre dextension, identifiable par la balise suivant le caractre [ .
Sa valeur est le texte compris entre la balise et le crochet de fermeture ] .
timestamp Horodatage, heure de transmission du message, requis si le message est crypt
(20 caractres, format "_HH:MM:SS,MM-DD-YYYY")
CR Caractre ASCII Carriage Return (0D en hexadcimal)

Le contrle de redondance cyclique (CRC) permet de dtecter les erreurs de transmission par ajout
de redondance (somme de contrle). Le CRC est calcul avant et aprs la transmission ou
duplication, puis compar pour s'assurer que cest le mme.
Pour les messages crypts, le CRC est calcul aprs le cryptage du message (donnes et
horodatage).
En cas de renvoi, le message est r-encrypt avec lhorodatage mis jour.
Flag de cryptage: Lorsque les donnes et lhorodatage sont crypts, un astrisque (*) est insr
dans le code de format dentre ("id"), aprs le 1er guillemet. Exemple: "*SIA-DCS".
Le numro de squence 0000 est rserv pour les messages de supervision (NULL) et NAK.

Le prfixe, requis dans la syntaxe DC-09, consiste en 1 6 caractres hexadcimaux prcds

dun L. Selon directive du prescripteur, les 2 premiers caractres suivant le L identifient loprateur
dalarmes. Les 4 caractres suivants sont optionnels (utilisation future). Les identifiants
doprateurs sont attribus par le prescripteur, dentente avec les oprateurs concerns.

Complment technique la Rgle de prescription Page 15/27

Version 1.5 Dcembre 2009
 6.1.1 Prcisions sur le champ data
Dans le champ data, les donnes utiles du message sont celles qui suivent le caractre | .
Dans ce champ, des balises spcifiques ( qualifiers ) sont utilises pour identifier les
informations.
Ces balises diffrent selon le format dentre dfini dans le champ "id" (cf. DC-07-2001.04).
En format SIA le qualifier pour un nouveau message est N .
Exemple:
Nouveau message, alarme eau (WA), zone 3 (format SIA-DCS) :
|NWA0003]
<x0D>

6.1.2 Prcisions sur les champs x.data

Les paramtres dextension (x.data) sont utiliss pour transmettre les diffrents paramtres
optionnels.
Ces paramtres sont cods selon la syntaxe [Xccc...cc] o X est la balise didentification
du paramtre (cf. 6.1.3) et ccc...cc sa valeur (texte de longueur variable compris entre la balise
et le crochet de fermeture). Cette syntaxe sapplique chaque paramtre dextension.
Les paramtres dextension peuvent ainsi tre mis la suite lun de lautre, dans nimporte quel
ordre, chaque paramtre tant identifi par une balise univoque. La syntaxe
<[><balise><valeur><]> doit tre respecte pour chacun de ces paramtres.
La chane <valeur> ne doit pas contenir les caractres [ , | ou ] .

6.1.3 Balises dfinies pour les champs x.data

Balises rserves dans le standard DC-09 (en gras) ou par le prescripteur pour les champs
dextension (selon DC-09 seules les lettres G Z sont utilisables) :

Balise Affectation Format/longueur du champ

G
H Heure de survenance dun vnement Format _HH:MM:SS,MM-DD-YYYY
I Description (Information) C caractres, longueur variable
J
K
L Lieu ou tage (Location) C caractres, longueur variable
M Adresse MAC 12 caractres hexa
N
O Btiment (Object) C caractres, longueur variable
P Donnes de Programmation Libre (usage futur)
Q
R Local (Room) C caractres, longueur variable
S Site ou campus (p.ex. EPFL) C caractres, longueur variable
T Dclencheur dalarme (Trigger) C caractres, longueur variable
U
V Donnes de Validation Libre (usage futur)
W
X Coordonnes X 6 chiffres (115000 205000)
Y Coordonnes Y 6 chiffres (490000 590000)
Z Altitude (Z) ou numro dtage 1-4 chiffres
Note:
Les champs dextension descriptifs, ayant pour valeur des chanes de caractres de longueur
variable, peuvent contenir des caractres accentus (ASCII 8 bits doit tre support).

Complment technique la Rgle de prescription Page 16/27

Version 1.5 Dcembre 2009
 6.1.4 Dclencheur dalarme (Trigger)
Le dclencheur dalarme peut tre un dtecteur automatique (p.ex. dtecteur feu, fume, gaz, eau,
etc.), semi-automatique (p.ex. sonde de temprature, dhumidit ou de pression, contact, etc.) ou
un dclencheur manuel (p.ex. poussoir dalarme).
Le dclencheur est identifi par une balise de type (B), suivie dun identifiant alphanumrique de
longueur libre (syntaxe: [TBident] ). Les balises de type suivantes ont t dfinies par le
prescripteur:
Balise Affectation Type
F Dtecteur feu / fume (Fire) Automatique
G Dtecteur Gaz (Gas) Automatique
W Dtecteur eau / inondation (Water) Automatique
S Sonde (temp. / humid. / pression) Semi-automatique
C Contact (effraction ou autre) Semi-automatique
M Dclencheur Manuel (p.ex. poussoir) Manuel

Syntaxe :
<data>][Xnnnnnn][Ynnnnnn][Snom_du_site][Onom_du_btiment][Llieu][Rlocal]
[TBident][Itexte_descriptif][H_ HH:MM:SS,MM-DD-YYYY]
<x0D>

Exemple :
Message dvnement avec, comme paramtres optionnels, les coordonnes gographiques
(533475/152263), le nom du site (EPFL), le btiment (Odyssea), le lieu (02 2me tage), le local
(B-205), le dclencheur dalarme (dtecteur gaz n003), la description de lvnement /
commentaire (texte descriptif) et lheure de survenance:
<data>][X152263][Y533475][SEPFL][OOdyssea][L02][RB-205]
[TG003][Itexte_descriptif][H_13:14:15,11-20-2008]
<x0D>

Complment technique la Rgle de prescription Page 17/27

Version 1.5 Dcembre 2009
 6.1.5 Arborescence Synthse

Dans cette arborescence, le Lieu peut tre assimil une Zone (par exemple administrative ou
technique), un dpartement ou un tage. C'est le niveau de granularit intermdiaire entre le
Btiment et le Local.
Dans lexemple ci-dessus, l'affectation des locaux de la Zone Technique (par exemple dpt de
solvants) requiert des critres spcifiques (alarme chimique,), inutiles pour la Zone
Administrative (par exemple bureaux).
Si lon ne dispose que d'un seul critre gnrique pour l'alarme pompiers (feu, gaz, inondation,
chimique,), le critre dominant sera considr, mais les moyens engags pourraient tre
survalus.

Complment technique la Rgle de prescription Page 18/27

Version 1.5 Dcembre 2009
 6.1.6 Exemples de message en DC-09 (selon ANSI/SIA DC-09:2007)
Dans les exemples suivants, les paramtres ci-aprs sont utiliss:
CRC: XXXX (appliqu sur la portion de donnes cryptes)
seq: 9876
rcvr: - (pas utilis dans les exemples suivants)
pref: 789ABC (les 2 premiers digits identifient loprateur dalarmes)
acct: 12345A

Cas 1 : alarme feu, zone 129, format SIA DCS, crypt, avec horodatage
<x0A>XXXX007D
"*SIA-DCS"9876L789ABC#12345A
[<x44179D26F6D423A6569543>|#12345A|NFA0129]_13:14:15,11-20-2008<x0D>

Dans cet exemple, le datagramme est reprsent avant le cryptage du texte compris entre le "["
douverture et le <x0D> de fermeture. La portion de texte crypter est surligne en gris. On
retrouve lidentifiant (acct), le N qui indique que cest un nouveau message, le code de critre (FA,
Fire Alarm), la zone (0129) et lhorodatage. Le message tant crypt, 11 octets de remplissage
sont rajouts. Le longueur du paquet (7D) est donne aprs cryptage.

Cas 2 : alarme intrusion, zone 65, format SIA DCS, non crypt, avec adresse MAC
<x0A>8580003B
"SIA-DCS"9876L789ABC#12345A
[#12345A|NBA0065][M1234567890AB]<x0D>

Dans cet exemple, le N indique que cest un nouveau message; il est suivi du code dalarme
cambriolage (Burglary Alarm, BA en format SIA), du numro de zone, cod sur 4 chiffres (0065) et
de ladresse MAC la suite du M dans le champ dextension. Il ninclut pas dhorodatage et pas de
caractres de remplissage (message non crypt).

Dans les exemples ci-dessus, la zone qui suit le code de critre, fait rfrence ladresse de
contact telle que dfinie sous 2.5.

Complment technique la Rgle de prescription Page 19/27

Version 1.5 Dcembre 2009
 6.2 Messages de quittancement
Transmis gnralement par le systme de rception (CSR, Central Station Receiver).
Le quittancement renvoy accuse uniquement la rception du message transmis, ce nest en
aucun cas un quittancement oprationnel (typiquement, de prise en charge, dfini dans un
systme daide lengagement en aval du processus ou dans tout autre systme suprieur).

6.2.1 Quittancement positif (ACK)

Lorsquun message reu est valid (somme de contrle vrifie et critre connu et support) le
systme rpond par un quittancement positif (ACK). Syntaxe selon ANSI/SIA DC-09:2007:

<LF><CRC><0LLL>
<"ACK"><seq><Rrcvr><Lpref><#acct>[]
<CR>

Exemple :
<x0A>D6F30019
"ACK"9876L789ABC#12345A
[]<x0D>

Si le systme rpond positivement un message crypt, le quittancement ACK est galement

crypt :

<LF><CRC><0LLL>
<"*ACK"><seq><Rrcvr><Lpref><#acct>[<pad>]<timestamp>
<CR>

Exemple :
<x0A>XXXX0059
"*ACK"9876L789ABC#12345A
[<x125A88A46F0E48DE8E68C3>]_13:14:15,11-20-2008<x0D>

Complment technique la Rgle de prescription Page 20/27

Version 1.5 Dcembre 2009
 6.2.2 Quittancement ngatif (NAK)
Si la somme de contrle dun message reu diffre de celle dorigine (transmise avec le message),
le rcepteur renvoie une quittance ngative (NAK) au transmetteur pour quil renvoie le message.
De mme, si lheure de transmission transmise dans un message horodat dpasse la tolrance
de dcalage admise (+20s/-40s) par rapport lheure du rcepteur, ce dernier rpond par un
quittancement ngatif, avec un horodatage de rfrence pour que le transmetteur ajuste son
horloge interne:

<LF><CRC><0LLL>
<"NAK"><0000><R0><L0><A0>[]<timestamp>
<CR>

Le message NAK a toujours le numro de squence 0000 et nest jamais crypt.

Exemple :
<x0A>2F780025
"NAK"0000R0L0A0
[]_11:11:38,12-14-2009<x0D>

6.2.3 Quittancement dincapacit (DUH)

Si le rcepteur reoit un message correctement structur mais ne sait pas comment le traiter, il
rpond par un quittancement dincapacit (DUH, Data Unable to Handle):

<LF><CRC><0LLL>
<"DUH"><seq><Rrcvr><Lpref><#acct>[]
<CR>

Le message DUH nest jamais crypt.

Exemple :
<x0A>05C90019
"DUH"9876L789ABC#12345A
[]<x0D>

Complment technique la Rgle de prescription Page 21/27

Version 1.5 Dcembre 2009
 6.2.4 Messages de supervision (NULL)
Le transmetteur et/ou le systme de rception peuvent tre configurs pour vrifier
priodiquement la connexion par lenvoi dun message de supervision (NULL). Le destinataire est
suppos rpondre par un quittancement positif (ACK) dans un intervalle de temps donn. cf. SIA
DC-09:2007, section 5.5.2.

<LF><CRC><0LLL>
<"NULL"><0000><Rrcvr><Lpref><#acct>[]<timestamp>
<CR>

Les messages NULL ont toujours le numro de squence 0000.

Lhorodatage (timestamp) est optionnel pour les messages NULL non crypts.

Exemple :
<x0A>3DCD001A
"NULL"0000L789ABC#12345A
[]<x0D>

Cas dun message de supervision crypt :

<LF><CRC><0LLL>
<"*NULL"><0000><Rrcvr><Lpref><#acct>[<pad>]<timestamp>
<CR>

Lhorodatage (timestamp) est requis pour les messages NULL crypts.

Exemple :
<x0A>XXXX005A
"*NULL"0000L789ABC#12345A
[<x6EC1C9C4C7B43FBD8D1D72>]_13:14:15,11-20-2008<x0D>

Complment technique la Rgle de prescription Page 22/27

Version 1.5 Dcembre 2009
 7 Envoi de commande

Ce chapitre dcrit lenvoi de commandes du centre de rception (CSR ou CT) au transmetteur

(TR), pour des applications de gestion distance (p.ex. commande douverture, de fermeture de
vannes, dverrouillage de porte distance, activation dun signal optique ou sonore sur le site
distant, tlgestion, maintenance distance, etc.).
La Rgle dfinit des commandes simples et volues. Les commandes simples sont traites dans
ce document. Les commandes dites volues, sont utilises pour de la tlgestion, soit par
exemple, pour la mise jour logicielle du transmetteur, ou encore la demande d'informations
permettant une leve de doute. Elles sont gnralement utilises par les oprateurs d'alarmes
pour la maintenance des transmetteurs, et dans certains cas, pour effectuer une leve de doute.
Dans ce sens, le prescripteur part du principe que les commandes volues sont du ressort de
l'oprateur d'alarme; mais le prescripteur se rserve nanmoins le droit de les exiger pour
effectuer une leve de doute. Les commandes simples restent requises au niveau du transmetteur
et du rcepteur.

7.1 Commandes simples

Les commandes simples sont envoyes par le rcepteur au transmetteur la place d'un message
d'acquittement (ACK) provoqu par un polling ou un message d'alarme. Pour ce faire, c'est le
paquet DC-09 RSP qui est utilis. Par consquent le paquet RSP doit tre considr par le
transmetteur comme un ACK. La syntaxe de ce paquet est la suivante:

<LF><CRC><0LLL>
<"RSP"><seq><Rrcvr><Lpref><#acct>[rsp.data]
<CR>

Si le message de polling ou d'alarme est crypt, le paquet RSP le sera:

<LF><CRC><0LLL>
<"*RSP"><seq><Rrcvr><Lpref><#acct>[<pad>rsp.data]<timestamp>
<CR>

rsp.data correspond :
#acct|NZZCCnnnn
Avec:
N Pour nouveau message
ZZ Code de critre fixe, indiquant l'envoi d'une commande.
CC Code de critre correspondant au type d'action, suivant la liste du prescripteur.
nnnn Numro de zone (correspond au numro du contact physique).

Par exemple, non crypt:

<x0A>A3AF002A
"RSP"9876L789ABC#12345A
[#12345A|NZZRC0065]<x0D>

Complment technique la Rgle de prescription Page 23/27

Version 1.5 Dcembre 2009
Par exemple, crypt (avant cryptage):
<x0A>XXXX0079
"*RSP"9876L789ABC#12345A
[<x29B43891FF0C3AA69E>|#12345A|NZZRC0065]_13:14:15,11-20-2008
<x0D>

Dans ces exemples, le code de critre RC est utilis pour la fermeture d'un relais. Le ZZ indique
une commande, le transmetteur doit fermer le relais correspondant au contact 0065.
Dans le deuxime exemple, c'est la partie grise qui est crypte, soit le message qui dbute par
du remplissage, et fini par l'horodatage.

7.2 Processus denvoi de la commande et de quittancement

En cas denvoi de commandes, le message de quittancement (ACK) est remplac par le message
de commande (RSP). Le transmetteur doit considrer le polling (ou l'alarme) quittanc en recevant
le RSP.

Ensuite, le transmetteur doit quittancer la bonne rception du message et le changement d'tat

demand par le rcepteur. Pour ce faire, il envoie un message d'alarme, avec comme code de
critre le code utilis pour la commande (par exemple RC).
Finalement, le rcepteur envoie un message d'acquittement en fonction (ACK, DUH, NULL),
puisque la validation de la commande envoye par le transmetteur est un message d'alarme
standard.

Complment technique la Rgle de prescription Page 24/27

Version 1.5 Dcembre 2009
 8 Scnarii

Les scnarii ci-aprs illustrent les diffrents cas de figure entre la transmission dun vnement par
un transmetteur client et les diverses possibilits de quittancement par le rcepteur, ainsi que le
contrle de ligne et lenvoi de commandes.

8.1 Scnario 1 Alarme feu envoye au CTA et ACK

Message alarme feu envoy au CTA en DC-09 (crypt, selon choix du prescripteur).
Quittance ACK (OK, crypt car en rponse un message crypt).

Droulement
temporel

8.1.1 Escalade en cas de non rponse

8.2 Scnario 2 Message avec code non support et DUH

Message vnement avec code de critre non support ou inconnu, adress au CTA (non
crypt).
Quittance DUH (pas support / pas connu, jamais crypt).

Complment technique la Rgle de prescription Page 25/27

Version 1.5 Dcembre 2009
 8.3 Scnario 3 Message avec horodatage incorrect et NAK
Message de supervision (polling, horodat) / test de ligne depuis le transmetteur (NULL).
Horodatage incorrect -> quittance NAK (PAS OK, jamais crypt) avec heure de rfrence.

8.4 Scnario 4 Alarme inondation au CTA via centre de transit

Message alarme inondation adress au CT en format conforme, puis relay au CTA en DC-
09:

8.5 Scnario 5 Commandes distance

Message de supervision (polling, horodat) / test de ligne depuis le transmetteur (NULL).
Commande de fermeture de contact depuis le systme de rception (RSP).
Quittance ACK.

Complment technique la Rgle de prescription Page 26/27

Version 1.5 Dcembre 2009
 9 En-ttes IP, TCP et UDP

Ce chapitre permet de situer certains paramtres requis ou optionnels de la rgle de prescription

(selon chapitre 5 du prsent document), qui ne figurent pas dans le datagramme DC-09 mais dans
les en-ttes IP, TCP ou UDP, ncessaires au transport de linformation sur IP.

9.1 En-tte IP

Le champ Protocole indique, en dcimal, le protocole utilis (6=TCP, 17=UDP)

La somme de contrle de l'en-tte IP, code sur 16 bits, permet de contrler l'intgrit de l'en-
tte afin de dterminer si celui-ci n'a pas t altr pendant la transmission.

9.2 En-tte TCP

URG: si ce flag est 1 le paquet doit tre trait de faon prioritaire.

La somme de contrle de l'en-tte TCP (checksum), code sur 16 bits, applique aux champs de
donnes de l'en-tte, permet de vrifier l'intgrit de l'en-tte.

9.3 En-tte UDP

Le port de destination est dfini par loprateur dalarmes (pour TCP et UDP).

Complment technique la Rgle de prescription Page 27/27

Version 1.5 Dcembre 2009