Détection de pollution maritime avec...
Transcript of Détection de pollution maritime avec...
Détection de pollution maritimeavec GNU/Linux
Eric Bénard - [email protected] - 08 juillet 2010
2/26
● Fabricant de modules processeurs intégrés● Conception de produits électroniques intégrant
des logiciels libres : u-boot, barebox, linux● Développement de BSP & drivers● Transfert de compétences Linux embarqué● Effort d'intégration du support de nos cartes
dans les sources officielles (mainlining) : u-boot, barebox, linux
● Sponsor et développeur OpenEmbedded
3/26
Laboratoire UMR 5805 EPOC CNRS
Environnements et Paléoenvironnements OCéaniques
GEMA Arcachon: 11 chercheurs et enseignants-chercheurs, 4 techniciens, 8 thésards. Un but, étudier les fonctionnements et les
dysfonctionnements dans les écosystèmes aquatiques face aux contaminants principalement métalliques.
Quatre spécialités majeures soutenues par4 plateaux techniques forts.
4/26
Valvométrie
● Utilisation de bi-valves comme capteurs :● filtrent l'eau● très sensibles à la modification de la
qualité de l'eau● comportement de référence en
milieu non contaminé vs comportement réel = détection de modifications de la qualité de l'eau
5/26
Le principe généralDéveloppé par le GEMA
6/26
Data RDY
Lecture valeur
Trigger
L'architecture électronique
ARM920T
32MoRAM
8MoFlash
EthernetUSB
ADC 16 bits
Conditionnementanalogique
V
TR
IG 16D
Trigger = timer hardware du CPU
Fin de conversion ADC = IRQ directe à priorité élevée
~ 100ms – temps de conversion = temps max de réponse à l'IRQ
SDCard4Go
ModemGPRS
7/26
L'intégration
Boîtier au maximum étanche + électronique plongée dans l'huile = protection vis à vis d'une éventuelle fuite d'eau.
8/26
L'architecture logicielle
● Gestion de l'acquisition dans le noyau :● Driver de configuration du timer hardware
● Driver d'acquisition de la mesure– Gestionnaire d'interruption– Méthode read– Utilisation de kfifo
● cf include/linux/kfifo.h
9/26
Applications
● busybox, dropbear, pppd, zlib …● Gestion d'un fichier de configuration● Acquisition● Données environnementales● Watchdog● Gestion modem● Gestion transfert de fichiers
10/26
Gestion d'un fichier de configuration
● Librairie de gestion de fichier de configuration :● À partir de Libconfig, GPL, POSIX, C, C++● http://www.hyperrealm.com/main.php?s=libconfig
version = "1.0";reseau : { srv1_ip = ""; srv1_login = ""; srv1_pass = ""; srv1_port = 21; srv1_path = ""; srv_ntp = "pool.ntp.org"; srv_ntp2 = ""; txip_periode = 10; gsm_pin = "0000";};
alertes : { bat_100 = 12; bat_50 = 11; bat_25 = 10; bat_0 = 9; bat_100_act = true; bat_50_act = true; bat_25_act = true; bat_0_act = true; sd_free = 128; sd_act = true;};
acquisition : { std_periode = 10; debut_hh = 0; debut_mm = 0; debut_ss = 0; duree_hh = 24; duree_mm = 0; duree_ss = 0; v_act = [ true, true, true, true, true, true, true, true, true, true, true, true, true, true, true, true ];};
11/26
Acquisition
● fifo de commande :● Modification du comportement
● thread d'acquisition :● Poll sur le device du driver d'acquisition● Récupération des données● Stockage dans un fichier
12/26
Données environnementales
● Température, niveau de tension de la batterie● Lecture directe sur un ADC I2C au travers de
i2cdev :● cf linux-2.6/Documentation/i2c/dev-interface● ouverture du fichier /dev/i2c-0● ioctl pour configurer l'adresse du périphérique● read et/ou write● close Ex : niveau batterie
13/26
Watchdog
● 1 watchdog hardware, plusieurs raisons de le faire claquer ...
● 1 daemon qui gère le watchdog :– open /dev/watchdog– boucle ioctl WDIOC_KEEPALIVE, test des conditions
● Attention : option noyau WATCHDOG_NOWAYOUT
14/26
Gestion modem
● ON/OFF● par une GPIO et donc un driver qui gère cette GPIO
● Séquence d'init et lancement de pppd● Envoi de l'IP sur un serveur FTP● Boucle de vérification de la connectivité
● Appelle un script qui fera la vérification périodiquement
15/26
Gestion transfert de fichiers
● FTP : libcurl http://curl.haxx.se/libcurl/● API « Easy » permettant de faire un client ftp
avec retry et/ou append en quelques lignes
● Retry : ● Pour les fichiers de données (1 à 2 Mo / jour)
● Append :● Pour les fichiers ascii (permet d'avoir un historique
des connexions / déconnexions)
16/26
Le liant entre les applications
● Quelques scripts shell :● cron.sh :
– envoie les séquences de commande dans la fifo du logiciel d'acquisition
– crontab généré à la volée à partir du fichier de conf
● fmonitor.sh :– Utilise inotifywait -e close_write /mnt/mmc– http://wiki.github.com/rvoicilas/inotify-tools/– Bloque jusqu'à ce qu'un fichier soit fermé dans /mnt/mmc– Compresse le fichier et l'envoie avec son md5sum
17/26
Les roues de secours
● Le garbage collector :● Parce que des fichiers peuvent ne pas avoir été
transmis intégralement● liste les fichiers non transmis et retente l'envoi
● Le status du système :● Envoi des infos par ftp● Exécuté par cron toute les 12 heures
18/26
Le logiciel de configuration
● multiplateforme, en GTK
19/26
Au final
● Un système assez simple à maintenir car constitué de scripts et applications aux fonctionnalités bien identifiées
● L'utilisation d'outils et de librairies réputés stables permet d'augmenter la fiabilité du système en se concentrant sur les points métiers clefs (ici la gestion de l'acquisition)
20/26
Résultats● Arcachon :
● Fonctionne depuis 2007
● IORO :● A fonctionné de 08/2007 à 02/2009, la maintenance
préventive de 2009 lui a été fatale
● Marenne :● Système modifié car antenne immergée : ne devait
émettre que pendant les marées basses.– web → annuaire des marées → script → crontab
● A fonctionné pendant 2 saisons
● Dataloger :● Sans émission, stockage sur carte SDCard
21/26
Les huîtres à Arcachon
Huître 6 le 04/06/2010
Huître 7 le 04/06/2010
Huître 6 le 11/06/2010
Huître 7 le 11/06/2010
La 7 a été remplacée le 03/06 : noter la différence de comportement le 04/06 liée à l'acclimatation dans son nouvel environnement. Une semaine plus tard, tout va bien !
22/26
Les bénitiers à Ioro (NC)
Ouverts lorsqu'ils reçoivent le soleil, fermés le reste du temps.
23/26
Difficultés
● Electronique immergée dans l'huile● Un fusible 0.5 A est passé à 0.05 A au bout de 1 an
… moins pratique pour faire du GPRS !
● Modem GPRS qui exécute du code (proprio)● A la fâcheuse tendance de ne pas répondre à sa
pin reset … nécessite un power cycle
● Dérive de l'horloge● Resynchro NTP régulière
24/26
Difficultés
● Vérification de la connectivité● ping souvent bloqué● test par wget
● Prise de contrôle à distance par SSH● réseau opérateur routable● Ports < 1024 bloqués
● Pas de gsmmux● Pas de gestion du modem lorsque PPP est lancé
25/26
Perspectives● En 2010 : projet valvomètre v2 soutenu par la
région Aquitaine● 2 cartes organisées différemment :
– n « au fond » : analogique + acquisition et transfert par bus CAN (sur base micro-contrôleur ARM Cortex M3)
– une « en haut » : sur base module CPUIMX25 (ARM926EJ-S @ 400 MHz) avec tous les moyens de communication (bluetooth, RF 2.4GHz, GPRS, 3G+, satellite, Ethernet)
– Prise en compte de toutes les difficultés constatées sur le V1
● Consommation totale moyenne sur 24h : – entre 0.5 et 1W (contre 2W actuellement)
26/26
Merci pour votre attention
● Questions / réponses
● Le site du projet :– http://www.domino.u-bordeaux.fr/molluscan_eye/– mots clefs moteurs de recherche :
● oeil du mollusque
Merci à Jean Charles Massabuau et Pierre Ciretde l'équipe GEMA pour leurs photos et explications