PFE Iot

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR
ET DE LA RECHERCHE SCIENTIFIQUE
Institut Supérieur Polytechnique Privé
*******
Projet de Fin d’Etudes

En vue de l’obtention du Diplôme National d’Ingénieur en Mécatronique
Elaboré par :
Frigui Ahmed
SMART BUILDING
Réalisé au sein de
Sofia HOLDING
Encadré par
Encadrant(s) universitaire(s) Encadrant(s) industriel(s)
AHMED BOUGHANMI Mr.NIZAR MERTAH

Mr. MOHAMED KARIM BALI
Année universitaire
2018 - 2019
Dédicaces
Je dédie ce travail en témoignage de mon profond respect, mon grand amour
et toute ma gratitude à :
Mes chers parents,
Les membres de ma famille,

Mes amis,
Et tous ceux qui m’ont soutenu de près ou de loin.
Frigui Ahmed
i
Remerciements
Je tiens en premier lieux de remercier la société SOFIA HOLDING qui m’a
offert l’opportunité de développer mes connaissances et il m’a mis dans le

chemin de la vie pratique ainsi tous les personnes de la société et plus
spécialement nos encadrants Mr.NIZAR MERTAH et Mr.MOHAMED

KARIM BALI pour ses conseils et son encouragement.
Nos profondes gratitudes s’adressent en particulier à notre encadreur

universitaire Mr. AHMED BOUGHANMI qui m’a donné de son temps et il
m’a toujours suivi par ces conseils.

On n’oublie pas de remercier nos parents, nos familles qui ont fait des
sacrifices énormes pour qu’on puisse arriver là où nous sommes.

Ainsi que toute personne ayant aidé de loin ou de près à la réussite de ce
projet, qui reçoivent l’expression de nos sincères reconnaissances et gratitudes.

Enfin, je tiens à apprécier l’honneur que m’a fait les membres du jury pour
avoir accepté de m’accorder leur attention et pour l’évaluation de mon travail.
ii
Table des matières
Introduction générale 1
1 Contexte général 3
1.1 Contexte de stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Présentation de la société d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 SOFIA Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 iFarming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 Sofia Europa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 Sofia Academy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.5 Sater Solar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Objectif du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.1 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.2 Comparaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.3 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.4 Comparaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.6 Synoptique de la solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.7 Travail Demandé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.8 Choix méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.8.1 Méthode Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.8.2 Méthode adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.8.3 Avantages de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.8.4 Les sprints du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.9 Planification du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2 Etat de l’art et spécification des besoins 19

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Internet des objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
iii
2.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2 Domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.3 Gateway IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 LoRa et LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.1 Technologies de communication sans fil . . . . . . . . . . . . . . . . . . . . . . 23
2.3.2 LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.3 LoRaWan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.1 Les besoins fonctionnels externes du projet . . . . . . . . . . . . . . . . . . . 27
2.4.2 Les besoins fonctionnels internes du projet . . . . . . . . . . . . . . . . . . . 28
2.4.3 Cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.5 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3 Sprint 1 : Réalisation d’un noeud weather station 33

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.1 Planification du SPRINT 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.2 Environnement de développement STM32 . . . . . . . . . . . . . . . . . . . . 35
3.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4.1 Diagramme d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4.2 Schéma Fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.3 Diagramme de flux de données . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.5.1 Matériels nécessaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.5.2 Développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5.3 Image Reel de l’end device Weather Station . . . . . . . . . . . . . . . . . . . 44
3.5.4 Expérimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4 Sprint 2 : Réalisationd’un noeud smart water 47

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
iv
4.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.2 Protocoles de communications . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.1 Diagramme d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.2 Schéma Fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4.3 Diagramme de flux de données . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5 Realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5.1 Decodage de payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5.2 Matériels nécessaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5.3 Développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5.4 Image Reel de l’end device Smart Water . . . . . . . . . . . . . . . . . . . . . 59
4.5.5 Expérimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5 Sprint 3 :Prototypage 62
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.5 Realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.5.1 CURA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.5.2 Configuration du logiciel cura . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Conclusion générale 67
6 ANNEXE 69
v
Table des figures
1.1 Logo Entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 L’organigramme de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 iFarming logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Sater Solar logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Principe de fonctionnement de technologie laser . . . . . . . . . . . . . . . . . . . . . 9
1.6 Principe de fonctionnement de Water and fish quality . . . . . . . . . . . . . . . . . . 10
1.7 Le schéma fonctionnel du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8 WeatherShop weather station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.9 WS-2902A Smart WiFi Weather Station . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.10 Synoptique de la solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.11 Processus Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.12 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1 architecture IoT Smart Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2 Smart City . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Smart City . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 architecture de gateway IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 Technologies de la communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6 Stack de protocole LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7 Architecture du réseau LoraWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.8 Classes de LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.9 Bête à Corne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.10 Diagramme Pieuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.11 Diagramme de FAST FP1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.12 Diagramme de FAST FP2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.13 Diagramme de Cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.14 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1 Sprint Backlog<Réalisation d’un End Device> . . . . . . . . . . . . . . . . . . . . . 34

3.2 Diagramme d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
vi
3.3 Schéma Fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4 Diagramme de flux de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.5 Image Reel de l’End Device Weather Station . . . . . . . . . . . . . . . . . . . . . . 45
3.6 image de dashboard weather station . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1 Sprint Backlog<Réalisation d’un End Device> . . . . . . . . . . . . . . . . . . . . . 48

4.2 Diagramme d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3 Schéma Fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4 Diagramme de flux de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5 Enregistrement d’un Device profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.6 Enregistrement d’un nouveau Device LoRa . . . . . . . . . . . . . . . . . . . . . . . . 53
4.7 Configuration de l’enregistrement du Device LoRa (en OTAA) . . . . . . . . . . . . . 54
4.8 Résumé du cheminement des trames LoRaWan en Uplink . . . . . . . . . . . . . . . 55
4.9 Réception des trames des Devices LoRa . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.10 Decodage de payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.11 Image Reel de l’End Device Smart Water . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1 Sprint Backlog<prototypage> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2 conception du boitier Smart Water . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3 conception du boitier weather station . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4 conception du shutter weather station . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5 configuration de CURA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
vii
Liste des tableaux
1.1 Tableau Comparatif des solutions existants . . . . . . . . . . . . . . . . . . . . . . . 11

1.2 Tableau Comparatif des solutions existants . . . . . . . . . . . . . . . . . . . . . . . 14
1.3 Les sprints du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1 Fonction des Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1 Planification du SPRINT 3 <Réalisation d’un End Device> . . . . . . . . . . . . . . 35

3.3 Materiels Necessaires pour la partie RF LoRa . . . . . . . . . . . . . . . . . . . . . . 42
3.4 Les differentes capteurs utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5 Tableau de mesures de differentes capteurs . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3 Materiels Necessaires pour la partie RF LoRa . . . . . . . . . . . . . . . . . . . . . . 57
4.4 Les differentes capteurs utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.5 Tableau de mesures de differentes capteurs . . . . . . . . . . . . . . . . . . . . . . . . 61
viii
Liste des abréviations
— ABP = Activation By Personnalisation
— ADC = Analog Digital Converter
— BW = Bande Passante
— CR = Coding Rate
— CSS = ChirpSpread Spectrum
— HTTP = Hyper Text Transfer Protocol
— IOT = Internet des Objets Things
— ISM = Industrial, Scientific and Media
— JSON = JavaScript Object Notation
— LAN = Local Aange Network
— LPWAN = Low Power Wide Area Network
— LoRa = Long Range
— OTAA = Over The Air Activation
— RTC = Real Time Clock
— WAN = Wide Area Network
ix
Introduction générale
Le chemin emprunté par la technologie est celui où un monde totalement moderne se trouve à
une fin inaccessible. Nous avons la chance de vivre dans un monde aussi diversifié, riche en nouvelles
technologies et opportunités. L’un des concepts impliquant pour atteindre un monde moderne est
IOT. Avec les solutions basées sur l’IoT, nous nous rapprochons d’un monde entièrement automatisé,
doté de capteurs, d’appareils connectés, d’actionneurs, de modules, de passerelles, permettant de
suivre et d’optimiser les ressources, la consommation d’énergie et de fournir une assistance toute la
journée.
Cette nouvelle vague de connectivité ne se limite pas aux ordinateurs portables et aux
téléphones intelligents, elle s’oriente vers les voitures connectées, les maisons intelligentes, les wearables
connectés, les villes intelligentes et les soins de santé connectés. Fondamentalement, une vie connectée.
Selon le rapport de la fondation allemande Statisca en 2019, d’ici à 2020, les appareils connectés,
toutes technologies confondues, atteindront 30,37.
Les Smart Buildings d’aujourd’hui commencent à tirer parti de l’Internet des objets pour
obtenir de meilleurs résultats, notamment une meilleure efficacité énergétique. Ils peuvent contenir
des milliers de capteurs mesurant divers paramètres de fonctionnement du bâtiment, notamment
la température, l’humidité, l’occupation, la consommation d’énergie, la fumée, les inondations, la
sécurité, les ascenseurs et la qualité de l’air et l’eau.
Ces capteurs collectent une énorme quantité de données qui doivent être transmises, stockées,
analysées et utilisées en temps réel, pour offrir une expérience de bâtiment réellement intelligente.
Ces actions sont capables d’exercer un contrôle sur l’environnement et la sécurité des bâtiments.
Notre objectif est d’aider à surmonter les obstacles technologiques existants des Smart Buildings.
Il existe plusieurs contraintes et points à améliorer qui nous empêchent d’avancer parmi
lesquels on peut citer, le manque des bâtiments automatisé intelligent, le système de HVAC (chauffage,
ventilation et climatisation), la maintenance prédictive, la surveillance de la qualité de l’eau et air,
la consommation énorme d’Energie et le manque d’outils de gestion et de contrôle des bâtiments.
Ce projet a été lancé dans le département Innovation de la société Sofia Holding. Au cours
duquel, nous avons créé une plateforme basée sur LoRaWAN offrant des connexions entre les
différents objets connectés (Weather Station, Green Land, Smart Camera, Sofia Salle Système,
HVAC et Smart Water) et le Cloud. À travers une étude de cas approfondie, nous proposons un
1
Introduction générale
modèle d’architecture IoT intégrée pouvant être utilisé pour développer une solution pour les Smart
Buildings.
Ce rapport comportera un chapitre de contexte général suivi d’un chapitre état de l’art et
spécification des besoins, ensuite, nous aurons trois chapitres dans lesquels nous avons travaillé selon
la méthodologie agile scrum, entre autre le 3éme et 4éme chapitre qui contiennent la réalisation
d’un nœud Weather Station et un nœud Smart Water et le chapitre 5 ou nous avons présenté les
Prototypes des boitier des deux nœud et pour finir nous avons résumé notre travail et exposer les
travaux futurs possibles dans une conclusion générale.
2
Chapitre 1
Contexte général
Plan
1 Contexte de stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Présentation de la société d’accueil . . . . . . . . . . . . . . . . . . . . . . 4
3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 Objectif du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6 Synoptique de la solution proposée . . . . . . . . . . . . . . . . . . . . . . 14
7 Travail Demandé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8 Choix méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9 Planification du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Chapitre 1. Contexte général
Introduction
Dans ce premier chapitre nous allons dans un premier temps présenter le contexte de notre
projet et la société d’accueil, par la suite, nous détaillerons la problématique, ainsi que les principaux
objectifs du projet en passant par l’étude de l’existant, la solution proposée ,le travail demandé et
la méthodologie de développement, et pour finir, nous exposerons un planning de notre projet d’une
durée de 6 mois.
1.1 Contexte de stage
Afin de valider notre formation acquise au sein de l’Université Libre de Tunis (ULT), nous
avons réalisé ce projet de fin d’étude dans le but d’obtenir le diplôme d’ingénieur en Mécatronique.
Nous nous sommes engagés avec l’organisme Sofia Holding qui est une société d’ingénierie et de
services IT spécialisée dans le développement de logiciels embarqués, des systèmes d’information,
des solutions Cloud et Internet des objets, pour la réalisation d’une solution IoT pour Smart Building
en utilisant la technologie LoRa.
1.2 Présentation de la société d’accueil
Fondée en 2016, SOFIA Holding est une société spécialisée dans la recherche et l’innovation
en électronique et génie logiciel. Il a 5 filiales :
— Sofia technologies
— Sofia Europa
— Sofia Academy
— iFarming
— Sater Solar
La figure 1.1 présente le logo de l’entreprise.
4
Figure 1.1: Logo Entreprise
1.2.1 SOFIA Technologies
SOFIA Technologies est une filiale de SOFIA Holding, opérant dans le domaine informatique
et spécialisée dans le développement de solutions cloud et IoT (Internet of Things). Sofia Technologies
a réalisé plusieurs projets dans de nombreux secteurs d’activité.
1.2.1.1 Secteurs d’activité
— Electronics : grâce à leur expertise des différents outils EDA (Electronic Design Automation),
l’équipe de Sofia Technologies est capable de réaliser tout type de système électronique, de la
phase de recherche à la phase finale, validation, en passant par les étapes de conception, de
simulation, d’intégration, de suivi de production et de fabrication des tests électroniques.
— Software : les experts en technologies de Sofia en technologies de l’information s’assurent que

