Appréciations et signature de

l’encadrant
Remerciements

Avant de présenter notre projet, c’est avec grand respect que nous adressons nos pro-
fonds remerciements à notre encadrant ...... pour sa disponibilité, sa confiance, la qualité
de son encadrement et surtout l’autonomie qui nous a offert pendant le déroulement du
projet.

Nous tenons à remercier tout particulièrement les membres du Jury qui nous ont fait
l’honneur en acceptant de juger ce travail.

Nous aimerons gratifier l’effort de l’équipe administrative et pédagogique de ......, qui

ont eu l’amabilité de répondre à nos questions et de fournir les explications nécessaires.

Nous exprimons nos sentiments de gratitude envers tous les personnes qui nous ont
supporté pour réaliser ce projet.

ii
Table des matières

Introduction générale 1

1 Présentation du société 2
1.1 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Présentation de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Historique du SONEDE . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Création et statut juridique . . . . . . . . . . . . . . . . . . . . . . 3
1.2.3 Mission et Activités . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.4 L’organigramme de la société . . . . . . . . . . . . . . . . . . . . . 4
1.3 Problématique et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Contexte de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4 Gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.1 Cycle de développement . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.2 Diagramme de GANTT . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 ETUDE PREALABLE 13
2.1 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1 Description et identification de l’existant . . . . . . . . . . . . . . . 13
2.1.2 Étude critique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Analyse et spécification des besoins . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 CONCEPTION 19
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Langage de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Modélisation fonctionnelle et structurelle du système en Sys ML . . . . . . 20
3.4 Diagramme De Cas d’Utilisation . . . . . . . . . . . . . . . . . . . . . . . . 20

iii
Table des matières iv

3.5 Diagramme Etat/Transition . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.6 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7 Diagramme de définition de Bloc . . . . . . . . . . . . . . . . . . . . . . . 24
3.8 Chaîne fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 REALISATION 27
4.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.3 Montage et Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Partie supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.1 Interface de contrôle et moyen d’interfaçage . . . . . . . . . . . . . 48
4.2.2 Solution d’interfaçage . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Conclusion et perspectives 55

Bibliographie 56

Netographie 57
Table des figures

1.1 Logo de la societé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Siège social SONEDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Organigramme SONEDE. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Forage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Station de pompage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Réservoir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.7 Modèle en V. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8 Diagramme de Gantt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 structure d’un système automatisé . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Diagramme bête à corne exprimant le besoin du système de contrôle . . . . 16
2.3 Diagramme pieuvre reliant le système avec son environnement extérieur . . 16

3.1 Diagramme De Cas d’Utilisation. . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Diagramme Etat/Transition. . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Diagramme de séquence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Diagramme de définition de Bloc. . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Chaîne fonctionnelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 Carte Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Synthèse des caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Shield GSM-GPRS 2 Arduino . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4 Synthèse des caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5 Shield SIM900A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.6 Synthèse des caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.7 Capteur ultrason . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.8 Synthèse des caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.9 Capteur niveau d’eau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.10 Synthèse des caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.11 Afficheur LCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.12 Synthèse des caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.13 modèle Tower Pro SG90. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

v
Table des figures vi

4.14 Synthèse des caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.15 modèle Tower Pro SG90. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.16 Synthèse des caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.17 Convertisseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.18 Synthèse des caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.19 Arduino IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.20 logiciel Frizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.21 Tera Term . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.22 LabView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.23 Montage avec le source d’alimentation . . . . . . . . . . . . . . . . . . . . 39
4.24 Liason entre carte Arduino et le PC . . . . . . . . . . . . . . . . . . . . . . 39
4.25 Montage LCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.26 Code d’affichage de niveau d’eau . . . . . . . . . . . . . . . . . . . . . . . . 40
4.27 Tableau récapitulatif d’état des Leds au différentes niveaux d’eau . . . . . 40
4.28 Montage Leds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.29 Cas ou le niveau d’eau dans le premier niveau . . . . . . . . . . . . . . . . 41
4.30 Montage de Shield GSM avec la carte Arduino . . . . . . . . . . . . . . . . 42
4.31 Code d’informaion des controleurs de niveau d’eau . . . . . . . . . . . . . . 42
4.32 Montage Arduino Shield GSM . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.33 Montage Arduino Shield GSM 3D . . . . . . . . . . . . . . . . . . . . . . . 43
4.34 Code de Traitement du message par le Shield receptif . . . . . . . . . . . . 43
4.35 Montage du capteur Ultrason . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.36 Code qui donne le volume d’eau de réservoir . . . . . . . . . . . . . . . . . 45
4.37 Montage Capteur Niveau d’eau . . . . . . . . . . . . . . . . . . . . . . . . 46
4.38 Code qui donne le niveau d’eau . . . . . . . . . . . . . . . . . . . . . . . . 46
4.39 Montage du Servomoteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.40 Site du pompage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.41 Site de contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.42 interface de contrôle de ce dernier après l’acquisition des données . . . . . . 49
4.43 Le niveau d’eau au cours du temps . . . . . . . . . . . . . . . . . . . . . . 49
4.44 débit et de la pompe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.45 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.46 Configuration émulateur Tera Term . . . . . . . . . . . . . . . . . . . . . . 51
4.47 Une lecture puis l’affichage de la valeur déjà lu sur le « Tank ». . . . . . . 52
4.48 Paramétrage du ficher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Liste des tableaux

vii
Liste des sigles et acronymes

ACRO1 ACRONYME1
ACRO2 ACRONYME2
ACRO3 ACRONYME3
ACRO4 ACRONYME4
ACRO5 ACRONYME5

viii
Introduction générale

L’automatisme est le domaine scientifique et technologique qui exécute et contrôle des

