Version du 21 décembre 2020 à 15:24

Présentation générale

Description

Aujourd’hui la qualité de l’air et plus globalement la pollution atmosphérique est un enjeu environnemental majeur, notamment dans le cadre du travail. Ce danger fait l’objet de préoccupations depuis plusieurs années et apparaît aujourd’hui comme un problème majeur de santé publique. Notre projet a pour objectif de répondre à cette problématique en proposant une analyse en temps réel de la qualité de l’air des locaux de Polytech. En effet, l’amélioration de la qualité de l’air passe en premier lieu par l’étude de celle-ci, il est primordial de connaître notre environnement avec précision.

Objectifs

Nos objectifs se séparent en 3 parties :

• Le développement de stations émettrices.

3 tailles de stations seront disponibles, pourvues de capteurs, une carte Nucléo-64 et d'un émetteur/récepteur Lora.

• La mise en place d’un réseau LoRaWaN.

Pour ce faire nous disposons de passerelle Kerlink permettant de faire le lien entre nos stations (end-points) et notre Network Serveur. Nous devrons bien évidemment mettre en place et configurer un Network Server. Les transmissions devront être privées et ce, grâce à un système de chiffrement (clé publique/clé privée).

• La récupération et l'affichage des données.

Le Network Server, commun à d'autres projets, transmettra ses données vers une base de données (Application Server). une application mobile et/ou web seront développées pour la consultation des données.

Prise en main du matériel

Transmission entre 2 cartes

Choix de l'IDE : Nous avons testé différentes IDE (Semtec, uVision, Mbed Studio, STM32). De par sa simplicité d'utilisation ainsi que de par la possibilité d'utiliser une version online nous avons privilégier l'utilisation de l'IDE Mbed pour effectuer nos tests. Cette IDE a d'ailleurs été utilisée dans d'anciens projets Polytech utilisant des émetteurs Lora et des cartes Nucléo.

Afin d'avoir une première manipulation de ces cartes et de l'IDE nous avons utilisé des programmes de démonstration du type "Ping/Pong". L'émission et la réception des données sont fonctionnelles entre 2 cartes Nucléo possédant des Antennes Lora.

Par la suite et sur demande de nos enseignants référents nous avons arrêté d'utiliser l'IDE Mbed pour partir sur l'IDE STM32. Cette IDE à l'avantage d'être plus bas niveau dans la configuration des pins mais elle dispose également de fonctions HAL (Hardware Abstraction Layer). Ce sont des fonctions qui ont été préalablement programmées par STMicroelectronics et qui nous permettent, par exemple, d'effectuer diverses opérations de lectures et d'écriture dans notre mémoire.

Test des différents capteurs

Nous disposons de plusieurs capteurs afin d'affiner nos données sur la qualité de l'air :

SEN0248 de chez DFROBOT, capteur de température, humidité, pression et gaz. L'envoie et la réception de données s'effectue via un bus I2C, il est donc nécessaire de fournir une clock à ce capteur.
https://wiki.dfrobot.com/Gravity__I2C_BME680_Environmental_Sensor__VOC,_Temperature,_Humidity,_Barometer__SKU__SEN0248

DFR0066 de chez DFROBOT, capteur de température et d'humidité. L'envoie et la réception de données se fait via une pin Data et SCK, nous devons également fournir une clock à ce capteur.
Datasheet : https://wiki.dfrobot.com/SHT1x_Humidity_and_Temperature_Sensor__SKU__DFR0066_

ULPSM-H2S de chez SPEC SENSOR, capteur de sulfure d'hydrogène
https://www.spec-sensors.com/wp-content/uploads/2016/10/ULPSM-H2S-968-003.pdf

T6713 de chez TELAIRE, capteur de C02
https://14core.com/wp-content/uploads/2017/11/T6700_Series_CO2_sensor_Module_Datasheet.pdf

EC4-2000-SO2 de chez SGX SensorTech, capteur de dioxyde de souffre
https://www.sgxsensortech.com/content/uploads/2014/07/DS-0243-EC4-2000-SO2-Datasheet-V2.pdf

Réseau LoRaWan

Network Server

Une machine virtuelle est déployée afin d'héberger le Network Server :

• Nom : lorawan.plil.info
• Mdp : glopglop

