Mise à disposition automatique des données sismiques des stations du RAP à partir de détection du réseau ISARD



Documents pareils
Prévention du risque sismique

Smart Notification Management

KWISATZ_TUTO_module_magento novembre 2012 KWISATZ MODULE MAGENTO

Guide de l utilisateur du Centre de gestion des licences en volume LICENCES EN VOLUME MICROSOFT

Préparation d un serveur Apache pour Zend Framework

LES FONCTIONS DE SURVEILLANCE DES FICHIERS

Le filtrage de niveau IP

Surveiller et contrôler vos applications à travers le Web

KWISATZ MODULE PRESTASHOP

Mise en place d un serveur Proxy sous Ubuntu / Debian

Rapport de certification ANSSI-CSPN-2011/14. Fonctionnalités de pare-feu de StoneGate Firewall/VPN build 8069

GenIP 30i : Passerelle intelligente dédiée aux applications industrielles les plus critiques

Le service FTP. M.BOUABID, Page 1 sur 5

Efficace et ciblée : La surveillance des signaux de télévision numérique (2)

Base de données de la sismicité historique de la Nouvelle-Calédonie, Wallis et Futuna et site internet associé

Description pas à pas des différents processus d installation, configuration, saisie des résultats et export des données.

Sync-A-BOX et Duplicati. est une plateforme Cloud pour stocker et gérer vos données en ligne.

Anticiper la gestion d'un séisme dommageable Anticipare la gestione dei danni di un terremoto

ENDPOINT SECURITY FOR MAC BY BITDEFENDER

Cyberclasse L'interface web pas à pas

Les différentes méthodes pour se connecter

Prestations de conseil en SRM (Storage Ressource Management)

DESCRIPTION DE L'ARCHITECTURE et PRESENTATION DES ESPACES DE TRAVAIL

White Paper - Livre Blanc

Sauvegarde de postes clients avec BackupPC

Guide d installation de SugarCRM Open Source version 4.5.1

PageScope Suite L accélérateur de workflow * L essentiel de l image

1 Démarrage de Marionnet

Manuel d utilisation de la plate-forme de gestion de parc UCOPIA. La mobilité à la hauteur des exigences professionnelles

Réparer un disque dur passé en RAW

Guide utilisateur des services WASATIS (Manuel Version 1.1)

Eyes Of Network 4.0. Documentation d installation et de configuration

IBM Tivoli Monitoring, version 6.1

et Active Directory Ajout, modification et suppression de comptes, extraction d adresses pour les listes de diffusion

Logiciel : GLPI Version : SYNCRHONISATION DE GLPI AVEC ACTIVE DIRECTORY. Auteur : Claude SANTERO Config. : Windows 2003.

GER helpdesk permet de traiter et d optimiser la gestion de vos interventions au sein de chaque bureaux.

Formation. Module WEB 4.1. Support de cours

Keyyo Guide de mise en service CTI / API / TAPI Keyyo

Documentation Ellipses Windows. Auteur : Léonard FRECHET Date : 10/01/07 Diffusion : Publique ELLIPSES Envoi Automatisé de SMS Ellipses SMS

Serveur Linux : FTP. Mise en place d un service FTP sous Linux. Bouron Dimitri 20/04/2014

L envoi d un formulaire par courriel. Configuration requise Mail Texte Mail HTML Check-list

Petit guide pour l installation de CVW sous Linux

Protection des protocoles

Configuration du serveur FTP sécurisé (Microsoft)

Installation d un serveur HTTP (Hypertext Transfer Protocol) sous Débian 6

CliniPACS : distribution sécurisée d'images DICOM en réseau local hospitalier

LAB : Schéma. Compagnie C / /24 NETASQ


MANUEL UTILISATEUR. ADELYAMIN Version V1.0

Fiabilisez la diffusion de vos messages!

Application des Spécifications détaillées pour la Retraite, architecture portail à portail

Les solutions de paiement CyberMUT (Crédit Mutuel) et CIC. Qui contacter pour commencer la mise en place d une configuration de test?

Julien MATHEVET Alexandre BOISSY GSID 4. Rapport RE09. Load Balancing et migration

Serveur virtuel infogéré

Transfert d un site local vers un serveur. NPDS REvolution 13. Rédaction : Axel Relecture : Dev & Jpb

NON URGENTE TEMPORAIRE DEFINITIVE OBJET : RÉCUPÉRATION DES DONNÉES CLIENT SUR DISQUE DUR DÉFECTUEUX OU INVALIDÉ

A L ERT. Pour démarrer rapidement avec

MANUEL UTILISATEUR KIWI BACKUP V 3

Mise en place Active Directory / DHCP / DNS

Réparer un disque dur passé en RAW

TP4 : Firewall IPTABLES

Installation d OwnCloud 8.0 sous Debian Avec connexion des utilisateurs active directory et mise en place de HTTPS