tâches techniques par des machines fonctionnant sans intervention humaine, ou à l’aide
d’une intervention réduite. Il s’est généralisée à l’ensemble des activités de production,
tant dans l’industrie, que dans les activités de services. Quel que soit son domaine d’ap-
plication et les techniques auxquelles elle fait appel, l’automatisation s’est constamment
développée dans l’unique but de réduire la pénibilité du travail humain et d’améliorer la
productivité du travail. C’est dans ce cadre que s’inscrit notre sujet de stage au sein du
SONEDE, Il consiste à automatiser et contrôler la station de traitement d’eau.

Pour bien mener ce travail, Ce mémoire sera divisé en quatre chapitres comme suit :
Le premier chapitre englobera la présentation de la société d‘accueil, une description de la
station de pompage sur laquelle notre étude a été effectuée ainsi que la méthodologie de
travail. Le deuxième chapitre sera dédié à une étude préalable en critiquant les solutions
existantes pour pouvoir détailler les différentes besoins fonctionnelles et non fonctionnelles
ayant comme résultat un cahier de charge. Dans le troisième chapitre, nous expliquerons
le fonctionnement de la solution proposée en se basant sur un modèle conceptuel détaillé.
Finalement, le quatrième chapitre sera dédié à la simulation de la solution réalisant durant
ce projet de fin d’étude.

1
Chapitre 1

Présentation du société

Dans ce chapitre, nous présentons l’organisme d’accueil SONEDE et ses principales

activités suivis par la présentation du contexte du sujet traité. Ensuite, nous posons la
problématique et les objectifs que doit répondre notre application. Enfin, nous décrivons
la démarche à suivre pour la planification des tâches dans la gestion du projet.

1.1 Cadre du projet

Le projet entre dans le cadre de préparation de stage de fin d’études pour l’obtention
de la licence appliquée en Génie électrique (AII) de l’Institut Supérieur d’Études Techno-
logiques du Kef. Ce projet a été effectué au sein de la Société Nationale d’Exploitation et
de Distribution des Eaux (SONEDE district du Kef) durant la période du 4 mois.

1.2 Présentation de la société

Dans le cadre du ce Projet de Fin d’Etudes, nous avons eu l’occasion d’effectuer un
stage de quatre mois au sein de la Société Nationale d’Exploitation et de Distribution des
Eaux (SONEDE) du Kef.

Figure 1.1 – Logo de la societé .

2
1.2. Présentation de la société 3

1.2.1 Historique du SONEDE

En 1968 et pour faire face à l’expansion du secteur de l’eau potable et à l’accroisse-
ment continu de la demande, il a été décidé de créer la Société Nationale d’exploitation
et de Distribution des Eaux (SONEDE). Sa vocation essentielle est de collecter les eaux
souterraines et de surface, de les traiter en vue de les rendre potables, d’acheminer les eaux
traitées depuis les sites de production jusqu’aux réservoirs de distribution, de fournir l’eau
aux abonnés tout en assurant les travaux d’entretien et de maintenance des réseaux et des
équipements.
Forte de sa longue expérience et des compétences dont elle dispose, la Société procède
à l’élaboration des études relatives à l’identification des projets, à l’évaluation de leur ren-
tabilité et à la fixation de leurs délais d’exécution. Elle assure, en outre, le contrôle des
nouveaux chantiers entrepris pour son compte, qu’il s’agisse de la construction de bar-
rages, de stations de traitement, de stations de dessalement et de stations de pompage, ou
de l’exécution de travaux de forage de puits et de la mise en place de réseaux d’adduction
et de distribution.

Figure 1.2 – Siège social SONEDE .

1.2.2 Création et statut juridique

La société nationale d’exploitation et de distribution des eaux (SONEDE) a été créée
par la loi n◦ 68-22 du 02 juillet 1968. Elle est sous la tutelle du ministre de l’agriculture et
de ressources hydrauliques, son statut est définit par la loi qui la qualifie d’établissement
public à caractère non administratif.
1.2. Présentation de la société 4

1.2.3 Mission et Activités

La mission principale de la SONEDE est la production et la distribution d’eau potable
sur l’ensemble du territoire tunisien.
Elle est ainsi chargée de l’exploitation et de l’entretien des installations de captage, du
traitement et de la distribution de l’eau potable.
Cette dernière présente plusieurs activités dont on peut citer :

-Etude et réalisation des installations de captage

L’étude des projets de l’approvisionnement en eau potable est composée d’étude préli-
minaire, étude détaillée et ? ? ?
Enfin Préparation des dossiers d’appels d’offres pour l’acquisition des équipements et
pour la fourniture des conduites et des travaux de poste et de génie civile.

-Traitement et production de l’eau potable

Les sources de production de l’eau potable diffèrent d’une région à l’autre compte tenu
des caractéristiques géographiques et climatiques.
Elles dépendent aussi du développement des besoins en eau de chaque région.
L’eau brute subit les étapes de traitement suivantes : la coagulation-floculation, la dé-
cantation, la filtration et enfin la désinfection.

-Gestion technique des réseaux

La SONEDE assure la distribution de l’eau potable à travers un réseau de conduites de
41619 Km de longueur, de 1126 réservoirs de différentes capacités.

-Gestion commerciale des abonnés

Le branchement et la desserte sur le réseau tout en garantissant une bonne qualité de
ses services.

1.2.4 L’organigramme de la société

La figure ci-dessous représente L’organigramme de la société :
1.2. Présentation de la société 5

Figure 1.3 – Organigramme SONEDE.

1.3. Problématique et objectifs 6

1.3 Problématique et objectifs

1.3.1 Contexte de projet
Pour une meilleure compréhension du projet et de la problématique, il est nécessaire
de décrire l’étape d’exploitation d’eau potable.
Après l’étude de faisabilité, on passe à l’étape d’exploitation ; forage, pompage et
conduite vers le réservoir.

-Le forage d’eau

