 |
Intégration de l’information géographique dans le traitement de l’alerte, la démarche du SDIS 89
0) Introduction, contexte et objectifs | | |
| | 0.1) présentation du SDIS de l’Yonne |
Le SDIS de l’Yonne est un Etablissement Public Local chargé de gérer l’ensemble des moyens et des opérations des services d’incendie et de secours du département de l’Yonne.
Composé d’un corps départemental comprenant 2200 sapeurs-pompiers volontaires, 270 sapeurs-pompiers professionnels et 70 Personnels Administratifs et Technique, il est réparti sur 34 centres de secours, trois groupements territoriaux et une direction. Il est intervenu 26710 fois durant l’année 2007.
En 2005, le SDIS de l’Yonne ne disposait que de cartes hétérogènes produites par les différents centres de secours avec les moyens dont ils disposaient. Face à des besoins opérationnels croissant, à une augmentation de la mobilité des personnels SP et aux exigences réglementaires, le Conseil d’Administration du SDIS a validé le projet de mise en œuvre du SIG.
Le déploiement initial est prévu sur trois années avec comme objectifs de :
- fournir aux centres de secours l’ensemble des cartes papier nécessaires aux interventions,
- mettre en œuvre un outil SIG couplé au logiciel de traitement de l’alerte,
- fournir des analyses spatiales des besoins et la réponse opérationnelle sur le département afin d’optimiser la répartition des secours,
- fournir aux communes les éléments nécessaires à l’étude de leur défense incendie.
 | | Utilisations du SIG au SDIS de l’Yonne |