MSP Center Plus. Vue du Produit

Disque Dur Internet «Découverte» Guide d utilisation du service

Installer un domaine DNS

Cours CCNA 1. Exercices

Copyright Arsys Internet E.U.R.L. Arsys Backup Online. Guide de l utilisateur

Réaliser un inventaire Documentation utilisateur

Appui SIE :Développement de services web ADES/SIE

MANUEL DE L UTILISATEUR

TAGREROUT Seyf Allah TMRIM

Gestion collaborative de documents

Installation d'un TSE (Terminal Serveur Edition)

Environnements informatiques

2 disques en Raid 0,5 ou 10 SAS

ITIL V3. Exploitation des services : Les processus

Tuto 2 : Configuration Virtual box, Configuration et installation du serveur XiBO

Netfilter & Iptables. Théorie Firewall. Autoriser le trafic entrant d'une connexion déjà établie. Permettre le trafic entrant sur un port spécifique

COMMUNICATION TECHNIQUE N TCV060 Ed. 01. OmniVista 4760 Nb de pages : 18 Date : URGENTE NON URGENTE TEMPORAIRE DEFINITIVE

Paris Airports - Web API Airports Path finding

Les commandes relatives aux réseaux

Configuration du nouveau Bureau Virtuel (BV) collaboratif de Lyon I

Pilot4IT Monitoring : Mesurez la qualité et la performance perçue de vos applications.

SUGARCRM Sugar Open Source Guide d Installation de French SugarCRM Open Source Version 4.2

Surveillance de Scripts LUA et de réception d EVENT. avec LoriotPro Extended & Broadcast Edition

Micro-ordinateurs, informations, idées, trucs et astuces. Utiliser les services de fichiers

Network Shutdown Module V3 Extension du Manuel Utilisateur pour architecture Virtualisée VMWare ESX Server 3, 3.5

I. Objectifs de ce document : II. Le changement d architecture :

L installation a quelque peu changée depuis les derniers tutos, voici une actualisation.

Accès à un coupleur/contrôleur Ethernet via une liaison téléphonique

Mandataires, caches et filtres

UltraBackup NetStation 4. Guide de démarrage rapide

Intrunet SI120/SI220 Pour une sécurité sur mesure

Introduction à Linux (pour le HPC) «Linux 101» Présentation :

Procédure d installation de la solution Central WiFI Manager CWM

Exonet : sauvegarde automatisée d une base de données

Installer Enterprise Miner 5.1 en SAS environnement Windows

Transcription:

Mise à disposition automatique des données sismiques des stations du RAP à partir de détection du réseau ISARD Rapport final BRGM/RP-56555-FR Convention BRGM-MEDAD n 0000802 Juillet 2008

Mise à disposition automatique des données sismiques des stations du RAP à partir de détection du réseau ISARD Rapport final BRGM/-56555-FR Juillet 2008 Étude réalisée dans le cadre des projets de Service public du BRGM n 2007-RISG-67 Convention BRGM-MEDAD n 0000802 A. Roullé, O. Morel, P. Delas Vérificateur : Approbateur : Nom : Date : Nom : Date : Signature : Signature : En l absence de signature, notamment pour les rapports diffusés en version numérique, l original signé est disponible aux Archives du BRGM. Le système de management de la qualité du BRGM est certifié AFAQ ISO 9001:2000. I M 003 SIMP - AVRIL. 05

Mots clés : alerte, temps réel, réseau sismologique, accélérométrie, RAP En bibliographie, ce rapport sera cité de la façon suivante : Roullé A., Morel O., Delas P. (2008) Mise à disposition automatique des données sismiques des stations du RAP à partir de détection du réseau ISARD. Rapport BRGM/RP-56555-FR, 40 p., 9 fig., 1 tabl. BRGM, 2008, ce document ne peut être reproduit en totalité ou en partie sans l autorisation expresse du BRGM.