Le forage est l’action de creuser un trou (aussi appelé « Puits » dans le domaine de la
prospection) dans la Terre. L’équipement du puits, tel les tubages, et de manière générale
les moyens techniques permettant de creuser, varient en fonction de son dimensionnement
et de ses objectifs. On fore pour prospecter et/ou exploiter le sous-sol. Par exemple, des
puits sont forés pour :
-Trouver et exploiter des ressources naturelles enfouies (eau, pétrole, ressources
minières).
-La géotechnique.
-la géothermie.
-L’environnement et la décontamination de sols.
-La recherche scientifique pure.
1.3. Problématique et objectifs 7

Figure 1.4 – Forage.

1.3. Problématique et objectifs 8

-Description d’une station de pompage

Dans une station de pompage, la pompe est l’un des éléments indispensable. Il est très
rare que l’eau puisse être transportée du point de captage aux consommateurs par voie
naturelle, il faut relever l’eau et l’a refoulée à l’aide d’une pompe hydraulique.
La station de pompage se devise en deux grandes parties en amont et en aval où
l’amont a contient un réservoir d’aspiration et une conduite d’aspiration et une vanne d’as-
piration permettant si nécessaire d’isoler la pompe, Alors que la partie aval correspond un
divergent dont le rôle est de réduire la vitesse de l’eau à la vitesse couramment admise dans
la conduite de refoulement, un clapet de refoulement dont le rôle est d’empêcher l’inversion
du débit de l’eau lors de l’arrêt de la pompe encore une vanne de refoulement qui permet
d’isoler la pompe en cas de besoin et enfin un réservoir d’air dont le rôle est de protéger la
conduite de refoulement contre les coups de bélier.
1.3. Problématique et objectifs 9

Figure 1.5 – Station de pompage .

1.3. Problématique et objectifs 10

-Le stockage d’eau dans les réservoirs

L’eau pompée sera conduit vers des bassins de stockage "réservoir" ayant les caracté-
ristiques suivantes :
-Fouille en pleine masse.
-Béton de forme dosé de 250KG HRS/m3 sous radier de hauteur 1.20 sur une
surface de 1800m2.
-Travaux d’étanchéité sur toute la surface du béton du forme posé sur un support
en enduit de ciment taloché et protégé par une couche d’enduit de ciment d’épaisseur
1.5 cm.
-Béton poreux sur toute la surface de béton de forme séparé par des caniveaux de
drainage d’une épaisseur 45cm.
-Radier général en béton armé dosé de 400kg HRS /m3, d’épaisseur 40 cm et de
surface 1800m2 renforcé par une chape dur taloché mécaniquement.
-Jupe périphérique en béton armé dosé de 400 kg HRS/m3 sur un rayon intérieur
de 22,50m, d’épaisseur 40cm et de hauteur 6,47m y compris tète de jupe.
-20 poteaux circulaires en béton armé de diamètre 50 cm et de hauteur.
-Poutre ceinture en béton armé repose sur la tête de jupe séparée par un joint
néoprène.
-Poutre de couronnement en béton armé repose sur les 20 poteaux sur un rayon
de 14,45m et de hauteur 70cm.
-Dalle incliné en béton armé repose sur la poutre ceinture et la poutre de couron-
nement séparé par un joint néoprène.
-Poutre en allège repose sur la poutre de couronnement de hauteur 1.70m.
-40 poutres courbées de longueur 14m et de rayon 21.50m en béton armé préfabri-
quées posées sur la poutre En allège et fermées par une poutre circulaire de rayon
3.20m et de hauteur 70cm.
-Des éléments préfabriqués en béton armé sous forme de coke posés entre les
poutres courbées servant comme couverture du réservoir cuvelage du réservoir par
un enduit spécial qui s’appelle "Masterseel".

Figure 1.6 – Réservoir.

1.4. Gestion de projet 11

1.3.2 Problématique
Vu la complexité d’exploitation et l’importance d’eau comme étant une ressource stra-
tégique et vitale, la SONEDE doit implémenter des stratégies et des normes de supervision
pour garantir le bon fonctionnement ses stations et minimiser le temps d’intervention.
Notre mission consiste à résoudre les problématiques liée au contrôle de la station de
pompage à distance et l’automatisation des interventions humaine. Alors, Le système doit
permet la mesure, le contrôle de la station de pompage et la surveillance à distance en
récupérant à tout instant l’état du système via l’envoi des notifications.

1.4 Gestion de projet

Avant de commencer notre projet, il serait judicieux de suivre un modèle de gestion de
projet pour le cycle de développement, ainsi la planification des tâches à effectuer tout au
long de la période du projet qui sera schématisée par le diagramme de GANTT.

1.4.1 Cycle de développement

Nous avons choisi un cycle de développement basé sur le modèle en V représenté sur la
figure 1.7. Ce modèle repose sur une approche de test et validation pour éviter le retour
aux étapes précédentes en cas d’anomalies. D’abord, nous formalisons les besoins du client,
et nous élaborons l’architecture générale du projet. Ensuite, nous définissons chaque sous
ensemble dans la phase de conception. Après, nous traduisons les fonctionnalités définies
lors de la phase de conception, où les fonctionnalités sont développées et testées séparément.
Finalement, tous les modules développés sont interfacés et le système final est testé.

Figure 1.7 – Modèle en V.

1.5. Conclusion 12

1.4.2 Diagramme de GANTT

Avant de commencer notre projet, il est indispensable d’ordonnancer les tâches, ce qui
nous a permettra ensuite de veiller à un bon avancement. Nous avons choisi le diagramme
de GANTT (figure 1.8) pour la présentation de la planification des tâches à réaliser.

Figure 1.8 – Diagramme de Gantt.

