Mise à disposition automatique des données sismiques des ... · l’IGC PC 1 PC 2 PC 3 PC 4...

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

ISARDRapport 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 :

Nom :

Date :

Signature :

Approbateur :

Nom :

Date :

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.ujf-grenoble.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 1er 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 -

ftp://ftp.brgm.fr/ftp://ftp.brgm.fr/ftp://ftp.brgm.fr/


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 1er 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


Liste des annexes

Annexe Manuel technique ......................................................................................................... 23

BRGM/RP-56555-FR – Rapport final -6-


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 1er août 2007.



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étriques1 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.

42°N

41°N

0°E 3°E 1°E 2°E

43°N

Figure 1 : Localisation des stations du projet ISARD existantes et état du réseau au 1er 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.


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. Celles-ci 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 : BdOracle : Stockage des données et diffusion de l’information sur le site web de l’IGC.

Base de données : ORLEANS 1

PC : NAQS : Réception des données

PC : DAS : Traitement des données par le logiciel DAS v 2.0

ALERTE

PC : ALERTE : Filtrage, cartographie et diffusion de l’information par le programme

Teleavis v 4.0

Site web de l’IGC

PC 1

PC 2

PC 3 PC 4

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.



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


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/LTA2 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.


ftp://ftp.brgm.fr/


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.


ftp://ftp.brgm.fr/

ISARD (Alerte) RAP

http://

ApachePHP

exécute

urgence.rap

Réseau

FTP

dépose

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


http://renass.u-strasbg.fr/


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 1er 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 cyclage3 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 2h00

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 -

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.


http://www.igc.cat/

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,

PYOR Oui 1h22

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.



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.



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, week-end, 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.


ftp://ftp.brgm.fr/ftp://ftp.brgm.fr/


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/


http://www-rap.obs.ujf-grenoble.fr/http://renass.u-strasbg.fr/http://www.ign.es/http://www.igc.cat/


Annexe

Manuel Technique



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é.


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



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.

ISARD (Alerte) RAP

http://

ApachePHP

exécute

urgence.rap

Réseau

FTP

dépose

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)


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 => pour la date au format jj-mm-aaaa

info1 => pour l’heure

info2 => pour la magnitude

info3 => pour la longitude

info4 => pour la latitude

info5 => pour la région

info6 => 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.



Ce script s’appelle urgenceIsard et se situe dans /home/rap/bin.

Ces choix ont été décidés pour ne pas interférer dans le code source des programmes existants, ceux-ci n’ayant pas été produits par le BRGM seul.

Comme pour les interrogations manuelles classiques, les fichiers rapatriés en format titan se situent dans le répertoire /home/rap/URGENCE, dans un sous-répertoire dont le nom correspond à la date de réalisation de l’interrogation. Ils sont également sauvegardés en format titan dans le répertoire /home/rap/BANK/2008/RAP-BRGM/EVENTS/DONNEES. Ces fichiers sont aussi disponibles au format SAC dans /home/rap/BANK/2008/RAP-BRGM/EVENTS/SAC et une image des données rapatriées est sauvegardée au format jpeg au niveau du serveur apache : /usr/local/apache2/htdocs/DATA/URGENCE. Toutes ces sauvegardes se font de façon automatique à partir du script urgenceIsard.rap.

2.5. FTP

Une fois le rapatriement des données effectué, celles ci doivent être déposées sur le serveur FTP du BRGM (ftp.brgm.fr).

Le compte FTP rapbrgm est utilisé pour ce faire.

Le script construit sur le FTP la même arborescence que le répertoire de données du jour et y dépose tous les fichiers répondant au pattern de nom « d.* ». Les fichiers sont déposés dans le répertoire : AValiderIsard.

2.6. SCHEMA D’APPEL DES PROGRAMMES

IsardWarning.php(/usr/local/apache2/htdocs)

IsardWarning.log(/usr/local/apache2/htdocs/IsardRap)1) - Enregistre dans

Event.lst(/home/rap/URGENCE)2) – Crée le fichier avec les

données du séisme

3) – Appele le script

urgence_automatic_call.sh (/home/rap/bin)