Mise à disposition automatique des données RAP à partir d une alerte ISARD Synthèse L objet de cette étude est de développer une passerelle automatique pour extraire les données accélérométriques du RAP (Réseau Accélérométrique Permanent, http://www-rap.obs.ujfgrenoble.fr/) des stations pyrénéennes gérées par le BRGM. Cette tâche devrait permettre de mettre plus rapidement et de manière automatique les données accélérométriques du RAP à disposition de la communauté scientifique pour une exploitation immédiate. Il s agit d une première étape pour un développement au niveau national du temps réel. Ce travail a bénéficié du soutien financier du MEDAD dans le cadre de l action 4.9 de la convention n 0000802 signée le 1 er août 2007. En l état actuel des systèmes ISARD et RAP, la communication entre les deux systèmes s est faite via une requête http transmise par le PC d alerte ISARD au PC du RAP via le réseau internet. Cette requête lance une interrogation automatique des stations pyrénéennes gérées par le BRGM via un script RAP existant. Cette interrogation permet de rapatrier les enregistrements dont l heure de déclenchement correspond à l événement sismique détecté par le système ISARD. Ces enregistrements sont stockés en local et envoyés sur le site ftp.brgm.fr pour mise à disposition au site central du RAP. Ce travail a montré plusieurs limites dues essentiellement à la façon dont les scripts RAP sont programmés dans l état actuel du système. Ces limites concernent à la fois la mise en œuvre informatique de la procédure, qui pose notamment des problèmes de droits et d indépendance d exécution des scripts, et l apparition potentielle de conflits entre deux interrogations simultanées. L ensemble de ces points pourraient être résolus par une analyse approfondie des scripts RAP utilisés au BRGM et une refonte de ces scripts. Ce point, non prévu dans le cadre de ce projet, doit être fait en collaboration avec le site central du RAP à Grenoble, responsable du développement des scripts actuellement utilisés au BRGM. Enfin, il est à noter que la mise à disposition automatique des données sur le site ftp.brgm.fr ne permet pas de validation manuelle de ces données par un sismologue avant leur diffusion. Cependant, la programmation d une procédure automatique d interrogation des stations pyrénéennes du RAP à partir d une alerte émise par le système ISARD a été réalisée avec succès. Cette procédure a permis de rapatrier automatiquement 16 enregistrements correspondant à 5 séismes et de mettre à disposition ces données, toujours de façon automatique, sur le site ftp.brgm.fr moins de 2 heures après le séisme. Néanmoins, les communications entre les stations et le site se faisant via une ligne téléphonique classique, le temps de rapatriement des données est pour le moment incompatible avec une application temps réel. BRGM/RP-56555-FR Rapport final -3 -

Mise à disposition automatique des données RAP à partir d une alerte ISARD Sommaire 1. Introduction... 7 2. Réalisation technique... 9 2.1. DESCRIPTIONS DES SYSTEMES ISARD ET RAP... 9 2.1.1. ISARD... 9 2.1.2. RAP... 11 2.1.3. Schéma fonctionnel adopté... 13 2.2. TESTS ET BILAN... 14 3. Conclusions... 19 4. Bibliographie... 21 Liste des illustrations Figure 1 : Localisation des stations du projet ISARD existantes et état du réseau au 1 er août 2008.... 9 Figure 2 : Schéma fonctionnel simplifié du système ISARD.... 10 Figure 3 : Exemple d alerte émise par le système ISARD (séisme du 15/07/2008).... 11 Figure 4 : Localisation des stations du RAP dans les Pyrénées. Les triangles rouges représentent les stations gérées par l OMP et les triangles bleus celles gérées par le BRGM.... 12 Figure 5 : Schéma fonctionnel général d une interrogation RAP.... 13 Figure 6 : Schéma fonctionnel adopté dans cette étude... 14 Figure 7 : Exemple de données RAP récupérées suite à une alerte ISARD (séisme du 31/03/2008, station PYLL).... 16 Figure 8 : Schéma de la chaine de traitement retenu... 27 Figure 9 : Dépendance des fichiers / Enchaînement de haut niveau... 29 BRGM/RP-56555-FR Rapport final -5 -

Liste des annexes Annexe Manuel technique... 23 BRGM/RP-56555-FR Rapport final -6-

Mise à disposition automatique des données RAP à partir d une alerte ISARD 1. Introduction Un système automatique a été mis en place dans le cadre du projet Interreg ISARD (Information Sismique Automatique Régionale de Dommages) pour pouvoir localiser un séisme dans la partie orientale des Pyrénées, estimer ses caractéristiques et, finalement, évaluer les dommages potentiels consécutifs à ce séisme. Ce système, issu d une collaboration entre l Institut Géologique de Catalogne (IGC) et le BRGM, reçoit actuellement en temps réel les données d un réseau des stations accélérométriques et vélocimétriques situé dans la partie orientale des Pyrénées. Par ailleurs, dans les Pyrénées françaises, il existe également 33 stations accélérométriques du RAP (Réseau Accélérométrique Permanent), dont 12 sont gérées par le BRGM et 21 par l OMP (Observatoire Midi-Pyrénées). Le but de ce réseau est de recueillir des données de mouvement fort sur l ensemble de la chaîne pyrénéenne à des fins scientifiques et préventives. Contrairement au réseau développé dans le cadre d ISARD ou du RéNaSS (Réseau National de Surveillance Sismique), il n a pas de vocation de réseau d alerte. L objectif du projet présenté dans ce rapport est d utiliser les détections automatiques d événements sismiques par le réseau ISARD pour déclencher une interrogation automatique des stations accélérométriques du RAP situées dans les Pyrénées afin de mettre rapidement les enregistrements à disposition sur le serveur ftp de distribution des données accessibles au BRGM et au site central du RAP à Grenoble pour une exploitation rapide en cas de séisme notable. Ce travail a bénéficié du soutien financier du MEDAD dans le cadre de l action 4.9 de la convention n 0000802 signée le 1 er août 2007. BRGM/RP-56555-FR Rapport final -7 -

Mise à disposition automatique des données RAP à partir d une alerte ISARD 2. Réalisation technique 2.1. DESCRIPTIONS DES SYSTEMES ISARD ET RAP 2.1.1. ISARD Le réseau ISARD est constitué actuellement de 15 stations : 12 situées en Catalogne appartenant à l IGC (constituées de capteurs large bande courte période avec pour objectif la détection) et 3 situées en France appartenant au BRGM (stations accélérométriques 1 pour l étude des mouvements sismiques forts). Sur les trois stations françaises, seule la station accélérométrique CNEB est intégrée au système Isard, l installation des deux autres stations étant en cours. Le réseau actuellement en place s étend approximativement sur 200 km d Est en Ouest et sur 280 km du Nord au Sud. 43 N 42 N 41 N 0 E 1 E 2 E 3 E Figure 1 : Localisation des stations du projet ISARD existantes et état du réseau au 1 er août 2008. 1 Ces stations ont été acquises dans le cadre de la convention n CV 04000212 du MEDD et des fonds FEDER dans le cadre des projets Objectif 2 en Languedoc-Roussillon. BRGM/RP-56555-FR Rapport final -9 -

Toutes ces stations sont équipées de liaison satellite, permettant de transférer les données enregistrées en temps réel au Hub de Barcelone qui les redirigent directement vers les deux «CRDS» (Seismic Data Reception Center) à Barcelone (IGC) et à Orléans (BRGM) où elles sont traitées, analysées et stockées. Ces deux «CRDS» fonctionnent exactement de la même façon et s appuie sur un système informatique constitué de quatre PC en réseau (NAQServer, DAS, BdOracle et ALERTE) ayant chacun sa propre fonctionnalité : 1. Le NAQSServer gère la réception temps réel des données transmises par satellite. Cellesci sont ensuite transmises au PC DAS ; 2. Le DAS (Seismic Automatic Determination) traite automatiquement les données brutes et transmet tout événement sismique détecté au PC BdOracle et au PC ALERTE ; 3. Le PC BdOracle stocke les données correspondant aux événements détectés et transfère les informations sur le site web de l IGC ; 4. Le PC ALERTE a pour fonction de filtrer les évènements grâce au programme Teleavis et de générer et transmettre les alertes par e-mail, SMS, FAX aux personnes et autorités concernées dans le cas où les critères d alertes définis dans le programme sont atteints. PC 1 PC : NAQS : Réception des données PC 2 PC : DAS : Traitement des données par le logiciel DAS v 2.0 PC 3 PC 4 PC : BdOracle : Stockage des données et diffusion de l information sur le site web de l IGC. Base de données : ORLEANS 1 PC : ALERTE : Filtrage, cartographie et diffusion de l information par le programme Teleavis v 4.0 Site web de l IGC ALERTE Figure 2 : Schéma fonctionnel simplifié du système ISARD. L idée est donc d utiliser les alertes diffusées par TeleAvis (Figure 3) pour lancer une interrogation automatique des stations RAP situées dans les Pyrénées en utilisant les paramètres du séisme localisé par ISARD. BRGM/RP-56555-FR Rapport final -10-

Mise à disposition automatique des données RAP à partir d une alerte ISARD Figure 3 : Exemple d alerte émise par le système ISARD (séisme du 15/07/2008). 2.1.2. RAP Le RAP ou Réseau Accélérométrique Permanent compte actuellement plus de 100 stations réparties sur l ensemble du territoire national (http://www-rap.obs.ujf-grenoble.fr). Dans les Pyrénées, il existe 33 stations, dont 12 sont gérées par le BRGM et 21 par l OMP en considérant l antenne de 10 stations installées à Bagnères-de-Bigorre. Le RAP n ayant pas vocation à assurer BRGM/RP-56555-FR Rapport final -11 -

une alerte, le système de communication et de traitement des données est très différent de celui d ISARD. Le fonctionnement du système est décrit succinctement ci-dessous. Figure 4 : Localisation des stations du RAP dans les Pyrénées. Les triangles rouges représentent les stations gérées par l OMP et les triangles bleus celles gérées par le BRGM. Les données accélérométriques sont enregistrées sur déclenchement (et non de façon continue comme pour les réseaux d alerte temps réel). Pour les stations pyrénéennes, ce déclenchement se fait sur un critère de seuil, c est-à-dire que l enregistrement n a lieu que si le paramètre STA/LTA 2 calculé à partir de l enregistrement obtenu au niveau du capteur dépasse un seuil défini préalablement au niveau de la station. Les enregistrements sont ensuite stockés sur la mémoire de la station accélérométrique. Pour récupérer les données, l opérateur responsable de la gestion de la station doit donc interroger la station pour vérifier les heures de ses déclenchements et si l un d entre eux est susceptible de correspondre à un séisme, l opérateur rapatrie alors les données correspondantes pour les valider et les transférer au site central (Figure 5). Cette interrogation peut se faire automatiquement en se basant sur un catalogue de sismicité fourni par un organisme officiel (dans le cas des Pyrénées, nous utilisons le catalogue fourni par le RéNaSS) ou manuellement avec des paramètres d interrogation (paramètres du séisme et stations à interroger) définis par l opérateur. Dans le dernier cas, elle se fait via un script appelé «urgence.rap». Une fois rapatriées, ces données sont vérifiées par un sismologue afin d éliminer les signaux non sismiques et, si elles sont valides, sont mises à disposition sur le site ftp.brgm.fr sur lequel elles seront récupérées par le site central du RAP à Grenoble pour intégration à la base de données 2 STA/LTA : de «Short Time Average» et «Long Time Average». Ce paramètre correspond au rapport entre la moyenne à court terme (sur une petite fenêtre de temps, typiquement 1 s dans les Pyrénées) et la moyenne à long terme (sur une longue fenêtre de temps, typiquement 30 s dans les Pyrénées). Si ce paramètre dépasse un seuil fixé par l utilisateur, il y a déclenchement de la station. Ce paramètre est couramment utilisé pour distinguer un signal sismique d un signal impulsionnel. BRGM/RP-56555-FR Rapport final -12-

Mise à disposition automatique des données RAP à partir d une alerte ISARD nationale. Les stations pyrénéennes du RAP sont interrogées via une ligne téléphonique classique sous système Linux. Figure 5 : Schéma fonctionnel général d une interrogation RAP. 2.1.3. Schéma fonctionnel adopté Afin de répondre aux besoins du client, le schéma fonctionnel décrit dans la Figure 6 a été retenu. Ce schéma consiste à envoyer l alerte ISARD au système du RAP via le réseau sous la forme d une requête http. Cette requête (programme PHP) est traitée par l utilisateur Apache du PC RAP qui prépare le log d exécution et le fichier d entrée contenant les paramètres du séisme. Puis, cette requête lance une interrogation automatique de l ensemble des stations pyrénéennes et rapatrie en local les données correspondant à l alerte ISARD à l aide du script RAP «urgence.rap». Ces données sont ensuite envoyées automatiquement sur le site ftp.brgm.fr dans un répertoire propre à cette application. BRGM/RP-56555-FR Rapport final -13 -

http:// Apache PHP ISARD (Alerte) Réseau RAP exécute dépose FTP urgence.rap Figure 6 : Schéma fonctionnel adopté dans cette étude. Les détails de la réalisation informatique du projet sont présentés en annexe 1. Les routines utilisées («urgence.rap» notamment) sont reprises intégralement des routines actuelles du système RAP décrites dans le manuel utilisateur fourni par le site central du RAP et disponibles pour tous les utilisateurs du RAP. Elles n ont donc pas été expliquées dans ce rapport et c est le dossier logiciel présenté en annexe 1 et où sont décrits les scripts développés pour cette étude qui tient lieu de manuel utilisateur. 2.2. TESTS ET BILAN 2.2.1. Tests de la procédure La mise en place du système d interrogation des stations RAP à partir d un alerte ISARD a été opérationnelle à partir du 21 mars 2008. Depuis lors et à fin juin 2008, 19 alertes ISARD ont été émises. Parmi ces 19 alertes, 13 correspondent à des séismes répertoriés dans les catalogues de sismicité du RéNaSS (Réseau National de Surveillance Sismique : http://renass.u-strasbg.fr/), de l IGN (Institut Géographique National, Espagne : http://www.ign.es/), et de l IGC (Institut BRGM/RP-56555-FR Rapport final -14-

Mise à disposition automatique des données RAP à partir d une alerte ISARD Géologique de Catalogne : http://www.igc.cat/). Les autres alertes correspondent soit à de fausses alertes générées par le système ISARD, soit à de petits séismes très locaux non détectés par les réseaux cités précédemment et non répertoriés. Nous n en tiendrons pas compte dans l analyse des résultats. Il est à noter que les paramètres de détection automatique du système ISARD ont été modifiés au 1 er juillet ce qui devrait diminuer le nombre de fausses alertes et améliorer la fiabilité du système. Parmi les 13 séismes répertoriés, 12 ont fait l objet d une procédure d interrogation automatique des stations RAP et de rapatriement automatique des données. La dernière interrogation ne s est pas faite suite à un défaut de communication entre le système ISARD et le système RAP suite à un problème réseau interne au BRGM. Les résultats de ces interrogations sont synthétisés dans le Tableau 1. Ces interrogations ont permis de récupérer les données de 5 séismes, soit 16 enregistrements, entre une et deux heures après le séisme. Cela permet donc de mettre les données rapidement et automatiquement à disposition du site central de Grenoble. La communication et le rapatriement des données se faisant via une ligne téléphonique classique, ce système est, dans sa configuration technologique actuelle, incompatible avec des actions en temps réel qui nécessiterait un rapatriement des données en quelques minutes. C est une des limites techniques actuelle du système RAP pour le temps réel. Par ailleurs, deux des séismes ayant fait l objet d une alerte n étaient pas répertoriés dans le catalogue du RéNaSS. Ils n auraient donc pas fait l objet d une interrogation automatique via le système RAP et, dans la procédure RAP classique, ils auraient dû être rapatriés manuellement par le sismologue en charge des interrogations. Cela a donc permis de récupérer rapidement des données non cataloguées par le RéNaSS et d éviter une perte de données liée à un cyclage 3 de la mémoire de la station. En effet, la vérification manuelle des catalogues de l IGN et l IGC se fait tardivement (le catalogue de l IGC n est pas remis à jour de façon quotidienne par exemple) et il arrive que les enregistrements correspondant à des séismes de ces 2 catalogues ne puissent être récupérés car ils ont été écrasés par d autres enregistrements plus récents. Date Heure TU (ISARD) Latitude (ISARD) Longitude (ISARD) Magnitude (ISARD) Stations avec enregistrements rapatriés Séisme du catalogue RéNaSS Temps de récupération des enregistrements 28/03/2008 12 :51 :28 42.272 2.143 2.5 PYLL, PYPM, PYPT Oui 0h55 28/03/2008 16 :03 :54 42.314 2.103 2.1 PYLL, PYPM, PYBA Oui 0h45 31/03/2008 14 :36 :19 42.299 2.127 2.1 PYLL Non 1h20 07/04/2008 00 :38 :02 42.455 1.228 2.0 - Oui - 07/04/2008 10 :38 :46 42.090 0.127 2.6 - Oui - 14/05/2008 18 :26 :16 42.406 0.113 2.2 - Oui - 16/05/2008 17 :51 :36 41.816 2.781 2.4 PYBA, PYPM, PYLL, PYPT, PYPE, Oui 26/05/2008 16:02:36 41.646 0.226 2.3 - Oui - 04/06/2008 21:08:56 41.660 0.747 2.3 - Oui - 2h00 3 La mémoire utilisée sur les stations du RAP cycle c est-à-dire que, quand la mémoire est pleine, les nouveaux enregistrements écrasent les plus anciens. BRGM/RP-56555-FR Rapport final -15 -

Date Heure TU (ISARD) Latitude (ISARD) Longitude (ISARD) Magnitude (ISARD) Stations avec enregistrements rapatriés Séisme du catalogue RéNaSS Temps de récupération des enregistrements 06/06/2008 09:56:19 42.45 0.273 2.2 - Non - 25/06/2008 15:32:01 41.857 0.980 2.5 PYCA, PYLS, PYAS, Oui 1h22 PYOR 29/06/2008 20:45:17 41.784-1.044 2.2 - Oui - Tableau 1 : Récapitulatif des interrogations du RAP réalisées suite à une alerte ISARD pour des séismes répertoriés dans les catalogues sismologiques. Figure 7 : Exemple de données RAP récupérées suite à une alerte ISARD (séisme du 31/03/2008, station PYLL). Enfin, il faut noter que certains séismes se sont produits à des périodes non ouvrables (week-end) comme les séismes du 28/03/2008, 16/05/2008 et 29/06/2008. Sans l appui du système ISARD, le rapatriement des données correspondantes n aurait pu se faire que de façon automatique et plus tardivement (le lendemain en général) à condition qu ils aient été intégrés dans le catalogue RéNaSS. 2.2.2. Bilan Le travail réalisé dans ce projet a permis de valider la faisabilité technique d une interrogation automatique des stations RAP à partir d une alerte générée par le système ISARD. Néanmoins, la mise en œuvre de la procédure décrite plus haut a montré les limites d une telle réalisation dans l état actuel des systèmes ISARD et RAP. BRGM/RP-56555-FR Rapport final -16-

Mise à disposition automatique des données RAP à partir d une alerte ISARD D un point de vue informatique, des difficultés sont apparues lors de la programmation. Ces difficultés sont détaillées dans l annexe 1 mais les points principaux sont les suivants : L exécution des scripts RAP est fortement liée au compte utilisateur (utilisateur «rap» en général) ce qui engendre des problèmes de droits et d indépendance d exécution lorsque l on souhaite les exécuter sous un autre utilisateur que celui prévu par défaut. Un clone du script original a notamment dû être généré pour que l exécution soit possible, ce qui pose des problèmes de maintenance du système en cas de modification du script principal ; La gestion des chemins et noms de répertoire dans les scripts RAP (incluant la date et l heure des exécutions) ne permet pas une gestion propre de la mise à disposition automatique des données sur le site ftp ; Il n a pas été possible d intégrer simplement le calcul de la distance séisme-station qui aurait permis de limiter le nombre de stations à interroger en utilisant un critère basé sur la magnitude du séisme et la distance épicentrale. Par défaut, toutes les stations pyrénéennes sont donc interrogées ce qui rallonge la durée de la procédure. Pour introduire le critère de sélection des stations à interroger, une simplification préalable des scripts RAP serait nécessaire. Pour être résolus, ces points nécessitent une refonte complète des scripts d interrogation du système RAP, refonte qui ne peut se faire qu en collaboration avec le LGIT à Grenoble qui a développé ces scripts. Ce travail ne pouvait pas se faire dans le budget alloué pour cette étude. Du point de vue du sismologue : En l état actuel du système, les données rapatriées suite à une alerte ISARD sont stockées dans les mêmes répertoires que les données rapatriées par le système RAP lui-même, ce qui complique la tâche de vérification de l état du réseau RAP et de validation des données rapatriées. Ceci est dû à la complexité actuelle du système, en particulier aux problèmes de droit évoqués plus haut qui ne permettent pas l envoi des mails récapitulatifs pour les tâches générées par les alertes ISARD. Pour l instant, cela n a pas posé de problème majeur mais, en cas de crise sismique, les deux types d interrogation automatique - lancées à partir d un script du type «urgence.rap» - (RAP et ISARD) risquent de saturer le système en produisant deux fois les mêmes interrogations (même séisme) à des heures différentes. Il risque d apparaître des conflits i) au niveau modem, et ii) pour l organisation du stockage des données rapatriées, chacun des scripts générant des répertoires similaires. Les tests effectués n ont pas généré d erreur, les scripts s exécutant l un après l autre, mais cela reste à confirmer en cas de crise nécessitant des appels répétés à courts intervalles (quelques minutes). Ce point pourrait être résolu après une analyse approfondie et une refonte des scripts RAP et en gérant des priorités au niveau des tâches. Enfin, il faut bien être conscient que, compte tenu du caractère automatique de la procédure, les données mises à disposition sur le site ftp n ont pas été validées préalablement par un sismologue. Des données correspondant à des signaux non sismiques peuvent ainsi être envoyées sur le site ftp réservé à l utilisation exclusive du site central en charge de la validation des signaux. Un autre site ftp peut également être défini comme destinataire si besoin est. BRGM/RP-56555-FR Rapport final -17 -

