Mini-plateforme pour l’évaluation de capteurs low-cost pour la mesure de la qualité de l’air
Bénéficiaire
- Service de l’air, du bruit et des rayonnements non ionisants (SABRA) de l’OCEV.
Contexte
La surveillance de la qualité de l’air extérieur est une des missions du SABRA. Le Réseau d’Observation de la Pollution Atmosphérique à Genève (ROPAG), composé par quatre stations de mesure fixes, de deux stations mobiles et près de nonante capteurs passifs de NO2, permet un suivi quotidien sur l’ensemble du canton. Bien que ces dispositifs produisent des mesures de qualité métrologique, un déploiement massif n’est pas envisageable à cause de leur coût élevé. Dans ce contexte, les capteurs low-cost constituent un complément intéressant aux stations de mesure de référence. Néanmoins, il est essentiel d’évaluer objectivement la qualité des mesures issues de ces capteurs, afin de déterminer l’adéquation avec les enjeux métiers ainsi que les usages éventuellement possibles.
Préambule
La documentation qui suit se focalise sur les apports de la DIT, qui ont concerné la collecte, traitement et restitution des données issues de mesures. Aux personnes souhaitant en savoir plus sur les questions métiers, nous recommandons de se rapprocher du SABRA.
Objectifs
Un premier lot de dix capteurs low-cost a été déployé début 2021. Ces capteurs utilisaient le protocole de communication LoRaWAN, issu du domaine de l’IoT (Internet of Things). L’un des premiers apports DIT au projet a été de faciliter la connexion des capteurs qualité de l’air au réseau LoRaWAN, appartenant aux Services Industriels de Genève (SIG). Rapidement, des mesures brutes de qualité de l’air ont commencé à être produites et remontées vers la plateforme du fabriquant des capteurs (à savoir Ecomesure), afin d’être transformées en mesures exploitables par les collaborateurs du SABRA. Ces derniers ayant besoin de consulter et d’évaluer les mesures dans le plus bref délai, il a été question de fournir une solution informatique permettant de :
- Collecter les données à partir de la plateforme du fabricant des capteurs,
- Les persister,
- Les restituer au SABRA sous forme
- Tabulaire et visuelle,
- Native (pas temporel égal à 10 minutes), mais aussi agrégée sur des plages de 30 minutes, 1 heure, 1 journée.
Aussi, le SABRA a exprimé le besoin de pouvoir comparer les mesures issues des capteurs low-cost avec celles produites par les stations de référence du ROPAG, par superposition visuelle ainsi que par la génération d’indicateurs objectifs (coefficient de corrélation de Pearson et racine de l’erreur quadratique moyenne). Il faut savoir qu’à cet effet les capteurs low-cost ont été physiquement installés au sein des stations de référence (en “colocation”). D’un point de vue informatique, il s’agissait de centraliser au sein d’une même solution les mesures low-cost et celles de référence, disponibles à partir d’une application métier utilisée par le SABRA.
Les éléments énumérés ci-dessus représentent les principaux objectifs de ce projet.
Par souci d’exhaustivité, il convient de préciser que, quelques mois après le début du projet, le protocole de communication LoRaWAN a été abandonné au profit d’une connexion par réseau de téléphonie mobile, afin d’augmenter la résolution temporelle (d’une mesure toutes les 10 minutes à un mesure par minute). À la fin de l’année 2021, quatre des dix stations initialement louées ont été achetées, puis équipées de ce mode de communication. La solution mise en place par la DIT a su suivre ce changement sans nécessiter aucun ajustement.
Méthodologie
La solution a été bâti à partir d’un socle s’occupant d’une tâche “simple”, pourtant incontournable et surtout urgente : la collecte et persistance des données. Sur la base de ce socle, une deuxième couche a été construite, responsable du traitement des données. L’architecture se complète par une troisième couche, permettant la visualisation et export des données. Les versions finales de ces trois couches sont illustrées par l’image suivante et décrites en détail dans les paragraphes suivants.
Tous les composants de cette mini-plateforme ont été déployés dans le cloud d’Infomaniak, par Docker Compose. Le déploiement initial et les montées de version ont été automatisés grâce aux fonctionnalités d’intégration continue offertes par GitLab.
Collecte et persistance des données
Dans un premier temps, les mesures issues de capteurs low-cost ont été récoltées
- Soit par téléchargement manuel à partir d’une interface,
- Soit par “push” via le protocole SFTP.
Nous avons fait recours à la 1ère option seulement ponctuellement, pour récupérer des petits échantillons. Autrement, un serveur SFTP a été déployé sur le SITG Lab. Le choix de l’application serveur SFTP s’est porté sur cet outil open source, s’agissant d’une solution bien sécurisées et très simple à déployer par Docker. Une configuration repartie entre ce serveur SFTP et la plateforme d’Ecomesure a permis d’établir le transit automatisé de données entre les deux systèmes, sous forme d’un fichier CSV par heure par capteur. Un composant spécifique, baptisé “Data Mover”, a été développé en langage Python, afin de déplacer les données de l’espace de stockage du serveur SFTP vers un espace accessible par interface S3, utilisant la solution open source MinIO, qui à l’époque était encore maintenu (aujourd’hui, d’autre choix pourrait être plus judicieux, p. ex. Garage ou SeaweedFS ou encore RustFS. Des solutions hébergées existent aussi, y. c. avec stockage garanti en Suisse). Indépendamment de l’implémentation retenue, il convient de souligner la pertinence d’une brique de type “Data Lake”, exposant une interface S3. En effet, l’interface S3 permet de faire abstraction de l’emplacement ou les données sont physiquement stockées ainsi que du système de fichier sous-jacent. Par conséquent, le code client (qu’il soit en lecture et/ou écriture) devient extrêmement “portable” (on dirait “cloud native”) et le confort des développeurs s’accroit.
Dans un deuxième temps, les mesures sont devenues accessibles à partir d’une API HTTP, au format JSON plutôt que CSV. Ainsi, un composant “Data Collector” a été développé en langage Python, permettant de collecter périodiquement les données et les stocker directement dans le Data Lake, sans besoin du composant Data Mover. Les données sont rangées dans le Data Lake selon une arborescence tenant compte de l’année, mois, jour et plage horaire de la collecte (voir image ci-dessous).
Une telle organisation facilite l’extraction d’échantillons, l’archivage, etc. Afin de garantir l’interopérabilité avec la couche suivante (transformation des données), le “Data Collector” produit également des fichiers au format CSV, respectant le même modèle des CSV précédemment fournis par la plateforme d’Ecomesure.
Il est à noter que plusieurs fonctionnalités spécifiques ont été implémentées au sein du Data Collector, afin de maximiser le taux de complétude des données collectées :
- Après un premier échec lors d’une requête donnée, quatre autres tentatives sont effectuées (avec un backoff factor).
- Si jamais la requête est toujours en échec au bout de ces cinq tentatives, alors un nouveau fichier (JSON) est écrit dans un répertoire local, incluant toutes les informations permettant de rejouer ultérieurement la même requête. Une tâche périodique itère sur les fichiers présents dans ce répertoire, rejoue les requêtes échouées et, en cas de succès, efface le fichier la concernant.
- Le code expose à son tour une API, implémentant
- Un point d’entrée permettant à l’utilisatrice ou utilisateur autorisé à déclencher une opération de backfilling, utile par exemple pour rattraper les données perdues durant une panne du Data Collector.
- Un point d’entrée de type “health check”, sur lequel un service tiers de monitoring a été branché, afin d’avertir l’exploitant en cas de problèmes de collecte dus à la plateforme émettrice. Le contrôle de santé tolère les indisponibilités connues de la plateforme émettrice, une fois par jour au sein d’une plage temporelle bien précise, dues à certaines opérations de maintenance. La fonctionnalité décrite au point 2 ci-dessus permet de récupérer les données manquantes ex-post. La “légalisation” de ces pannes, périodiques mais maitrisées, permet d’éviter des faux positifs dans les alertes.
Concernant la collecte des données de référence mesurées par les stations du ROPAG, une instance du Data Mover a été utilisée pour télécharger les données à partir d’un serveur FTP, une fois par heure, et les persister dans le Data Lake.
Il est à noter qu’une copie de chaque nouveau fichier CSV est déposée au sein d’un répertoire du Data Lake faisant office de boîte de dépôt. La raison apparaitra claire après la lecture de la section qui suit.
Traitement des données
Au-dessus du socle en charge de la collecte et persistance des données, une deuxième couche logique a été bâtie, ayant déjà une idée de la constitution de la troisième et dernière couche, celle permettant la visualisation et l’export des données, sous forme agrégée ou pas (détails ci-dessous). Les données pouvant atteindre une taille importante, en termes de nombre d’enregistrements encoure plus qu’en termes de volume en octets, il a été estimé judicieux de prévoir un composant de type “Data Warehouse”,
- Capable de filtrer et agréger efficacement les données selon plusieurs critères, par exemple afin de permettre d’extraire les mesures d’un capteur donné au sein d’une plage temporelle particulière, réduire la résolution temporelle par agrégations sur intervalles arbitraires (30 min., 1 heure, 1 jour, …), etc.
- Supportant des connexions à partir de clients de différente nature, en lecture et/ou écriture : outils de dashboarding, le langage de programmation Python (utilisé à la fois par la DIT et le SABRA), etc.
Le choix pour ce composant s’est porté sur la base de données PostgreSQL, s’agissant d’une solution
- Offrant toutes les capacités attendues,
- Open source,
- Très qualitative,
- Supportée par Grafana (l’outil pressenti pour le dashboarding - détails ci-dessous),
- Sur laquelle la DIT a beaucoup plus d’expérience que d’autres solutions libres (p. ex. MySQL).
Une fois PostgreSQL choisi, un programme Python a été spécifiquement développé, faisant office d’ETL (Extract Transform Load). Lors de la première exécution, le programme génère le modèle de données souhaité au sein de la base. Autrement, le programme observe (“watches”) périodiquement deux sous-répertoires du Data Lake jouant le rôle de boîte de dépôt, traite les fichiers qu’il y trouve et les supprime après le traitement (à moins qu’une erreur ne soit survenue).
Les traitements appliqués aux données sont relativement simples :
- Certaines colonnes sont renommées pour améliorer la lisibilité (p. ex. “RH” devient “relative_humidity”, “WD” -> “wind_direction”).
- Les éventuelles valeurs nulles dans différentes colonnes sont toutes modélisées de la même manière (p. ex. “No signal” -> “NULL”, “N/A” -> “NULL”).
- On s’assure que les horodatages soient bien interprétés (fuseau horaire, horaire été/hiver).
- Des identifiants abrégés sont générés, afin de faciliter la définition de filtres sur les capteurs.
Des colonnes supplémentaires de type booléen ont été prévues en base de données, afin de permettre aux experts métier du SABRA d’invalider certaines mesures et/ou toutes les mesures issues d’un même capteur à un instant donné, par exemple pour tenir compte des cas de figure où le capteur serait en maintenance auprès du fabriquant. À cet effet, un rôle avec droit d’écriture sur ces colonnes a été créé est affecté à qui de droit.
Visualisation et export des données
Grafana est un logiciel open source très répandu, particulièrement adapté à la réalisation de tableaux de bord alimentés par des séries temporelles et consultables à partir d’un navigateur. La prise en main est relativement simple. En termes de typologie d’indicateurs restitués et de réactivité de l’interface, le résultat final dépend essentiellement des capacités offertes par la/les source(s) de données sous-jacentes. Dans le cas ci-documenté, Grafana a été connecté à la base PostgreSQL. Ainsi, les indicateurs attendus par les experts métier du SABRA ont pu être construits et visualisés dans Grafana simplement en préparant des requêtes SQL : les opérations de filtrage et agrégation (p. ex. dans le temps) sont toutes déléguées à PostgreSQL, Grafana se charge de l’affichage de diagrammes et permet certaines interactions (choix de la plage temporelle, interrogation des mesures au survol de la souris, affichage/masquage de courbes issues de tel ou tel autre capteur, etc.). La configuration d’index dans la base de données a permis d’améliorer sensiblement la rapidité de l’affichage. Il convient de rappeler qu’à la fois les mesures des capteurs low-cost et des capteurs de référence ont été chargées dans PostgreSQL, afin de permettre la comparaison directement dans Grafana, qualitative par superposition visuelle ainsi que quantitative par le biais d’indicateurs comme la corrélation de Pearson (calculée en SQL). Un tableau de bord spécifique a été réservé à la supervision du taux de disponibilité des capteurs et de complétude des données.
Un deuxième outil, Adminer, a été déployé et connecté à PostgreSQL afin de permettre aux experts du SABRA de
- Consulter les mesures sous forme tabulaire,
- Les exporter au format CSV,
- Les invalider.
Il s’agit d’un client supportant différentes bases de données et exposant une interface web. En dépit de son approche très minimaliste, Adminer a su répondre aux besoins métier.
Résultats
À ce jour, plus que 10 millions d’enregistrements (environ 6 Go) ont été collectés, persistés dans le Data Lake, traités et poussés dans PostgreSQL, chacun comportant différentes mesures (température, humidité, concentration de NO2, O3, particules fines, etc.). Bien qu’il ne s’agisse pas de “Big Data”, le volume des données dépasse largement celle qui serait traitable par un logiciel de type tableur.
Les stratégies de reprise automatique sur échec ont permis d’atteindre un taux de complétude de données presque total, avec peu d’interventions humaines. Les capacités d’agrégation offertes par PostgreSQL ont permis de générer différents indicateurs à la volée, évitant ainsi le besoin de pré-générer plusieurs séries temporelles avant l’intégration en base, avec les risques de 1. jamais en avoir assez, 2. devoir tout régénérer après l’invalidation d’un ou plusieurs enregistrements par les experts métiers.
La solution a réussi à suivre le projet tout au long de ses différentes phases, moyennent des ajustements qui n’ont comporté aucune perte de données. Par exemple, à partir d’un certain moment le modèle de données a pu être très facilement étendu, afin d’englober aussi des mesures corrigées par des algorithmes d’IA.
Grâce à la plateforme ci-documentée les experts métiers du SABRA ont pu évaluer la qualité des mesures effectuées par les capteurs low-cost et faire remonter des retours pertinents au fabriquant, dans une logique d’amélioration continue. Une partie des analyses ont été effectuées directement au sein de la plateforme, d’autres par des solutions tierces (Python, PowerBI) maîtrisées par le SABRA en passant par l’export au format CSV (obligé, étant la base de données PostgreSQL déployée dans le cloud et donc pas joignable depuis l’Intranet).
Enseignements
Le choix d’architecturer la solution en plusieurs couches, en partant d’un socle fortement dépendant des sources de données spécifiques à ce projet et terminant par une couche faisant intervenir exclusivement des composants sur étagère, s’est avéré très concluant. Plus en particulier,
L’utilisation d’un composant de type “Data Lake” a permis de sécuriser la persistance des données “brutes” dans un délai très bref, avant que d’ultérieures spécifications en permettent l’intégration en données : la disponibilité d’une copie “maîtresse” laisse tout le temps pour concevoir les modèles de données répondant aux enjeux métiers et les chaînes de traitement permettant d’aligner les données source sur la cible.
L’utilisation d’un composant de type “Data Warehouse” a permis d’assurer l’interopérabilité avec différentes solutions restituant les données sous forme de diagramme (Grafana) ou de tableau (Adminer), ainsi que la prise en charge efficace des opérations de filtrage, agrégation à la volée et indexation sans aucun besoin de code spécifique.
Il est à noter que la collecte de données s’est avérée bien moins banale que prévu, l’API exposant les données étant en panne une fois par jour pour maintenance et aussi aléatoirement pour des raisons inconnues : des automatismes programmés au niveau du “Data Collector” ont permis d’éviter des interventions humaines qui auraient été fastidieuses et nullement intéressantes d’un point de vue intellectuel.
Recommandations
L’outil Grafana est déjà utilisé à l’Etat de Genève pour la supervision de composants IT, mais aucune offre de service n’existe permettant l’utilisation de Grafana pour la visualisation d’autres typologies de données. Bien que des alternatives propriétaires puissent offrir des capacités équivalentes voire meilleures, nous trouvons pertinent que l’opportunité d’une adoption plus large de Grafana (open source) au sein de l’Etat de Genève soit étudiée.
Le découpage Data Lake / Data Warehouse s’est avéré très pertinent, surtout en raison de la nature très dynamique des données concernées par le projet ci-décrit : si ce n’est déjà pas le cas, nous recommandons fortement l’adoption d’une même approche dans les solutions étatiques portant sur les séries temporelles.
La collecte de données peut s’avérer être une tâche complexe. Ainsi, la possibilité d’implémenter de logiques métiers par du code spécifique devient un aout indéniable. Pourtant, nous reconnaissons au moins un manque dans la solution conçue pour ce projet, celui d’une sorte d’orchestrateur/superviseur des tâches assurant la collecte de données et, pourquoi pas ?, de celles chargeant les données en base (ETL) à partir du Data Lake. L’outil open source Windmill se présente, sur papier, comme un très bon candidat pour palier le manque fonctionnel. Ainsi, nous en recommandons l’évaluation, soulignant l’intérêt d’un outil aussi “agnostique”, puisque capable d’exécuter des programmes écrits en différents langages (Python, TypeScript, PHP, …) aussi bien que des programmes encapsulés dans des images Docker.