PFE Iot [PDF]

Zitiervorschau

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

Planification du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

1.9

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

19

2.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.2

Internet des objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

iii

2.3

2.4

2.5

2.2.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.2.2

Domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.2.3

Gateway IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

LoRa et LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

2.3.1

Technologies de communication sans fil . . . . . . . . . . . . . . . . . . . . . .

23

2.3.2

LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

2.3.3

LoRaWan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

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

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

Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

3.3.1

Planification du SPRINT 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

3.3.2

Environnement de développement STM32 . . . . . . . . . . . . . . . . . . . .

35

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

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

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

3.4

3.5

3.6

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

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iv

47 48

4.2

Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

4.3

Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

4.3.1

Planification du SPRINT 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

4.3.2

Protocoles de communications . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

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

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

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

4.4

4.5

4.6

5 Sprint 3 :Prototypage

62

5.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

5.2

Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

5.3

Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

5.3.1

Planification du SPRINT 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

5.4

Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

5.5

Realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

5.5.1

CURA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

5.5.2

Configuration du logiciel cura . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

5.6

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

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

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

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

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

Planification du SPRINT 3 . . . . . . . . . . . . . .

49

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

5.1

Planification du SPRINT 3 . . . . . . . . . . . . . .

64

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 = — LoRa

=

— OTAA =

Low Power Wide Area Network Long Range 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

Chapitre 1. Contexte général

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

Chapitre 1. Contexte général — 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

Chapitre 1. Contexte général

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

Chapitre 1. Contexte général 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

Chapitre 1. Contexte général

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

Chapitre 1. Contexte général 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

Chapitre 1. Contexte général 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 Reseau Securité Consommation d’energie Portée Cloud Temp Reel Protocole Capteurs

1.5.2.1

Technologie Laser non non elevée courte non oui non non

Water and Fish Quality Libelium 3G /GPRS /WIFI TLS elevée longue privé oui LAN /Cellulaire oui

India Smart Water WIFI non elevée courte Open source oui LAN oui

Weather Station

Il existe de nombreux exemples de solutions de Weather Station. On peut citer : — WeatherShop — WS-2902A Smart WiFi Weather Station 11

Chapitre 1. Contexte général 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

Chapitre 1. Contexte général

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

Chapitre 1. Contexte général 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

Chapitre 1. Contexte général 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

Chapitre 1. Contexte général — 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

Chapitre 1. Contexte général 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

Chapitre 1. Contexte général Tableau 1.3: Les sprints du projet

1.9

Sprints

Description

Sprint 1

Réalitation d’End Device weather station

Sprint 2

Réalitation d’End Device Smart Water

Sprint 3

Prototypage

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

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

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

Chapitre 2. Etat de l’art et spécification des besoins 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

Chapitre 2. Etat de l’art et spécification des besoins 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

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

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

Chapitre 2. Etat de l’art et spécification des besoins 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

Chapitre 2. Etat de l’art et spécification des besoins 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

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

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

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

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 FP 1 FP 2 FC 1 FC 2 FC 3 FC 4 FC 5

2.4.2

Expression de la fonction Permettre a l’utilisateur la surveillance de la qualité d’eau en temps reel Permettre à l’utilisateur la surveillance de les changements climatiques Respecter les normes de sécurité. Être moins chère. Être très fiable et simple à utiliser. Utiliser l’énergie électrique disponible. Assurer une connexion sans fil.

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

Chapitre 2. Etat de l’art et spécification des besoins 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

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

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

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

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

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

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

3

Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

3.3

Analyse des besoins 3.3.1

Planification du SPRINT 3

L’end Device weather station doit offrir les fonctionnalites suivante :

34

Chapitre 3. Sprint 1 : Réalisation d’un noeud weather station Tableau 3.1: Planification du SPRINT 3

ID

Titre

Description

1

collecter

les

données

de

differente

capteurs.

L’end device doit collecter les données 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