BRGM/RP-56555-FR Rapport final -18-

Mise à disposition automatique des données RAP à partir d une alerte ISARD 3. Conclusions Ce travail a montré plusieurs limites dues essentiellement à la façon dont les scripts RAP sont programmés dans l état actuel du système. Ces limites concernent à la fois la mise en œuvre informatique de la procédure, occasionnant des difficultés concernant les droits et l indépendance d exécution des scripts, et l apparition potentielle de conflits entre deux interrogations simultanées au niveau du modem et du stockage des données, particulièrement en cas de crise sismique. L ensemble de ces points pourraient être résolus par une analyse approfondie des scripts RAP utilisés au BRGM et leur amélioration. La réécriture des scripts du système d interrogation RAP, non prévue dans le cadre de ce projet, peut être réalisée en collaboration avec le site central du RAP à Grenoble. Enfin, il faut rappeler que les données mises à disposition automatiquement sur le site ftp.brgm.fr ne sont pas validées par un sismologue avant leur diffusion, sachant que le système d alerte automatique peut induire de fausses alertes et que le rapatriement automatique de données peut conduire à rapatrier des signaux non sismiques. La programmation d une procédure automatique d interrogation de stations pyrénéennes du RAP à partir d une alerte émise par le système ISARD a été réalisée avec succès. Cette procédure a permis de rapatrier automatiquement 16 enregistrements correspondant à 5 séismes et de mettre à disposition ces données, toujours de façon automatique, sur le site ftp.brgm.fr moins de 2 heures après le séisme. Malgré un temps de rapatriement des données incompatible avec les applications temps réel en l état actuel du système, l intérêt d une telle procédure est multiple : Interrogation en veille permanente et automatique ne nécessitant pas d intervention humaine et donc d astreinte, en particulier pendant les heures non ouvrables (nuit, weekend, jours fériés) ; Gain de temps pour l accessibilité aux enregistrements ; Rapatriement indépendant d une mise à jour externe par un observatoire du catalogue de sismicité (type RéNaSS) ; Accessibilité partagée des enregistrements (ftp) ; Compte-tenu de l évolution prochaine de plusieurs stations accélérométriques du RAP vers la technologie continue, ce type d interrogation et de rapatriement automatiques peut constituer une alternative pour un nombre limité de stations connectées au réseau téléphonique classique et isolées des technologies de communication rapide de type ADSL réduisant ainsi le temps global de rapatriement. BRGM/RP-56555-FR Rapport final -19 -

