Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Alarmes automatiques Transmissions sécurisées d'alarmes sur IP Complément techn

Alarmes automatiques Transmissions sécurisées d'alarmes sur IP Complément technique à la Règle de prescription Etablissement Cantonal d’Assurance, Division Prévention Avenue du Général Guisan 56│1009 Pully│Téléphone +41 58 721 21 21│prevention@eca-vaud.ch│www.eca-vaud.ch Edition : Etablissement cantonal d'assurance contre l'incendie et les éléments naturels du Canton de Vaud Division Prévention Avenue du général Guisan 56 1009 Pully +41 58 721 21 21 prevention@eca-vaud.ch Décembre 2009 Complément technique à la Règle de prescription Page 3/27 Version 1.5 – Décembre 2009 Etablissement cantonal d'assurance contre Police cantonale Fribourg l'incendie et les éléments naturels du canton de Vaud Transmission sécurisée d'alarmes sur IP Complément technique à la Règle de prescription Ce document a pour objectif de clarifier certains points de la Règle de prescription v1.5 de décembre 2009, potentiellement sujets à interprétation, afin de garantir une implémentation uniforme du protocole DC-09 par les différents constructeurs et assurer l’interopérabilité entre produits. Il permet en outre d’identifier plus clairement les paramètres requis et optionnels décrits dans la règle de prescription, et de les situer soit dans le datagramme DC-09, soit dans les en-têtes IP ou TCP/UDP, voire même pour certains de les déduire d’autres paramètres transmis et donc de les exclure de la transmission elle-même. Plusieurs scénarios sont illustrés entre la transmission d’un événement par un transmetteur client et les diverses possibilités de quittancement par le récepteur, ainsi que le contrôle de ligne et l’envoi de commandes. Ce complément technique est appliqué par les centres officiels de traitement d’alarmes suivants: VD CTA – 118 FR CEA – 112 – 117 – 118 Version 1.5 – Décembre 2009 Cette version remplace et annule toutes les précédentes. Complément technique à la Règle de prescription Page 4/27 Version 1.5 – Décembre 2009 Sommaire 1 Domaine d'application.............................................................................................................6 1.1 Conventions d’écriture........................................................................................................6 1.2 Terminologie.......................................................................................................................6 2 Définitions.................................................................................................................................7 2.1 DC-09 de base ...................................................................................................................7 2.2 DC-09 extensions...............................................................................................................7 2.3 Autre...................................................................................................................................7 2.4 Format d’entrée..................................................................................................................7 2.5 Code de critère...................................................................................................................7 2.6 Cryptage.............................................................................................................................7 3 Architecture..............................................................................................................................8 3.1 Modèle global.....................................................................................................................8 3.2 Exemple d'implémentation n°1...........................................................................................8 3.3 Exemple d'implémentation n°2...........................................................................................9 3.4 Exemple d'implémentation n°3...........................................................................................9 3.5 Remarques générales sur l'implémentation .....................................................................10 4 Principe et séquence de la transmission.............................................................................11 5 Paramètres requis et optionnels ..........................................................................................13 6 Types de messages ...............................................................................................................15 6.1 Messages d’événement (alarme feu)...............................................................................15 6.1.1 Précisions sur le champ data..................................................................................................16 6.1.2 Précisions sur les champs x.data ...........................................................................................16 6.1.3 Balises définies pour les champs x.data ................................................................................16 6.1.4 Déclencheur d’alarme (Trigger)..............................................................................................17 6.1.5 Arborescence – Synthèse.......................................................................................................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 négatif (NAK)..................................................................................................21 6.2.3 Quittancement d’incapacité (DUH) .........................................................................................21 6.2.4 Messages de supervision (NULL) ..........................................................................................22 7 Envoi de commande ..............................................................................................................23 7.1 Commandes simples........................................................................................................23 7.2 Processus d’envoi de la commande et de quittancement................................................24 8 Scénarii ...................................................................................................................................25 8.1 Scénario 1 – Alarme feu envoyée au CTA et ACK...........................................................25 8.1.1 Escalade en cas de non réponse ...........................................................................................25 8.2 Scénario 2 – Message avec code non supporté et DUH .................................................25 8.3 Scénario 3 – Message avec horodatage incorrect et NAK...............................................26 8.4 Scénario 4 – Alarme inondation au CTA via centre de transit..........................................26 8.5 Scénario 5 – Commandes à distance ..............................................................................26 Complément technique à la Règle de prescription Page 5/27 Version 1.5 – Décembre 2009 9 En-têtes IP, TCP et UDP.........................................................................................................27 9.1 En-tête IP .........................................................................................................................27 9.2 En-tête TCP......................................................................................................................27 9.3 En-tête UDP .....................................................................................................................27 Complément technique à la Règle de prescription Page 6/27 Version 1.5 – Décembre 2009 1 Domaine d'application Ce document a pour objectif de clarifier certains points de la Règle de prescription v1.3 de juillet 2009, potentiellement sujets à interprétation, afin de garantir une implémentation uniforme du protocole DC-09 par les différents constructeurs et assurer l’interopérabilité entre produits. Il permet d’identifier plus clairement les paramètres requis et optionnels décrits dans la règle de prescription, et de les situer soit dans le datagramme DC-09, soit dans les en-têtes IP ou TCP/UDP, voire même pour certains de les déduire d’autres paramètres transmis et donc de les exclure de la transmission elle-même. 1.1 Conventions d’écriture Les conventions d’écriture suivantes sont appliquées dans le présent document, dans les différents chapitres décrivant les datagrammes DC-09 : • Si un paramètre est requis il est inscrit en gras. • Les paramètres optionnels sont inscrits en orange. 1.2 Terminologie TR : Transmetteur (ou PE, Premises Equipment). CSR : Système de réception (Central Station Receiver). CTA : Centre de Traitement des Alarmes (centre officiel). CT : Centre de Transit (tous types d’alarmes). Complément technique à la Règle de prescription Page 7/27 Version 1.5 – Décembre 2009 2 Définitions Les définitions suivantes s’appliquent en particulier aux en-têtes de colonnes du tableau du chapitre 5. 2.1 DC-09 de base Paramètres définis du standard ANSI/SIA DC-09:2007 en l’état. 2.2 DC-09 extensions Paramètres transmis dans les champs d’extension de données (x.data). Les données d’extension sont identifiées par des balises spécifiques (cf. 6.1.3). 2.3 Autre Paramètres pas transmis dans les champs de données du datagramme DC-09 mais ailleurs (par exemple dans l’en-tête IP), voire pas transmis du tout mais déduits du code de critère transmis. 2.4 Format d’entrée Format ou codage d’origine des données à transmettre. Le format d’entrée est spécifié dans le champ "id" du datagramme DC-09. Les autres champs sont repris tels quels dans le datagramme DC-09. Important: Pour simplifier l’implémentation, le prescripteur a décidé de ne supporter qu’un seul format d’entrée au niveau de son système de réception, en l’occurrence le format SIA-DCS. Le prescripteur se réserve le droit de supporter ultérieurement d’autres formats d’entrée selon l’évolution des standards. 2.5 Code de critère Code de 2 caractères (pour le SIA-DCS), identifiant un événement spécifique (p.ex. FA, Fire Alarm). Une liste des codes supportés par le prescripteur sera publiée séparément. Le code de critère est suivi d’une adresse sur 4 chiffres (toujours complétée, soit par ex. 0004), appelée "zone", correspondant à l’adresse de contact du code de critère. 2.6 Cryptage Le prescripteur demande que les données qui lui sont adressées soient cryptées. Toutefois, la méthode de cryptage est laissée libre, pour autant que les pré-requis soient respectés (cf. Règle § 6.7.1). Le cryptage doit être fait au niveau des datagrammes DC-09. Dans le cas d'une communication cryptée, le prescripteur ne demande pas de fonction de hachage. Si la transmission est non cryptée, le hachage est obligatoire. Complément technique à la Règle de prescription Page 8/27 Version 1.5 – Décembre 2009 3 Architecture 3.1 Modèle global Le principe global de transmission des alarmes automatiques est présenté sur la figure suivante: Pour obtenir les explications détaillées de cette figure, se référer à la Règle de prescription. 3.2 Exemple d'implémentation n°1 La figure suivante schématise un exemple d'implémentation de la transmission. Ce schéma propose une implémentation possible de la transmission des alarmes automatiques pour une entreprise ne désirant pas effectuer la réception et le traitement des alarmes techniques. Dans ce cas, l'Opérateur propose une solution "clé en main". Transmission via un centre de transit Transmission directe Transmission via un centre de transit Complément technique à la Règle de prescription Page 9/27 Version 1.5 – Décembre 2009 3.3 Exemple d'implémentation n°2 La figure suivante schématise un exemple d'implémentation de la transmission. Ce schéma propose une implémentation possible de la transmission des alarmes automatiques pour une entreprise désirant gérer ces propres transmetteurs, mais mandate une société externe pour effectuer la réception et le traitement des alarmes techniques. 3.4 Exemple d'implémentation n°3 La figure suivante schématise un exemple d'implémentation de la transmission. Ce schéma propose une implémentation possible de la transmission des alarmes automatiques pour une entreprise désirant gérer de bout en bout la transmission des alarmes. Transmission via un centre de transit Transmission directe Transmission via un centre de transit Transmission directe Complément technique à la Règle de prescription Page 10/27 Version 1.5 – Décembre 2009 3.5 Remarques générales sur l'implémentation Dans certains cas, il est tout à fait envisageable que le réseau privé de l'entreprise et ses accès à Internet soient utilisés pour transmettre les alarmes aux différents centres officiels (exemple 3.4). En effet, plusieurs services peuvent transiter sur un même réseau IP. Dans ce cas précis, la société en question devient elle-même opérateur d'alarme au sens des Directives Organisationnelles. Le serveur d'alarme (ou système de gestion des alarmes) peut être situé à l'intérieur même de l'entreprise, lui permettant de traiter les critères techniques nécessaire au bon fonctionnement de l'entreprise et de ses installations. Il est également envisageable de confier cette tâche à un prestataire externe (exemple 3.3). Dans ce cas, le prestataire externe reçoit et traite les alarmes techniques, mais ne gère pas administrativement les clients (raccordements). Les transmetteurs envoient leurs informations à l'Opérateur, au(x) Centre(s) de traitement officiels ou au Système de gestion des alarmes (d'après les exemples en dessus), les critères techniques sont traités sur place. En ce qui concerne les critères tactiques, un renvoi automatique doit être effectué vers le centre officiel correspondant. Complément technique à la Règle de prescription Page 11/27 Version 1.5 – Décembre 2009 4 Principe et séquence de la transmission Le schéma suivant illustre le cas d’une centrale domestique multifonctions qui transmet ses événements par des contacts secs ou par RS232 à un transmetteur qui génère les datagrammes correspondants et les envoie au(x) destinataire(s) respectif(s) dans uploads/Industriel/ complement-technique1-ip-pdf.pdf