leurs logiciels sont conformes aux normes en assurant l’intégrité des données et des informations
échangées.
1.2.1.2 Départements
— Département des systèmes électroniques : composé de 5 employés, ce département est

spécialisé dans l’analyse des spécifications, la conception et la simulation, le prototypage (PCB
et PCBA), les tests (évolutifs et fonctionnels) et l’industrialisation.
— Département des systèmes embarqués : Ce département est chargé de la création et de

la conception de logiciels et d’applications intégrés en fonction des besoins du projet. Il est
composé de 25 personnes.
— Département systeme d’information : experts en industrialisation, configuration, optimisation

et développement d’applications serveur,également dans la migration et le support de plate-forme.
5
— Developpement d’affaires et veille strategique : dans lequel on a passé notre stage de

fin d’etude
1.2.1.3 L’organigramme de l’entreprise
La figure 1.2 présente l’organigramme de l’entreprise :
Figure 1.2: L’organigramme de l’entreprise
1.2.2 iFarming
Créée en Tunisie, iFarming est également une filiale de Sofia Holding.créé en 2017 et est
basé à Tunis. iFarming opère dans les domaines agricole, environnemental et alimentaire, il a créé
de nombreux sites Web et applications mobiles basées sur l’Internet des objets et l’intelligence
artificielle.
La figure 1.3 présente le Logo de IFarming :
Figure 1.3: iFarming logo
6
1.2.3 Sofia Europa
Basé à Paris, en France, Sofia Europa est une extension des Sofia technologies.
1.2.4 Sofia Academy
Une filiale de Sofia Holding, chargée de dispenser une formation pour développer le logiciel
compétences à l’intérieur et à l’extérieur de Sofia Holding. Les domaines de formation de l’Académie
Sofia sont directement liés aux domaines de Sofia Holding et de ses sociétés filiales. Les sessions de
formation sont assistées par des professionnels et des experts formés, environnements professionnels,
opérant sur des projets réels.
1.2.5 Sater Solar
Crée en 2007, Sater Solar a rejoint Sofia Holding en juin 2017. Elle est spécialisée dans le
marketing et installation de panneaux photovoltaïques. Il est basé à Tunis et à Sfax.
La figure ci-dessous Figure 1.4 représente le Logo de Satar Solar :
Figure 1.4: Sater Solar logo
1.3 Problématique
L’année 2019 est arrivée avec des attentes encore plus grandes vis-à-vis des technologies de
Smart Buildings. La croissance de l’Internet des objets (IoT) s’accélérera en 2019. Bien au-delà
d’un supplément optionnel, l’IoT est devenu un élément central des plans visant à tirer parti de
l’innovation technologique dans les Smart Buildings.
Posséder une station météo personnelle dans un Smart Building est l’un des moyens de rester
au sommet des tendances technologiques qui concernent la météo. Oui, vous pouvez ouvrir une
application qui peut vous donner une estimation heure par heure de la météo, mais ces informations
proviennent d’une station distante de plusieurs kilomètres et datant de plus d’une heure.
Avec une station météo qui se trouve à l’extérieur de votre bâtiment, vous obtenez des
7
informations exactes à la minute près.

Les conditions climatiques extrêmes sont devenues une réalité dans le monde entier en raison
des feux de forêt et des sécheresses. aux inondations et aux tsunamis qui se propageant partout
dans le monde et deviendront un moteur essentiel de l’innovation dans les bâtiments intelligents en
2019. La protection des bâtiments commerciaux et industriels deviendra un secteur de croissance
important, car de plus en plus de propriétaires d’immeubles prendront des mesures calculées dans
la conception et la construction de leurs bâtiments pour atténuer les dommages environnementaux.
Au 21 e siècle, l’approvisionnement en eau potable pure devient un défi majeur dans le
monde entier. Il est essentiel dans l’agriculture, l’industrie, le transport, la production d’énergie, la
fabrication et les batiments intelligentes. Les impacts humains sur les systèmes aquatiques dus au
développement socio-économique, y compris l’urbanisation, la croissance industrielle, l’expansion de
l’agriculture et la pollution qui en résulte, ont atteint un niveau où la qualité de l’eau est devenue
un facteur limitant du développement. L’inquiétude mondiale croissante suscitée par la pollution de
l’eau a créé un besoin urgent de données fiables et opportunes sur la qualité de l’eau. Cela nous laisse
aujourd’hui avec des problèmes de qualité de l’eau aussi divers que l’eutrophisation, l’acidification,
les métaux lourds dans le biote et le poisson, les nitrates dans les eaux souterraines, la contamination
microbienne des eaux de boisson et les pesticides accumulés tout au long de la chaîne alimentaire.
donc la surveillance de la qualité de l’eau fait passer les bâtiments intelligents à un niveau supérieur.
Alors quels sont les moyens qui nous permettent de savoir la qualité d’eau exacte, les changements
climatiques dans les Smart Buildings ? Quels sont les éléments de cette opération ? Ce sont autant
de question que nous allons essayer de résoudre tout au long de notre projet.
1.4 Objectif du projet
L’objectif de notre projet est de concevoir, d’étudier et réaliser une solution IoT pour les
Smart Buildings pour la surveillance de la qualité de l’eau et les changements climatiques baseé sur
la Technologie LoRa.
Pour réaliser cet objectif, nous allons commencer par la conception des objets connectés
contenant un ensemble des capteurs specifiques ainsi la construction de notre propre Gateway LoRa
pour acheminer les données vers notre serveur privé distant.
En faisant ensuite le stockage des informations dans les differentes base de données et en
migrant vers un Cloud privé a fin de visualiser les données dans une application web IoT intelligente.
8
1.5 Etude de l’existant
Cette étape est l’une des principales étapes lors de la réalisation d’un projet. Elle nous a
permis d’identifier les points faibles de la solution actuelle pour pouvoir y pallier et concevoir une
application qui répond aux besoins de ses utilisateurs en offrant des fonctionnalités plus riches et
plus développées qui permettront à l’utilisateur une utilisation simple et fluide.
1.5.1 Analyse de l’existant
1.5.1.1 Smart Water
Il existe de nombreux exemples de solutions de Smart Water. On peut citer :
— La technologie laser
— Water and fish quality libelium
— Geetha and Gouthami india Smart Water
1.5.1.2 La technologie laser
L’une des méthodes actuellement disponibles pour la surveillance du niveau de la qualité

de l’eau en utilisant des images ultraviolettes (UV), visibles ou infrarouges (IR).Les scanners sont
principalement utilisés comme capteurs dans la région visible du spectre [1].
Les principes de La Technologie Laser sont illustrés dans la figure 1.5 :
Figure 1.5: Principe de fonctionnement de technologie laser
9
1.5.1.3 Water and Fish Quality Libelium
Il a été déployé à la source d’approvisionnement en eau et également à l’intérieur de la

pisciculture. La qualité de l’eau et du poisson est contrôlée par les paramètres suivants (Temperature,
Conductivity, Disolved Oxygen (DO) et pH). Les Capteurs communiquent avec le Gateway via 3G /
GPRS et 802.15.4. Les informations collectées sont envoyées au Cloud via 3G et WiFi. La plate-forme
utilisée pour visualiser les données est PioT-SW, une application cloud qui permet de contrôler en
temps réel le niveau de différents paramètres et d’obtenir des diagrammes montrant leur évolution
[13].
La figure 1.6 présente le principe de fonctionnement de Water and fish quality :
Figure 1.6: Principe de fonctionnement de Water and fish quality
1.5.1.4 Geetha and gouthami india smart water
Les principaux paramètres surveillés dans le système proposé sont la conductivité, la turbidité,
niveau d’eau et pH. Le schéma fonctionnel du système proposé est présenté à la figure 1.7.
Les paramètres du capteur tels que la conductivité, la turbidité, le niveau d’eau et le pH sont
mesurés en plaçant le capteur dans différentes solutions d’eau.Les paramètres mesurés peuvent être
visualisés à l’aide de l’écran LCD. Les données des capteurs sont envoyées au nuage en utilisant le
contrôleur. Le seuil est défini dans le cloud en fonction des normes fournies par l’OMS.Le message
est envoyé du cloud au mobile de l’utilisateur si la valeur dépasse le seuil.
Une application mobile a été développée dans laquelle les valeurs obtenues par chaque capteur
du nuage peut être visualisé. Cela peut être utilisé à la fois par la qualité de l’eau autorités de contrôle
ainsi que les utilisateurs [14].
10
La figure 1.7 ci-dessous représente le Le schéma fonctionnel du système :
Figure 1.7: Le schéma fonctionnel du système
1.5.2 Comparaison
Afin de comparer ces différentes solutions et d’extraire leurs spécifications. Nous avons établi
un tableau récapitulatif qui résume les différentes caractéristiques des solutions étudiées et les
principaux points à prendre en considération dans le tableau 1.1 :
Tableau 1.1: Tableau Comparatif des solutions existants