1.5 Conclusion
Dans cette partie, nous avons présenté l’organisme d’accueil « SONEDE» et Nous avons
présenté le contexte de notre projet.
Ainsi, nous avons pu décrocher problématique qui réside au contrôle des stations de
pompage et l’automatisation des interventions.
Nous avons aussi détaillé notre méthodologie et la répartition des tâches à effectuer.
Chapitre 2

ETUDE PREALABLE

Après avoir présenté le projet, nous passons à l’analyse et la spécification des besoins
relatifs à notre projet. Pour ce faire, nous identifions d’abord le système existant, puis une
étude critique de ce dernier pour nous permettre la spécification des besoins fonctionnels
et non fonctionnels. Finalement, nous choisissons de clarifier quelques scénarios que devra
assurer notre application pour répondre à ses besoins.

2.1 Étude de l’existant

Cette partie d’étude met en lumière la station de pompage comme étant un système à
superviser et à contrôler.

2.1.1 Description et identification de l’existant

Le système de pompage est parmi les nœuds les plus critiques au niveau d’exploitation
d’eau potable. Durant notre étude nous avons constaté que ce système est totalement isolé,
l’équipe contrôle ne peut rien constater ainsi rien décider en cas d’anomalie ou rupture du
service. Les actions ou les interventions résultants des ruptures peuvent être une perte de
temps et d’énergie malgré parfois leur complexité faible.

2.1.2 Étude critique

Pour que la station de pompage fonctionne de manière optimale en réduisant les in-
terventions des opérateurs sur site, La supervision et l’automatisation des interventions
deviennent indispensables.
Notre solution permet de piloter et d’optimiser l’exploitation à distance de l’installation
du pompage, et cela afin :
- D’éviter les pertes d’eau constatées au niveau des unités de stockage d’eau
- Améliorer le confort et la sécurité des exploitants et utilisateurs

13
2.1. Étude de l’existant 14

- Réaliser des économies d’énergie, éventuellement, apporter une aide aux décisions de
gestion et d’investissement.

Cette étude révèle les anomalies majeures suivantes :

En premier lieu, l’absence des informations relatives aux sites et aux systèmes de
pompage dont on peut citer niveau d’eau du réservoir, aussi bien le débit d’eau et l’état
des vannes par exemple. Ainsi, nous avons constaté que la station de pompage reste sans
supervision industrielle.
En second lieu, les interventions pour le remplissage du réservoir d’eau reste sans
contrôle malgré sa faible complexité elle peut engendrer plusieurs problèmes.

Donc, il est évidant d’automatiser certaines tâches. Car, L’automatisation du système

sert principalement à améliorer la sécurité et le confort des acteurs ainsi que la qualité des
produits. L‘objectif de l’automatisation des systèmes est de produire, en ayant recours le
moins possible à l’opérateur humain, des Produits de qualité et ce pour un coût le plus
faible possible.

Définition d’un système automatisé

un système automatisé est un ensemble d’éléments qui effectue des actions sans interven-
tion de l’utilisateur : c’est l’opérateur. Celui-ci se contente de donner des ordres de départ
et si besoin d’arrêt. La figure ci-dessous représente le concept du modèle automatisé.

Figure 2.1 – structure d’un système automatisé

Enfin, nous pouvons citer la difficulté d’avoir une vision d’état réelle des stations de
pompage du à la récupération des indicateurs qui peuvent être effectué qu’en site.
2.2. Analyse et spécification des besoins 15

La communication et l’échange des données peuvent améliore la qualité, l’expertise et

diminuer le coût des interventions en se basant sur des statistiques échangés par le site de
pompage et leur composant et le site de supervision et de contrôle.

2.2 Analyse et spécification des besoins

Après l’étude préalable et critique d’existant, comme première étape de développement
d’un système nous allons identifier les acteurs et intervenants de notre système, leurs rôles
et les services qu’offre le système. puis nous passons à l’analyse des besoins de notre projet
qui nous permis de cerner les fonctionnalités à fournir afin de répondre aux exigences du
SONEDE. Les besoins seront classés en besoins fonctionnels et non fonctionnels.

2.2.1 Identification des acteurs

L’acteur est le composant logiciel ou humaine qui interagit avec le système. Dans notre
projet, on a un seul type d’acteurs :
- Il s’agit du superviseur qui est considéré comme acteur principal.

2.2.2 Analyse des besoins

Cette étape consiste à analyser la situation pour tenir compte des contraintes et assurer
un processus répondant aux besoins de la SONEDE.
L’analyse fonctionnelle est possible grâce à des outils clairement défini. On trouve
ainsi :
-La bête à cornes, qui permet d’exprimer la recherche du besoin
-Le diagramme pieuvre, qui permet de définir les liens (c’est-à-d les fonctions de ser-
vice) entre le système et son environnement. Ce diagramme permet de recenser la plupart
des fonctions du système.
-le cahier des charges, qui permet de décrire et lister les fonctions primaires, secon-
daires et les contraintes du système étudié.
Les besoins devront être exprimés sous forme de fonction et non de solution pour permettre
un choix lors de l’étude technique.

1- La bête à cornes
Pour établir la bête à corne, il est essentiel de se poser les trois questions suivantes :
-A qui, a quoi le produit rend-il service ?
-Sur qui, sur quoi agit-il ?
-Dans quel but ? (Pour quoi ?)
2.2. Analyse et spécification des besoins 16

Figure 2.2 – Diagramme bête à corne exprimant le besoin du système de contrôle

2- Diagramme Pieuvre
Le diagramme pieuvre nous nous permet de répertorier toutes les fonctions de notre
produit.
On distingue deux types de fonction :
Fp : Fonction principale : Lien entre le produit et deux objets environnants.
Fc : Fonction de contrainte : Lien entre le produit et un objet environnant.

Figure 2.3 – Diagramme pieuvre reliant le système avec son environnement extérieur

3-Cahier de charges :
3.1- Besoins fonctionnels :
2.2. Analyse et spécification des besoins 17