La démarche adoptée par le SDIS de l’Yonne est une démarche de gestion intégrée, centralisée et participative de l’information géographique et ce dans un contexte d’amélioration continue.
Intégrée puisque l’on va identifier et formaliser les circuits d’informations : qui détient quelle informations à partir de quel moment selon quelle source afin d’intégrer la gestion de l’information aux procédures existantes. Une rationalisation de ses circuits permet d’augmenter l’efficacité du traitement de données tout en minimisant les risques.
Centralisée en travaillant sur une base de données unique et cohérente. Ce stockage est réalisé à l’aide d’une base ArcSDE dont le maintien de l’intégrité est assuré par l’administrateur SIG.
Participative puisque l’on adapte les outils et les procédures aux différents besoins et méthodes existants au lieu de former les utilisateurs sur des produits complets. Ces outils et procédures évoluent par la suite dans une démarche d’amélioration continue à laquelle les utilisateurs sont impliqués.
Pour mettre en œuvre cette démarche et répondre à l’ensemble de ses besoins en terme de cartographie et d’information géographique, le SDIS de l’Yonne s’appuie sur :
- un serveur SDE,
- une licence ArcEditor flottante pour les fonctions d’administration et de mise à jour des données,
- des clients ArcReader pour tout ce qui est visualisation simple des données,
- des clients ArcEngine pour l’ensemble des applications spécifiques de gestion d’informations, consultation ou utilisation (gestion des hydrants, traitement de l’alerte).
En 2006, Le SDIS a donc débuté ce projet en intégrant les informations dont il disposait.
Dès le départ, le SDIS s’est orienté vers une architecture centralisée afin de rationaliser la gestion des informations. En effet, il est indispensable que tous les maillons de la chaine des secours disposent d’une cartographie uniforme dans des versions identiques. De plus, cela permet de mettre en œuvre une démarche qualité autour de la gestion des données avec la définition de circuits rationalisés de gestion d’informations.
En 2007, les premières cartographies papier ont été remises aux centres de secours et le couplage avec le logiciel d’alerte à été entamé au niveau des données avec la mise en cohérence des bases de données alerte/SIG et la validation des fonctions et du comportement du futur logiciel SIG couplé à l’alerte.
En 2008, une première version de l’ensemble des cartes au 1/25000 et au 1/5000 a été remise aux centres de secours afin de vérifier que l’ensemble des informations y figurent et d’ajouter les informations opérationnelles manquantes. Parallèlement, le logiciel SIG couplé au logiciel de traitement de l’alerte à été développé.
|
1) Gestion des informations | | |
| |
1.1) La gestion des informations concernant les hydrants |
Les besoins d’informations concernant la défense incendie sont nombreux et leurs sources multiples :
- le CTA-CODIS doit disposer des indisponibilités de défense incendie afin de pouvoir engager des moyens supplémentaires le cas échéant,
- les services prévision pour le suivi des tournées de vérification des hydrants et l’étude de la défense incendie des communes,
- les services prévention pour instruire les permis de lotir et de construire,
- l’ensemble de l’opérationnel pour la production des atlas parcellaires.
Les points d’entrées des informations identifiés sont :
- les centres de secours lors des visites annuelles de contrôle,
- les communes qui sont responsables de leur défense incendie, de l’entretien et de l’implantation des hydrants,
- les sociétés fermières qui sont responsables du maintien en eau des réseaux d’adduction.
L’organisation territoriale et fonctionnelle du SDIS de l’Yonne compte dans chacun des trois groupements territoriaux un service prévision qui assure le suivi des vérifications périodiques des hydrants. Ce sont ces services qui disposent historiquement des informations et qui sont en relation avec les centres de secours, les mairies et les sociétés fermières concernant les questions de défense incendie. De plus, ce sont eux qui assurent le suivi des vérifications annuelles des hydrants réalisées par les centres de secours.
Par ailleurs, le CTA-CODIS est le seul service à maintenir une activité opérationnelle 24h/24h tout au long de l’année. Les indisponibilités pouvant survenir à n’importe quel moment, ce sera lui qui gérera en temps réel ces indisponibilités ponctuelles.
L’identification des informations nécessaires aux différents services, de leurs points d’entrée et de leurs utilisations a permis d’établir des circuits de gestion des informations afin de rationnaliser cette dernière et d’assurer le maintien d’une information complète et à jour.
Deux circuits ont été formalisés en s’appuyant sur les besoins, les points d’entrée, les méthodes et les données existantes :
- l’un concerne l’évolution du parc d’hydrants (ajout, suppression, modification)
- l’autre concerne la gestion de la disponibilité de la défense incendie.
| | Synoptique de la gestion des informations concernant les indisponibilités d’hydrants |
| | Synoptique de la gestion des informations concernant l’évolution de la défense incendie |
| | Présentation des éléments entrant en compte dans la gestion et l’utilisation des informations concernant les hydrants (la zone rosée comprend les utilisations et la zone bleutée la gestion d’informations) |
1.2) Descriptif des applications intervenant dans le processus de gestion des informations relatives aux hydrants |
Les circuits de gestion de données ainsi établis ont permis de définir, développer et mettre en place les applications nécessaires à leur mise en œuvre.
1) L’interface HYDRAYONNE (asp.net) alimente la base de données SDIS des informations alphanumériques concernant les hydrants.
Elle permet la création, la modification et la suppression des informations fixes (adresse, numéro, commune…) ainsi que l’ensemble des informations relatives aux tournées de contrôles des hydrants (débits mesurés, anomalies constatées, indisponibilités jusqu'à nouvel ordre) avec un accès sécurisé.
Afin d’intégrer la gestion des informations relatives aux hydrants dans les procédures existantes, l’application suit les principes de l’instruction concernant la vérification des hydrants et édite l’ensemble des documents relatifs aux tournées de vérification (convocation, listes de poteaux par tournée de vérification, comptes-rendus…).
Elle ne comprend pas de volet cartographique mais alimente les données attributaires des hydrants via une connexion SQLSERVER.
2) 3) et 4) GPSHYDRANTS, développé en vb6, permet de rapatrier dans une base Access sur le tablet pc les hydrants non relevés au GPS et parallèlement d’injecter les données issues des relevés GPS dans la base centrale.
Lors de l’import des retours GPS, c’est au prévisionniste du groupement de valider la création de nouveaux hydrants et de valider les informations qui ont pu être modifiées sur les hydrants à relever.
Cette opération permet de garantir l’intégrité des données et de limiter les informations folkloriques.
Les relevés GPS sont réalisés sans interface cartographique mais la qualité du signal est enregistrée afin de pouvoir exclure les valeurs trop aléatoire (dans ce cas l’application informera l’utilisateur qu’il doit réitérer sa mesure), de garder la valeur la moins aléatoire et connaitre son degré d’exactitude.
5) Un dernier type d’information présente un fort intérêt opérationnel.
Il s’agit :
- des indisponibilités prévues à l’avance (le réseau de telle commune sera coupé le 03/10/2008 de 09h00 à 17h00)
- des indisponibilités périodiques (tel hydrant est indisponible tous les jeudis de 09h00 à 12h00 du 01/06/2008 au 01/09/2008).
Un dispositif permettant de saisir les informations dès que l’on en a la connaissance tout en ne passant l’hydrant indisponible qu’aux périodes prévues a été mis en place.
Lors de la saisie de ces types d’indisponibilités dans l’application « Dispohydrant », les données sont stockées dans des tables sql server distinctes en attendant la date de mise en indisponibilité.
6) Toutes les dix minutes, une routine « integreSIG » s’effectue sur le serveur afin de passer indisponible ou disponible les hydrants en fonction de la date courante et des dates saisies par les utilisateurs
|
L’ensemble du cheminement des interfaces à été défini à partir des méthodes de travail et des instructions déjà existantes au SDIS, ce qui a permis une bonne appropriation par les différents utilisateurs et l’intégration des informations déjà existantes sous différentes formes (fichiers excel…)
Cet exemple illustre bien la démarche intégrée, centralisée et participative de l’utilisation et de la gestion des informations géographiques grâce à la base ArcSde-SQLServer2005 centralisée et au développement d’applications sur mesure à l’aide des technologies ArcEngine.
|
2) Intégration de l’information géographique au traitement de l’alerte
| | |
| | 2.1) Présentation du fonctionnement opérationnel CTA-CODIS |
Le CTA-CODIS traite l’ensemble des appels 18-112 du département de l’Yonne et déclenche les moyens adaptés à la demande de secours traitée en fonction de la nature de l’intervention, de son importance et de sa localisation.
Lors du déclenchement d’un centre de secours par la CTA, celui-ci reçoit un ticket de départ récapitulant les informations nécessaires à la bonne conduite de l’opération et les personnels prévus sur le(s) véhicule(s) déclenché(s) sont alertés par des bips.
Le CTA assure ensuite le suivi des moyens pour l’ensemble des interventions du département.
L’interaction SIG/logiciel d’alerte permet d’apporter un certain nombre d’informations opérationnelles du CTA jusqu’au centre de secours et une cohérence entre les informations disponibles aux différents niveaux.
| | Intégration de l’information géographique à la chaine de traitement de l’alerte |
2.2) Présentation de SIGALYONNE |
Le SDIS de l’Yonne dispose d’un nouveau logiciel de traitement de l’alerte dont il est propriétaire. La maitrise de la structure de ce dernier et l’intégration du SIG dès la conception en amont de l’application a permis de coupler une interface SIG à ce logiciel. Les deux applications communiquent par socket sur un port défini.
Les principaux apports de cette dernière sont :
- la localisation en temps réel sur l’adresse saisie par l’opérateur ou remontée par un annuaire inversé. Un bouton permet de désactiver cette fonctionnalité afin de pouvoir suivre une intervention particulière tout en continuant à saisir les autres demandes de secours,
- la levée de doute et la détermination du lieu du sinistre à l’aide de la carte,
- la recherche de coordonnées,
- la localisation d’une intervention en cours,
- l’export de carte sous différents formats afin de pouvoir les transmettre par mail ou de les imprimer,
- la visualisation de l’ensemble des moyens en opération en temps réel,
- l’ajout des coordonnées DFCI, et du (des) planche(s) de l’atlas sur la(les)quelle(s) se situe l’intervention aux tickets de départ,
- l’ajout aux tickets de départ d’informations issues de requête spatiale prédéfinies. Celles-ci sont paramétrables depuis une table dans laquelle on précise le type d’objet recherché, la nature d’intervention concernée, le périmètre de recherche, l’intitulé à inscrire sur le ticket de départ. Ainsi, n’importe quelle nouvelle couche d’information peut servir de base à apporter de nouvelles informations sur les tickets de départ par un simple paramétrage de l’application.
Les informations sur les hydrants précédemment gérées par les différents services sont utilisées en opérationnel avec une mise à jour des informations en temps réel.
Cette application client serveur est installée sur 5 clients qui doivent chacun visualiser en temps réel les actions effectuées sur les autres clients. On s’appuie ici sur des clients ArcEngine et un serveur ArcSDE.
Description de l’architecture générale |
Un Serveur Socket écoute sur un port auquel se connecte chacun des clients CTA (connexion s3-s4) et SIGALYONNE (cnx s2-s4) afin d’avoir les informations envoyées par l’ensemble des postes.
C’est cette partie serveur qui réalise l’ensemble des écritures en base de données suite à la réception de message des clients de l’application CTA et envoie des messages de demande de rafraichissement du contenu de la carte de chacun des clients SIGALYONNE connectés.
Parallèlement, chacun des clients SIGALYONNE se connecte en local avec le client CTA (connexion s1-s2) afin de répercuter au niveau du positionnement dans la carte les actions réalisées sur le client CTA (positionnement sur une adresse lors de sa saisie, positionnement sur une intervention lors de sa sélection dans le logiciel CTA…). Cette fonction peut être inhibée à l’aide d’un bouton dans le cas où l’utilisateur souhaite garder une emprise de carte tout en continuant à traiter diverses interventions depuis le client CTA.
Cette connexion permet également d’envoyer des messages depuis le SIG afin d’appeler des fenêtres du client CTA (demande de renfort sur une intervention, déplacement d’une intervention depuis la cartographie…)
Pour ce qui est de l’affichage, toutes les informations mises à jour en temps réel sont stockées sur le serveur sqlserver ou le serveur sde (dans la version opérationnelle) afin d’avoir les mêmes informations sur tous les postes.
Pour permettre cette interaction, les bases de données de l’alerte et les bases de données SIG ont du être mises en cohérence. L’ensemble des localisations sur SIGALYONNE suite à une action du client CTA s’effectue par un simple passage d’identifiant et par référencement linéaire dans certains cas.
| | Synoptique de l’architecture logicielle CTA-SIGALYONNE |
Le couplage entre les bases de données a été fastidieux notamment pour les adresses et les points remarquables. L’ensemble des nouveaux éléments intégrés par les administrateurs et les opérateurs de saisie sont mis à jour mensuellement dans la base opérationnelle. La fréquence de mise à jour de ces dernières pourra évoluer. Certaines applications restent à étudier pour automatiser l’ensemble du système.
2.3) Parcellaire, tickets et centres de secours |
L’intégration d’informations spécifiques aux tickets de départ à destination des centres de secours permet d’intégrer totalement l’information géographique à la chaine de traitement de l’alerte
Ces informations sont :
- la localisation du sinistre en coordonnée DFCI (200m ou chasse),
- la précision à laquelle le SIG à pu localiser l’alerte en fonction des éléments renseignés (adresse, voie, lieu-dit, commune),
- les noms des planches au 1/5000 et au 1/25000 sur lesquelles se situe le sinistre,
- des informations spécifiques à la nature de l’intervention.
Elles permettent aux sapeurs-pompiers sur le terrain d’établir leur itinéraire à l’aide des atlas dont les pages correspondent à celles mentionnées dans les tickets de départ et de voir dès le départ les contraintes et les moyens existants à proximité du sinistre.
Les atlas dit parcellaire couvrent de manière exhaustive le territoire d’intervention au 1/25000, et au 1/5000 l’ensemble des zones comprenant plusieurs voies nommées sur le territoire d’intervention.
Ils comprennent l’ensemble de la voirie et un certains nombre d’éléments sur l’occupation du sol et les informations spécifiques (établissement recevant du public, hydrant, sites remarquables, accès aux autoroutes…). La charte graphique et les informations qui y sont présentes sont uniformes avec celles de l’application de traitement de l’alerte afin de faciliter le dialogue entre le commandement opérationnel et le personnel sur le terrain.
Les deux exemples présentés permettent de montrer l’intégration de la gestion et de l’utilisation de l’information dans les différents services ainsi que l’intégration de l’information géographique à l’ensemble des niveaux de la chaine de traitement de l’alerte.
|
|
|