Cette machine est connectée à internet via l'interface eth0 et est relié au Vlan 501 (Lorawan) via l'interface eth1. Le Vlan501 comprend donc notre VM, la passerelle Kerlink Outdoor (sur le toit de l'école) et la passerelle Kerlink Indor.

Serveur DHCP

Les passerelles Kerlink doivent être connues sur notre réseau, elles doivent donc posséder leur propre adresse IP. Cette adresse IP leur est fournie par un serveur DHCP présent sur la carte réseau "eth1" de la VM lorawan. Pour ce faire nous créons un sous-réseau IPV4 192.168.42.0/24. Nous attribuons l'adresse 192.168.42.10 à la carte "eth1" et nous configurons le serveur DHCP de manière à attribuer dynamiquement des adresses IPV4 aux nouveaux appareils repérés sur le réseau.

Dans le fichier dhcpd.conf :
subnet 192.168.42.0 netmask 255.255.255.0 {
   range 192.168.42.1 192.168.42.9
}

Ce sous réseau permet d'attribuer des adresses IPV4 allant de 192.168.42.1 à 192.168.42.9.

Nous pouvons ainsi accéder à l'interface de configuration des passerelles Kerlink en ssh via l'adresse IP attribuée (Sur lorawan.plil.info) :

• Passerelle Outdoor : ssh 192.168.42.1, mdp: pdmk-062E7A)
• Passerelle Indoor : ssh 192.168.42.2, mdp: pdmk-030970)

Cette interface de configuration nous sera très utile lors de la configuration de notre Network Server.

Installation et configuration du ChirpStack Network Server

ChirpStack Network Server est une implémentation open-source de LoRaWAN® Network Server. La responsabilité du composant Network Server est la déduplication des trames LoRaWAN reçues par les passerelles LoRa® et de gérer :

- L'authentification

- La couche mac LoRaWAN (et commandes mac)

- La communication avec le serveur d'applications ChirpStack

- La planification des trames de liaison descendante

• Installation :

La mise en place de ce serveur sur la VM lorawan nécessite d'installer trois entités : un gateway-bridge, un network-server et un application-server

Pour se faire nous avons suivi les instructions du site officiel : https://www.chirpstack.io/network-server/

• Configuration :

Différents fichiers de configuration sont alors disponibles :

- /etc/chirpstack-gateway-bridge/chirpstack-gateway-bridge.toml

- /etc/chirpstack-network-server/chirpstack-network-server.toml

- /etc/chirpstack-application-server/chirpstack-application-server.toml

Paramétrages notables :
- Les trois serveurs démarrent automatiquement lors de l'allumage de la VM
- NetworkID : 000000

Nous avons alors un accès a une interface graphique de configuration sur le port 8080 pour notre LoRaWan_Network (accès 172.26.189.22:8080 (désactiver le proxy pour cette adresse)). Nous instancions alors notre network serveur sous le nom de localhost (localhost:8000).

• Configuration des passerelles Kerlink :

En connection ssh sur les gateways, nous mettons à jour le firmware des deux passerelles (Indoor : Wirnet iFemToCell et Outdoor Wirnet iBTS). Une fois l'environnement correctement installé, nous nous sommes appuyés sur le https://wikikerlink.fr/ pour activer les gateways ainsi que leurs packet_fowarder (https://wikikerlink.fr/wirnet-productline/doku.php?id=wiki:lora:keros_4.3.3:cpf_configuration). Nous instancions notamment notre LoraNetworkServer au sein de nos gateways via la ligne gwmp.node = "192.168.42.10" dans le fichier /etc/lorafwd.toml

• Instanciation des passerelles sur le LNS (LoraNetworkServer) :

Sur la VM lorawan, les logs nous montre bien l'émission de message en provenance de nos deux passerelles. Sur l'interface graphique de paramétrage, nous créons alors deux nouvelles instances de gateways en fournissant leur ID respective. Les gateways sont alors visible pour notre LNS et nous remarquons une émission de trame LoRaWan de façon régulière.

A ce point, nous avons un LNS installé, configuré, capable de détecter et communiquer en LoRaWan avec les passerelles au sein de son réseau. La dernière étape consiste donc à tester la transmission complète d'une trame, d'un terminal LoRa à l'application_server.

• Test du LNS :

Un module GPS LoRa est alors utilisé pour tester le bon fonctionnement de notre architecture.

Une nouvelle application GPS_Test est créée sur l'interface graphique du LNS, des "application" et "network" Keys sont alors générées et transmises manuellement à notre terminal LoRa. Une fois les clefs correctement transmises, nous sommes capables de recevoir les trames et données issue du GPS. Ces données ont donc transité au sein de nos passerelles Kerlink pour être finalement reçu par notre application_server.

Ceci conclu donc la mise en place du LoraNetworkServer, la prochaine étape consistant à connecter nos propres terminaux LoRa.

Stations

Implémentation du firmware