Nous allons préciser ci-dessous ce que le système permet à chacun des acteurs qui sont
représenté par un seul pour notre cas qui est le superviseur.
La solution proposée doit répondre aux besoins demandés par SONEDE comme système
de contrôle et d’automatisation des interventions au niveau d’une station de pompage à
distance :
-Contrôle en temps réel du niveau du réservoir
-Collection d’information à distance
-Affichage des indicateurs en site
-Intégration des indicateurs avec la plateforme existante du SONEDE "LabVIEW"
-Envoie des notifications et des alertes
-Automatisation du processus de pompage et d’ouverture de vanne en cas d’atteinte du
seuille limite

3.2- Besoins non fonctionnels :

Les besoins non fonctionnels sont des besoins qui caractérisent le système. Ce sont des
besoins en matière de performance, de type de matériel (type capteur...) ou le type de
conception. Ces besoins peuvent concerner les contraintes d’implémentation (langage de
programmation, de système d’Exploitation...). Afin d’avoir un système performant et effi-
cace. L’application doit vérifier implicitement ces critères :
-La rapidité d’envoi de l’SMS (synchronisation du GSM avec l’application traitement en
temps réel).
-La facilité de l’utilisation de l’application via son interface LabVIEW.
-La fiabilité : l’application doit garantir l’envoi du message à un superviseur contacts.
-Assurer une cohérence et une crédibilité aux informations stockées dans l’interface Lab-
VIEW
-Sécurité : à développer d’avantage
-Qualité
-Accessibilité et performance

3.3- Contraintes du projet :

3.3.1- Contraintes temporelles du projet :

-Le temps dédié à ce travail qui ne doit pas dépasser quatre mois.
-Le travail final doit être rendu avant la date de la présentation définitive.

3.3.1- Contraintes techniques du projet :

-La simulation des volets matérielle et logicielle est nécessaire.
-L’application de certaines solutions techniques comme IOT (Internet Of Thing)
nécessite plus de matérielle.
2.3. Conclusion 18

2.3 Conclusion
Dans ce chapitre, nous avons étudié le système existant d’une façon crédible ce qui
nous a permis de spécifier les besoins fonctionnels et les besoins non fonctionnels de notre
système et identifier les acteurs qui entrent enjeu. Ainsi, nous allons entamer la prochaine
étape qui consiste à présenter la phase de conception.
Chapitre 3

CONCEPTION

3.1 Introduction

La phase d’étude de l’analyse l’existant et l’analyse et spécifications des besoins nous

ont donné une vue claire sur le système à réaliser. Dans ce chapitre, nous allons présenter
la conception globale ainsi que la conception détaillée de notre application ce qui va nous
faciliter la tache de réalisation.

3.2 Langage de conception

Les systèmes embarqués sont aujourd’hui le secteur le plus important pour l’informa-
tique tant pour le volume que pour le taux de croissance. Un système embarqué est système
autonome composé de logiciels et matériels, conçu pour exécuter une fonction spécifique. Ils
sont présents dans tous les domaines. On les trouve dans le transport, le domaine militaire,
les télécommunications, le médical, etc. Alors, la définition de l’architecture matérielle et
logicielle est une phase importante pour les systèmes embarqués car ce choix a une in-
fluence directe sur les performances. Pour accomplir cette phase, nous adoptant le langage
de conception UML. UML est imposé comme un standard et il est de plus en plus utilisé
pour la conception des systèmes embarqués temps réel. Afin de modéliser les aspects spéci-
fiques de tels systèmes, le profil UML for "Schedulability, Performance Time" (SPT)
a été adopté par l’OMG. L’objectif est de prendre en compte les spécificités du temps réel
en conservant les bénéfices de l’approche objet, et proposer aussi un cadre de modélisa-
tion temporel afin de réaliser une validation temporelle par une méthode d’analyse. Ainsi,
UML avec ses mécanismes d’extensions est désormais une place au sein des langages de
développement pour les systèmes embarqués temps réel.

19
3.3. Modélisation fonctionnelle et structurelle du système en Sys ML 20

3.3 Modélisation fonctionnelle et structurelle du sys-

tème en Sys ML
La modélisation en Sys Ml est le nouveau langage de modélisation défini par l’OMG. Il
est peut être vu comme une extension d’UML destinée à la modélisation d’un large spectre
de système complexe. Son champ d’application est en ce sens plus large que celui d’UML
mais sa filiation le rend tout particulièrement intéressant pour la modélisation de système
embarqué majoritairement composés de logiciel.
Nous allons maintenant combiner la modélisation RT-UML et Sys ML pour définir les
fonctionnalités de notre système de contrôle et d’intervention au niveau d’une station de
pompage. Puis, on va clôturer avec la représentation générale de la chaine de fonction de
notre système.

3.4 Diagramme De Cas d’Utilisation

Le diagramme de cas d’utilisation est un diagramme utilisé pour donner une vision
globale du comportement fonctionnel d’un système dans notre cas le système de contrôle
du site du pompage.
Dans ce diagramme, les utilisateurs sont appelés acteurs, ils interagissent avec les cas
d’utilisation qui représentent à leurs tour des unités significatives de travail ou des tâches.
3.4. Diagramme De Cas d’Utilisation 21

Figure 3.1 – Diagramme De Cas d’Utilisation.

3.5. Diagramme Etat/Transition 22

3.5 Diagramme Etat/Transition

Le diagramme représente l’aspect comportemental de l’application. C’est une machine
à état dont les transitions sont des évènements entrants sur le processus de contrôle dans
notre cas détection du niveau d’eau dans le réservoir et les actions correspondent à émettre
des évènements vers les processus fonctionnels qui se résument en trois actions :
-Affichage et information instantanée d’état du réservoir en site local.
-Contrôle de la vanne pour régler le niveau d’eau.
-La communication avec le module distant à travers le réseau GSM.
-La réception, le stockage et l’intégration avec la tierce partie "LABVIEW".