urgence_automatic_data.dat (/home/rap/URGENCE)

4) – utilise pour répondre au question de l’interface de urgenceIsard.rap

urgenceIsard.rap(/home/rap/bin)

5) – Appele le clone de urgence.rap adapter à l’automatisationDécorrélation de l’utilisateur rap.

Figure 9 : Dépendance des fichiers / Enchaînement de haut niveau.


ftp://ftp.brgm.fr/

3. Code Source Le système tournant sur un PC linux dans un sous-réseau particulier, il n’y a pas d’accès à un système de gestion des versions et du code source. Je mets donc dans cette partie, comme référence, les codes sources de la réalisation.

3.1. ISARDWARNING.PHP


logit(" Start at ".date("d-m-Y H:i:s - "));

$atDate = $_GET['dataact'];

$atTime = $_GET['info1'];

$magnitude = $_GET['info2'];

$longitude = $_GET['info3'];

$latitude = $_GET['info4'];

$region = $_GET['info5'];

$profondeur = $_GET['info6'];

$pla = $_GET['pla'];

$sep = '-';

$day = strtok($atDate, $sep);

$month = strtok($sep);

$year = strtok($sep);

foreach($_GET as $key=>$val)

{

logit(' '.$key.'=>'.$val);

}

// Open the event.lst file to write data input for the urgence script.

$eventFileHandle = fopen("/home/rap/URGENCE/event.lst", "w");

$sTemp = $year.'-'.$month.'-'.$day.' '.$atTime.'+00|'.$latitude.'|N|'.$longitude.'|E|'.$profondeur.'|'.$magnitude.'|'.$region.'|isard';

fputs ($eventFileHandle, $sTemp);

fclose($eventFileHandle);


// Launch the script urgence

if ($region != '')

{

logit(" Appel du script ... ");

$sResult = passthru("/home/rap/bin/urgence_automatic_call.sh");

logit(" Code retour script: ".$sResult);

}

else

{

logit(" Pas d'appel script, pas de donnees reelles");

}

logit(" End ");

fclose ($logFileHandle);

?>

3.2. URGENCE_AUTOMATIC_CALL.SH

#!/bin/bash

HOST='ftp.brgm.fr'

USER='rapbrgm'

PASSWD='lgti2001'

repertoire_base=/home/rap/URGENCE

repertoire_ftp=AValiderIsard

ficout=/tmp/instructions_ftp.txt

#trouver les repertoires a transferer



repertoire_jour=`date +"%Y.%m.%d.RAP-BRGM"`

repertoire_jour_ftp=`date +"%Y.%m.%d.%H.%M.%S.RAP-BRGM"`

/home/rap/bin/urgenceIsard.rap -archive -s PYAS PYBA PYCA PYFE PYFO PYLI PYLL PYLS PYOR PYPE PYPM PYPT < /home/rap/bin/urgence_automatic_data.dat

# Test existence du repertoire

if [ -d ${repertoire_base}/${repertoire_jour} ]

then

cd ${repertoire_base}/${repertoire_jour}

echo "Generation fichier de commande FTP : $ficout"

echo "ftp -n "$HOST" > $ficout

for directory in `find . -type d -print `

do

rep=`echo ${repertoire_jour_ftp}/$directory | sed -e 's/\/\.//g' `

echo "mkdir $rep" >> $ficout

done


#copie des fichiers

for fichier in `find .\ -name d.* -type f -print `

do

fichier=`echo $fichier | sed -e 's/\.\///g' `

echo "lcd ${repertoire_base}/${repertoire_jour}/"`dirname $fichier` >> $ficout

echo "put "`basename $fichier` ${repertoire_jour_ftp}"/"$fichier >> $ficout

done

echo "quit" >> $ficout

echo "END_SCRIPT" >> $ficout

# Lancement du script

echo "Lancement du fichier $ficout"

chmod u+x $ficout

$ficout

else

echo "Le repertoire ${repertoire_base}/${repertoire_jour} n'existe pas !!!"

fi

echo "Suppression du fichier $ficout"

rm -f ${ficout}



3.3. URGENCE_AUTOMATIC_DATA.DAT

Y