Critéres/Solutions Technologie Laser Water and Fish Quality Libelium India Smart Water
Technologie Reseau non 3G /GPRS /WIFI WIFI
Securité non TLS non
Consommation d’energie elevée elevée elevée
Portée courte longue courte
Cloud non privé Open source
Temp Reel oui oui oui
Protocole non LAN /Cellulaire LAN
Capteurs non oui oui
1.5.2.1 Weather Station
Il existe de nombreux exemples de solutions de Weather Station. On peut citer :
— WeatherShop
— WS-2902A Smart WiFi Weather Station
11
1.5.2.2 WeatherShop
WeatherShop a créé une solution personnalisée exclusive au problème de la surveillance de

la météo sur un site distant avec la station météo cellulaire.En utilisant un adaptateur spécialisé
prenant en charge presque tous les fournisseurs de données cellulaires avec une couverture 3G, le
système entièrement autonome et entièrement automatisé, fonctionnera sans surveillance partout où
il y a une couverture de réseau cellulaire.
Une page Web complète de station météo prête à fonctionner, contenant les données les plus
récentes, ainsi un archivage automatique des données.Le système de batterie solaire à double panneau
alimentera la station météo et émetteur-récepteur jusqu’a 4 jours dans l’obscurité totale [15].
la figure 1.8 suivante montre le weather station de WeatherShop
Figure 1.8: WeatherShop weather station
1.5.2.3 WS-2902A Smart WiFi Weather Station
La WS-2902 mesure la vitesse et la direction du vent, les précipitations, la température

extérieure, l’humidité extérieure, le rayonnement solaire et les rayons UV, la température intérieure,
l’humidité et la pression barométrique.Cet station se connecte via le Wi-Fi, ce qui permet de lire
toutes les informations lors de déplacements surle téléphone portable, tablette ou ordinateur [16].
la figure 1.9 suivante montre le weather station de WS-2902A Smart WiFi Weather Station
12
Figure 1.9: WS-2902A Smart WiFi Weather Station
1.5.3 Critique de l’existant
Les systèmes existants de la surveillance du qualité d’eau et de changement climatiques ne

se trouve pas pour le moment ensemble dans une seule solution dedié pour les smarts buildings.
De plus ils ne peuvent pas détecter tous les parametres necessaires pour l’analyse de la
qualité d’eau, manque de securité, courtes portée d’envoi des données pour quelques systemes avec
une consommation d’energie tres elevés.
Le développement d’un solution de surveillance en ligne en temps réel est très important pour
empêcher la futures maladies liées à l’eau .
1.5.4 Comparaison
Afin de comparer ces différentes solutions et d’extraire leurs spécifications. Nous avons établi
un tableau récapitulatif qui résume les différentes caractéristiques des solutions étudiées et les
principaux points à prendre en considération dans le tableau 1.2 :
13
Tableau 1.2: Tableau Comparatif des solutions existants
Critéres/Solutions WeatherShop WS-2902A Smart WiFi Weather Station
Technologie Reseau cellulaire 3G WIFI
Securité oui non
Consommation d’energie elevée elevée
Portée longue courte
Cloud non open source
Temp Reel oui oui
Protocole Cellulaire LAN
Capteurs oui oui
1.6 Synoptique de la solution proposée
Nous présentons dans la figure 1.10 l’architecture de notre solution proposé qui contient
plusieurs parties que nous allons expliquer par la suite :
Figure 1.10: Synoptique de la solution proposée
— End Device : Smart Water c’est l’élément qui prend la décision de tout et qui contient
14
les capteurs nécessaires pour avoir des informations sur la qualité d’eau. Ils comprennent un
capteur de co2, un capteur température/humidité exterieur, un capteur de pH, conductivité,
luminosité et un capteur de temperature d’eau.
— End Device : Weather Station c’est l’élément qui prend la décision de tout et qui contient
les capteurs nécessaires pour avoir des informations sur les changements climatiques. Ils comprennent
un capteur température/humidité exterieur, un pluviomètre, un capteur de vitesse et direction
du vent.
— Gateway : constituent le passerelle entre l’end device et notre serveur privé LoRa.
— Backup Gateway : constituent la 2eme passerelle entre l’end device et notre serveur privé
dans le cas de panne de gateway principale.
— Serveur privé : fournit le composant réseau-serveur LoRaWAN, responsable de la gestion de

l’état du réseau. Il a connaissance des end devices actifs sur le réseau et est capable de gérer
les demandes de jointure lorsque des end devices souhaitent rejoindre le réseau.
— backup base de données : la base de données va servir à stocker les informations pour mieux
les manipuler et pour avoir toujours une copie. Cette base de données va être installée sur un
serveur locale.
— Firebase : permet de sauvegarder et synchroniser les données avec notre base de données
NoSQL temps reel.Ils sont synchronisées en temps réel sur tous les clients et restent disponibles
lorsque votre application se déconnecte.
— Private Cloud : c’est une plateforme cloud fiable et évolutive qui s’exécute sur notre infrastructure.
Il propose des services communs pour le déploiement en libre service.
— Application Web IoT : sert a visualiser et controler les données stockées dans la base de
données a distance.
— Applications Mobiles (Android et IOS) : Le rôle de deux application mobile est qu’ils
permettent à l’utilisateur de consulter les informations enregistrées dans la base a distance et
d’une façon plus lisible.
1.7 Travail Demandé
Les taches à déterminer sont les suivantes :
15
— Réaliser une communication LoRa entre les objets connectés et notre serveur privé en utilisant
le protocole LoRaWan.
— Réaliser un End Device Weather Station pour mesurer la vitesse et direction du vent , le niveau
de Pluit ainsi que la température et l’humidité de le environnement, et il est capable d’envoyer
les données des capteurs vers notre serveur privé.
— Réaliser un End Device Smart Water pour mesurer la temperature et l’humidité de l’air, CO2,
rayon solaire (luminosite), le pH d’eau, la conductivité et la temperature de l’eau et il est
capable d’envoyer les données des capteurs vers notre serveur privé aussi.
— Conception et impression des boitiers en 3D de chaque objets.
1.8 Choix méthodologique
La finalisation du projet dans les délais de livraison est le souci majeur de chaque équipe de
développement. L’un des problèmes plus fréquemment lors de la réalisation de projet est la mauvaise
spécification et le changement brusque des besoins. Cela peut non seulement mener l’équipe de
développement en créant un environnement de stress, mais aussi le temps consacré pour la réalisation
du projet et donc des délais de livraison dépassées. A fin d’éviter ces situations critiques, nous
adoptons la méthodologie agile pour la gestion de notre projet.
1.8.1 Méthode Agile
Les problématiques que nous avons mentionnées précédemment nous ont poussé à réinventer
les méthodes de gestion de projet et de conception en introduisant ce qu’on appelle les méthodes
agiles consistent en une approche incrémentale et itérative, menée dans un esprit collaboratif, avec
juste ce qu’il faut de formalisme. Elle peut générer un produit de bonne qualité tout en prenant en
compte l’évolution des besoins des clients. En suivant cette approche, le projet est conçu dans son
ensemble et peut être construit étape par étape.
1.8.2 Méthode adoptée
Parmi les méthodes agiles, nous citons Scrum que nous avons choisie pour les raisons suivantes :
— Scrum est la méthodologie suivie par la société Sofia Holding pour la gestion de ses projets.
— Scrum est une méthode dédiée à la gestion de projets de développement de produits complexes.
16
Ce Framework s’appuie sur le découpage d’un projet en boîtes de temps nommées Sprints.Ces
sprints peuvent durer entre quelques semaines et un mois. Chaque sprint commence par une estimation
suivie d’une planification opérationnelle. Le sprint se termine par une démonstration de ce qui a été
achevé.
La figure 1.11 décrit le processus de fonctionnement de la méthode Scrum :
Figure 1.11: Processus Scrum
1.8.3 Avantages de Scrum
La méthode Scrum assure plusieurs avantages :
— Compréhension du travail et des tâches à accomplir : La fragmentation du projet en

plusieurs petites parties réalisables.
— Transparence : Scrum exige de la transparence. Les membres de l’équipe doivent savoir ce

que les autres accomplissent et le résultat qu’ils peuvent en attendre.
— Deadlines intégrées : Comme le projet est subdivisé et que des tâches très spécifiques
peuvent être attribuées aux membres de l’équipe, on intègre chaque jour des échéances pour
évaluer l’avancement des uns et des autres. Cela implique que tout le monde doit assumer ses
responsabilités.
— Visibilité continue : Travailler de manière efficace n’est possible que si nous conservons une
vue d’ensemble est restons organisés.
1.8.4 Les sprints du projet
Dans notre projet, nous avons cinq principaux sprints décrits dans le tableau 1.3 suivant :
17
Tableau 1.3: Les sprints du projet
Sprints Description
Sprint 1 Réalitation d’End Device weather station
Sprint 2 Réalitation d’End Device Smart Water
Sprint 3 Prototypage
1.9 Planification du projet
Pour bien accomplir nos taches dans le temps qui nous a été contraint, nous avons réalisés
un planning afin de mieux organiser notre travail puis pour faciliter la réalisation du projet dans les
meilleurs délais, et dans de bonnes conditions. La planification se présente dans la figure 1.12 :
Figure 1.12: Diagramme de Gantt
Conclusion
Dans cette première partie, nous avons mis le projet dans son contexte et préciser l’organisation
de notre travail. Dans le chapitre suivant, nous décrirons l’etat de l’art , en parlant par la suite sur
la spécification des besoins de la solution proposée.
18
Chapitre 2
Etat de l’art et spécification des