Figure 3.2 – Diagramme Etat/Transition.

3.6. Diagramme de séquence 23

3.6 Diagramme de séquence

Pour modéliser le concept d’action qui définit l’unité fondamentale de la spécification
comportementale, on va utiliser le diagramme de séquence. Ce dernier supportant la défi-
nition du temps.
-TimeExpression : définit la spécification d’une valeur qui représente une valeur
de temps.
-Duration : définit la spécification d’une valeur décrivant la distance temporelle
qui sépare deux expressions de temps marquant deux instants.
Le diagramme ci-dessous illustre la contrainte d’occurrence temporelle de communication
dès l’acquisition d’état du réservoir entre le site de pompage et jusqu’au site distant de
réception, stockage et intégration avec le tierce partie "LABVIEW" ainsi que la durée du
temps entre l’envoie et la réception.

Figure 3.3 – Diagramme de séquence.

3.7. Diagramme de définition de Bloc 24

3.7 Diagramme de définition de Bloc

Ce diagramme Montre le système du point de vue composant et il répond à la question
"qui contient quoi ?". Le bloc Sys ML ("block") constitue la brique de base pour la modé-
lisation de la structure d’un système.
Le diagramme ci-dessous représente une vue d’ensemble des composant élémentaire de
notre système de control du site de pompage.

Figure 3.4 – Diagramme de définition de Bloc.

3.8 Chaîne fonctionnelle

Notre système se décompose en deux partie ; une partie commande (chaine d’informa-
tion) et une autre partie opérative (chaine d’énergie). Une chaine fonctionnelle est l’ad-
jonction de ces deux chaines.
La chaine d’information est responsable d’élaborer des ordres à partie de grandeurs phy-
siques mesurées sur la partie opérative du système et des consignes venues de l’extérieur.
Elle traite ces données pour en déduire les ordres à donner.
La chaine d’énergie c’est la partie opérative du système.
3.8. Chaîne fonctionnelle 25

Alors, on peut représenter la chaine fonctionnelle de notre système de supervision de la

station de pompage et d’intervention automatique au niveau de la vanne comme suit :

Figure 3.5 – Chaîne fonctionnelle.

3.9. Conclusion 26

3.9 Conclusion
Chapitre 4

REALISATION

Après avoir définit la conception de notre système de supervision et d’automatisation

de la station de pompage, dans ce chapitre, nous décrivons les étapes de l’implémentation
de notre solution.
Une première partie, nous présentons l’environnement matériel et logiciel. Ensuite, nous
passons à la description détaillée du montage et le développement réalisé par composant.
Enfin, nous présentons le système de communication et de supervision tierce.

4.1 Environnement de travail

Dans cette section, nous décrivons l’environnement matériel et logiciel utilisé pour ac-
complir la dernière phase du projet.

4.1.1 Environnement matériel

Durant ce projet, nous avons utilisé les composants matériels suivants :

1-La carte ARDUINO UNO :

Le système Arduino nous donne la possibilité d’allier les performances de la program-
mation à celles de l’électronique. Plus précisément, nous allons programmer des systèmes
électroniques. Le gros avantage de l’électronique programmée c’est qu’elle simplifie gran-
dement les schémas électroniques et par conséquent, le cout de la réalisation, mais aussi la
charge de travail à la conception d’une carte électronique.
La carte Arduino Uno est une carte à microcontrôleur basée sur l’ATmega328.
Cette carte peut être alimentée soit via la connexion USB (qui fournit 5V jusqu’à
500mA) ou à l’aide d’une alimentation externe. La source d’alimentation est sélectionnée
automatiquement par la carte.

27
4.1. Environnement de travail 28

Figure 4.1 – Carte Arduino

Figure 4.2 – Synthèse des caractéristiques

4.1. Environnement de travail 29

2-Les shield GSM :

Pour assurer la communication entre les deux sites, le site du pompage et le site distant
de contrôle et de supervision.
2.1-Shield GSM-GPRS 2 Arduino :
Le shield GSM-GPRS 2 Arduino avec antenne intégrée basé sur le module M10 de
Quactel est prévu pour ajouter les fonctionnalités de SMS, GSM/GPRS et appel à des
applications Arduino.
L’ajout d’une carte SIM est nécessaire pour pouvoir appeler, envoyer des SMS et hé-
berger une page web.
L’utilisation de ce shield nécessite d’alimenter la carte Arduino via le connecteur ex-
terne par une alimentation de 700 à 1000 mA.

Figure 4.3 – Shield GSM-GPRS 2 Arduino

Figure 4.4 – Synthèse des caractéristiques

4.1. Environnement de travail 30

2.2-Shield SIM900A
Le shield GSM-GPRS compatible Arduino basé sur le module SIM900 de Simcom est
prévu pour ajouter les fonctionnalités de SMS, GSM/GPRS et appel vos applications Ar-
duino.
L’ajout d’une carte SIM est nécessaire pour pouvoir appeler, envoyer des SMS et hé-
berger une page web.
Nous ne pouvons pas alimenter le module à partir de l’Arduino, car il est incapable
de fournir les courants de pointe nécessaires. Le Sim900 consomme environ 2A

Figure 4.5 – Shield SIM900A

Figure 4.6 – Synthèse des caractéristiques

4.1. Environnement de travail 31

3-Capteur ultrason
Les capteurs ultrasons fonctionnent en mesurant le temps de retour d’une onde sonore
inaudible par l’homme émise par le capteur. La vitesse du son étant à près stable, on en
déduit la distance à l’obstacle.
Ce capteur ultrason compatible Arduino, permettant d’effectuer des mesures de dis-
tance plus de 4 mètre. Il va nous servir pour la détection du niveau d’eau du réservoir.

Figure 4.7 – Capteur ultrason