4. Difficultés rencontrées • Les scripts rap (comme urgence.rap) ont été construits en se basant sur le principe qu’ils

seraient lancés par l’utilisateur rap. L’utilisation de la variable $HOME impose en effet de les lancer en étant connecté avec l’utilisateur rap. Cette liaison forte avec le compte utilisateur est à l’origine des problèmes rencontrés suivants :

o Problème de droits : Le serveur apache, lancé jusqu’à présent avec le compte apache, est dorénavant lancé par le compte administrateur root de la machine afin de s’affranchir des difficultés de navigation pour la compte apache à aller dans l’arborescence de l’utilisateur rap et des problèmes de propriétaires des répertoires créés. Il était en effet difficile d’autoriser l’utilisateur apache à aller dans tous les répertoires de rap tout en autorisant la réciproque, c'est-à-dire que le compte rap accède à tous les nouveaux répertoires possédés par apache, répertoires créés par le rapatriement des données des stations.

o Problème d’indépendance d’exécution, déjà évoqué plus haut, et qui a conduit à devoir créer un clone de urgence.rap en urgenceIsard.rap et de supprimer les référence à $HOME. Si par la suite il devait y avoir des évolutions fonctionnelles à cette application, il faudrait impacter les 2 sources.

• La gestion des répertoires pour les données rapatriées n’a pas permis de faire des actions simples pour la mise à disposition sur le site FTP. La non connaissance des noms de répertoires qui incluent date et heure, ne permet pas de les retrouver a posteriori du rapatriement.

Ces 2 points sont à améliorer dans la conception des scripts et programmes rap.

5. Limites d’utilisation Au début du projet, nous avons fait des tests pour savoir comment se comportait le script urgence par rapport au script programmé routine vis-à-vis de la ressource modem. Il n’y a pas de conflit ou d’erreur générée par l’un ou l’autre des scripts. Les 2 scripts s’exécutent en prenant le modem. En revanche il nous est impossible de dire, lorsque le modem se connecte à une station, s’il le fait pour le script routine ou le script urgence.

En revanche, si 2 scripts urgence sont exécutés, la gestion du modem se fera sur la même manière, mais l’organisation de stockage des fichiers rapatriés, les copies effectuées par le script lui-même pour une exécution pluri-quotidienne, ne permettent pas de nous prononcer sur la qualité du rapatriement. Les fichiers rapatriés risquent d’être mélangés.


Une analyse et une amélioration dans les scripts rap permettrait d’améliorer ce point et d’apporter une réponse fiable.


Centre scientifique et technique

Service Aménagement et Risques Naturels 3, avenue Claude-Guillemin

BP 36009 – 45060 Orléans Cedex 2 – France – Tél. : 02 38 64 34 34

Mise à disposition automatique des données sismiques des stations du RAP à partir de détection du réseau ISARD Mise à disposition automatique des données sismiques des stations du RAP à partir de détection du réseau ISARD 1. Introduction 2. Réalisation technique 2.1. DESCRIPTIONS DES SYSTEMES ISARD ET RAP 2.1.1. ISARD 2.1.2. RAP 2.1.3. Schéma fonctionnel adopté

2.2. TESTS ET BILAN 2.2.1. Tests de la procédure 2.2.2. Bilan

3. Conclusions 4. Bibliographie 1. But 2. Détails de la réalisation 2.1. INFRASTRUCTURE RESEAU 2.2. CONFIGURATION PC RAP 2.3. PROGRAMME PHP 2.4. SCRIPTS EXISTANTS ET ADAPTATIONS 2.5. FTP 2.6. SCHEMA D’APPEL DES PROGRAMMES

3. Code Source 3.1. ISARDWARNING.PHP 3.2. URGENCE_AUTOMATIC_CALL.SH 3.3. URGENCE_AUTOMATIC_DATA.DAT

4. Difficultés rencontrées 5. Limites d’utilisation

Mise à disposition automatique des données sismiques des ... · l’IGC PC 1 PC 2 PC 3 PC 4...

Documents

Transcript of Mise à disposition automatique des données sismiques des ... · l’IGC PC 1 PC 2 PC 3 PC 4...