besoins
Plan
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2 Internet des objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 LoRa et LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Chapitre 2. Etat de l’art et spécification des besoins
2.1 Introduction
Dans ce chapitre, nous commençons par une étude de la technologie d’internet des objets,
étudier en détail la technologie LoRa et LoRaWAN, afin de definir les specifications des besoins.
2.2 Internet des objets
2.2.1 Introduction
L’Internet des objets, ou IoT fait référence à des milliards de périphériques physiques à
travers le monde connecté à Internet, collectant et partageant des données. Grace aux processeurs et
réseaux sans fil bon marché, il est possible de tout transformer. Cela ajoute un niveau d’intelligence
numérique aux dispositifs leur permettant de communiquer sans implication humaine, et la fusion
des mondes numérique et physique [1].
2.2.2 Domaine d’application
L’IoT a de nombreuses applications, mais nous allons couvrir 3 applications [2] .
2.2.2.1 Smart Home
Chaque fois que nous pensons aux systèmes IoT, l’application la plus importante et la plus
efficace qui se démarque à chaque fois est le classement Smart Home en tant qu’application IoT
la plus élevée sur tous les canaux. Le nombre de personnes à la recherche de maisons intelligentes
augmente chaque mois avec environ 60 000 personnes. Une autre chose intéressante est que la base
de données de maisons intelligentes pour IoT Analytics comprend 256 entreprises et startups. Plus
d’entreprises sont maintenant être activement impliqué dans les maisons intelligentes que d’autres
applications similaires dans le domaine de l’Internet des objets.
20
Figure 2.1: architecture IoT Smart Home
2.2.2.2 Smart City
La ville intelligente, comme son nom l’indique, est une très grande innovation et couvre une
grande variété de cas d’utilisation, de la distribution de l’eau à la gestion du trafic, en passant par la
gestion des déchets, la surveillance de l’environnement et la sécurité urbaine. La raison pour laquelle il
est si populaire est qu’il essaie de supprimer l’inconfort et les problèmes que rencontrent les citadins.
Les solutions IoT proposées dans la zone de la ville intelligente résolvent divers problèmes liés à
la ville, notamment la circulation, réduisent la pollution atmosphérique et sonore et contribuent à
rendre les villes plus sûres
Figure 2.2: Smart City
21
2.2.2.3 Ehealth
L’IoT a diverses applications dans le secteur de la santé, qui vont des équipements de
surveillance à distance aux capteurs avancés et intelligents, en passant par l’intégration d’équipements.
Il a le potentiel d’améliorer la manière dont les médecins dispensent les soins et de garder les patients
en sécurité et en bonne santé. Healthcare peut permettre aux patients de passer plus de temps
avec leur médecin pour communiquer l’engagement et stimuler la satisfaction des patients. Des
capteurs de condition physique personnels aux robots chirurgicaux, l’IoT dans le secteur de la santé
apporte de nouveaux outils mis à jour avec la dernière technologie de l’écosystème, contribuant au
développement de meilleurs soins de santé.
Figure 2.3: Smart City
2.2.3 Gateway IoT
Une passerelle IoT est une solution permettant la communication IoT, généralement des
communications entre device-to-device ou device-to-cloud. La passerelle est généralement un périphérique
matériel hébergeant une application logicielle effectuant des tâches essentielles. Au niveau le plus
élémentaire, la passerelle facilite les connexions entre différentes sources de données et destinations.
Un moyen simple de concevoir une passerelle IoT consiste à la comparer à votre routeur ou passerelle
réseau domestique ou professionnel. Une telle passerelle facilite la communication entre vos appareils,
maintient la sécurité et fournit une interface d’administration où vous pouvez exécuter des fonctions
de base [3].
22
La figure 2.3 ci-dessous montre l’architecture de gateway IoT :
Figure 2.4: architecture de gateway IoT
2.3 LoRa et LoRaWAN
2.3.1 Technologies de communication sans fil
En fonction de l’application, des facteurs tels que la portée, les exigences en matière de
données, la sécurité, les exigences en matière d’alimentation et la durée de vie de la batterie dicteront
le choix d’une technologie ou d’une combinaison de technologies. Voici quelques unes des principales
technologies de communication proposées aux développeurs. Une représentation des différences entre
les technologies sans fil à faible consommation d’énergie au débit et au niveau de la portée est presenté
dans la figure suivante :
Figure 2.5: Technologies de la communication
23
2.3.2 LoRa
LoRa est une communication longue portée à faible débit de données utilisant une technologie
sans fil à plate-forme basse consommation et longue distance pour la construction d’un réseau IoT. Il
utilise le spectre radio sans licence dans les bandes industrielle, scientifique et médicale (ISM) pour
permettre la communication entre capteurs et passerelles connectés au réseau Serveurs et serveurs
d’applications [4].
2.3.3 LoRaWan
La technologie brevetée de radiofréquence LoRa est le protocole de couche physique. Bien que
LoRaWAN, développé par LoRa Alliance, représente le protocole de la couche de contrôle d’accès aux
supports, qui exploite et inclut la modulation physique LoRa de Semtech. Les réseaux LoRaWAN,
utilisant le protocole LoRaWAN, sont proposés par plus de 70 opérateurs de réseau. Des déploiements
LoRaWAN IoT sont également déployés dans plus de 100 pays (y compris les réseaux privés) [4].
Figure 2.6: Stack de protocole LoRaWAN
2.3.3.1 Topologie LoRaWAN
L’architecture de réseau LoRaWAN est déployée dans une topologie en étoile dans laquelle les
passerelles envoient les messages entre les terminaux et un serveur de réseau central. Les passerelles
sont connectées au serveur de réseau via des connexions IP standard et agissent comme un pont
transparent, convertissant simplement les paquets RF en paquets IP et inversement.
24
La communication sans fil tire parti des caractéristiques à longue portée de la couche physique
LoRa, permettant ainsi une liaison à un seul saut entre le terminal et une ou plusieurs passerelles.
Tous les modes sont capables de communication bidirectionnelle, et les groupes d’adressage multidiffusion
sont pris en charge pour une utilisation efficace du spectre lors de tâches telles que les mises à niveau
FOTA (Firmware Over-The-Air) ou d’autres messages de distribution en masse [4].
Figure 2.7: Architecture du réseau LoraWAN
— End Devices : Les nœuds sont généralement :
* Capteurs (utilisés pour détecter le paramètre changeant, par exemple température, humidité,
accéléromètre, gps)
* Transpondeur LoRa pour la transmission de signaux via une transmission radio LoRa.
* Un micro-contrôleur.
— Gateway LoRa : Les périphériques de passerelles sont toujours connectés à une source
d’alimentation. Les passerelles connectées au serveur de réseau via des connexions IP standard
agissent comme un pont transparent, convertissant simplement les paquets RF en paquets IP
et inversement.
— Network server :Le serveur de réseau gère tout le réseau. Lorsqu’il reçoit des paquets, il
supprime la redondance des paquets et effectue un contrôle de sécurité, puis détermine la
passerelle la plus appropriée pour renvoyer un message d’accusé de réception.
— Application Server :Il est responsable de la partie «inventaire» du périphérique d’une

infrastructure LoRaWAN, du traitement de la demande de jointure ainsi que du traitement
25
et du chiffrement des charges utiles des applications. Il offre une interface Web permettant de
gérer les utilisateurs, les organisations, les applications et les périphériques. Pour l’intégration
avec des services externes, il propose une API RESTful et gRPC. Les données de l’appareil
peuvent être envoyées et / ou reçues via MQTT et HTTP.
2.3.3.2 Les classes de LoRaWAN
LoRaWAN dispose de trois classes pour couvrir un large éventail d’applications [5]. L’utilisation
prévue pour chacune des classes d’appareils est résumée dans la figure 2.8 ci-dessous
Figure 2.8: Classes de LoRaWAN
— Classe A : Puissance la plus basse, appareils terminaux bidirectionnels.
— Classe B : Dispositifs terminaux bidirectionnels avec latence déterministe pour la liaison

descendante.
— Classe C : Latence la plus basse, périphériques finaux bidirectionnels.
2.4 Analyse des besoins
Il s’agit d’exprimer avec précision le but et les limites de l’étude. Pour cela on peut utiliser
la représentation « bête à corne » figure 2.9 suivant :
26
Figure 2.9: Bête à Corne
2.4.1 Les besoins fonctionnels externes du projet
L’analyse fonctionnelle externe, décrit le système du point de vue de l’utilisateur et ne