Figure 4.8 – Synthèse des caractéristiques

4.1. Environnement de travail 32

4-Capteur niveau d’eau

Pour assurer la continuité du fonctionnement nous avons utilisé un capteur dédié pour
la mesure du niveau d’eau. Le modèle choisi est "Module capteur de niveau d’eau ST045".
Ce module didactique délivre une tension analogique en fonction du niveau d’eau grâce
à ses pistes imprimées. Le capteur délivre ”700” lorsque le niveau est au maximum et ”450”
lorsque le niveau est au plus bas.

Figure 4.9 – Capteur niveau d’eau

Ce module se raccorde sur une entrée analogique de notre carte Arduino.

Figure 4.10 – Synthèse des caractéristiques

4.1. Environnement de travail 33

5-Afficheur LCD
Pour assurer la fonction d’affichage nous avons recours à un afficheur lcd de type LCD
2x16.

Figure 4.11 – Afficheur LCD

Figure 4.12 – Synthèse des caractéristiques

4.1. Environnement de travail 34

Simulation d’ouverture de la vanne :

La simulation de la pompe nécessite plus de matériel dont on peut citer :
Capteur de pression d’eau (pressostat) pour transformer une ou plusieurs valeurs de
pression déterminées en provoquant par exemple le démarrage ou l’arrêt de notre pompe.
6-Un mécanisme de pompage.
Notre tâche ce limite à l’interfaçage système-vanne pour le commander. Il nous suffit
d’un Servomoteur. Notre choix s’est porté sur un modèle Tower Pro SG90.

Figure 4.13 – modèle Tower Pro SG90.

Figure 4.14 – Synthèse des caractéristiques

4.1. Environnement de travail 35

7-Sources d’alimentation à commutation

Pour alimenter notre système nous avons choisi un le model "MEAN WELL RS-15-5".

Figure 4.15 – modèle Tower Pro SG90.

Figure 4.16 – Synthèse des caractéristiques

4.1. Environnement de travail 36

8-Convertisseur
Nous avons utilisé le convertisseur (XL6009E1 Step-Up Adjustable DC-DC Switching
Boost Converter) car il représente un excellent moyen d’augmenter facilement une tension
donnée. Puisqu’il s’agit d’un convertisseur élévateur, la tension de sortie doit être supé-
rieure à la tension d’entrée fournie.

Figure 4.17 – Convertisseur

Figure 4.18 – Synthèse des caractéristiques

4.1. Environnement de travail 37

4.1.2 Environnement logiciel

Dans cette section, on va repérer les différents logiciels utilisés dans notre projet.
1-Arduino IDE :
Nous avons utilisé l’environnement de programmation Arduino (IDE en anglais) pour
le développement. Il s’agit d’une application java, libre et multiplateforme.
Le langage de programmation utilisé est le C++, compilé avec avr-g++.

Figure 4.19 – Arduino IDE

2-Fritzing
Frizing est un logiciel libre de conception de circuit imprimé. A l’aide de ce dernier
nous avons pu détailler le montage des différents composants de notre système.

Figure 4.20 – logiciel Frizing

3-Tera Term
Tera Term est un programme d’émulation de terminal gratuit, à source libre et im-
plémentée par logiciel. Nous avons l’utilisé pour émuler le terminal Arduino et prendre en
charge les ports série.
4.1. Environnement de travail 38

Figure 4.21 – Tera Term

4-LabView
Labview (Laboratory Virtual Instrument Engineering WorkBench) est un logiciel de
développement de programmes d’application. LabView utilise un langage de programma-
tion essentiellement graphique dédié au contrôle, à l’acquisition, l’analyse et la présentation
de données.

Figure 4.22 – LabView

4.1.3 Montage et Code

Après avoir fixé les composants matériels nécessaires pour accomplir notre projet, nous
passons à la description détaillée du montage ainsi que les bouts de code (Snippet) les plus
critiques qui assurent le fonctionnement du système.
4.1. Environnement de travail 39