Suite à plusieurs tests et expérimentations et comme expliqué dans notre partie sur le choix de l'IDE, il a été décidé d'utiliser l'IDE STM32 Cube pour implémenter le firmware. Cette IDE permet en effet l'utilisation de bibliothèques de plus bas niveau que mbed et ainsi d'obtenir un meilleur contrôle de notre carte. Ce meilleur contrôle nous sera par ailleurs utile lors de l'implémentation des bus I2C pour la lecture de certains capteurs mais également lors de la mise en commun de nos différents bibliothèques relatives à nos capteurs.

Architecture du firmware

Dans un souci de modularité et de simplicité d'implémentation, notre firmware se découpera en deux parties. La première partie permettra la lecture de chaque capteur connecté à la station tandis que la seconde se chargera de transmettre toute ces données en LoRaWan. Afin de faciliter l'ajout ou le retrait de capteur sur une station établie l'architecture ci-dessous :

Il convient ainsi de créer, pour chaque capteur sur la station :

• Une fonction d'initialisation du capteur (startup séquence etc...), appelée au démarrage de la station.
• Une fonction de lecture spécifique à chaque capteur, appelée dans la boucle principale. Cette fonction de lecture se déroule en deux temps :
  • 1-Lecture du capteur (réception et prétraitement des données si besoin)
  • 2-Remplissage de la trame avec les données récupérées (en accord avec le format ci-contre)

Une fois la trame remplie, celle-ci est transmise à la fonction d'envoi, chargée de transmettre ces données par ondes radio.

Il est capital pour notre projet, avant toute lecture de capteur, d'être capable de transmettre des données vers notre LNS. Nous devons donc disposer d'une bibliothèque permettant de communiquer en respectant les normes d'un réseau LoRa. Cette bibliothèque existe et est disponible à l'adresse suivante : https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/i-cube-lrwan.html

Problèmes rencontrés :

La bibliothèque propose des programmes de communications LoRaWan uniquement pour des carte STM32L, non compatible avec notre STM32F411. Après avoir tenté durant plusieurs jours d'adapter le code de la bibliothèque et face à la complexité de la tâche, décision est prise d'utiliser des cartes compatibles avec notre librairie. Nos stations seront donc bâties sur des cartes STM32L152_RE.

Communication en LoRa

Sur l'interface du LNS :

• Nous créons donc une application "PFE_TheoLolo_2020"
• Nous y instancions un nouveau Device
• L'EUI Device doit correspondre à celui de notre carte, que l'on récupère via les logs de notre serveur.
• Generation d'une Application_key (MAIS PAS de Gen_Application_key qui doit être laissé vide)

Sur notre firmware :

• Ouverture du projet EndNode présent dans la librairie
• Modification du commisionning.h : MAJ de la LORAWAN_APP_KEY et de la LORAWAN_NTW_KEY (Ces deux clefs doivent être IDENTIQUES)

Une fois ces quelques paramètres ajustés, nous sommes capables de visualiser les données issues de notre carte sur notre LNS. La chaîne de communication est maintenant entièrement fonctionnelle. On peut donc pleinement se concentrés sur la lecture des capteurs et la mise en forme des données en amont ainsi que sur la récupération et l'affichage de ces données en aval.

Lecture des capteurs On dispose, pour notre projet, de nombreux capteurs différents, avec chacun un protocole de lecture définit (en principe) dans leur datasheet. Dans un souci

Application

Les données arrivant sur notre LNS doivent être transmises et traitées afin d'être présentées aux utilisateurs de l'application. La partie applicative de notre projet s'effectuera sur une VM nommée Lorap, afin de bien cloisonner la gestion du réseau LoRaWan (sur la VM lorawan) de la gestion applicative (traitement et affichage des données).

Réception et Gestion des données

On utilise le bus MQTT (Mosquitto) proposé dans les fichiers de configuration du LNS pour récupérer les données émises par nos stations. La configuration de cette file de message s'effectue donc dans le fichier /etc/chirpstack-application-server/chirpstack-application-server.toml de la VM lorawan. Par défaut, le MQTT serveur est disponible sur tcp://localhost(VMlorawan):1883. On installe mosquitto sur la VM lorap puis on implémente un script python chargé de récupérer et stocker les données à chaque nouveau message.

mosquitto.py :

• On souscrit un abonnement à la file de message MQTT 172.26.189.22:1883
• Une fonction d'écoute attend l'arrivée de message UP (arrivée de données sous format Json)
• On extrait l'EUI de la station émettrice ainsi que la trame de données des capteurs (en base64)
• Une fonction se charge d'extraire les informations de la trame (température, pression, etc...)
• Les données sont stockées au sein d'une base de donnée postgreSQL

Interface utilisateur

Questions du moment