Mise à disposition automatique des données RAP à partir d une alerte ISARD 4. Bibliographie Site du RAP : http://www-rap.obs.ujf-grenoble.fr/ Site du RéNass : http://renass.u-strasbg.fr/ Site de l IGN : http://www.ign.es/ Site de l IGC : http://www.igc.cat/ BRGM/RP-56555-FR Rapport final -21 -

Mise à disposition automatique des données RAP à partir d une alerte ISARD Annexe Manuel Technique BRGM/RP-56555-FR Rapport final -23 -

Mise à disposition automatique des données RAP à partir d une alerte ISARD MANUEL TECHNIQUE ISARD vers RAP 2007 Intervenants sur le projet : Agathe ROULLE, Philippe DELAS, Olivier MOREL Rédacteur du document : Olivier MOREL - Création du document décembre 2007 - Document mis à jour le 30 Juillet 2008 Transfert des fichiers d.* sur le FTP corrigé. BRGM/RP-56555-FR Rapport final -25 -

SOMMAIRE 1. But... 27 2. Détails de la réalisation... 27 2.1. INFRASTRUCTURE RESEAU... 27 2.2. CONFIGURATION PC RAP... 28 2.3. PROGRAMME PHP... 28 2.4. SCRIPTS EXISTANTS ET ADAPTATIONS... 28 2.5. FTP... 29 2.6. SCHEMA D APPEL DES PROGRAMMES... 29 3. Code Source... 30 3.1. ISARDWARNING.PHP... 30 3.2. URGENCE_AUTOMATIC_CALL.SH... 32 3.3. URGENCE_AUTOMATIC_DATA.DAT... 35 BRGM/RP-56555-FR Rapport final -26-