Alimentation
Pour alimenter le système lié à la station du pompage, tout en respectant les caracté-
ristiques du coté tension et intensité du matériel utilisé. Nous avons adapté cette solution :
Connexion directe 220V pour alimenter la source à commutation ("MEAN WELL RS-
15-5"). Ce dernier délivre une tension 4,5V (2A) pour la Shield Sim900A et en utilisant
le convertisseur ("XL6009E1 Boost Converter") pour supporter la carte Ardiuno et les
différentes composants comme les leds, l’afficheur, le servo et les capteurs.

Figure 4.23 – Montage avec le source d’alimentation

Au niveau du site distant, la liaison de la seconde carte Arduino avec le pc assure l’ali-
mentation du Shield GSM-GPRS 2 Arduino.

Figure 4.24 – Liason entre carte Arduino et le PC

Montage D’affichage
Pour l’affichage nous avons utilisé un afficheur LCD et des LEDs pour indiquer le ni-
veau d’eau dans le réservoir comme explique les deux figures ci-dessous.
On inclut les bibliothèques LiquidCrystal-I2C et Wire (FastIO.h, 2CIO.h, LCD.h, Wire.h)
et la méthode est la suivante :
4.1. Environnement de travail 40

Figure 4.25 – Montage LCD

Figure 4.26 – Code d’affichage de niveau d’eau

Montage Leds
Nous avons utilisé trois leds pour visualiser les trois niveaux d’eau :

Figure 4.27 – Tableau récapitulatif d’état des Leds au différentes niveaux d’eau
4.1. Environnement de travail 41

Figure 4.28 – Montage Leds

Le changement du niveau doit être capturé et visualisé à l’utilisateur selon des for-
mules conditionnelles dont le résultat est un signal en premier temps puis un moyen d’in-
formations des utilisateurs distants ainsi la réaction et l’ajustement du niveau d’eau qui
doit être gérer en temps réel.
Exemple de contrôle :
Pour des raisons de prototypage les dimensions sont très réduites.

Figure 4.29 – Cas ou le niveau d’eau dans le premier niveau

4.1. Environnement de travail 42

Montage Shield SIM900A Mini

Pour informer les utilisateurs distants nous avons choisi la communication avec un Mo-
dule GSM ; c.-à-d. tout type de changement de niveau entraine un envoi d’un SMS pour
les contrôleurs.

Figure 4.30 – Montage de Shield GSM avec la carte Arduino

Le shield utilise une série de commande « Basic AT Command » :

Figure 4.31 – Code d’informaion des controleurs de niveau d’eau

4.1. Environnement de travail 43

Montage Shield GSM 2 Arduino

Ce shield est relié à la poste du contrôle du site distant. Il joue le rôle du récepteur.
Les deux cartes (Arduino Uno et Shield GSM) sont superposées comme l’explique la figure
ci-dessous.
Cette méthode assure la réception et l’affichage du message.

Figure 4.32 – Montage Arduino Figure 4.33 – Montage Arduino Shield

Shield GSM GSM 3D

Figure 4.34 – Code de Traitement du message par le Shield receptif

4.1. Environnement de travail 44

Montage du capteur Ultrason

Pour calculer le niveau d’eau nous avons recours à un capteur ultrason dont la formule
de calcul est la suivante : Distance = duration / 29.1*SOUND-SPEED ;

Figure 4.35 – Montage du capteur Ultrason

En se basant sur la distance calculée précédemment, nous déterminons le volume d’eau

du réservoir.
4.1. Environnement de travail 45

Figure 4.36 – Code qui donne le volume d’eau de réservoir

4.1. Environnement de travail 46

Montage Capteur Niveau d’eau

Ce capteur délivre deux valeurs distinctes ; au niveau maximum « 700 » et au niveau
bas « 450 ».

Figure 4.37 – Montage Capteur Niveau d’eau

Figure 4.38 – Code qui donne le niveau d’eau

4.1. Environnement de travail 47

Montage du Servomoteur
Pour simuler l’ouverture de la vanne du réservoir nous avons recours au servomoteur
SG90.

Figure 4.39 – Montage du Servomoteur

Nous distinguons trois états de la vanne :

Ouverture complète : servo en 180◦
Demi-ouverture : servo en – 90◦
Fermeture : servo en -90◦ (état précédente -90◦ )

Montage Globale
La figure ci-dessous illustre notre système complet du deux sites local et distant.
4.2. Partie supervision 48

Figure 4.40 – Site du pompage Figure 4.41 – Site de contrôle

4.2 Partie supervision

La tierce partie responsable de la supervision est le logiciel "LABVIEW". Il propose
une solution pour l’acquisition de données (Mesures, alarmes, retour d’état de fonction-
nement) et des paramètres de commande des processus. Nous avons choisi ce programme
pour les plusieurs raisons :
- interface graphique sophistiquée.
- outil de développement des interfaces personnalisées.
- acquisition des données à partir des différentes sources (Arduino, fichier...).
- contrôle des composants matériels.

4.2.1 Interface de contrôle et moyen d’interfaçage

Nous allons détailler dans ce qui suit les interfaces graphiques et l’interaction avec notre
plateforme.

Interface de contrôle LABVIEW

La fonctionnalité du système réalisé est le contrôle du niveau d’eau dans le réservoir.
La figure ci-dessous représente l’interface de contrôle de ce dernier après l’acquisition
des données.
4.2. Partie supervision 49

Figure 4.42 – interface de contrôle de ce dernier après l’acquisition des données

Le niveau d’eau au cours du temps est exprimé dans la figure ci-dessous.

Figure 4.43 – Le niveau d’eau au cours du temps

4.2. Partie supervision 50

Pour assurer une supervision complète nous avons ajouté le suivi du débit et de la
pompe comme explique la figure.

Figure 4.44 – débit et de la pompe

Et pour des raisons de fiabilité et de disponibilité des alertes, nous communiquons aux
utilisateurs de control des SMS à chaque changement critique de niveau d’eau.

Figure 4.45
4.2. Partie supervision 51

4.2.2 Solution d’interfaçage

L’interfaçage de notre solution avec le logiciel LABVIEW est assuré par le programme
TraTerm. Après l’envoie du sms chaque période T (5 min pour la phase du test), la réception
est exécutée par le shield GSM Arduino qui à son tour présente un flux d’entré pour le
TeraTerm.

Phase configuration d’émulateur Tera Term

L’émulateur assure le transfert des données communiqué entre les deux sites à travers
le port série pour le sauvegarder dans un fichier cible.

Figure 4.46 – Configuration émulateur Tera Term

4.2. Partie supervision 52

Phase configuration et acquisition des données LABVIEW

Pour visualiser les données mis à jour du fichier cible du Tera Term nous avons créé cet
algorithme et paramétré le chemin du fichier.

Figure 4.47 – Une lecture puis l’affichage de la valeur déjà lu sur le « Tank ».
4.2. Partie supervision 53

Figure 4.48 – Paramétrage du ficher

Pour finir nous présentons ci-dessous la synchronisation du réservoir avec les valeurs
communiqué, transfert et sauvegardé.
4.3. Conclusion 54

4.3 Conclusion
Dans ce chapitre, nous avons met l’accent sur la description des caractéristiques de l’en-
vironnement du travail et décrit les plateformes matérielles et logiciel d’une part. D’autre
part, nous avons détaillé le montage et le code nécessaire pour accomplir la tâche du
contrôle et d’automatisation. Enfin nous avons clôturé ce chapitre par la présentation des
configurations et des interfaces graphiques de contrôle.
Conclusion et perspectives

Récapitulation du travail réalisé

Enrichissements possibles

55
Bibliographie

56
Netographie

57