Chapitre 3. Sprint 1 : Réalisation d’un noeud weather station (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

Chapitre 3. Sprint 1 : Réalisation d’un noeud weather station 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

Chapitre 3. Sprint 1 : Réalisation d’un noeud weather station 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

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

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

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

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

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

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

Chapitre 3. Sprint 1 : Réalisation d’un noeud weather station Tableau 3.3: Materiels Necessaires pour la partie RF LoRa Image de Composant

Nom

Caractéristiques R R — ARM 32-bit Cortex -M0+ CPU

— Frequence de CPU Max 32 MHz — STM32L4 NUCLEO

— VDD de 1.65 V à 3.6 V — 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

Chapitre 3. Sprint 1 : Réalisation d’un noeud weather station Tableau 3.4: Les differentes capteurs utilisés Image de Composant

Nom

Caractéristiques — 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 — 2-bit ADC avec 16 cannals — VDD de 1.65 V à 3.6 V

— c000direction du vent, degré — s000vitesse du vent (1 minute), 0.1 miles per hour — g000vitesse du vent (5 minutes), 0.1 miles

— APRS

per hour

interface 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

Chapitre 3. Sprint 1 : Réalisation d’un noeud weather station 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

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

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

Chapitre 3. Sprint 1 : Réalisation d’un noeud weather station 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

3

Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Ce Sprint Backlog représenté sur la figure 4.1 ci-dessous comporte l’ensemble des modules suivants :

Figure 4.1: Sprint Backlog

4.3

Analyse des besoins 4.3.1

Planification du SPRINT 3

L’end Device Smart Water doit offrir les fonctionnalites suivante :

48

Chapitre 4. Sprint 2 : Réalisationd’un noeud smart water Tableau 4.1: Planification du SPRINT 3

ID

Titre

Description

1

collecter

les

données

de

differente

capteurs.

l’end device doit collecter les données 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

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

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

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

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

Chapitre 4. Sprint 2 : Réalisationd’un noeud smart water — 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

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

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

Chapitre 4. Sprint 2 : Réalisationd’un noeud smart water 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

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

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

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

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

Chapitre 4. Sprint 2 : Réalisationd’un noeud smart water Tableau 4.3: Materiels Necessaires pour la partie RF LoRa Image de Composant

Nom

Caractéristiques R R — ARM 32-bit Cortex -M0+ CPU

— Frequence de CPU Max 32 MHz — STM32L4 NUCLEO

— VDD de 1.65 V à 3.6 V — 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

Chapitre 4. Sprint 2 : Réalisationd’un noeud smart water Tableau 4.4: Les differentes capteurs utilisés Image de Composant

Nom

Caractéristiques — 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 — 2-bit ADC avec 16 cannals — 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

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

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

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

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

Chapitre 4. Sprint 2 : Réalisationd’un noeud smart water Tableau 4.5: Tableau de mesures de differentes capteurs Image de Composant

Aquarium

Eau d’usage quotidien

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

Capteurs/ Cas de test

pH

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

3

Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Ce Sprint Backlog représenté sur la figure 5.1 ci-dessous comporte l’ensemble des modules suivants :

Figure 5.1: Sprint Backlog

5.3

Analyse des besoins 5.3.1

Planification du SPRINT 3

Le prototypage doit offrir les fonctionnalites suivante :

63

Chapitre 5. Sprint 3 :Prototypage Tableau 5.1: Planification du SPRINT 3

ID

Titre

Description

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

Chapitre 5. Sprint 3 :Prototypage 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

Chapitre 5. Sprint 3 :Prototypage

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/internetinternet-objets-15158/ [2] : https://blog.lesjeudis.com/10-applications-de-l-internet-desobjets-qui-revolutionnent-la-societe [3] : https://whatis.techtarget.com/definition/IoT-gateway [4] : https://www.journaldunet.fr/web-tech/dictionnaire-de-liot/1197635-lora-comment-fonctionne-le-reseau-quelles-differencesavec-sigfox/ [5] https://lora-alliance.org/ [6] https://www.carnetdumaker.net/articles/faire-un-scanneur-de-bus1-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/genieindustriel-th6/outils-pour-la-conception-42663210/cao-logiciel-catiaag2535/

[12] : https://ultimaker.com/en/resources/21932-mastering-cura [13] : http://www.libelium.com/controlling-fish-farms-water-qualitywith-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-WiFiStation/dp/B01N5TEHLI

Chapitre 6

ANNEXE

4

3

1

D

2

2

1

3

D

4

C

C

B

B

ITEM NO.

Echelle 1:1 A Nom

PART NUMBER

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

A4

Dessin d'ensemble

Sofia technologies Document:

Frigui Ahmed 4

DESCRIPTION

3

A

Date

Smart Water Boitier PFE 2019 2

1

4

3

2

1

D

3

8

53

D

SECTION A-A SCALE 2 : 3 C

C 115

A

118,50

B

55

3

A

Echelle 2:3 A Nom

A4

Frigui Ahmed 4

Dessin de définition

Sofia technologies Document:

3

B

A

Date

Boitier partie 1 2

1

4

2

1

D

2

D

3

3

C

118,50

C

B

B

3

Echelle 1:1 A Nom

115

A4

Sofia technologies Document:

Frigui Ahmed 4

Dessin de définition

3

A

Date

Boitier partie 2 2

1

4

3

2

5

4

D

1

D

3

1

C

C

2

B

B ITEM NO. 1 Shutter

A Nom

A4

1

3 4

Détecteur de niveau de pluie

1

5

Vitesse du vent

1

Document:

4

1

3

1

Dessin d'ensemble

Sofia technologies

Frigui Ahmed

DESCRIPTION QTY.

boitier end device Support

2

Echelle 2:3

PART NUMBER

A

Date

wather station PFE 2019 2

1

4

3

D

2

1

D

1

2 3

C

C

B

B

4

ITEM NO.

Echelle 2:3 A Nom

PART NUMBER

QTY.

Electronique

1

1

Antenne lora

2

boiteir

Fabrication imprimante 3d : PLA

1

3

couvercle

Fabrication imprimante 3d : PLA

1

4

support de fixation

Fabrication imprimante 3d : PLA

2

A4

Dessin d'ensemble

Sofia technologies Document:

Frigui Ahmed 4

DESCRIPTION

3

A

Date

boitier end device PFE 2019 2

1

4

3

2

1

D

D

C

C 63

104

125,50

B

B

Echelle 2:3 A Nom

A4

Sofia technologies Document:

Frigui Ahmed 4

Dessin de définition

3

A

Date

Boitier 2

1

4

3

2

1

D

D

125,50

3

C

80

C

18

B

B

Echelle 1:1 A Nom

A4

Sofia technologies Document:

Frigui Ahmed 4

Dessin de définition

3

A

Date

Couvercle 2

1

4

3

2

1

D

D

5 13,50

16,50

0 R1 104

C

104

C

B

B

95,50

Echelle 1:1 A Nom

A4

Sofia technologies Document:

Frigui Ahmed 4

Dessin de définition

3

A

Date

support de fixation 2

1

4

3

4

2

1

6

5

D

D

3

2

1

C

C

B

B ITEM NO.

A Nom

QTY.

Assiette 1

Fabrication imprimante 3d : PLA

1

2

Assiette 2

Fabrication imprimante 3d : PLA

1

3

Fabrication imprimante 3d : PLA Fabrication imprimante 3d : PLA Fabrication imprimante 3d : PLA

1

5

Assiette 3 Assiette 4 Support de fixation

6

boitier

Fabrication imprimante 3d : PLA

1

A4

Frigui Ahmed 3

1 1

Dessin d'ensemble

Sofia technologies Document:

4

DESCRIPTION

1

4

Echelle 1:1

PART NUMBER

A

Date

Shutter 2

1

4

3

2

1

D

D

135

2

°

C

C

F

B

88

64

12

SECTION F-F

F Echelle 1:1 A Nom

A4

SCALE 1 : 1 Dessin de définition

Sofia technologies Document:

Frigui Ahmed 4

B

3

A

Date

Assiette 1 2

1

4

3

2

D

12 9

2

20

D

1

SECTION E-E

4

SCALE 1 : 1

C

E

E

135

64 88

°

C

B

B

Echelle 1:1 A Nom

A4

Sofia technologies Document:

Frigui Ahmed 4

Dessin de définition

3

A

Date

Assiette 2 2

1

4

3

2

1

D 55

R2 5

D

C

R1

0,

50

132,50

C

B

B

20

Echelle 2:3 A Nom

16

A4

Sofia technologies Document:

Frigui Ahmed 4

Dessin de définition

3

A

Date

Support de fixation 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, Buildings.

LoRa, IoT, Cloud, Serveur privé, Smart