Mise à disposition automatique des données RAP à partir d une alerte ISARD 1. But Le but du projet était de pouvoir déclencher le téléchargement des stations RAP depuis la détection d un séisme dans le système ISARD. http:// Apache PHP ISARD (Alerte) Réseau RAP exécute dépose FTP urgence.rap Figure 8 : Schéma de la chaine de traitement retenu 2. Détails de la réalisation Cette partie présente les interventions qui ont été nécessaires pour mener à terme la réalisation. La dernière partie récapitule dans un schéma l ensemble de la réalisation. 2.1. INFRASTRUCTURE RESEAU Des droits ont été donnés pour que le réseau DMZ-Isard puisse envoyer des requêtes http sur port 80 au PC rapbrgm2.brgm.fr (10.100.0.44) BRGM/RP-56555-FR Rapport final -27 -

2.2. CONFIGURATION PC RAP Dans le répertoire d installation du serveur Apache (/usr/local/apache2) le répertoire htdocs appartenant à l utilisateur rap, un sous répertoire IsardRap y a été créé. Ce répertoire avec des droits étendus recevra les logs d exécution du script PHP. Il s agit du fichier IsardWarning.log L utilisateur Apache, propriétaire des processus de traitement des pages PHP, a été rajouté au groupe de l utilisateur rap. Ainsi, les accès par le script PHP aux répertoires dont rap est propriétaire se fait par une autorisation des droits d accès sur le groupe. 2.3. PROGRAMME PHP La page PHP appelé par le PC de notification d alerte du système ISARD est IsardWarning.php. Elle est située dans le répertoire htdocs de l installation Apache. Cette page récupère les données du séisme avec les variables suivantes : dataact info1 info2 info3 info4 info5 info6 => pour la date au format jj-mm-aaaa => pour l heure => pour la magnitude => pour la longitude => pour la latitude => pour la région => pour la profondeur 2.4. SCRIPTS EXISTANTS ET ADAPTATIONS Le programme à appeler est urgence.rap. Ce programme prend automatiquement en entrée le fichier event.lst qui contient les caractéristiques du séisme pour lequel on déclenche le rapatriement des données des stations RAP. Le code source de ce programme montre son interaction forte avec le compte utilisateur rap. Hors, nous souhaitons faire appeler ce programme depuis l exécution d une page PHP, processus tournant pour le compte utilisateur apache. Une copie du programme urgence.rap a été faite dans le fichier urgenceisard.rap et a été adapté dans les variables d environnement de la copie pour dé corréler de l utilisateur rap. Ces variables ont reçu des valeurs en dur pour retrouver les chemins relatif à /home/rap. De plus, la liste des stations a été codée en dur dans l appel à urgenceisard.rap car le module de calcul de détermination des stations concernées est fondu dans le code existant et nécessite une meilleure connaissance pour cette intervention. BRGM/RP-56555-FR Rapport final -28-