s’intéresse au produit qu’en tant que "boîte noire" capable de fournir des services dans son environnement
durant son cycle d’utilisation. Cette étude consiste à analyser le besoin auquel devra répondre le
produit, les fonctions de service qu’il devra remplir, les contraintes auxquelles il sera soumis.
Les besoins fonctionnelle sont les services qui doivent être offrent par notre système.
2.4.1.1 Diagramme pieuvre
Le diagramme de « Pieuvre » met en évidence les relations entre les différents éléments du
milieu environnant et le produit. Ces différentes relations sont appelées les fonctions de service qui
conduisent à la satisfaction du besoin.
Les fonctions principales (FP) expriment obligatoirement des relations d’interaction (relations,
par l’intermédiaire du produit, entre au moins deux composants au milieu enivrant. Ils expriment
comment le produit aide à faire modifier l’état d’un intéracteur par un autre.
Les fonctions de contraintes (FC) expriment obligatoirement des relations d’adaptations, de
réaction ou de résistance (relation entre le produit et un élément du milieu environnant).
27
Figure 2.10: Diagramme Pieuvre
Les fonctions de services sont detaillé dans le tableau 2.3 ci dessous :

Tableau 2.1: Fonction des Services
Fonction de Services Expression de la fonction
FP 1 Permettre a l’utilisateur la surveillance de la qualité d’eau en temps reel
FP 2 Permettre à l’utilisateur la surveillance de les changements climatiques
FC 1 Respecter les normes de sécurité.
FC 2 Être moins chère.
FC 3 Être très fiable et simple à utiliser.
FC 4 Utiliser l’énergie électrique disponible.
FC 5 Assurer une connexion sans fil.
2.4.2 Les besoins fonctionnels internes du projet
L’analyse fonctionnelle interne privilégie le point de vue du concepteur, chargé de construire

un produit réel à partir d’un cahier des charges donné. Elle propose une décomposition conduisant
l’expression fonctionnelle du besoin à la définition des solutions constructives. Pour déterminer ou
optimiser des solutions constructives, cette analyse utilise un outil de description : le diagramme
FAST.
2.4.2.1 La technique d’analyse fonctionnelle et systématique (FAST)
Pour rechercher le maximum de solutions, il est nécessaire de procéder à une recherche

progressive et descendante des fonctions techniques à partir de chacune des fonctions de service.
L’outil permettant de réaliser et de visualiser cet enchaînement s’appelle le FAST. Le modèle FAST
28
se présente sous forme d’un arbre fonctionnel établi à partir de la fonction globale ou d’une fonction
de service, en s’appuyant sur la technique interrogative suivante : Pourquoi ? Cette fonction doit être
assurée Quand ? Et comment ?
Dans la figure 2.11 on montre le diagramme FAST de la fonction principale FP1 :
Figure 2.11: Diagramme de FAST FP1
Dans la figure 2.12 on montre le diagramme FAST de la fonction principale FP2 :
29
Figure 2.12: Diagramme de FAST FP2
2.4.3 Cas d’utilisation global
Pour mieux comprendre notre système, nous avons réalisé le diagramme figure 2.13 ci dessous
pour donner une vision globale du comportement fonctionnel du système :
30
Figure 2.13: Diagramme de Cas d’utilisation global
2.5 Backlog produit
Le Backlog produit est la liste des besoins et exigences que veut le client classé par ordre
de priorité. Il doit être rédigé avant les Sprints, dans la phase de préparation (Sprint 0) .Il permet
de décomposer le problème en des sprints à réaliser un par un . A la fin de chaque sprint, il faut
toujours livrer un produit partiel fonctionnel. La figure 2.14 présente le Backlog produit de notre
projet :
31
Figure 2.14: Backlog produit
Conclusion
Le réseau LoRaWAN est l’un des réseaux LPWAN les plus fiable dans le marché, répond
aux exigences de notre solution smart building et il est assez disponible dans le marché local. Nous
présenterons dans le chapitre suivant le premier sprint detaillé sur la realisation d’un end device
weather station. C’est un chapitre très important dans notre rapport, car il permet de planifier et
encadrer le reste des étapes dans lesquelles nous avons divisé le reste des tâches sur 3 Sprints.
32
Chapitre 3
Sprint 1 : Réalisation d’un noeud

weather station
Plan
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Chapitre 3. Sprint 1 : Réalisation d’un noeud weather station
3.1 Introduction
Dans ce sprint nous allons essayer de concevoir et réaliser notre end device Weather Station
pour collecter les données de différente capteurs (vitesse et direction du vent, niveau de pluie,
température/humidité) afin de les envoyer vers notre serveur privé en utilisant la Technologie LoRa.
3.2 Sprint Backlog
Ce Sprint Backlog représenté sur la figure 3.1 ci-dessous comporte l’ensemble des modules
suivants :
Figure 3.1: Sprint Backlog<Réalisation d’un End Device>
3.3.1 Planification du SPRINT 3
L’end Device weather station doit offrir les fonctionnalites suivante :
34
Tableau 3.1: Planification du SPRINT 3 <Réalisation d’un End Device>
ID Titre Description
1 collecter les données de differente L’end device doit collecter les données
capteurs. de capteurs : température/humidité,
vitesse et direction du vent, niveau de
pluie en utilisant un STM32L0
2 envoyer les données vers le le serveur L’end device doit communiquer avec
privé en utilisant la Technologie LoRa. le Gateway en utilisant la modulation
LoRa à travers USI LoRa module. Par la
suite le Gateway va diffuser les données
vers notre serveur privé.
3.3.2 Environnement de développement STM32
3.3.2.1 Outils de développement logiciel
— Programmation en C pour systèmes embarqués :
Nous pouvons définir au sens large un système embarqué comme un système de contrôle en
temps réel, fiable, piloté par logiciel, basé sur un microcontrôleur et conçu pour exécuter une
tâche spécifique. Il peut être considéré comme un système informatique comportant un logiciel
intégré. Un système embarqué peut être soit un système indépendant, soit une partie d’un grand
système C’est le langage de programmation le plus utilisé pour les processeurs/contrôleurs
embarqués En raison de la large acceptation de C dans les systèmes embarqués, divers types
d’outils de support comme les compilateurs et les compilateurs croisés, ICE, et plus se produit.
Et ils ont tous facilité développement de systèmes embarqués utilisant C.
— Interface de développement :
EWARM signifie IAR Embedded Workbench pour ARM, c’est un environnement de développement
qui inclut un compilateur et un débogueur C/C++.
— STLINK Debugger :
Le ST-LINK/V2 est un débogueur/programmeur en circuit pour les microcontrôleurs STM8

et STM32. Le module d’interface monofilaire (SWIM) et les interfaces JTAG / débogage série
35
(SWD) facilitent la communication avec tout microcontrôleur STM8 ou STM32 fonctionnant

sur une carte application.
3.3.2.2 Couches Drivers STM32
— LL Drivers :
Les Drivers LL offrent des services matériels basés sur les fonctionnalités disponibles des
périphériques STM32. Ces services reflètent exactement les capacités matérielles. Les services
LL ne sont pas basés sur des processus autonomes et ne nécessitent aucune ressource mémoire
supplémentaire pour sauvegarder leurs états, compteurs ou pointeurs de données. En fait,
toutes les opérations sont effectuées par le changement du contenu des registres périphériques
associés. En comparaison avec le HAL, les API LL ne sont pas fournies pour les périphériques
[10].
— HAL Drivers :
La couche pilote HAL fournit un ensemble générique d’APIs (interfaces de programmation

d’application) simples à plusieurs instances pour interagir avec la couche supérieure (application,
bibliothèques et piles). Les API des Drivers HAL sont divisés en deux catégories : les API
génériques qui fournissent des fonctions communes et génériques pour toutes les séries STM32
et les API d’extension qui incluent des fonctions spécifiques et personnalisées pour une famille
ou un numéro de pièce donné. Les Drivers HAL sont orientés fonctionnalités plutôt qu’IP. Par
exemple, les API de minuterie sont divisées en plusieurs catégories suivant les fonctions offertes
par l’IP : minuterie de base, capture, modulation de largeur d’impulsion (PWM), et ainsi de
suite [10].
— BSP Drivers :
Dans les systèmes embarqués, un BSP (Board Support Package) est la couche logicielle contenant
des Drivers spécifiques au matériel et d’autres routines qui permettent à un système d’exploitation
particulier (traditionnellement un système d’exploitation en temps réel ou RTOS) de fonctionner
dans un environnement matériel particulier (ordinateur ou carte CPU), intégré avec le RTOS
lui-même [10].
3.3.2.3 Configuration de l’horloge
— RCC PLL :
36
LL est un moteur de génération d’horloge dans le MCU qui est utilisé pour générer la vitesse
d’horloge lorsque l’horloge interne n’est pas suffisante. Dans MCU, la plupart des périphériques
comme USB, Ethernet PHY peuvent pas fonctionner si vous horlogez le MCU par HSI basse
vitesse ou HSE. Ainsi, dans ces cas, vous pouvez prendre l’aide de PLL [9].
3.3.2.4 Cristaux internes et externes
— HSE HSI :
Dans un bref aperçu, la différence majeure entre HSI et MSI est que HSI est un cristal qui
ne délivre qu’une seule fréquence, c’est pourquoi nous devons utiliser PLLL pour générer
d’autres fréquences, mais la MSI peut générer plusieurs fréquences (environ 12 fréquences dans
STM32L467RG) donc pas besoin de PLL [7].
3.3.2.5 Timer
En général, la plupart des timers STM32 sont composées d’un compteur de rechargement
automatique 16 bits et d’un prescaler 16 bits. Le prescaler est responsable de diviser le signal
d’horloge entrant d’une source d’horloge selon nos besoins. Le compteur de rechargement automatique
est utilisé pour charger les registres de temporisation des MCU 8 bits. La seule chose exceptionnelle
à son sujet est sa fonction de rechargement automatique. Dans les anciens MCU 8 bits, nous avions
besoin de recharger la minuterie après chaque interruption ou après chaque débordement. Ceci
n’est pas nécessaire dans les STM32s car il est géré automatiquement. Contrairement à la plupart
des autres MCU dans lesquels les minuteries comptent habituellement de façon incrémentale, les
minuteries STM32 peuvent compter vers le haut, vers le bas ou alignées au centre. Pourtant, dans
la plupart des applications, le comptage à la hausse est susceptible d’être supérieur à celui des
autres méthodes.A l’exception des timers de base, tous les timers STM32 ont quatre canaux E/S
indépendants (TIMx-CH1 - TIMx-CH4) [7].
3.3.2.6 Interruptions
Une interruption est un mécanisme matériel qui permet au processeur de détecter si un

périphérique nécessite son attention. L’unité centrale dispose d’une ligne de demande d’interruption
de fil qui est vérifiée par l’unité centrale après l’exécution de chaque instruction. Lorsque l’unité
centrale détecte un signal d’interruption sur la ligne de demande d’interruption, elle arrête sa
tâche d’exécution en cours et répond à l’interruption envoyée par le dispositif d’E/S en passant
37
la commande au gestionnaire d’interruption. Le gestionnaire d’interruptions résout l’interruption en

assurant la maintenance de l’appareil. Bien que le CPU ne soit pas au courant du moment où une
interruption peut se produire, car elle peut se passer à tout moment, mais il doit y répondre chaque
fois qu’elle se produit [7].
3.3.2.7 RTC
Le module Real Time Clock du STM32 est utilisé comme une horloge qui a ce format
heure/min/secs. Pour atteindre la consommation d’énergie minimale et pour fournir une base de
temps très précise, le module RTC est réglé pour réveiller le MCU alternativement en utilisant un
événement [7].
3.3.2.8 UART /USART
UART signifie Universal Synchronous/Asynchronous Receiver Transmitter En communication

UART, deux UART communiquent directement entre eux. L’UART émetteur convertit les données
parallèles d’un dispositif de commande tel qu’une unité centrale de traitement en données série,
puis les transmet en série à l’UART de réception, ce dernier convertit ensuite les données série en
parallèle. Pour l’appareil récepteur. Les UART diffèrent des USART dans le sens ou ils n’orent pas
de contrôle de flux matériel ou de contrôle de flux de fonctionnement synchrone ou émulation de
carte à puce [7].
3.3.2.9 LPUART
Le récepteur asynchrone universel de faible puissance transmis (LPUART) est un UART qui
permet des communications UART Full-duplex avec une consommation limitée. Seule une horloge
LSE de 32,768 kHz est nécessaire pour permettre des communications UART jusqu’à 9600 bauds/s.
Même lorsque le microcontrôleur est en mode Stop, le LPUART peut attendre l’arrivée d’une trame
UART tout en ayant une consommation d’énergie extrêmement faible. Le LPUART inclut tout
le support matériel nécessaire pour rendre possible les communications série asynchrones avec une
consommation d’énergie minimale. Il prend en charge les communications monofilaire semi-duplex et
les opérations par modem (CTS/RTS). Il prend également en charge les communications multiprocesseurs
[8].
38
3.4 Conception
3.4.1 Diagramme d’activité
Le diagramme d’activité est un diagramme comportemental d’UML, permettant de représenter

le déclenchement d’événements en fonction des états du système et de modéliser des comportements
parallélisables. Il té est également utilisé pour décrire un flux de travail, donc voici les etapes de
deroulement de notre end device Weather Station dans le figure 3.2 ci-dessous suivante :
Figure 3.2: Diagramme d’activité
39
3.4.2 Schéma Fonctionnel
C’est une représentation graphique simplifiée de notre end device weather station impliquant
plusieurs unités ou étapes. Il est composé de blocs connectés par des lignes d’action quicontiennent
les éléments suivants :
Figure 3.3: Schéma Fonctionnel
— Les capteurs : : Leurs rôles est la mesure des grandeurs suivantes : température et humidité
de l’environnement, la vitesse et la direction du vent ainsi que le niveau de pluie.
— La carte de Commande : la carte STM32L4
— Module Radio LoRa (USI) : c’est la carte de communication RF LoRa .
— USART : Universal Synchronous/Asynchronous Receiver Transmitter peut communiquer de

façon synchrone.
— Serveur Privé : c’est notre serveur LoRa.
— MQTT : (Message Queuing Telemetry Transport) est un protocole de messagerie publish-subscribe

basé sur le protocole TCP/IP.
— LoRaWan : LoRaWAN est un protocole de télécommunication permettant la communication

à bas débit, par radio, d’objets à faible consommation électrique communiquant selon la
technologie LoRa .
40
3.4.3 Diagramme de flux de données
Le diagramme de flux de données est un type de représentation graphique du flux de données,

il est également utilisé pour visualiser le traitement de données (structured design).
La figure 3.4 ci-dessous montre le diagramme de flux de données de notre systeme :
Figure 3.4: Diagramme de flux de données
3.5 Réalisation
3.5.1 Matériels nécessaires
3.5.1.1 Interface Radio LoRa
Le Tableau 3.3 ci-dessous représente le matériel nécessaire pour la partie RF LoRa de notre
end device :
41
Tableau 3.3: Materiels Necessaires pour la partie RF LoRa
Image de Composant Nom Caractéristiques

— ARM 32-bit
R Cortex -M0+
R CPU
— Frequence de CPU Max 32 MHz
— STM32L4 — VDD de 1.65 V à 3.6 V
NUCLEO — 4 KB Flash
— 2-bit ADC avec 16 cannals
— VDD de 1.65 V à 3.6 V
— Ce module sans fil LPWAN (low-cost,

low-power wide area module) prend en
— USI LORA
charge le protocole sans fil longue portée
LoRaWAN en utilisant les AT Commandes
3.5.1.2 Les Capteurs Necessaires :
on represente dans le tableau 3.4 les differentes capteurs utilisés pour la realisation de notre
end device, en premier lieu ces capteurs nous ont donnés des valeurs avec des unités standard
américaines, nous les avons par la suite convertis et nous avons eu les résultats suivants :
42
Tableau 3.4: Les differentes capteurs utilisés

— capteur de Température et Humidité
— Alimentation : 3,3 à 6 Vcc
— Consommation maxi : 1,5 mA
— Plage de mesure :
— DHT22
- température : -40 à +80 C
- humidité : 0 à 100
— VDD de 1.65 V à 3.6 V
— c000direction du vent, degré
— s000vitesse du vent (1 minute), 0.1 miles

per hour
— APRS — g000vitesse du vent (5 minutes), 0.1 miles
interface per hour
weather — t086temperature, Fahrenheit

station — r000niveau de pluie (1 hour), 0.01 inches
— p000niveau de pluie (24 hours), 0.01 inches

h53humidité, 00 et 100 (Pourcentage)
— b10020pression atmosphérique ,0.1 hpa
3.5.2 Développement
Notre tâche principale était en premier lieu d’établir les communications suivantes :
— Communication entre STM32 et USI, C’est une communication USART base sur des AT
Commande
— Communication entre STM32 et APRS interface weather station, Après la réalisions de la

communication USART, on reçoit une trame de donnée sur 35 bits qui contient les données
43
collecter depuis les capteurs de l’interface Weather Station : vitesse et direction du vent et
niveau de pluie.
— DHT22 Sur Stm32, Le DHT22 communique en série 1 fil avec un protocole spécial, et fournit
une indication de température sur 16 bits et une indication d’humidité sur 16 bits également.
On peut redemander une mesure toute les secondes.
En seconde lieu nous avons fait face à un véritable défi pour atteindre la consommation de
courant la plus basse possible de l’end device.
— Nous avons essayé avec différents modes de faible consommation (Sleep mode, Stop mode, Run
mode) et on a eu les résultats suivants :
• Stop mode avec une consommation du 7 A.
• Sleep mode avec une consommation de 70 A.
• Run mode avec une consommation 32 mA.
Et finalement nous avons choisi le stop mode car c’est celui qui répond le plus au besoin du
client.
3.5.3 Image Reel de l’end device Weather Station
La figure 3.5 ci-dessous montre une image reel de l’end device Weather Station :
44
Figure 3.5: Image Reel de l’End Device Weather Station
3.5.4 Expérimentation
Dans ce tableau 3.5 ci-dessous nous avons testé notre End Device Weather Station et nous
avons obtenu les resultats suivantes :
45
Tableau 3.5: Tableau de mesures de differentes capteurs
valeurs
Données
E (East)
Direction de vent
23
Vitesse de vent ( km/h)
24.1
Temperature (C)
59.2
Humidite (pourcentqge)
0
Niveau de pluie (mm)
La figure 3.6 ci-dessous montre le dashboard de notre weather station :
Figure 3.6: image de dashboard weather station
3.6 Conclusion
On a pu concevoir et réaliser notre propre end device Weather Station qui a pour role de
collecter les donnees pour les envoyer vers notre serveur prive puis les sauvegarder dans les bases de
donnees et Cloud.
46
Chapitre 4
Sprint 2 : Réalisationd’un noeud

smart water
Plan
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5 Realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Chapitre 4. Sprint 2 : Réalisationd’un noeud smart water
4.1 Introduction
Dans ce sprint on essayera de concevoir et réaliser notre end device smart water pour collecter
les données de differente capteurs (pH, EC, temperature d’eau, temperature/humidité exterieur, Co2,
luminosité) afin de les envoyer vers notre serveur privé en utilisant la Technologie LoRa.
4.2 Sprint Backlog
suivants :
Figure 4.1: Sprint Backlog<Réalisation d’un End Device>
L’end Device Smart Water doit offrir les fonctionnalites suivante :
48
1 collecter les données de differente l’end device doit collecter les données
capteurs. de capteurs : pH, EC,temperature
d’eau, temperature/humidité exterieur,
Co2 , luminosité en utilisant un
microcontroleur de l’STM32L4 Nucleo.
2 envoyer les données vers le serveur privé l’end device doit communiquer avec le
en utilisant la Technologie LoRa. gateway en utilisant la modulation LoRa
a travers USI LoRa module . Par la suite
le gateway va diffuser les données vers
notre serveur privé.
4.3.2 Protocoles de communications
4.3.2.1 ADC
Les microcontrôleurs sont des composants numériques, ils ne comprennent donc que les
signaux discrets/numériques. Par conséquent, si nous voulons lire la tension analogique qui peut
provenir de différents capteurs, nous avons besoin d’ADC. C’est un périphérique qui permet de
mesurer la tension (entre 0 et Vref) sur une certaine entrée du microcontrôleur et de la convertir en
un nombre entre 0 et 2N-1 où N est la résolution ADC. Les cartes STM32 ont plusieurs ADC qui
peuvent fonctionner indépendamment. Généralement, les ADC ont 18 canaux et plus : 16 canaux sont
externes et connectés à la broche GPIO ,2 canaux sont interne connecté à une sonde de température
interne [7].
Dans ce end device smart waternous allons utilise l’ADC pour connecter les capteurs :
— capteur de CO2
— capteur de Luminosité
— capteur pH
— capteur de conductivité d’eau
49
4.4 Conception
4.4.1 Diagramme d’activité
Le diagramme d’activité est un diagramme comportemental d’UML, permettant de représenter

le déclenchement d’événements en fonction des états du système et de modéliser des comportements
parallélisables. Il est également utilisé pour décrire un flux de travail, les etapes de deroulement de
notre end device Smart Water sont expliqués dans le figure 4.2 ci-dessous : :
Figure 4.2: Diagramme d’activité
50
4.4.2 Schéma Fonctionnel
C’est une représentation graphique simplifiée de notre end device smart water impliquant
plusieurs unités ou étapes. Il est composé de blocs connectés par des lignes d’action qui contient les
elements suivates :
Figure 4.3: Schéma Fonctionnel
— Les capteurs : Leurs roles est la mesures des grandeurs suivantes :ph,conductivité, temperature
d’eau, luminosité, CO2, temperature et humidité de l’environement.
— La carte de Commande : la carte STM32L4
— Module Radio LoRa (USI) : c’est la carte de communication RF LoRa .
— Gateway : la passerelle entre l’end device et notre serveur privé.
— Serveur Privé : c’est notre serveur LoRa.
— MQTT : (Message Queuing Telemetry Transport) est un protocole de messagerie publish-subscribe

basé sur le protocole TCP/IP.
— One Wire : Le protocole s’appelle 1-Wire car il utilise 1 fil pour transférer les données [6].
— ADC : il est intégré dans les microcontrôleurs STM32L4 qui utilise le principe du SAR (registre
d’approximation successive) selon lequel la conversion est effectuée en plusieurs étapes.
51
— LoRaWan : LoRaWAN est un protocole de télécommunication permettant la communication

à bas débit, par radio, d’objets à faible consommation électrique communiquant selon la
technologie LoRa .
4.4.3 Diagramme de flux de données
Le diagramme de flux de données est un type de représentation graphique du flux de données,

il est également utilisé pour visualiser le traitement de données (structured design).
La figure 4.4 ci-dessous montre le diagramme de flux de données de notre systeme :
Figure 4.4: Diagramme de flux de données
4.5 Realisation
4.5.0.1 Configuration de Device LoRa Smart Water
— Enregistrement des Devices LoRa Il faut tout d’abord faire l’enregistrement d’un Device-profile
figure 4.5 pour les Devices LoRa que vous souhaitez connecter. Dans notre cas, nous ferons
un premier test en spécifiant que nous utilisons seulement le mode d’authentification OTAA :
Devices profile > Create
52
Figure 4.5: Enregistrement d’un Device profile
Nous pouvons alors créer dans notre application de nouveau Device : Application puis Smart
Water et apres Create.
Figure 4.6: Enregistrement d’un nouveau Device LoRa
Dans la fenêtre Activation, on va alors configurer les 2 éléments indispensables à une authentification
53
en OTAA : le Network key, et Application key.
La figure 4.7 montre la configuration d’activation OTAA :
Figure 4.7: Configuration de l’enregistrement du Device LoRa (en OTAA)
La configuration minimale de LoRa Server est maintenant terminée. Nous pouvons donc
brancher un Device LoRa qui possède les les attribus de OTAA que nous avons enregistré
dans notre serveur privé et le faire émettre.
— Visualisation des trames reçues Les trames émises par le Device LoRa vont donc parcourir
le cheminement suivant figure 4.8 :
54
Figure 4.8: Résumé du cheminement des trames LoRaWan en Uplink
En allant dans le Live Device Data (Application >Nom-du-Device > Live Device Data) on
peut voir la liste des trames reçues ainsi que les données applicatives déchiffrées.
La figure 4.9 montre le reception des trames chiffrées provenant des devices LoRa :
Figure 4.9: Réception des trames des Devices LoRa
55
4.5.1 Decodage de payload
Sur notre serveur privé LoRa, une section intitulée «Codec Payload» a été créée pour permettre
à l’utilisateur de décoder les données LoRa à l’aide du langage de programmation javaScript,
seulement en sélectionnant l’objet, par exemple Température et écriture d’un script pour
déchiffrer les données du capteur.
Cette opération peut être illustrée à travers cette figure 4.10 :
Figure 4.10: Decodage de payload
4.5.2 Matériels nécessaires
4.5.2.1 Interface Radio LoRa
Le Tableau 4.3 ci-dessous représente le matériel nécessaire pour la partie RF LoRa de notre
end device :
56
Tableau 4.3: Materiels Necessaires pour la partie RF LoRa

— ARM 32-bit
R Cortex -M0+
R CPU
— Frequence de CPU Max 32 MHz
— STM32L4 — VDD de 1.65 V à 3.6 V
NUCLEO — 4 KB Flash
— 2-bit ADC avec 16 canaux
— VDD de 1.65 V à 3.6 V
— Ce module sans fil LPWAN (low-cost,

low-power wide area module) prend en
— USI LORA
charge le protocole sans fil longue portée
LoRaWAN en utilisant les AT Commandes
4.5.2.2 Les Capteurs Necessaires :
Nous avons représenté dans le tableau 4.4 les differentes capteurs utilisés pour la realisation
de notre end device :
57
Tableau 4.4: Les differentes capteurs utilisés

— capteur de Température et Humidité
— Alimentation : 3,3 à 6 Vcc
— Consommation maxi : 1,5 mA
— Plage de mesure :
— DHT22
- température : -40 à +80 C
- humidité : 0 à 100
— VDD de 1.65 V à 3.6 V
— Tension d’entrée 3.0-5.5V
— DS18B20 — Plage de températures de -55 C à +125 C
— Précision de 0,5 C de -10 C à +85 C
— pH — Measure range : 0 14pH
— Applicable temperature : 0 60C

— EC
— Sortie analogique
— Haute sensibilité au fumée.
— CO2 — Une réponse rapide .
— Durée de vie stable et longue Circuit
— La résistance des cellules diminue avec

— LDR
l’intensité lumineuse croissante
58
4.5.3 Développement
Notre tâche principale dans ce sprint est en premier lieu d’établir :
— Communication entre STM32 et USI, C’est une communication USART base sur des AT
Commande
— Communication I2s entre le capteur DHT22 et l’Stm32, le protocole i2s utilise une méthode
différente de celle de spi ou i2c, il est basé sur un seul fil, il fournit une indication sur 16 bit
pour la température et l’humidité, il faut noter que les mesures peuvent être redemandé chaque
seconde.
— Lecture du signal analogique issue des capteurs LDR, CO2, PH, et conductivité pour les
convertir en un signal numérique comprise entre 0 et 2N-1 ou N représente la résolution de
convection
— DS18B20 Cette sonde de température numérique nous permet de mesurer avec précision la
température dans des environnements humides grâce à une simple interface 1-Wire.
Le capteur DS18B20 fournit des mesures de température de 9 à 12 bits (configurables) sur une
interface 1-Wire, de sorte qu’un seul fil (et masse) doit être connecté à un microcontrôleur. Le
thermomètre numérique à 1 fil a son propre protocole de communication. Toute la communication
avec le DS18B20 commence par une séquence d’initialisation. Après que le maître de bus a
détecté une impulsion de présence, le microcontrôleur envoie un signal demande de lecture
pour les données stockées dans la ROM. En seconde lieu nous avons fait face à un véritable
défi pour atteindre la consommation de courant la plus basse possible de l’end device.
— Nous avons essayé avec différents modes de faible consommation (Sleep mode, Stop mode, Run
mode) et nous avons eu les résultats suivants :
• Stop mode avec une consommation du 23 A
• Sleep mode avec une consommation de 45 mA
• Run mode avec une consommation 76 mA
Et finalement nous avons choisi le stop mode qui répond le plus besoin du client.
4.5.4 Image Reel de l’end device Smart Water
La figure 4.11 ci-dessous montre une image reel de l’end device Smart Water :
59
Figure 4.11: Image Reel de l’End Device Smart Water
4.5.5 Expérimentation
Dans ce tableau 4.5 dessous nous avons testé notre Smart Water End Device dans l’eau de
l’Aquarium puis avec l’eau des foyers et nous avons obtenu les resultats suivantes :
60
Tableau 4.5: Tableau de mesures de differentes capteurs
Image de Composant Aquarium Eau d’usage quotidien
Capteurs/ Cas de test
pH 6.66 6.06
Conductivite(uS/cm) 10500 200
Temperature eau(C) 25 27
Humidite exterieur(pourcentqge) 37 36
CO2(pourcentqge) 11 12
Temperature exterieur(C) 24 25
Luminosite(pourcentqge) 45 53
On remarque de la conductivité change et varie entre l’eau de l’Aquarium de l’Aquarium et

l’eau à usage quotidien car les poissons ont besoin de l’eau salée pour vivre dans un environnement
stable.
4.6 Conclusion
Nous avons pu concevoir et réaliser notre propre end device Smart Water qui a pour role de
collecter les donnees pour les envoyer vers notre serveur prive puis les sauvegarder dans les bases de
donnees et Cloud.
61
Chapitre 5
Sprint 3 :Prototypage
Plan
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5 Realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Chapitre 5. Sprint 3 :Prototypage
5.1 Introduction
Dans ce sprint nous allons mettre en évidence la conception et la réalisation des boitiers des
deux sprints précédents Weather Station et Smart Water.
5.2 Sprint Backlog
suivants :
Figure 5.1: Sprint Backlog<prototypage>
Le prototypage doit offrir les fonctionnalites suivante :
63
1 Conception 3D des boitiers.. Le boitier de l’end device doit être

étanche, encombré, plaisant a l’œil,
biodégradable et contenir un support de
fixation
2 Fabrication des prototypes La fabrication doit être non coûteuse,

rapide et avec l’imprimante 3D
5.4 Conception
Nous avons utilisé CATIA V5 qui est une plate-forme de conception assistée par ordinateur
(CAO), qui accompagne l’ingénieur dans la conception de produits (production, montage, maintenance,
prototypage, etc. . . ). pour concevoir les boitiers tout en respectant les dimensions des composant
électronique et des pièces mécanique standard sans oublier les contraintes de pression et de retrait
issu de l’injection plastique de d’imprimante [11].
Voici les imprime-écrans de la conception du boitier Smart Water dans la figure 5.2 ci-dessous
suivante :
Figure 5.2: conception du boitier Smart Water
64
Les imprime-écrans dans la figure 5.3 ci-dessous représentent la conception du boitier wather
station :
Figure 5.3: conception du boitier weather station
L’imprime écran de la figure 5.4 représente la conception du shutter weather station :
Figure 5.4: conception du shutter weather station
Pour plus d’informations sur les détails techniques consulter l’annexe 0000 tel que les dessins
d’ensemble et de définition
65
5.5 Realisation
5.5.1 CURA
Lorsque nous avons un modèle 3D et que nous somme prêt à imprimer, nous avons besoin
d’un programme qui prépare notre fichier pour notre imprimante 3D. Un programme de tranchage
prend un fichier STL et crée un code G, le code qui indique à notre imprimante 3D où déplacer la
tête d’impression, à quelle vitesse la déplacer et quel chemin suivre. Cura est le logiciel de tranchage
d’Ultimaker que nous avons utilisé [12].
5.5.2 Configuration du logiciel cura
Avant de passer a l’impression 3D faut faire les configurations suivante : La configuration de

Cura qui dépend du type de l’imprimante, la matière première et de la buse utiliser et pour ce faire
Nous avons utilisé l’imprimante anycubic Delta (Diamètre 180mm, Hauteur 300 mm) Nous avons
utilisé du PLA (D 1.75mm) comme matière car elle est plus résistante et nécessite que 190 C de
température pour l’impression Et une buse de 0.4 mm
Figure 5.5: configuration de CURA
5.6 Conclusion
Nous avons pu concevoir et réaliser les dierentes boitiers en 3D de dierentes objets connectés
que nous avons réalisé dans notre projet smart building.
66
Conclusion générale
Ce projet de fin d’études, qui s’est déroulé au sein de l’organisme « SOFIA HOLDING »
représente une grande opportunité car il nous a permis d’améliorer nos connaissances dans plusieurs
domaines.
Tout au long du projet, nous avons eu l’opportunité de connaitre des nouvelles technologies,
des environnements informatique, électronique et mécanique que nous ne connaissions pas au part
avant. Notre projet a duré plusieurs mois et il a été réalisé en plusieurs étapes.
Au début nous avons commencé par nous familiariser avec le sujet, en effectuant des recherches
concernant les différentes technologies et leurs modes de fonctionnement, nous sommes ensuite passé
à la pratique et à l’étudie de chaque phase en utilisant la méthodologie SCRUM, en commençant
par le développement des nœuds jusqu’à la réalisation d’un prototype pour les boitiers.
Notre but était de créer une plateforme basée sur la technologie LoRaWAN offrant des
connexions entre les différentes objets connectées (Weather Station, Green Land, Smart Camera,
Sofia Salle Système, HVAC et Smart Water) et le Cloud qui permet à son utilisateur de surveiller et
consulter des informations concernant la qualité d’eau, les changements climatiques et la surveillances
zones vertes tout en assurant la sécurité du bâtiment en utilisant une caméra intelligente basée
sur le Deep Learning. Nous avons apporté nos connaissances personnelles ainsi que des phases
d’auto-formations dans divers domaines pour arriver à notre but. Ce projet représente une étape très
importante dans le futur et dans la surveillance des Smart Buildings non seulement dans notre pays
mais partout dans le monde. C’est avec un grand plaisir que nous arrivons au terme de ce projet
durant lequel nous avons pu réaliser une solution que nous avons déjà installé à partir d’une chaine
IoT complète.
Finalement nous espérons que ce travail a été à la hauteur de vos espérances comme il l’a été
pour nous.
67
Webographie
[1] : https://www.futura-sciences.com/tech/definitions/internet-
internet-objets-15158/
[2] : https://blog.lesjeudis.com/10-applications-de-l-internet-des-
objets-qui-revolutionnent-la-societe
[3] : https://whatis.techtarget.com/definition/IoT-gateway
[4] : https://www.journaldunet.fr/web-tech/dictionnaire-de-l-
iot/1197635-lora-comment-fonctionne-le-reseau-quelles-differences-
avec-sigfox/
[5] https://lora-alliance.org/
[6] https://www.carnetdumaker.net/articles/faire-un-scanneur-de-bus-
1-wire-avec-une-carte-arduino/
[7] :https://www.st.com/content/ccc/resource/technical/document/user
_manual/98/2e/fa/4b/e0/82/43/b7/DM00105823.pdf/files/DM0010582
3.pdf/jcr:content/translations/en.DM00105823.pdf
[8] :https://www.st.com/resource/en/application_note/dm00151811.pd
f
[9] http://www.emcu.it/SILICASTDay2016/X/Presentazioni/6_2_ST
M32L4_System_Operat ing_Modes.pdf
[10] : https://www.st.com/resource/en/user_manual/dm00105879.pdf
[11] : https://www.techniques-ingenieur.fr/base-documentaire/genie-
industriel-th6/outils-pour-la-conception-42663210/cao-logiciel-catia-
ag2535/
[12] : https://ultimaker.com/en/resources/21932-mastering-cura
[13] : http://www.libelium.com/controlling-fish-farms-water-quality-
with-smart-sensors-in-iran/
[14] :https://www.researchgate.net/publication/318736646_Internet_o
f_things_enabled_real_time_water_quality_monitoring_system
[15] : https://www.weathershop.co.uk/
[16] : https://www.amazon.com/Ambient-Weather-WiFi-
Station/dp/B01N5TEHLI
Chapitre 6
ANNEXE
4 3 2 1
D 1 2 3 D
C C
B B
ITEM NO. PART NUMBER DESCRIPTION QTY.

1 Boitier partie 1 Fabrication imprimante 3d : PLA 1
2 Boitier partie 2 Fabrication imprimante 3d : PLA 1
3 Antenne lora Electronique 1
4 presse étoupe Piece mecanique standard 5
Echelle 1:1 A4 Dessin d'ensemble
A Sofia technologies A
Date
Nom Document:
Frigui Ahmed Smart Water Boitier PFE 2019
4 3 2 1
4 3 2 1
D D
53
8
3
SECTION A-A
SCALE 2 : 3
C C
115
3 55
118,50
B B
A A
Echelle 2:3 A4 Dessin de définition

Date
Nom Document:
Frigui Ahmed Boitier partie 1
4 3 2 1
4 3 2 1
D D
2
C C
118,50
B B
3
115

Date
Nom Document:
Frigui Ahmed Boitier partie 2
4 3 2 1
4 3 2 1
5
D 4 D
C C
2
B B
ITEM PART NUMBER DESCRIPTION QTY.

NO.
1 Shutter 1
2 boitier end device 1
3 Support 1
4 Détecteur de niveau de pluie 1
5 Vitesse du vent 1
Date
Nom Document:
Frigui Ahmed wather station PFE 2019
4 3 2 1
4 3 2 1
D D
1
C C
B 4 B

1 Antenne lora Electronique 1
2 boiteir Fabrication imprimante 3d : PLA 1
3 couvercle Fabrication imprimante 3d : PLA 1
4 support de fixation Fabrication imprimante 3d : PLA 2
Date
Nom Document:
Frigui Ahmed boitier end device PFE 2019
4 3 2 1
4 3 2 1
D D
C C
125,50 63
104
B B

Date
Nom Document:
Frigui Ahmed Boitier
4 3 2 1
4 3 2 1
D D
18
C 125,50 3 C
80
B B

Date
Nom Document:
Frigui Ahmed Couvercle
4 3 2 1
4 3 2 1
D D
R1
0
16,50
5
13,50
C C
104
104
B B
95,50

Date
Nom Document:
Frigui Ahmed support de fixation
4 3 2 1
4 3 2 1
4 5 6
D D
1
C C
B B

1 Assiette 1 Fabrication imprimante 3d : PLA 1
5 Support de fixation Fabrication imprimante 3d : PLA 1
6 boitier Fabrication imprimante 3d : PLA 1

Date
Nom Document:
Frigui Ahmed Shutter
4 3 2 1
4 3 2 1
D D
135
°
2
C C
F 12
<MOD-DIAM>64
<MOD-DIAM>88
B B
SECTION F-F
F SCALE 1 : 1

Date
Nom Document:
Frigui Ahmed Assiette 1
4 3 2 1
4 3 2 1
<MOD-DIAM>20
D D
2
9
12
SECTION E-E
SCALE 1 : 1
>4
M
IA
-D
D
O
<M
C C
°
135
<MOD-DIAM>64
<MOD-DIAM>88
E E
B B

Date
Nom Document:
Frigui Ahmed Assiette 2
4 3 2 1
4 3 2 1
D D
5
R2
55
C C
132,50
50
0,
R1
B B
20 16

Date
Nom Document:
Frigui Ahmed Support de fixation
4 3 2 1
Résumé
Ce document décrit le travail réalisé au sein de la société « SOFIA HOLDING ». Il
s'inscrit dans la continuité et la validation du diplôme National d’ingénieur en Mécatronique.
L’objectif de notre projet est de créer une plateforme basée sur la technologie
LoRaWAN offrant des connexions entre les différents objets connectés (Weather Station,
Green Land, Smart Camera, Sofia Salle Système, HVAC et Smart Water) et le Cloud afin de
mettre en place un modèle d'architecture IoT qui doit être utilisé pour développer une solution
IoT pour les Smart Buildings.
Des objets connectés contenant un ensemble des capteurs spécifiques doit envoyer les
données vers un serveur privé distant a fin de visualiser les données dans une application web
IoT intelligente en utilisant un Cloud privé.
Mots clé: Smart Water,Weather Station, LoRa, IoT, Cloud, Serveur privé, Smart Buildings.
Abstract
This document describes the work done within the company "SOFIA HOLDING". It is
part of the continuity and the validation of the national diploma of engineer in Mecatronique.
The objective of our project is to create a platform based on LoRaWAN technology

offering connections between the different connected objects (Weather Station, Green Land,
Smart Camera, Sofia System Room, HVAC and Smart Water) and the Cloud in order to
implement place an IoT architecture model that should be used to develop an IoT solution for
Smart Buildings.
Connected objects containing a set of specific sensors must send the data to a remote
private server in order to view the data in a smart IoT web application using a private cloud.
Keywords: Smart Water, Weather Station, LoRa, IoT, Cloud, Serveur privé, Smart
Buildings.

PFE Iot

Transféré par

Informations du document

Description :

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Formats disponibles

PFE Iot

Titre original :

Transféré par

Description :

Droits d'auteur :

Formats disponibles

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR

Projet de Fin d’Etudes

Encadrant(s) universitaire(s) Encadrant(s) industriel(s)

AHMED BOUGHANMI Mr.NIZAR MERTAH

Je dédie ce travail en témoignage de mon profond respect, mon grand amour

Mes chers parents,

Les membres de ma famille,

Et tous ceux qui m’ont soutenu de près ou de loin.

Je tiens en premier lieux de remercier la société SOFIA HOLDING qui m’a

offert l’opportunité de développer mes connaissances et il m’a mis dans le

spécialement nos encadrants Mr.NIZAR MERTAH et Mr.MOHAMED

Nos profondes gratitudes s’adressent en particulier à notre encadreur

m’a toujours suivi par ces conseils.

sacrifices énormes pour qu’on puisse arriver là où nous sommes.

projet, qui reçoivent l’expression de nos sincères reconnaissances et gratitudes.

avoir accepté de m’accorder leur attention et pour l’évaluation de mon travail.

2 Etat de l’art et spécification des besoins 19

3 Sprint 1 : Réalisation d’un noeud weather station 33

4 Sprint 2 : Réalisationd’un noeud smart water 47

1.1 Logo Entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 architecture IoT Smart Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 Sprint Backlog<Réalisation d’un End Device> . . . . . . . . . . . . . . . . . . . . . 34

4.1 Sprint Backlog<Réalisation d’un End Device> . . . . . . . . . . . . . . . . . . . . . 48

5.1 Sprint Backlog<prototypage> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

1.1 Tableau Comparatif des solutions existants . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Fonction des Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1 Planification du SPRINT 3 <Réalisation d’un End Device> . . . . . . . . . . . . . . 35

4.1 Planification du SPRINT 3 <Réalisation d’un End Device> . . . . . . . . . . . . . . 49

5.1 Planification du SPRINT 3 <Réalisation d’un End Device> . . . . . . . . . . . . . . 64

— ABP = Activation By Personnalisation

— ADC = Analog Digital Converter

— CSS = ChirpSpread Spectrum

— HTTP = Hyper Text Transfer Protocol

— IOT = Internet des Objets Things

— ISM = Industrial, Scientific and Media

— JSON = JavaScript Object Notation

— LAN = Local Aange Network

— LPWAN = Low Power Wide Area Network

— LoRa = Long Range

— OTAA = Over The Air Activation

— RTC = Real Time Clock

— WAN = Wide Area Network

2 Présentation de la société d’accueil . . . . . . . . . . . . . . . . . . . . . . 4

6 Synoptique de la solution proposée . . . . . . . . . . . . . . . . . . . . . . 14

1.1 Contexte de stage

1.2 Présentation de la société d’accueil

La figure 1.1 présente le logo de l’entreprise.

Figure 1.1: Logo Entreprise

1.2.1 SOFIA Technologies

1.2.1.1 Secteurs d’activité

— Software : les experts en technologies de Sofia en technologies de l’information s’assurent que

— Département des systèmes électroniques : composé de 5 employés, ce département est

— Département des systèmes embarqués : Ce département est chargé de la création et de

— Département systeme d’information : experts en industrialisation, configuration, optimisation

— Developpement d’affaires et veille strategique : dans lequel on a passé notre stage de

1.2.1.3 L’organigramme de l’entreprise

La figure 1.2 présente l’organigramme de l’entreprise :

Figure 1.2: L’organigramme de l’entreprise

Figure 1.3: iFarming logo