Universite Libre Des Pays de Grands Lacs (Ulpgl)

Télécharger au format pdf ou txt
Télécharger au format pdf ou txt
Vous êtes sur la page 1sur 87

UNIVERSITE LIBRE DES PAYS DE GRANDS LACS

(ULPGL)

B.P 368 GOMA


www.ulpgl.net

FACULTE DES SCIENCES ET TECHNOLOGIES APPLIQUEES


DEPARTEMENT DE GENIE ELECTRIQUE ET INFORMATIQUE

CONCEPTION ET REALISATION D’UN


SYSTEME DE DISTRIBUTION
AUTOMATIQUE DE BOISSONS

Par DANIELLA MUGHOLE KALIMUMBALO

Travail présenté et défendu en vue de l’obtention du


diplôme d’Ingénieur Civil en Génie électrique et
Informatique
Option : Génie Informatique
Directeur : Prof. Dr Ir Claude TAKENGA MBUSA
Encadreur : Ass. Ir Raoul IRENGE BAGUMA

Année Académique : 2017-2018


i

EPIGRAPHE

« L’innovation est cette incroyable intersection entre l’imagination d’une personne et


la réalité dans laquelle elle vit »
Ron Johnson
ii

DEDICACE

A mes très chers parents KAMBALE KALIMUMBALO et KABUO


ISEGHUNDI

Que ce travail constitue pour vous une source de fierté, de confiance et surtout
un fruit de bonheur.

DANIELLA MUGHOLE
iii

REMERCIEMENTS
En premier lieu, nous rendons gloire à Dieu, Maitre de temps et des circonstances, pour
ses innombrables, inestimables et immérités dons et bienfaits en notre faveur.

Nos remerciements vont ensuite au Professeur Claude TAKENGA MBUSA, notre


directeur et à l’Assistant Raoul IRENGE BAGUMA, notre encadreur. Nous avons eu le
privilège de travailler à vos côtés durant toute la période qu’a pris la réalisation de ce travail
; votre sérieux, votre compétence et votre sens du devoir nous ont énormément marqués.
Veuillez trouver ici l’expression de notre respectueuse considération et notre profonde
admiration pour toutes vos qualités scientifiques et humaines.

Notre reconnaissance s’adresse par la suite à nos chers parents KAMBALE


KALIMUMBALO Dieudonné et KABUO ISEGHUNDI Joséphine pour leur soutien
moral et matériel, leur sollicitude, leurs incalculables égards et leur immense amour.

A nos frères et sœurs : Fleurette VASIYIRWANDI, Inès MUHERUKI, Justine


KALIMUMBALO, Josiane NDAGHANE, Thierry KASONGO et Raph-Arsène
KASONGO pour leur soutien indéfectible à notre égard.

Notre gratitude particulière à Ir Patrick VINGI, pour ses orientations, ses connaissances
et sa disponibilité inconditionnelle qui nous ont été d’une grande aide pour la
concrétisation effective de notre idée.

A nos amis et camarades d’auditoire : Elie LUBAMBA, Alvin BAUMA, Pascal KOKO,
Grevisse KALUMENDO, Jonas MALUMA, Rosette LUKONGE, Irène MASENGU et
Marie-Reine BAHARANYI pour leurs encouragements et leur soutien durant toute la
période passée ensemble à l’université.

Que ceux qui, de près ou de loin, nous ont apporté leur soutien, tant moral que matériel,
trouvent ici l’expression de notre profonde gratitude.

DANIELLA MUGHOLE
iv

LISTE DES FIGURES


Figure I.1: Structure d’un système automatisé .............................................................................. - 6 -
Figure I.2: Structure d’un GRAFCET .......................................................................................... - 10 -
Figure I. 3: Image d'un distributeur automatique de café .......................................................... - 11 -
Figure I.4: Présentation de la carte Arduino UNO ...................................................................... - 16 -
Figure I.5: Une carte Arduino étendue avec un Ethernet Shield ................................................ - 17 -
Figure I.6: Shield écran LCD Arduino .......................................................................................... - 18 -
Figure I.7: Bouton poussoir ............................................................................................................ - 18 -
Figure I.8: Photorésistance ............................................................................................................. - 19 -
Figure I.9: Servomoteur Arduino .................................................................................................. - 19 -
Figure I.10: Fenêtre du logiciel Arduino ....................................................................................... - 20 -

Figure II.1: Cycle de développement d’une application informatique ....................................... - 23 -


Figure II.2: Diagramme de contexte du système .......................................................................... - 27 -
Figure II.3: Diagramme préliminaire du système ........................................................................ - 28 -
Figure II.4: Représentation de base d’un diagramme d’état-transition .................................... - 30 -
Figure II.5: Diagramme d’état-transition du système ................................................................. - 31 -
Figure II.6: Représentation des synchronisations entre les tâches ............................................. - 37 -
Figure II.7: Représentation d’un module de données partagé par plusieurs tâches. ................ - 38 -
Figure II.8: Diagramme multitâche DARTS du système ............................................................. - 40 -
Figure II.9: Diagramme des classes du système............................................................................ - 41 -
Figure II.10: Modèle logique des données ..................................................................................... - 42 -

Figure III.1: Diagramme de séquence du système........................................................................ - 43 -


Figure III.2: Diagramme d’activité du système ............................................................................ - 44 -
Figure III.3: Fenêtre du logiciel Fritzing ...................................................................................... - 46 -
Figure III.4: Carte Arduino Mega 2560 ........................................................................................ - 47 -
Figure III.5: Module RFID RC522 ................................................................................................ - 48 -
Figure III.6: Clavier Arduino 4x4.................................................................................................. - 49 -
Figure III.7: Ecran LCD ................................................................................................................. - 50 -
Figure III.8: Mini pompe à air ....................................................................................................... - 50 -
Figure III.9: Capteur à ultrasons ................................................................................................... - 51 -
Figure III.10: Capteur de niveau d’eau ......................................................................................... - 51 -
Figure III.11: Relais à 1 canal ........................................................................................................ - 52 -
Figure III.12: Buzzer ....................................................................................................................... - 52 -
Figure III.13: LED .......................................................................................................................... - 53 -
Figure III. 14: Shield Wifi .............................................................................................................. - 53 -
Figure III.15: Fils de pontage ......................................................................................................... - 54 -
Figure III.16: Page d’accueil de l’application ............................................................................... - 55 -
Figure III.17: Historique des consommations............................................................................... - 55 -
Figure III.18: Liste des abonnés ..................................................................................................... - 56 -
Figure III.19: Enregistrement d’un abonné .................................................................................. - 56 -
Figure III.20: Recharge du compte d’un abonné ......................................................................... - 57 -
Figure III.21: Schéma du système .................................................................................................. - 57 -
Figure III.22: Montage du système ................................................................................................ - 58 -
Figure III. 23: Maquette du système.............................................................................................. - 58 -
v

LISTE DES TABLEAUX

Tableau 1: Broches du module RFID ............................................................................................ - 48 -


Tableau 2: Description des broches de l’écran LCD .................................................................... - 49 -
Tableau 3: Caractéristiques des LEDs .......................................................................................... - 53 -
Tableau 4: Coût estimatif des matériels ........................................................................................ - 59 -
vi

RESUME

L’humain dans sa quête du confort et de la bienséance cherche toujours à éliminer des


opérations fastidieuses dans son quotidien ; les automatismes qui en résultent sont fascinants.
Pour répondre au rendez-vous du progrès de la technologie, nous avons développé un système
automatisé de distribution de boisson construit autour de la plateforme Arduino avec sa gamme
bien fournie en capteurs et actionneurs, parmi lesquels nous avons utilisé le module RFID, le
capteur à ultrasons, le capteur de niveau d’eau, les pompes, …

Ainsi, pour mieux cerner l’essentiel de cette étude, nous l’avons axé sur trois grandes parties :
dès les premiers contacts, nous avons présenté les généralités sur les automatismes et la
plateforme Arduino ; ensuite nous avons présenté la description des différentes fonctionnalités
du système proposé à travers la conception et la modélisation en utilisant les méthodes SART
et DARTS. En dernier lieu nous avons réalisé le prototype du système ici proposé.

Mots clés : distributeur de boisson, Arduino, module RFID, capteur à ultrason, capteur de
niveau d’eau, UML, SART, DARTS, mini pompe à air.
vii

ABSTRACT
The human being in his search for comfort and privacy seeks to eliminate tedious operations in
his daily life; the automation resulting from this process is fascinating. In order to meet the
appointment of advances in technology, we developed an automated drink/beverage dispensing
system built around Arduino Platform with its supplied range of sensors and actuators among
which we used RFID module, ultrasonic sensor, water level sensor, pump, …

Thus, to catch the essential of this study, we focused on three main parts: first, we presented
the general information on automation and Arduino platform; then we presented a description
of various features of the proposed system through the design and modelling, using SART and
DARTS methods. Finally, we implemented the prototype of the proposed system.

Key words: beverage distributor, Arduino, RFID module, ultrasonic sensor, water level sensor,
UML, SART, DART, mini air pump
viii

SIGLES ET ABREVIATIONS

DARTS: Design Approach for Real Time Systems

D.A: Distributeur automatique

EEPROM: Electrically-Erasable Programmable Read-Only Memory

FIFO: First In First Out

GRAFCET: Graphe Fonctionnel de Commande Etape/Transition

LCD: Liquid Crystal Display.

LED: Light-emitting diode

NTIC : Nouvelle technologie de l’information et de la communication

PWM: Pulse-width Modulation

RFID: Radio Frequency Identification

SART: Structured Analysis Real-Time

SRAM: Static Random Access Memory

TOR : Tout Ou Rien

UML : Unified Modeling Language.


-1-

INTRODUCTION GENERALE
La technologie de l’information et de la communication devient de plus en plus indispensable
et incontournable dans la vie de l’homme, pour un développement durable, et s’impose dans
plusieurs domaines d’activités.
Actuellement, le monde connaît une avancée technologique considérable dans plusieurs
secteurs et cela grâce à l’informatique et l’électronique diffuse ou ubiquitous computing
(ubiquitous hardware) en anglais. Ils comprennent des systèmes faits d’électronique plus ou
moins complexe et d’informatique plus évoluée.

La communication entre un homme et une machine (homme-machine) ou la communication


entre machines (machine-machine) peut être considérée comme étant un nouveau type de
dialogue possible. En effet, depuis quelques années, les appareils embarqués sont devenus de
plus en plus capables d’agir d’une façon intelligente selon le profil des utilisateurs et capables
de prendre des décisions de manière autonome.
Il suffit de regarder autour de soi, au quotidien, pour avoir la réponse. Les systèmes embarqués
nous entourent, et nous sommes littéralement envahis par eux ; fidèles au poste et prêts à nous
rendre service. Un système embarqué peut être défini comme un système électronique et
informatique autonome, qui est dédié à une tâche bien précise. [1]

C’est dans cette optique que s’inscrit notre projet de recherche intitulé : « Conception et
réalisation d’un système de distribution automatique de boissons ». Le cœur du système sera
conçu sur base de la plateforme Arduino, des technologies RFID, des pompes et des capteurs.
Une interface web, liée à une base de données permettra de configurer et de gérer les données
des utilisateurs.

1. Problématique
La demande des distributeurs automatiques est en constante évolution, surtout dans des lieux
tels que les centres commerciaux, les aéroports, les entreprises, les hôpitaux, les universités, les
écoles, etc.
Il suffit de travailler dans un bureau ou d’être dans des lieux très fréquentés pour comprendre
tout ce qu’un simple distributeur automatique peut signifier pour les êtres humains. Nos
journées sont de plus en plus remplies, les pauses deviennent plus fondamentales, non
seulement parce que ce sont des véritables moments de convivialité au cours desquels les
personnes travaillant dans une même société ou dans un même établissement se retrouvent,
mais de plus, elles permettent de restaurer notre énergie. Il est à noter que durant chaque journée
-2-

de travail, les employés quittent leurs lieux de travail pendant plusieurs minutes pour prendre
une boisson rafraichissante ou une tasse de boisson chaude. Les chefs d’entreprises disent
souvent : « le temps, c’est de l’argent ». Le temps que peut prendre un employé pour qu’il soit
servi, s’il s’est rendu dans une cafétéria, ou qu’il puisse préparer son thé ou son café, est non
négligeable pour l’entreprise.
Dans notre région, en particulier dans la ville de Goma, il est souvent difficile de trouver une
boutique, un magasin ou une cafétéria qui fonctionne 24h/24 ou 7j/7. L’indisponibilité
contingente du service peut être due par diverses raisons (jour férié, grève, congé, …) et cela
peut être pénalisant pour les clients. Par exemple, les cantines dans les universités ne
fonctionnent pas le Samedi, alors que les étudiants ont cours et auront peut-être besoin de
s’acheter une petite collation à la pause.
Dans ce travail, nous nous intéressons à la conception et réalisation d'un système de distribution
automatique de boisson. Pour mieux cerner cet énoncé, nous essayerons de trouver des réponses
aux questions suivantes :

 De quelle manière un distributeur peut-il améliorer le quotidien de l’homme ?


 Comment assurer la performance ainsi que la rapidité de service de notre système ?
 Quels mécanismes mettre en œuvre pour assurer l’automatisme du système ?

2. Hypothèses
Étant donné que les hypothèses sont des réponses anticipées aux questions spécifiques d'une
recherche, il sied d'évoquer les hypothèses ci-dessous, considérant que celle relative à la
question principale est que le distributeur automatique influencerait de manière considérable la
vie de l’utilisateur dans le sens qu'elle lui ferait gagner en temps et lui permettrait d’augmenter
ainsi sa productivité :

 L’utilisation des cartes RFID, permettrait de sécuriser le distributeur ainsi que les
données des utilisateurs tout en garantissant la rapidité de traitements des données.
 Le recours à la plateforme Arduino nous permettrait d’optimiser notre système compte
tenu des fonctionnalités matérielles et logicielles qu’elle offre.

3. Objectif
Le présent travail se fixe comme objectif de répondre à la fois à un besoin de performance et
de rapidité (boissons prêtes à la consommation) ainsi qu’à un besoin de confort et de qualité
(choix de la boisson). Au regard des progrès réalisés dans le domaine des systèmes automatisés,
notre étude a pour but d’apporter, par notre conception et modélisation, une opinion optimiste
-3-

des systèmes automatiques de distribution de boissons, débouchant ainsi sur une


implémentation, qui bien sûr tirera le meilleur des certaines plateformes existantes.

4. Choix et intérêt du sujet


Porter le choix sur un sujet d’innovation est un exercice un peu difficile. En effet, le choix de
ce sujet a été motivé par l’orientation de notre formation et par plusieurs faits qui sont
d’actualité dans le domaine de la NTIC. Ce travail nous permettra non seulement d’accroître
nos connaissances dans ce domaine mais mieux encore de nous familiariser avec
l’environnement pratique des systèmes embarqués, du développement des systèmes temps-réel
en apportant une contribution modeste pour améliorer le confort de l’homme qui lui permettra
de gagner en temps et en qualité de service.

5. Méthodologie et technique de recherche


Tout travail scientifique nécessite l’usage de certaines méthodes et techniques pour aboutir à
des résultats probants et ainsi vérifier les hypothèses fixées. Dans le cadre de notre étude nous
avons fait recours à des méthodes et techniques suivantes :

Méthodes

 Méthode analytique : pour une analyse systématique de données et informations en


notre disposition.
 Méthode descriptive : pour l’appréhension, dans son ensemble et dans ses aspects
particuliers, de notre sujet d’étude.
 Méthode SA-RT et DARTS : ce sont des méthodes d’analyse fonctionnelle et
opérationnelle des applications de contrôle-commande. Le langage UML complètera
la conception et la modélisation

Techniques

 Technique documentaire : qui consiste en une fouille systématique de tout ce qui est
écrit ayant une liaison avec notre domaine de recherche.
 Technique d’observation : afin d’acquérir, par nos propres sens, des informations
pertinentes sur la façon dont notre sujet d’étude est perçu dans le milieu dans lequel
nous évoluons.
 Technique expérimentale : pour appliquer et tester, sur une maquette, les résultats de
notre conception.
-4-

6. Délimitation du sujet
De par l’énoncé même du sujet, il nous est paru difficile, dans le cadre d’un travail de mémoire
et surtout dans les délais impartis, de traiter de tous les aspects de l’automatique. La présente
recherche ayant pour centre d'intérêt la mise en place d'un système de distribution automatique
de boissons, nous marquons nos frontières dans le contexte de la ville de Goma. La mise en
œuvre du présent travail couvre la période allant du mois de Mars 2018 au mois d’Octobre
2018. Notre but n'est pas de développer une application comparable aux systèmes de
distribution de boissons complexes existants mais avant tout de réaliser le prototype du système
pour en tirer le meilleur profit.

7. Subdivision du travail
Hormis l’introduction générale et la conclusion générale, notre travail comprend 3 principaux
chapitres organisés de la manière suivante :

 Chapitre I : Notions théoriques de base. Ce chapitre présente, de manière générale, la


théorie sur les systèmes automatisés et la plateforme Arduino.
 Chapitre II : Conception et modélisation du système de distribution de boisson. Ce
chapitre traite de la conception du dit système en se basant sur un cahier de charge,
conduisant à une modélisation appropriée.
 Chapitre III : Implémentation et réalisation du système. Ce chapitre concerne la
présentation des matériels utilisés aboutissant ainsi au montage du prototype.
-5-

CHAP I : NOTIONS THEORIQUES DE BASE


I.1. Introduction
Simples ou complexes, les systèmes automatisés sont partout dans notre environnement
quotidien. Ils se développent de plus en plus et prennent une place importante dans la manière
de travailler tant dans les ateliers de production que dans les bureaux des entreprises. Connaître
leur fonctionnement, permet de comprendre l’évolution de notre environnement.

Dans le présent chapitre, nous présentons brièvement les notions sur les automatismes, et en
particulier les distributeurs automatiques ainsi que d’autres concepts qui leur sont directement
associés.

I.2. Automatismes
Techniquement, un automatisme est un sous-ensemble ou un organe de machines destiné à
remplacer de façon automatisée une action ou une décision habituelle et prédéfinie, en général
simple et répétitive, où l'être humain intervient.
L'automatique est la discipline qui étudie mathématiquement et techniquement les méthodes de
conception ou d'utilisation des automatismes. [2]

I.2.1. Objectifs de l’automatisation

L’automatisation permet d’apporter des éléments supplémentaires aux systèmes de production.


Ces éléments sont exprimables en termes objectifs par: [3]

 Accroître la productivité du système c’est-à-dire augmenter la quantité des produits


élaborés pendant une durée donnée. Cet accroissement de productivité exprime un gain
de valeur ajoutée sous forme :
- D’une meilleure rentabilité,
- D’une meilleure compétitivité, ...
 Améliorer la flexibilité de production
 Améliorer la qualité du produit
 S’adapter à des contextes particuliers :
- Adaptation à des environnements hostiles pour l’homme (milieu marin,
spatial, nucléaire, ...)
- Adaptation à certaines tâches physiques ou intellectuelles pénibles pour
l’homme.
-6-

 Augmenter la sécurité, etc.

I.2.2. Structure d’un système automatisé

Figure I.1: Structure d’un système automatisé [4]


Tout système automatisé comporte : [3]

- Une Partie Commande (P.C.) : c’est le cerveau du système qui pilote les actionneurs de la
partie opérative, et qui reçoit des informations venant des capteurs et de l’opérateur (consignes).

- Une Partie Opérative (P.O.) : c’est la partie du système qui exécute les ordres venant de la
partie commande grâce aux actionneurs. Elle recueille aussi des informations sur les états du
système grâce aux capteurs.

Définitions

 Un capteur : est un élément de la partie opérative capable de détecter et de réagir (avec


ou sans contact) à un phénomène physique dans son environnement (lumière, chaleur,
présence ou déplacement d’un objet) et d’envoyer le signal sous forme électrique à la
-7-

partie commande. Par exemple, les photorésistances, les détecteurs de présence, les
capteurs de température, ...
 Un actionneur : est un organe de la partie opérative capable de traduire le signal
électrique reçu de la partie commande en une action physique (mouvement, chaleur,
son, lumière etc.). Par exemple le servomoteur, le radiateur, une ampoule, …

Entre la partie commande et l’homme (l’opérateur) se trouve la partie dialogue qui permet à ce
dernier de transmettre des informations au moyen des dispositifs adaptés (boutons poussoirs,
commutateurs, etc.). Il s’établit un dialogue d’exploitation.

Entre la partie commande et la partie opérative s’établit un dialogue de fonctionnement.

a. Analyse de la partie commande :

La partie commande se compose de quatre ensembles :

 Les interfaces d’entrée qui transforment les informations issues des capteurs placés sur
la partie opérative ou dans la partie dialogue en informations de nature et d’amplitude
compatible avec les caractéristiques technologiques du système.
 Les interfaces de sortie qui transforment les informations élaborées par l’unité de
traitement en informations de nature et d’amplitude compatibles avec les
caractéristiques technologiques des préactionneurs d’une part, des visualisations et des
avertisseurs d’autre part.
 Les préactionneurs qui sont directement dépendants des actionneurs, sont nécessaires à
leur fonctionnement.
 L’unité de traitement qui élabore les ordres destinés aux actionneurs en fonction des
informations reçues des différents capteurs et du fonctionnement à réaliser.
b. Analyse de la partie opérative :

La partie opérative se compose de trois ensembles :

 L’unité de production dont la fonction est de réaliser la fabrication ou la transformation


pour laquelle elle remplit un rôle dans le processus industriel.
 Les actionneurs qui apportent à l’unité de production l’énergie nécessaire à son
fonctionnement à partir d’une source d’énergie extérieure (cas d’un moteur par
exemple). Ces actionneurs peuvent aussi prélever de l’énergie sur l’unité de production
pour la retourner vers un récepteur d’énergie extérieur (cas d’un frein, par exemple).
-8-

 Les capteurs qui créent, à partir d’informations de natures divers (déplacement,


température…etc.), des informations utilisables par la partie commande (ouverture ou
fermeture d’un circuit électrique, par exemple).
c. Analyse de la partie dialogue :

La partie dialogue se compose de deux ensembles :

 Les visualisations et avertisseurs qui transforment les informations fournies par


l’automate en informations perceptibles et compréhensifs par l’homme (informations
optiques ou sonores).
 Les capteurs qui transforment les informations fournies par l’homme (action manuelle
sur un bouton poussoir, par exemple) en informations exploitables par le système.

I.2.3. Conduite et surveillance d’un système automatisé


Il s’avère très difficile en pratique d’intégrer dans une partie commande la totalité des savoir-
faire humains de sorte que l’automatisation reste souvent partielle : certaines tâches restent
confiées à des intervenants humains.

Certaines tâches restent donc manuelles et l’automatisation devra ainsi prendre en compte la
spécificité du travail humain, c'est-à-dire en particulier :

 Assurer le dialogue entre les intervenants et le système automatisé


 Assurer la sécurité de ces intervenants dans l'exécution de leurs tâches manuelles [3]

I.2.4. Exemples d’automatismes


- Distributeur automatique de boissons
- Distributeur automatique de billets
- Système de contrôle routier (feux de carrefour)
- Barriere de parking
- Ascenseurs
- Les robots
- Etc.

I.2.5. Représentation des automatismes


Le GRAFCET est un modèle de représentation graphique des comportements dynamiques de la
partie commande. Il permet de visualiser de façon particulièrement claire toutes les évolutions
du système. [5]
-9-

Le GRAFCET est un langage créé en 1977 et signifie : Graphe Fonctionnel de Commande


Etape/Transition. Il permet de programmer “visuellement” le déroulement du système à piloter.

Il est fondé sur les notions d’étapes, de transitions et de réceptivités qui simplifient la synthèse
d’un automatisme en tenant compte du fait que, parmi le grand nombre d’informations présentes
à un instant donné, peu sont significatives.

Le GRAFCET décrit les interactions entre la partie commande et la partie opérative à partir de
la frontière d’isolement. Il établit une relation entre :

- Les entrées, correspondant aux transferts d’informations de la partie opérative vers la


partie commande.
- Les sorties, correspondant aux ordres transmis de la partie commande vers la partie
opérative.

Le GRAFCET est défini par [3] :

 Un ensemble d’éléments graphiques de base :


- Les étapes : qui caractérisent un comportement invariant d’une partie ou de la
totalité de la partie commande à un instant donné, suivant l’évolution du système.
Une étape est soit active, soit inactive.
- Les transitions : indiquent la possibilité d’évolution entre étapes. Chaque transition
représente une, et une seule possibilité d’évolution. Une transition est dite validée
lorsque toutes les étapes immédiatement précédentes reliées à cette transition sont
actives.
- Les liaisons orientées reliant les étapes aux transitions et les transitions aux étapes.
Elles indiquent les voies d’évolution du GRAFCET.
 Une interprétation, traduisant le comportement de la partie commande vis-à-vis de ses
entrées et de ses sorties, caractérisée par :
- Les actions associées aux étapes, qui traduisent « ce qui doit être fait » chaque fois
que cette étape est active.
- Les réceptivités associées aux transitions, qui regroupent, parmi toutes les
informations disponibles, uniquement celles qui sont susceptibles, à un instant
donné, de faire évoluer la situation (ensembles des étapes actives) de la partie
commande.
 Des règles d’évolution définissant formellement le comportement dynamique de la
partie commande ainsi décrite.
- 10 -

Figure I.2: Structure d’un GRAFCET

I.3. Distributeur automatique


Un distributeur automatique ou machine distributrice, est une machine qui permet d’obtenir des
biens sans intervention humaine, en libre-service, grâce aux techniques d’automatique. Les
machines les plus courantes sont les distributeurs de boissons fraiches. Un grand nombre de
biens et services marchands sont accessibles grâce à ce mode de distribution : boissons chaudes
ou froides, aliments (confiserie, fruits, sandwichs, etc.), des billets pour le train, des jouets, …
[6]

Les banques ont aussi développé des automates permettant de retirer de l’argent avec une carte
bancaire, c’est le distributeur automatique des billets.

Le marché de la distribution automatique est très vaste et varié, qu’il s’agisse d’une simple
fontaine à eau, d’un distributeur de boisson froides ou chaudes, le choix est tellement grands
- 11 -

qu’il peut répondre à plusieurs besoins. C’est pourquoi ces types de distributeur sont adaptés à
beaucoup d’endroits : les lieux publics comme les gares, les aéroports, les écoles, les hôpitaux,
les centres commerciaux, les halls sportifs, … et les entreprises privées ou publics, quel que
soit le secteur d’activité et la taille.

Figure I. 3: Image d'un distributeur automatique de café

I.3.1. Historique
On raconte que le premier distributeur automatique remonterait à 215 avant Jésus-Christ et
aurait été inventé par un mathématicien grec, Heron, pour vendre de l’eau dans les temples,
fonctionnant à l’aide d’une pièce de quatre drachmes… [7]

Les égyptiens auraient inventé un distributeur automatique pour vendre des balles de coton
imbibées de vin… Dès le début du XVIIème siècle, avec la généralisation de l’usage du tabac,
les Anglais fabriquèrent des machines en distribuant dans les auberges et les tavernes, une dose
de tabac à fumer et à priser, pour un demi-penny. Ensuite, nombreuses ont été les personnes à
souhaiter commercialiser leurs produits sous la forme de la distribution automatique. Ce fut le
- 12 -

cas vers 1820, du libraire Richard Carlile, qui inventa un distributeur automatique de livres afin
de vendre des ouvrages subversifs ; de Siméon Denham, pour distribuer des timbres contre une
pièce d’un penny. Puis, ce fut l’Allemand Carl Ade qui inventa des machines à vendre des
mouchoirs, des cigarettes et des confiseries.

En 1887, en Angleterre, fut lancée la « Sweet Meat Automatic Delivery by », première société
de gestion de distributeurs automatiques de confiserie. L’année suivante, des distributeurs de
chocolats à croquer et de confiseries se développèrent en France dans toutes les gares. C’est en
1891, que l’on vit des bars automatiques fleurirent en France, pour la vente de vin de Malaga,
de bière et durant l’Exposition Universelle, des distributeurs automatiques de boissons chaudes
et fraîches furent présentés. [8]

Le développement de l’industrie de la distribution automatique a vraiment commencé au XXème


siècle. C’est en 1906, aux U.S.A., que l’on trouve le premier distributeur automatique de
boissons gazéifiées à dix sélections, sans gobelet. Puis, la Public Cup Vendor Cie construisit
deux ans plus tard le premier distributeur automatique utilisant des gobelets en papier. Le tabac
et la cigarette en D.A. se développèrent à partir de 1925 avec les distributeurs automatiques de
National à Saint-Louis, de William Rowe à Los Angeles et de Smoketeria à Detroit. En 1926
aux USA, apparurent les premiers « counter dispensers » modernes de boissons gazéifiées ou
non.

La distribution automatique a connu un formidable développement jusqu’à la fin des années


2000, puis a enregistré un sensible tassement de son activité au cours de la dernière décennie.
Aujourd’hui, elle reprend un nouvel essor en s’appuyant sur les notions du « bien manger » et
la préoccupation de plus en plus forte du développement durable.

En parallèle, on a assisté à une professionnalisation de la gestion des appareils de distribution


automatique qui est assurée en 2013 à 80% par des gestionnaires spécialisés, assurant la
maintenance, l’entretien et l’approvisionnement des appareils.

I.3.2. Techniques d’automatisation


Ces machines font appel à un grand nombre des techniques d’automatisation :

 Les monnayeurs : qui permettent la détection et l’identification des pièces de monnaies


ou des billets de banques
 Les lecteurs de carte, de clés cashless, des puces sans contact (RFID)
- 13 -

 La mise à disposition des produits avec des mécanismes en spire ou avec des pompes.
Elle est aujourd'hui également renforcée par des solutions d'ascenseur qui viennent
collecter le produit libéré par les spires et le restituer en douceur au consommateur.

I.3.3. Types de distributeurs de boissons


Le marché des distributeurs automatiques s’est beaucoup développé afin d’élargir les gammes
des modèles et l’offre de produit. Le but étant avant tout de répondre à la demande des
consommateurs et de satisfaire un maximum de besoins. Les principaux distributeurs
automatiques de boissons sont les suivant [9] :

a. Distributeur de boissons froides

Il offre une très large variété de boissons fraiches, selon le modèle et le ravitaillement : l’eau
minérale, des jus de fruits, des boissons énergisantes… Les boissons sont sous forme de
canettes, de bouteilles en plastiques. Ce distributeur nécessite une prise électrique pour la
réfrigération et de l’espace pour permettre un ravitaillement.

b. Distributeur de boissons chaudes

Il met jusqu’à 4 types de boissons chaudes à disposition des consommateurs : le café, le thé, le
chocolat chaud, la soupe … qui peuvent être déclinés en grande variété (café au lait, café noir,
la soupe à la tomate …). Ce distributeur nécessite une prise électrique et une arrivée d’eau.

c. Fontaine à eau

Il existe deux types de fontaines à eau : la fontaine en bonbonnes et la fontaine sur réseau. Elles
peuvent fournir de l’eau fraiche, de l’eau tempérée, et pour certains modèles, de l’eau pétillante.

La fontaine à eau doit être raccordée à une prise électrique pour la réfrigération. Seules les
fontaines sur réseau nécessitent une arrivée d’eau.

d. Distributeur automatiques mixte

Il s’agit de la combinaison d’un distributeur de boissons fraiches et de boissons chaudes ou de


boissons et de snacks. Ils sont simplement constitués de deux appareils juxtaposés.

I.3.4. Système de paiement


Lorsqu’on souhaite installer un distributeur de boissons, on peut choisir de les délivrer
gratuitement ou en contrepartie d’un paiement. Cependant le système de paiement peut être de
deux formes [9] :
- 14 -

a. Monnayeur

C’est le système le plus courant dans les lieux publics. Il consiste à accepter les pièces de
monnaies et parfois les billets. Ces pièces sont introduites par l’utilisateur dans un interstice
prévu à cet effet. Dès que les pièces sont acceptées par la machine, l’utilisateur reçoit le produit
souhaité.

Il existe 2 types de monnayeur : le monnayeur qui rend la monnaie et le monnayeur qui ne rend
pas la monnaie.

b. Système par cartes prépayées

C’est le système de paiement qui consiste à créditer une somme d’argent sur une carte ou une
clé. Lorsqu’un utilisateur utilise le distributeur, le montant du produit choisi est débité de la
somme contenue sur sa carte.

Il existe différents types de systèmes prépayés : les cartes magnétiques ou à puce, les clés
prépayées, les systèmes électroniques par codes numériques, … Grace aux cartes prépayées,
les utilisateurs n’ont plus besoin d’avoir constamment de la monnaie sur eux.

I.3.5. Durée de vie et Sécurité


De nombreux facteurs influencent la durée de vie d’une machine à boissons. Cependant, les
tests réalisés sur ces appareils ont permis de l’estimer entre 7 et 13 ans. Plusieurs éléments
peuvent réduire ou allonger la durée de vie : la marque, le modèle, le lieu d’installation, … [9]

La sécurité d’un distributeur de boissons est très importante. En effet, tout comme les autres
produits de consommation, ces distributeurs ne sont pas à l’abri des tentatives de vol ou de
dégradation. Même si les lieux publics présentent des risques beaucoup plus élevés, les
distributeurs de boissons au sein des entreprises ne sont pas épargnés. Tout d’abord, ils sont
généralement massifs et peuvent atteindre plus de 400kg, de cette manière, il est quasiment
impossible pour les utilisateurs de l’emporter. Ensuite, les parois du distributeur sont renforcées
pour limiter les dégradations en les composant d’une cage qui sert de barrière de protection, de
cette manière, les vandales ne peuvent atteindre les zones plus fragile de l’appareil (monnayeur,
vitre, …).
- 15 -

I.4. Arduino
La plateforme « Arduino » est l’œuvre d’une équipe de développeurs italiens passionnés
d’électronique et d’informatique qui ont eu l’ingénieuse idée d’allier, sur une carte électronique,
les performances de la programmation à celle de l’électronique. [10]

Il existe dans le commerce, une multitude de plateformes qui permettent de faire la même chose,
notamment les microcontrôleurs « PIC » du fabricant Microchip mais Arduino a su tirer son
épingle du jeu grâce à sa politique basée sur :

 La liberté : logiciel gratuit et Open source, les schémas du matériel circulent librement
sur Internet.
 Le prix : en vue des performances qu’elles offrent, les cartes Arduino sont relativement
peu couteuses.
 La compatibilité : le logiciel et les matériels sont compatibles avec différentes
plateformes comme Windows, Linux, Mac.
 La communauté Arduino est impressionnante et le nombre de ressources à son sujet est
en constante évolution sur internet. De plus, on trouve les références du langage
Arduino ainsi qu’une page complète de tutoriels sur le site www.arduino.cc

Le système Arduino donne la possibilité d'allier les performances de la programmation à celles


de l'électronique. Le gros avantage de l'électronique programmée est qu'elle simplifie
grandement les schémas électroniques et par conséquent, le coût de la réalisation, mais aussi la
charge de travail à la conception d'une carte électronique.

I.4.1. Historique
Arduino est un projet créé en 2005 par une équipe de développeurs, composée de 6 individus :
Massimo Banzi, David Cuartielles, Tom Igoe, Gianluca Martino, David Melis et Nicholas
Zambetti, en Italie. Cette équipe a créé le " système Arduino", qui est un outil qui va permettre
aux débutants, amateurs ou professionnels de créer des systèmes électroniques plus ou moins
complexes. Le projet a débuté avec 3000 euros pour la production de 200 cartes dont seulement
50 furent achetées par l’IDII mais très vite, la petite carte est devenue le couteau suisse de
nombreux artistes, passionnés, étudiants et tous ceux qui rêvaient d’un tel gadget. [11]

Le succès d’Arduino fut tel que partant des 200 premières cartes vendues en 2005, 30000 cartes
ont été fabriquées partout sur la planète en 2007 et plus de 220000 en 2010. Massimo BANZI
indique, dans une interview accordée au magazine SHY ROBOTICS en 2015, que plus de 1,5
- 16 -

millions de cartes officielles, sans comptés ses copies chinoises, ont déjà été vendu. Il souligne
aussi que ce succès ira crescendo vu que Arduino est en train de s’implanter plus solidement
dans les milieux scolaires et éducatifs.

A ce jour, 17 versions des cartes Arduino fabriquées par les sociétés Smart Projects et SparkFun
Electronics s’écoulent comme de petits pains sur le marché. Notons aussi la présence de
nombreux articles (capteurs, shield, etc.) qui sont directement rattachés aux cartes Arduino.

I.4.2. Matériel Arduino


Le matériel Arduino est essentiellement composé d’une carte électronique façonnée autour du
microcontrôleur ATmega AVR (ATmega328, ATmega324 ou ATmega2560 pour les versions
récentes, ATmega168, ATmega1280 ou ATmega8 pour les plus anciennes) et d’un ensemble
de composants complémentaires qui permettent l’interaction avec le monde extérieur.

a. Brève description d’une carte Arduino

Présentons brièvement les grandes parties d’une des cartes Arduino. [10]

Figure I.4: Présentation de la carte Arduino UNO

 Le microcontrôleur (en 1) : C’est le cerveau de la carte. Il reçoit le programme créé et


le stocke dans sa mémoire puis l’exécute.
 L’alimentation : Pour fonctionner, la carte a besoin d’une alimentation. Le
microcontrôleur fonctionnant sous 5V, la carte peut être alimentée en 5V par le port
USB (en 2) ou bien par une alimentation externe (en 3) qui est comprise entre 7V et
12V. Cette tension doit être continue et peut par exemple être fournie par une pile 9V.
- 17 -

 La visualisation (en 4) : sont en fait des LED qui servent à tester le matériel (quand on
branche la carte au PC, elle clignote quelques secondes) et à visualiser l’activité sur la
voie série (une pour l’émission et l’autre pour la réception). Le téléchargement du
programme dans le microcontrôleur se faisant par cette voie, on peut les voir clignoter
lors du chargement.
 La connectique (en 5a et 5b) : Pour connecter à la carte des composants qui peuvent
être utilisés par un programme. Par exemple, une LED, un servomoteur, des capteurs,
des Shields, etc.

Figure I.5: Une carte Arduino étendue avec un Ethernet Shield


b. Types de carte
Il y a trois types de cartes :

- Les dites « officielles » qui sont fabriquées en Italie par le fabricant officiel : Smart
Projects.
- Les dites « compatibles » qui ne sont pas fabriqués par Smart Projects, mais qui sont
totalement compatibles avec les Arduino officielles.
- Les « autres » fabriquées par diverses entreprises et commercialisées sous un nom
différent (Freeduino, Seeduino, Femtoduino, ...)
c. Shields

Les Shield Arduino sont d’autres cartes que l’on branche sans soudure aux cartes Arduino ou à
d'autres Shield Arduino pour augmenter leur capacité ou pour rajouter d’autres fonctionnalités.
Les Shields Arduino conservent ainsi l’esprit original de Arduino, qui est de demeurer facile à
produire et à utiliser. Les Shields Arduino sont très nombreux et diversifiés. Dans la liste nous
- 18 -

retrouvons des Shields GPS, des Shields écran dont l’un est présentés sur la figure I.5, des
Shields GPRS/GSM, des Shields caméra, etc.

Figure I.6: Shield écran LCD Arduino(Source : www.generationrobots.com)

I.4.3. Capteurs et actionneurs


1. Les capteurs
Comme on l’a défini plus haut, les capteurs sont des éléments qui indiquent l’état d’une
information. Il existe plusieurs classifications des capteurs Arduino mais la plus simple, les
classes en deux catégories [12] :

a. Les capteurs logiques ou TOR


Ces capteurs fournissent des informations sous deux états (HIGH ou LOW) selon que se
présente le phénomène observé. Ils sont lus sur les ports numériques de l’Arduino et leurs
résultats sont souvent stockés dans des variables de type booléen. Citons parmi eux : les
capteurs de contact, le tilt switch, récepteur infrarouge, le bouton poussoir, etc.

Figure I.7: Bouton poussoir


- 19 -

b. Les capteurs de variation


Ils font varier la tension de sortie soit en résistant, soit en produisant un courant. Ces capteurs
seront donc lus avec les ports analogiques de l'Arduino. On transforme alors la valeur de la
tension récupérée (souvent entre 0V et 5V) en un nombre entier entre 0 et 1024. Citons les
photorésistances, capteurs à ultrasons, capteur de température, etc.

Figure I.8: Photorésistance


2. Les actionneurs

Si Arduino était un corps, les actionneurs seraient ses mains. En effet, ce sont eux qui sont
chargés d’agir sur l’environnement en exécutant les actions tel que prescrites par la carte. Citons
à titre d’exemple : les LED, les afficheurs, les servomoteurs, électropompes, etc.

Figure I.9: Servomoteur Arduino

I.4.4. Langage Arduino


Le langage Arduino, est un langage de programmation, fortement inspiré du C et du C++. Avec
une syntaxe relativement aisée, ce langage permet d’écrire des instructions qui seront converties
en langage machine par un compilateur et exécutées de façon séquentielle, une instruction après
l’autre. [12]

a. Structure d’un programme


Un programme Arduino comporte trois parties :

 Une partie réservée à la déclaration des variables. Elle est optionnelle.


- 20 -

 Une autre destinée à l’initialisation et à la configuration des entrées/sorties. Encapsulée


dans la méthode setup ().
 Enfin, celle qui est sensée s’exécuter en boucle. Elle est considérée comme la partie
principale du programme car c’est bien elle qui, dans sa méthode loop (), englobera
toutes les instructions qui devront s’exécuter.

La syntaxe d'un langage de programmation est l'ensemble des règles d'écritures liées à ce
langage. Celle du langage Arduino repose sur trois piliers que sont :

 La structure : Nous retrouvons dans cette rubrique les deux méthodes citées
précédemment (setup et loop), les structures de contrôle, les opérateurs arithmétiques,
booléens, bit à bit, d’accès pointeurs, de comparaison et des opérateurs composés.
 Les variables et les constantes : Nous avons ici les constantes, les types de données, la
conversion, la portée des variables et d’autres utilitaires.
 Les fonctions : nombreuses et variées entre autres citons Digital I/O, Analog I/O, Time,
math, trigonométrie, etc.
b. Logiciel Arduino

Le logiciel Arduino est un environnement de développement intégré écrit en Java, libre et


multiplateforme. Il permet d’écrire le code, de le compiler ensuite d’envoyer le sketch sur le
matériel au travers une connexion série.

Figure I.10: Fenêtre du logiciel Arduino


- 21 -

I.5. Conclusion partielle


Dans ce chapitre, nous avons présenté les automatismes, leur structure, et la place qu’ils
occupent actuellement dans notre environnement. Nous nous sommes attelés de façon
particulière aux distributeurs automatiques de boisson. Nous avons fait un bref aperçu sur l’outil
Arduino, la plateforme que nous utiliserons pour la réalisation de notre système.
- 22 -

CHAP II : CONCEPTION ET MODELISATION


DU SYSTEME DE DISTRIBUTION DE BOISSON
II.1. Introduction
Le développement des applications informatiques demande de plus en plus de rigueur dans le
suivi des différentes étapes de spécification, de conception et de codage. Ce cycle de
développement permet ainsi d’obtenir des applications de bonne qualité d’un point de vue
architecture logicielle, d’augmenter la maintenabilité et l’évolutivité. C’est ainsi que dans ce
chapitre nous procédons d’une part à la modélisation du système en utilisant les méthodes
SART et DARTS et d’autre part à la modélisation de la base de données en utilisant le langage
UML.

II.2. Cycle de développement des applications informatiques


Le cycle de développement des applications informatiques suit trois étapes classiques que sont :
la spécification, la conception et la programmation. L’analyse des besoins permet d’écrire le
cahier des charges de l’application, à partir duquel, se déroulent successivement les étapes qui
conduisent aux descriptions suivantes, de l’application [13] :

– Spécification globale : description de « ce que l’on a à faire » ou le « quoi », c’est-à-dire une


mise en forme plus ou moins formelle du « cahier des charges » ;

– Conceptions préliminaire et détaillée : description du « comment », c’est-à-dire une


modélisation de l’architecture logicielle de l’application (modules, tâches, objets…). Il peut
être nécessaire d’employer différents niveaux de raffinement selon la taille de l’application ;

– Programmation : traduction dans un langage exécutable de l’architecture logicielle de


l’application.

Ces étapes peuvent être plus ou moins formelles selon les méthodes employées. A chaque étape,
il est primordial de vérifier la cohérence de la description ou de la traduction réalisée à partir
de l’étape précédente, cela concerne la validation.

Ces différentes étapes sont aussi utilisées dans le cycle de développement des applications de
contrôle-commande. Il existe de nombreuses méthodes appliquées au développement logiciel
des applications de contrôle-commande de procédé qui couvrent une ou plusieurs étapes du
cycle de développement selon les niveaux de raffinement où elles sont utilisées.
- 23 -

Figure II.1: Cycle de développement d’une application informatique

II.3. Analyse des besoins


Notre système est élaboré pour pallier certains problèmes auxquels la plupart des travailleurs,
des étudiants ou d’autres clients font souvent face lors de l’achat de leur boisson ou d’autres
produits dans les cafétérias ou les boutiques. Nous pouvons citer :

 La lenteur dans le service qui peut être dû à un nombre insuffisant du personnel


 Le temps que peut faire le client dans la cafétéria avant d’être servi parce qu’il y a
beaucoup de monde
 L’indisponibilité du vendeur
 La sécurité du client et du vendeur
 Etc.

Cahier des charges


Le système à réaliser est appelé « FastSoda » ; il doit être capable de prendre en charge et de
contrôler les commandes faites par l’utilisateur. Il permettra donc :

- A l’utilisateur, de s’abonner au distributeur et de recevoir une carte sur laquelle sont


enregistrées les informations (montant, mot de passe, …) nécessaires pour l’usage.
- De lire et de traiter les informations enregistrées sur la carte présentée par l’utilisateur
- A l’utilisateur, d’écrire le mot de passe et de choisir une boisson à partir d’un clavier
- De servir la boisson choisie par l’utilisateur, de façon automatique
- 24 -

Le système sera constitué d’un kit électronique, en interaction avec une base de données
contenant les informations sur les clients, qui est composé :

- D’un lecteur RFID, qui permet de lire la carte présentée par le client afin de lui accorder
ou non l’accès aux options du distributeur
- D’un clavier, qui permet au client de saisir le mot de passe et de choisir la boisson
- Des LEDs, pour les effets lumineux : une led verte pour indiquer une bonne action du
client et une led rouge pour indiquer une mauvaise action ou une alerte
- D’un buzzer, pour un effet sonore
- D’un écran LCD, pour afficher les options au client
- D’un capteur ultrason, pour détecter la présence d’un verre
- D’un capteur de niveau d’eau, pour indiquer le niveau de la boisson dans le réservoir
- Des mini pompes et d’autres composants (les résistances, le potentiomètre, …)

II.4. Spécifications globales


Pour décrire de manière claire les spécifications de notre système, nous allons utiliser la
méthode SA-RT (Structured Analysis for Real Time systems).

SA-RT est une méthode d’analyse fonctionnelle et opérationnelle des applications de contrôle-
commande. Cette méthode permet de réaliser une description graphique et textuelle de
l’application en termes de besoins, c’est-à-dire de « ce que l’on a à faire » ou le « quoi ». En
revanche, elle ne permet pas d’effectuer une vérification de propriétés de l’application à partir
des seules descriptions SA-RT. [13]

II.4.1 Syntaxe de la méthode SA-RT


La méthode SA-RT intègre trois aspects fondamentaux d’une méthode de spécification en
mettant l’accent sur les deux premiers qui sont des points essentiels dans les applications de
contrôle-commande :

 Aspect fonctionnel (ou transformation de données) : c’est la représentation de la


transformation que le système opère sur les données et spécification des processus qui
transforment les données. On y trouve les éléments graphiques suivants :
- Le Processus fonctionnel : représente une transformation des données. Un ou plusieurs
flux de données en entrée sont traités pour donner un ou plusieurs flux de données en
- 25 -

sortie. Le Processus est représenté par un cercle avec une étiquette ou label explicite
formé de :

Étiquette_Processus = verbe (+ un ou plusieurs compléments d’objets) + numéro

- Le Stockage de Données : modélise le besoin de mémorisation d’une donnée de telle


façon que sa valeur puisse être relue plusieurs fois. Le stockage de données est
représenté par deux traits horizontaux encadrant l’étiquette ou label explicite formé de :

Étiquette_Stockage_de_Données = nom (+ qualifiant)

- La Terminaison, encore appelée « bord de modèle » : représente une entité extérieure


échangeant des données avec le système modélisé. Une terminaison peut donc être une
entité logicielle (programme, base de données…) ou matérielle (capteurs, actionneurs,
console opérateur…). Représentée par un rectangle, elle est nommée par une étiquette
ou label explicite formé de :

Étiquette_Terminaison = nom (+ qualifiant)

 Aspect événementiel (piloté par les événements) : c’est la représentation des événements
qui conditionnent l’évolution d’un système et la spécification de la logique de contrôle qui
produit des actions et des événements en fonction d’événements en entrée et fait changer le
système d’état. On y trouve les éléments graphiques suivants :
- Le Processus de contrôle : représente la logique du pilotage des processus fonctionnels.
Il génère l’ensemble des événements qui vont activer ou désactiver les processus
fonctionnels. En retour, les processus fonctionnels fournissent au processus de contrôle
tous les événements nécessaires aux prises de décision. Le processus de contrôle ne peut
pas gérer les données. Le Processus de contrôle est représenté par un cercle en pointillé
avec une étiquette ou label explicite formé de :

Étiquette_Processus_Contrôle = verbe (+ un ou plusieurs compléments) + numéro

Les événements, fournis par le processus de contrôle, sont généralement liés à l’activation ou à
la désactivation des processus fonctionnels. Le Flot de Contrôle transporte les événements ou
informations qui conditionnent directement ou indirectement l’exécution des processus de
transformations de données. Ces événements spécifiques ont été formalisés et prédéfinis :

– E pour Enable(activation) ;

– D pour Disable(désactivation) ;
- 26 -

– T pour Trigger(déclenchement).

Les deux premiers événements sont utilisés ensemble « E/D » pour piloter un processus
fonctionnel de type « boucle sans fin » ou périodique, c’est-à-dire que le processus de contrôle
doit lancer l’exécution de ce processus avec l’événement « E » et ensuite peut l’arrêter avec
l’événement « D ». L’événement « T » est utilisé pour activer un processus fonctionnel de type
début-fin, c’est-à-dire que le processus de contrôle doit lancer l’exécution de ce processus avec
l’événement « T » et ensuite le processus s’arrête à la fin de son exécution sans intervention du
processus de contrôle.

 Aspect informationnel (données) : c’est la spécification des données sur les flots ou dans
les stockages.

II.4.2. Analyse SA-RT du système de distribution automatique de boisson


1. Diagramme de contexte
Le diagramme de contexte est une représentation qui permet de définir le contexte et
l’environnement extérieur du système piloté. Nous y trouvons un et un seul processus
fonctionnel, numéroté « 0 », qui traduit l’application à réaliser effectivement par le concepteur.
Autour de ce processus fonctionnel, un ensemble de bords de modèles qui fournit ou consomme
les données ou événements de cette application.

Le diagramme de contexte de notre système est représenté sur la figure II.2, il intègre sept
bords de modèle correspondant aux quatre entrées : lecteur RFID, clavier, capteur à ultrasons,
capteur de niveau d’eau et aux trois sorties : écran, mini pompe, module d’alerte. Le diagramme
de contexte est enrichi d’un flot de contrôle qui émane d’un nouveau bord de modèle « Prise
électrique » qui fournit un flot de contrôle « Mise_en_marche » au processus fonctionnel 0. Le
processus fonctionnel initial 0 « Distribuer boisson » constitue l’application à réaliser. En plus
de l’événement « Mise_en_marche », nous avons sept flots de données : quatre entrants
(Carte_lue, Donnee_saisie, Mesure_distance, Niveau_eau) et trois sortants (Affichage,
Action_pompe, Alerte). L’ensemble de ces flots doit se retrouver dans le diagramme
préliminaire qui est le premier niveau d’analyse du processus fonctionnel 0.
- 27 -

Figure II.2: Diagramme de contexte du système

2. Diagramme préliminaire
Le diagramme préliminaire est la première décomposition du processus fonctionnel 0 à réaliser,
présenté dans le diagramme de contexte. À ce niveau, le diagramme représente la liste
graphique des processus fonctionnels nécessaires à l’application sans tenir compte de
l’enchaînement (séquence d’exécution).

Le diagramme préliminaire, présenté sur la figure II.3, donne une analyse ou décomposition
fonctionnelle du processus fonctionnel initial 0 « Distribuer boisson ». Cette analyse fait
apparaître huit processus fonctionnels de base : Acquérir données carte, Analyser données
carte, Acquérir données clavier, Acquérir état capteur à ultrasons, Acquérir niveau eau,
Commander pompe, Alerter état système, Afficher état système, et un processus de contrôle
« Contrôler distributeur » permettant de séquencer l’ensemble. Nous pouvons vérifier la
- 28 -

cohérence des flots de données ou d’événements entrants ou sortants par rapport au diagramme
de contexte sur la figure II.2.

Figure II.3: Diagramme préliminaire du système


Les processus 1 (Acquérir données carte) et 2 (Analyser données carte) concernent le contrôle
des éléments (ID carte, identité de l’abonné, …) enregistrés sur la carte que l’utilisateur
présente. Il s’agit d’un processus d’acquisition des données lors de la lecture de la carte et d’un
processus d’analyse et de comparaison des données lues aux niveaux de consignes stockés dans
l’unité de stockage « Consignes_Donnees_carte ». Ces deux processus fonctionnels sont liés
par le transfert d’une donnée « Donnees_carte ».

Le processus 3 (Acquérir donnees clavier) concerne les données (mot de passe, choix de la
boisson, …) que l’utilisateur tape sur le clavier.
- 29 -

Le processus 4 (Acquérir état capteur à ultrasons) concerne la détection de la présence d’un


verre.

Le processus 5 (Acquérir niveau eau) concerne le contrôle du niveau de la boisson dans le


réservoir avec un processus d’acquisition et de comparaison aux niveaux de consignes stockés
dans l’unité de stockage « Consignes_niveau_eau ».

Le processus 6 (Commander pompe) concernent le contrôle de l’action des pompes qui est
déclenchée lorsque la présence d’un verre est détectée.

Le processus 7 (Alerter état système) concerne les alertes (effets sonores, lumineux, …) liées à
l’état du système.

Le processus 8 (Afficher état système) concerne l’interface qui permet l’interaction de


l’utilisateur avec le système.

Le processus 9 (Contrôler distributeur) est le processus de contrôle qui permet d’exprimer


l’exécution des processus fonctionnels et est lié à ceux-ci par les évènements (E/D, T). Certains
processus fonctionnels possèdent des retours d’exécution vers le processus de contrôle :
Donnees_lues, Donnees_correctes, Donnees_incorrectes, Fin_saisie, Verre_detecte,
Niveau_correct, Niveau_bas et arret_pompe.

3. Diagramme d’état-transition
La compréhension du diagramme de flots de données, tracé à un certain niveau d’analyse,
nécessite une description ou spécification du processus de contrôle. Cette spécification,
représentant l’aspect comportemental ou temps réel de l’application, peut être faite de diverses
manières : diagramme état-transition, table état transition, matrice état-transition ou
éventuellement un GRAFCET.
La représentation la plus courante est le diagramme état-transition, qui décrit le fonctionnement
du processus de contrôle et explique le comportement du système. Il est composé de quatre
éléments :
- État courant : correspondant à un fonctionnement précis du système, en particulier à
un état des processus fonctionnels (exécution ou non) ;
- Événement : occurrence d’un événement émanant d’un processus fonctionnel vers
le processus de contrôle qui va provoquer le franchissement de la transition et donc
faire changer l’état du système ;
- 30 -

- Action : occurrence d’un événement émanant du processus de contrôle vers un ou


plusieurs processus fonctionnels pour les activer (« E » ou « T ») ou les désactiver
(« D »). Ces actions caractérisent l’effet du franchissement de la transition. Les
actions du processus de contrôle sur les processus fonctionnels sont notées par :
< E ou D ou T > + numéro ou nom du processus fonctionnel
- État suivant : correspondant au fonctionnement après les actions faites par le
processus de contrôle en direction des processus fonctionnels.

Figure II.4: Représentation de base d’un diagramme d’état-transition


Le diagramme d’état-transition de notre système est présenté à la figure II.5. Hormis l’état au
repos où le système est hors tension (à l’arrêt), le diagramme comprend six états :
- Fonctionnement normal du distributeur : c’est-à-dire que le système est en marche et
en attente des évènements (lecture de la carte, …) pour effectuer sa tâche.
- Alerte du niveau de la boisson dans le réservoir : c’est-à-dire que le système donne
une alerte sur le niveau de la boisson, par un effet lumineux.
- Analyse des données de la carte : après la lecture de la carte présentée par l’utilisateur,
le système effectue une analyse et donne le résultat. Si les données lues sont correctes
le système passe à l’état suivant sinon il retourne à l’état initial.
- Saisie du code et choix de la boisson : lorsque la carte de l’utilisateur est acceptée, il
peut alors saisir son mot de passe et choisir la boisson.
- Vérification présence verre : la vérification de la présence d’un verre est faite pour
soumettre la distribution de la boisson
- Présence verre et pompe en marche : une fois le verre détecté, la pompe est mise en
marche pour servir la boisson
- Détection remplissage verre et facturation : lorsque le verre est rempli, la pompe
s’arrête automatiquement puis on procède à la facturation de la boisson et après le
système revient à son état de fonctionnement normal
- 31 -

Figure II.5: Diagramme d’état-transition du système

4. Spécification des processus fonctionnels primitifs


C’est une spécification textuelle des fonctions réalisées par les processus fonctionnels du
système. Une des méthodes de spécifications de processus fonctionnels, la plus usitée et
adaptée à ce domaine, est celle qui s’appuie sur une spécification procédurale. Celle-ci se
décline en 6 mots-clés [13]:

- « E/ données : Nom_flots_de_données… » : liste des flots de données en entrée du


processus fonctionnel ;
- 32 -

- « E/ événements : Nom_flots_d’événements… » : liste des flots d’événements en entrée


du processus fonctionnel, c’est-à-dire en général « E/D » ou « T », ou éventuellement
les événements produits directement par les bords de modèle ;
- « S/ données : Nom_flots_de_données… » : liste des flots de données en sortie du
processus fonctionnel ;
- « S/ événements : Nom_flots_d’événements… » : liste des flots d’événements en sortie
du processus fonctionnel ;
- « Nécessite : » : liste des contraintes sur les données en entrée du processus fonctionnel
- « Entraîne : » : description algorithmique du traitement à réaliser.
Description procédurale
 Processus fonctionnel 1 : Acquérir données carte
- E/données : Carte_lue
- E/évènements : E/D
- S/données : Donnees_carte
- S/évènements : Donnees_lues
- Nécessite : Carte_lue = 0
- Entraine :
Faire
Acquérir données carte
Si Carte_lue > 0
Alors Emettre Donnees_lues vers processus de contrôle 9 (Contrôler
distributeur)
Emettre Donnees_carte vers processus fonctionnel 2 (Analyser
données carte)
Fin Si
Fin Faire
 Processus fonctionnel 2 : Analyser données carte
- E/données : Donnees_carte, Consignes_donnees_carte
- E/évènements : T
- S/données : aucune
- S/évènements : Donnees_correctes, Donnees_incorrectes
- Nécessite : Donnees_carte = 0, Consignes_donnees_carte = 0
- 33 -

- Entraine :
Faire
Analyser données carte
Si Donnees_carte > 0 ET Consignes_donnees_carte > 0
Alors Emettre Donnees_correctes ou Donnees_incorretes vers
processus de contrôle 9 (Contrôler distributeur)

Fin Si

Fin Faire

 Processus fonctionnel 3 : Acquérir données clavier


- E/données : Donnee_saisie
- E/évènements : E/D
- S/données : aucune
- S/évènements : Fin_saisie
- Nécessite : Donnee_saisie = 0
- Entraine :
Faire
Acquérir données clavier
Si Donnee_saisie > 0
Alors Emettre Fin_saisie vers processus de contrôle 9 (Contrôler
distributeur)
Fin Si
Fin Faire
 Processus fonctionnel 4 : Acquérir état capteur à ultrasons
- E/données : Mesure_distance
- E/évènements : E/D
- S/données : aucune
- S/évènements : Verre_detecte
- Nécessite : Mesure_distance=0
- Entraine :
Faire
Acquérir état capteur à ultrasons
- 34 -

Si Mesure_distance >0
Alors Emettre Verre_detecte vers processus de contrôle 9 (Contrôler
distributeur)
Fin Si
Fin Faire
 Processus fonctionnel 5 : Acquérir niveau eau
- E/données : Niveau_eau, Consignes_niveau_eau
- E/évènements : E/D
- S/données : aucune
- S/évènements : Niveau_correct, Niveau_bas
- Nécessite : Niveau_eau = 0, Consignes_donnees_carte = 0
- Entraine :
Faire
Acquérir niveau eau
Si Niveau_eau > 0 ET Consignes_niveau_eau> 0
Alors Emettre Niveau_correct ou Niveau_bas vers processus de contrôle 9
(Contrôler distributeur)

Fin Si

Fin Faire

 Processus fonctionnel 6 : Commander pompe


- E/données : aucune
- E/évènements : T
- S/données : Action_pompe
- S/évènements : Arret_pompe
- Nécessite : aucune
- Entraine :
Faire
Commander pompe
Fin Si
 Processus fonctionnel 7 : Alerter état système
- E/données : aucune
- 35 -

- E/évènements : E/D
- S/données : Alerte
- S/évènements : aucun
- Nécessite : aucune
- Entraine :
Faire
Alerter état système
Fin Faire
 Processus fonctionnel 8 : Afficher état système
- E/données : aucune
- E/évènements : E/D
- S/données : Affichage
- S/évènements : aucun
- Nécessite : aucune
- Entraine :
Faire
Afficher état système
Fin Faire

II.5. Conception préliminaire et détaillée


La méthode de conception permet de passer d’un modèle de spécification aux programmes
codés dans un langage exécutable. Étant donné que l’analyse de type fonctionnel et structuré a
été réalisée avec la méthode SA-RT, nous pourrions être tentés de traduire directement ces
modules fonctionnels (processus fonctionnels des diagrammes flots de données de SA-RT) en
des entités de programmes. Cette approche serait très néfaste pour deux raisons :

- D’une part, le découpage modulaire de l’application a été fait en se préoccupant


essentiellement des fonctions à réaliser et non pas de la structuration efficace en
termes de réalisation et d’exécution, c’est-à-dire que le nombre de tâches de
l’application ne correspond pas obligatoirement au nombre de processus fonctionnels
des diagrammes SA-RT ;
- 36 -

- D’autre part, les relations entre les processus fonctionnels des diagrammes flots de
données sont décrites de manière très abstraite (zone mémoire, passage de données)
sans se préoccuper de leurs implémentations possibles avec ou sans synchronisation.

Afin d’établir le lien entre la méthode d’analyse SA-RT et l’implémentation de l’application,


nous allons utiliser la méthode de conception DARTS.

II.5.1. Introduction
La méthode DARTS (Design Approach for Real-Time Systems) trouve naturellement sa place
entre la méthode d’analyse SA-RT et une implémentation avec un langage de programmation
de haut niveau exécuté dans un environnement de type noyau temps réel, ou avec un langage
multitâche ou un langage flots de données. La méthode de conception DARTS est une méthode
de type flots de données. Ainsi, les diagrammes flots de données de la méthode SA-RT
(diagrammes préliminaires ou diagrammes de décomposition) sont traduits en diagramme flots
de données DARTS représentant l’architecture multitâche de l’application. [13]

Les différentes caractéristiques à représenter avec la méthode DARTS sont :

 Les tâches
Ce sont les paramètres ou données en entrées ou en sorties et le type d’activation. Il existe deux
grandes catégories de tâches : les tâches matérielles et les tâches logicielles. Les tâches sont
modélisées par un parallélogramme qui comporte une étiquette ou label explicite formé de :

Étiquette_Tâche = verbe (+ un ou plusieurs compléments d’objets)

Les tâches matérielles ou tâches immédiates sont associées à des évènements matériels externes
au programme. On trouve en particulier toutes les taches d’acquisitions de type régulier. Ces
tâches sont déclenchées par des signaux externes. On distingue trois type de signaux :

 Signal « Horloge temps réel – HTR ». C’est un signal, qui provient d’une horloge
matérielle interne à l’ordinateur, et correspond à un signal rigoureusement périodique.
 Signal « Interruption – IT ». C’est un signal qui provient du procédé externe. Il doit
toujours être considéré comme apériodique du fait de l’asynchronisme du monde
extérieur par rapport au cadencement de l’ordinateur.
 Signal « Chien de garde – CG ». Ce signal provient d’une horloge interne utilisée
comme un réveil. En termes de signal, il est identique à l’horloge temps réel (signal
interne) ; mais il se produit de façon apériodique.
- 37 -

Les activations sont donc représentées par un symbole orienté (ligne brisée) avec une étiquette
ou label explicite formé de :

Étiquette_Activation_HTR = HTR (durée en ms)

Étiquette_Activation_IT = IT (+ nom interruption)

Étiquette_Activation_CG = CG (+ nom chien de garde)

Les tâches logicielles sont celles dont l’activation est demandée par une autre tâche ou tâche
appelante qui peut être de type matériel ou logiciel, avec les mécanismes de synchronisation ou
de communication de type bloquant. Ainsi, le signal d’activation de ces tâches peut être l’action
des éléments suivants :

– boîtes aux lettres à écrasement ou non gérées selon une file FIFO ou FIFO à priorité ;

– boîtes aux lettres à écrasement ou non à une seule place ;

– boîtes aux lettres à n places gérées selon la priorité.

 Les relations entre les tâches

Le point le plus complexe est la traduction des différentes relations entre les tâches. En effet,
cette relation traduit un lien de dépendance entre les tâches, c’est-à-dire qu’une ou plusieurs
tâches ne commencent leur exécution uniquement que lorsqu’une autre tâche s’est exécutée en
partie ou en totalité. Cette synchronisation ou communication peut être unilatérale ou
asynchrone (seule la tâche en attente est bloquée), ou bilatérale ou synchrone (les deux tâches
ont un rendez-vous). Les synchronisations sont donc représentées par un symbole orienté avec
une étiquette ou label explicite formé de :

Étiquette_Synchronisation = nom (+ qualifiant)

Figure II.6: Représentation des synchronisations entre les tâches


- 38 -

 Le partage de ressources critiques

Le module de données permet une protection des accès à une unité de gestion de données en
exclusion mutuelle par deux ou plusieurs tâches. Les modules de données sont représentés par
un rectangle associé à des entrées permettant de réaliser une action sur les données : LIRE,
ÉCRIRE, etc. Ce symbole du module de données est représenté avec une étiquette ou label
explicite formé de :

Étiquette_module_données = nom (+ qualifiant)

Figure II.7: Représentation d’un module de données partagé par plusieurs tâches.

II.5.2. Conception avec DARTS du système de distribution automatique de


boisson
Pour cette méthode de conception non formelle, il est défini des règles générales permettant de
passer d’un diagramme flots de données de la méthode SA-RT à un diagramme multitâche
DARTS. Pour cela, nous devons réaliser la traduction selon les quatre phases suivantes [13]:

– Phase 1 : Création des tâches. Cela correspond à la traduction des processus fonctionnels ou
de contrôle en tâches.

– Phase 2 : Détermination du typage et de l’activation des tâches. Les tâches sont déclarées
matérielles ou logicielles. Dans le cas des tâches matérielles, le signal d’activation doit être
défini précisément (HTR, IT, CG). Pour les autres tâches logicielles, il est nécessaire
d’identifier les synchronisations permettant de les activer. Celles-ci sont souvent déjà déclarées
comme des événements traités par le processus de contrôle.

– Phase 3 : Mise en place des synchronisations et des transferts de données. Les relations par
communications sont traduites par des boîtes aux lettres ou par des modules de données.

– Phase 4 : Regroupement ou rassemblement des tâches.


- 39 -

Traduction du diagramme préliminaire SA-RT en diagramme multitâche DARTS

Phase 1 : La première phase consiste à créer des tâches. Ainsi, nous allons créer neuf tâches :
une tâche correspondant au processus de contrôle et huit tâches correspondant aux huit
processus fonctionnels du diagramme préliminaire représenté sur la figure II.3. Nous obtenons
un diagramme multitâche DARTS comportant neuf tâches ayant les mêmes noms que les
processus fonctionnels SA-RT du diagramme préliminaire et comporte de plus pour chacune
des tâches les entrées/sorties des processus fonctionnels correspondant, avec des noms
identiques.

Phase 2 : La deuxième phase concerne la détermination du type des tâches et de leur activation.
Les tâches d’acquisition « Acquérir données carte », « Acquérir données clavier » et « Acquérir
état capteur à ultrasons » sont des tâches matérielles déclenchées respectivement par les
interruptions « lecture carte », « touche appuyée » et « présence verre ». La tâche d’acquisition
« Acquérir niveau eau » est une tâche matérielle déclenchée par l’horloge temps réel avec une
période de 1000 ms. Les cinq autres tâches sont des tâches logicielles.

Phase 3 : C’est la mise en place des communications entre les tâches. Nous avons une
traduction du flot de données direct entre les deux processus fonctionnels « Acquérir données
carte » et « Analyser données carte » par une synchronisation unique Donnees_carte. Pour
effectuer la vérification des données reçues, la tâche « Analyser données carte » puise les
informations dans le modules des données « Consigne_donnes_carte » et les évènements
donnees_correctes, donnees_incorrectes sont traduits par une synchronisation
Evt_donnees_verifiees. Nous pouvons identifier sur le diagramme préliminaire les évènements
Fins_saisie, Verre_detecte qui sont traduits, dans le diagramme DARTS, par les
synchronisations Evt_fin_saisie, Evt_verre_detecte, et les évènements Niveau_correct et
Niveau_bas du processus fonctionnel « Acquérir niveau eau » ont été remplacés par le module
de données « Niveau_eau_mesure » qui sauvegarde la comparaison par rapport aux consignes
de niveau et aussi le niveau mesuré. Les tâches « Commander pompe », « Alerter état système »
et « Afficher état système » sont activées respectivement par les synchronisations
Evt_commande_pompe, Evt_commande_alerte et Evt_commande_affichage.

Phase 4 : Cette phase consiste au regroupement des taches et relations du diagramme DARTS
obtenu après les trois premières phases.
- 40 -

Figure II.8: Diagramme multitâche DARTS du système


- 41 -

II.6. Modélisation de la base de données


Il est évident, départ notre cahier de charge, que les informations que nous allons utiliser
devront être stockées dans une base de données qui pourra nous permettre d’effectuer différents
traitements. La modélisation de la base de données du système est faite avec le langage UML.

1. Diagramme des classes

UML est un langage de représentation destiné en particulier à la modélisation objet (utilisé plus
pour la programmation orientée objet). UML est devenu une norme OMG en 1997 (OMG-
Object Management Group est un organisme à but non lucratif créé en 1989 à l'initiative de
sociétés comme HP, Sun, Philips, etc..) [14]. UML permet de rester indépendant d’un langage
de programmation donné. A l'aide de ce langage nous pouvons créer un diagramme de classes
qui se base autour de 3 concepts principaux : les classes, les associations et les attributs. Une
classe est un type abstrait caractérisé par des propriétés (attributs et méthodes) communes à un
ensemble d'objets et permettant de créer des instances de ces objets, ayant ces propriétés.

La modélisation sous forme de diagramme de classes est une modélisation statique, qui met en
exergue la structure d'un modèle, mais ne rend pas compte de son évolution temporelle. UML
propose d'autres types de diagrammes : diagramme des cas d’utilisation, diagramme d’activité,
diagramme d’état, … [15]

Figure II.9: Diagramme des classes du système


- 42 -

2. Stockage des données

Notre système aura à conserver un nombre important de données sur les utilisateurs, et sur les
paramètres de fonctionnement du système dans une base de données. Sa structure interne est
présentée par le modèle logique présenté sur la figure II.10.

Figure II.10: Modèle logique des données

II.7. Conclusion partielle


Dans ce chapitre, nous avons fait une étude détaillée du système de distribution de boisson à
réaliser, appelé « FastSoda ». Comme nous l’avons dit précédemment le cycle de
développement d’une application de contrôle-commande comprend trois étapes : la
spécification, la conception et la programmation, seules la spécification et la conception ont été
décrites dans ce chapitre, en utilisant respectivement les méthodes SA-RT et DARTS. Nous
avons également modélisé la base de données du système avec le langage UML. Ainsi l’étape
de la programmation fera partie du troisième chapitre.
- 43 -

CHAP III : IMPLEMENTATION ET


REALISATION DU SYSTEME
III.1. Introduction
Les applications informatiques dites de contrôle-commande ont envahi l’environnement
industriel et notre vie quotidienne. Le dénominateur commun à toutes ces applications est la
fourniture de fonctionnalités toujours plus sophistiquées. Les trois grands domaines permettant
ces développements sont l’électronique, l’automatique et l’informatique, qui ont dû progresser
et s’adapter.

La conception réalisée dans le chapitre précédent nous permet de passer à l’étape suivante qui
est la programmation ou la mise en œuvre effective du système de distribution automatique de
boisson. Dans ce chapitre nous ferons donc le point sur les éléments matériels qui vont
intervenir dans la confection dudit système.

III.2. Fonctionnement du système

Figure III.1: Diagramme de séquence du système


- 44 -

Le diagramme présenté sur la figure III.1 représente la communication, l’interaction qui existe
entre le client et le système.

Figure III.2: Diagramme d’activité du système


- 45 -

Le diagramme présenté sur la figure III.2 représente le processus d’exécution du système


implémenté.

III.3. Environnement de développement


III.3.1. Environnement logiciel
Lors de la réalisation du présent travail, nous avons eu à utiliser un certain nombre des logiciels
et technologies y afférent, entre autres :

 Le logiciel et le langage Arduino : Etant le socle de notre système, le code source de


notre système a été écrit dans le langage Arduino dans son environnement de
développement intégré qui assure la compilation et le téléversement dans les cartes
Arduino.
 Les logiciels Visual paradigm community : Ce logiciel nous a permis de tracer les
diagrammes de classe, d’activité et de séquence.
 Le logiciel NetBeans : L’Environnement de Développement Intégré Netbeans est un
environnement de développement, un outil des programmeurs pour écrire, compiler,
déboguer et déployer des programmes. Pour implémenter notre application Web, nous
avons utilisé le logiciel Netbeans.
 Le logiciel Fritzing est un logiciel libre de conception des circuits imprimés, qui permet,
de concevoir de façon entièrement graphique le circuit et d'en imprimer le typon. Se
voulant dans la ligne d'Arduino et de processing, Fritzing est un projet de logiciel libre,
destiné aux non-professionnels de l'électronique. Il a notamment pour vocation de
favoriser l'échange de circuits électroniques libres et d'accompagner l'apprentissage de
la conception de circuits. [16]
- 46 -

Figure III.3: Fenêtre du logiciel Fritzing

III.3.2. Environnement matériel et les composants


Le principe de fonctionnement de notre système est basé sur l’acquisition d’un certain nombre
d’informations provenant d’une étiquette RFID ou d’un tag par le lecteur RFID. Ces
informations sont ensuite analysées, traitées par le cerveau du système qui est notre carte
Arduino. Cette dernière, selon les informations reçues et selon les actions de l’utilisateur, est à
l’origine d’un certain nombre d’opérations.

a. Carte Arduino Mega

La carte Arduino Mega 2560 est basée sur un ATMega2560 cadencé à 16 MHz. Elle dispose
de 54 E/S dont 14 PWM, 16 analogiques et 4 UARTs. Elle est idéale pour des applications
exigeant des caractéristiques plus complètes que la carte Uno. Des connecteurs situés sur les
bords extérieurs du circuit imprimé permettent d'enficher une série de modules
complémentaires. [17]

Caractéristiques principales :

 Version : Rev. 3
 Microcontrôleur : ATMega2560
 Tension de fonctionnement : 5 V
 Tensions d’alimentation via port USB : 5 V
 Tensions d’alimentation externe (recommandées) sur connecteur alim : 7-12 V
 Tensions d’alimentation externe (limites) : 6 et 20V
- 47 -

 Broches E/S numériques : 54 (dont 14 disposent d’une sortie PWM)


 Broches d’entrées analogiques : 16 (utilisables en broches E/S numériques)
 Intensité maximale disponible par broche E/S (5 V) : 40 mA
 Intensité maximale disponible pour la sortie 3.3 V : 50 mA
 Intensité maximale disponible pour la sortie 5 V : 500 mA maximum si port USB
utilisé seul
 Mémoire Programme Flash : 256 KB dont 8 KB sont utilisés par le bootloader
 Mémoire SRAM (mémoire volatile) : 8 KB
 Mémoire EEPROM (mémoire non volatile) : 4 KB
 Dimensions :107x53x15 mm
 Vitesse d’horloge ou cadencement : 16 MHz

Figure III.4: Carte Arduino Mega 2560


b. Module RFID

Le RFID (Radio Frequency Identification) est un terme commun utilisé pour décrire un module
employé pour le transfert de données à l’aide des ondes radio sur des courtes distances
(typiquement <15.24cm). [1]

La structure RFID est constituée de 2 composantes principales :

- L’émetteur localisé sur le produit à identifier (son étiquette)


- Le lecteur qui peut être un simple lecteur ou un simple module de lecture ou de lecture
& écriture

Application des modules RFID :

- Traçage des marchandises


- Contrôle d’accès à des endroits sécurisés
- 48 -

- Traçage du personnel
- Gestion des chaines d’approvisionnement
- Réalisation de badges d’identification
- Cartes de payement, d’étudiants, d’identité, passeports
- Etc.

Dans notre système, nous utilisons ce module pour permettre l’authentification des utilisateurs
en vue de leur donner ou non accès aux options du distributeur.

Le lecteur RFID possède 8 broches que nous avons branchées comme suit :

Tableau 1: Broches du module RFID

Pin du RFID RC-522 Pin de la carte Arduino Mega


1. SDA(donnée) Pin 53
2. SDK(horloge) Pin 52
3. MOSI Pin 51
4. MISO Pin 50
5. IRQ Pas connecté
6. GND Masse
7. RST Pin 49
8. 3.3V 3.3V (pas 5V)

Figure III.5: Module RFID RC522


- 49 -

c. Clavier Arduino 4x4

Ce clavier est composé de 16 boutons poussoirs sous forme d’une matrice 4x4. Il a 8 fils de
connections [1]:

- R1, R2, R3, R4 : pour les lignes


- C1, C2, C3, C4 : pour les colonnes

Nous avons utilisé un clavier Arduino 4x4 pour permettre à l’utilisateur de saisir le mot de passe
et de faire le choix de la boisson, une fois sa carte vérifiée et acceptée. Ce mot de passe est
comparé à celui conservé dans la base des données.

Figure III.6: Clavier Arduino 4x4


d. Ecran LCD

LCD signifie "Liquid Crystal Display" ou " Écran à Cristaux Liquides " en français. C’est un
petit écran qui permet d’afficher certains caractères. Il existe plusieurs types d’écran LCD. Dans
notre système, nous avons utilisé un écran LCD de 16 colonnes et 2 lignes. Il permettra
d’afficher les résultats de certaines actions de l’utilisateur afin d’interagir avec le système. Cet
écran comprend 16 broches décrites comme suit [12] :

Tableau 2: Description des broches de l’écran LCD

N° Nom Rôle
1 VSS Masse
2 Vdd 5V
- 50 -

3 V0 Réglage du contraste
4 RS Sélection du registre(commande ou donnée)
5 R/W Lecture ou écriture
6 E Entrée de validation
7 à 14 D0 à D7 Bits de données
15 A Anode du rétroéclairage
16 K Cathode du rétroéclairage

Figure III.7: Ecran LCD


e. Mini pompes à air

Une mini pompe est un instrument de petite dimension qui permet de créer le vide (baisse de
pression) dans un récipient [18]. Ces mini pompes, nous ont permis de pomper la boisson
choisie par l’utilisateur.

Figure III.8: Mini pompe à air


- 51 -

f. Capteur ultrason

Un capteur d’ultrason est un senseur qui peut mesurer la distance par rapport à un solide ou un
objet physique. Ce module contient un émetteur d’ondes ultrasoniques. Un récepteur de ces
ondes et un circuit de control. Ce capteur permet à notre système de détecter la présence d’un
verre ou d’un gobelet qui conditionne la distribution de la boisson.

Figure III.9: Capteur à ultrasons


g. Capteur de niveau d’eau
Ce module sert à détecter le niveau d’eau dans un petit réservoir. Il est très simple à utiliser
avec une tension d’utilisation 3.3V~5V [1]. Il nous a permis de détecter le niveau de la boisson
dans les réservoirs.

Figure III.10: Capteur de niveau d’eau


h. Relais

Un interrupteur contrôlé électriquement : L’excitation d’une bobine engendre un champ


électromagnétique qui actionne un certain mécanisme pour l’ouverture ou la fermeture d’un
contact. Il permet d’effectuer une isolation électrique entre 2 circuits qui peuvent avoir 2
niveaux de tension différents. Les relais sont disponibles avec un canal, 2 canaux, 4 canaux.

Il nous a permis de commander les mini pompes.


- 52 -

Figure III.11: Relais à 1 canal


i. Buzzer

C’est un transducteur électronique intégré. Il est beaucoup utilisé dans les ordinateurs,
imprimantes, copieuses, alarmes, jouets électroniques, … pour fournir une signalisation ou une
alerte sonore et peut être contrôlé par programme. Le buzzer émet un son avec différentes
tonalites selon les actions de l’utilisateur.

Figure III.12: Buzzer


j. LED

Une LED / DEL : Light-Emitting Diode ou bien Diode Electro-Luminescente. C’est un


composant électronique qui émet de la lumière lorsqu'il est parcouru par un courant électrique.
Nous avons utilisé des leds pour signaler certaines actions de l’utilisateur.
- 53 -

Caractéristiques [19]:

Tableau 3: Caractéristiques des LEDs

Couleur Tension de seuil Intensité(mA)


Rouge 1,6V à 2V 6 à 20
Jaune 1,8V à 2V 6 à 20
Vert 1,8V à 2V 6 à 20
Bleu 2,7V à 3,2V 6 à 20
Blanc 3,5V à 3,8V 30

Figure III.13: LED


k. Shield Wifi

Le Shield Wifi permet à un Arduino d’établir une communication sans fil en utilisant un module
Wireless. Il est basé sur les modules Xbee. Le module sait communiquer sur une distance de
30m en extérieur et jusqu’à une distance de 90m en intérieur [20]. Ce Shield nous a permis de
connecter notre carte Arduino à notre réseau local afin qu’elle puisse communiquer avec notre
application web et lui transférer des informations telles que l’ID de la carte, le montant, ...

Figure III. 14: Shield Wifi


- 54 -

l. Fils de pontage

Ce sont des fils que nous utilisons pour réaliser les connexions de différents composants lors
de la réalisation du prototype de notre système. On en trouve généralement à des couleurs
différentes.

Figure III.15: Fils de pontage

III.3.3. Réalisation du système


a. Application web

Notre système intègre une application qui permet à l’administrateur d’avoir, des informations
sur l’état du distributeur et d’effectuer certaines opérations comme : l’enregistrement des
abonnés, recharger leurs comptes, regarder l’historique des consommations …

 Page d’accueil

La figure III.16 représente la page d’accueil qui est la première page qui se lance lorsque l’on
accède à l’application. Elle permet à l’administrateur d’accéder à son compte à partir de son
login et de son mot de passe.
- 55 -

Figure III.16: Page d’accueil de l’application

 Page de l’historique

Cette page donne la liste des consommations en indiquant le nom de l’abonné, la date, le nom
de la boisson commandée ainsi que son prix.

Figure III.17: Historique des consommations


- 56 -

 Liste des abonnés

Figure III.18: Liste des abonnés

 Page d’enregistrement

Figure III.19: Enregistrement d’un abonné


La figure III.19 représente la page d’enregistrement des abonnés au système FastSoda et la
figure III.20 représente la page de recharge du compte d’un abonné.
- 57 -

Figure III.20: Recharge du compte d’un abonné


b. Schéma de montage

Figure III.21: Schéma du système


La figure III.21 représente le montage du système, réalisé avec le logiciel Fritzing. Elle décrit
les connexions entre les composants.
- 58 -

Figure III.22: Montage du système

Figure III. 23: Maquette du système


- 59 -

III.4. Estimation du coût des matériels


Tableau 4: Coût estimatif des matériels

Nom du matériel Prix unitaire(€) Quantité Prix total(€)


Coût des matériels (www.amazon.fr)
Arduino Mega 2560 13.99 1 13.99
Arduino Uno R3 10.99 1 10.99
Buzzer 3.78 1 3.78
Capteur du niveau d’eau 3.50 1 3.50
Capteur à ultrasons 1.73 1 1.73
Clavier 4x4 3.49 1 3.49
Ecran LCD 5.99 1 5.99
Fils connecteurs 6.51 1 paquet 6.51
Led 4.98 1 boite 4.98
Mini pompe à air 5.04 3 15.12
Module RFID RC522 6.99 1 6.99
Pile d’alimentation 9V 3.10 2 6.20
Relais 6.76 3 20.28
Shield wifi 6.20 1 6.20
Sous-Total 1 109.75
Coût du développement logiciel
Application web 850.34 1 850.34
Sous-Total 2 850.34
Total général 960.09
Le prix estimatif du logiciel et du matériel utilisé pour la réalisation du prototype est donc de
960.09 euros équivalent à peu près à 1129.07 dollars américains si l’on considère le taux au
moment de la rédaction : 1€ = 1.176 $.

III.5. Conclusion partielle


Dans cette partie nous avons décrit le fonctionnement de notre système et présenté les différents
composants qui ont contribués à sa mise en place. Nous l’avons fini par la présentation du coût
des matériels utilisés.
- 60 -

CONCLUSION GENERALE
Au terme de ce travail, rédigé dans le cadre de la fin de nos études, intitulé « Conception et
Réalisation d’un système de distribution automatique de boissons », nous avons implémenté
un système que nous avons nommé FastSoda, qui effectue une distribution automatique des
boissons selon le choix de l’utilisateur. Il est conçu sur base des technologies RFID, autour de
la plateforme Open Source Arduino. Une application Web est l'interface permettant de faire
l’enregistrement, la configuration et la gestion du système.

Le système proposé dans ce travail, n'étant pas un système de distribution automatique assurant
toutes les fonctionnalités possibles qu'offrent ces genres de plateformes, nous avons néanmoins
proposé, un prototype pouvant permettre d'enregistrer les abonnés, de gérer leurs comptes, et
de servir la boisson.

Pour arriver à cette fin nous avons commencé par une phase d’analyse, en fixant dans un cahier
des charges, certaines fonctionnalités que devrait nécessairement implémenter notre système,
et une phase de conception et de modélisation du système dans laquelle les méthodes SART,
DARTS et le langage UML ont été utilisés. Nous avons ensuite fait le choix des technologies à
utiliser et notre attention s’est tournée vers la plateforme Arduino comme socle matériel de
notre système à cause de sa gamme bien fournie en capteurs et actionneurs.

Enfin nous sommes passés par une étape d’implémentation de l’application Web qui tient lieu
d’interface de configuration, en donnant les détails sur les composants utilisés ainsi que le coût
estimatif du prototype.

Le prototype ici proposé n'étant pas en soi un système fini, nous restons ouverts à toute
observation, critique et suggestion susceptibles de faire avancer, d'éclairer et de stimuler
davantage notre approche et la créativité dans l'ingénierie système.

N’ayant aucunement la prétention d’avoir épuisé, toute la matière gravitant autour de ce sujet
ou d’avoir fait une œuvre idéale, il est évident que ce type de travail peut être élargi dans les
jours à venir. Les passionnés de ce domaine pourront améliorer ce système en y apportant autant
des fonctionnalités que possible pour le rendre plus attrayant et confortable et encore plus
répondant aux normes de standardisation. Toutefois, nous proposons aux chercheurs, qui auront
à cœur de continuer sur notre lancée de prendre en compte un module de notification de l’état
du système, une gestion de la température, un système de reconnaissance de forme, etc.
- 61 -

BIBLIOGRAPHIE

a. Références

[1] O. BARAKA, Cours des systèmes embarqués, ULPGL Goma: Inédit, 2017.

[3] B. JRAD, Systèmes automatisés, Institut Supérieur de Etudes Technologiques de Djerba: Inédit,
2012.

[10] Astalaseven, Eskimon et olyte, Arduino pour bien commencer en electronique et en


programmation, Site du zero, 2012.

[11] D. Kushner, The Making of Arduino, IEEE Spectum, 2011.

[12] Eskimon et Olyte, Arduino: premier pas en informatique embarquée, Paris: Zeste de savoir,
2015.

[13] F. Cottet et E. Grolleau, Système temps réel de contrôle-commande, Paris: Dunod.

[14] C. Soutou, UML 2 pour les bases de données, Paris: Eyrolles.

[15] C. Takenga, «Informatique de gestion,» Goma, Inédit, 2015, p. 24.

b. Liens

[2] «Automatisme,» [En ligne]. Available: https://fr.wiktionary.org/wiki/automatisme. [Accès le 31


Mai 2018].

[4] «Notions de chaine fonctionnelle,» [En ligne]. Available:


http://philppe.berger2.free.fr/automatique/cours/CF/notions_de_chaine_fonctionnelle.htm.
[Accès le 12 Avril 2018].

[5] «Les systemes automatisés,» [En ligne]. Available:


http://www.kingkongevenement.com/cbruneau. [Accès le 1 Mai 2018].

[6] «Distribution automatique,» [En ligne]. Available:


https://fr.m.wikipedia.org/wiki/Distributeur_automatique. [Accès le 6 Juin 2018].

[7] «Distributeur automatique de boisson, une longue histoire,» [En ligne]. Available:
https://www.distributeur-de-boisson.fr. [Accès le 15 Juin 2018].

[8] «La distribution automatique, une histoire qui remonte à loin…,» [En ligne]. Available:
http://influence-ce.fr. [Accès le 13 Juillet 2018].
- 62 -

[9] «Guide distributeur de boisson-Tout savoir,» [En ligne]. Available: https://www.guide-


distributeur-boissons.be. [Accès le 22 Juin 2018].

[16] Fritzing, «fritzing electronics made easy,» Fritzing, [En ligne]. Available:
http://fritzing.org/home/. [Accès le 21 Septembre 2018].

[17] Solution e-commerce Arobase, «Arduino Mega 2560,» [En ligne]. Available:
https://www.gotronic.fr. [Accès le 26 Septembre 2018].

[18] «Pompe à air,» [En ligne]. Available: https://fr.m.wikipedia.org/wiki/pompe. [Accès le 5 Août


2018].

[19] «Les diodes LED,» [En ligne]. Available:


http://etronics.free.fr/dossiers/analog/analog12/diodeled.htm. [Accès le 12 0ctobre 2018].

[20] «Arduino Wireless shield,» [En ligne]. Available: https://www.wiki.mchobby.be. [Accès le 30


Septembre 2018].
- 63 -

ANNEXES
I. Image du système réalisé

II. Extrait du code source Arduino

//========fonction pour RFID=======

void lireCarte() {

lcd.clear();

lcd.print("Scanner");

lcd.setCursor(0, 1);

lcd.print("votre carte,SVP!");
- 64 -

if ( ! moduleRfid.PICC_IsNewCardPresent()) {

return;

if ( ! moduleRfid.PICC_ReadCardSerial()) {

return;

String UID = "";

for (byte i = 0; i < moduleRfid.uid.size; i++) {

UID.concat(String(moduleRfid.uid.uidByte[i] < 0x10 ? "0" : " "));

UID.concat(String(moduleRfid.uid.uidByte[i], HEX));

UID.toUpperCase();

//si carte est acceptee

if (UID.substring(1) == "30 D7 9E A3") {

lcd.clear();

lcd.setCursor(0, 0);

lcd.print("Accces autorise....");

lcd.setCursor(0, 1);

lcd.print("Bonjour Raph");

digitalWrite(ledVerte, HIGH); //on allume la led verte

tone(buzzer, 1500, 100);

delay(125);

tone(buzzer, 1500, 100);


- 65 -

delay(3000);

lcd.clear();

lcd.setCursor(0, 0);

lcd.print("Entrez le code: ");

digitalWrite(ledVerte, LOW); //on eteint la led

//test du code

do {

char touche = clavier.getKey();

int compte;

if (touche != NO_KEY) {

lcd.setCursor(5, 1);

for (compte = 0; compte <= presscounter; ++compte) {

lcd.print("*");

presscounter ++;

pr += touche;

if (presscounter == 4) {

msg = "";

msg += pr;

pr = "";

delay(10);

} while (presscounter < 4);


- 66 -

while (msg != secret) {

digitalWrite(ledRouge, HIGH);

lcd.clear();

lcd.print("Code incorrect");

lcd.setCursor(0, 1);

lcd.print("Recommencez!!!");

presscounter = 0;

tone(buzzer, 200, 1000);

delay(3000);

digitalWrite(ledRouge, LOW);

lcd.clear();

lcd.setCursor(0, 0);

lcd.print("Entrez le code: ");

//test du code

do {

char touche = clavier.getKey();

int compte;

if (touche != NO_KEY) {

lcd.setCursor(5, 1);

for (compte = 0; compte <= presscounter; ++compte) {

lcd.print("*");

presscounter ++;
- 67 -

pr += touche;

if (presscounter == 4) {

msg = "";

msg += pr;

pr = "";

delay(10);

} while (presscounter < 4);

if (msg == secret) {

digitalWrite(ledVerte, HIGH);

presscounter = 0;

tone(buzzer, 1500, 100);

delay(125);

tone(buzzer, 1500, 100);

lcd.clear();

lcd.setCursor(0, 0);

lcd.print("Code est valide");

delay(1500);

digitalWrite(ledVerte, LOW);

//choix de la boisson

lcd.clear();

lcd.setCursor(0, 0);
- 68 -

lcd.print("Choisissez votre");

lcd.setCursor(0, 1);

lcd.print("boisson :");

delay(4000);

lcd.clear();

lcd.setCursor(0, 0);

lcd.print("A:Orange");

lcd.setCursor(9, 0);

lcd.print("B:Coca");

lcd.setCursor(0, 1);

lcd.print("C:Citron");

lcd.setCursor(9, 1);

lcd.print("D:Eau");

//validation choix de la boisson

char bouton;

do {

bouton = clavier.getKey();

if (bouton != NO_KEY) {

lcd.clear();

lcd.setCursor(0, 0);

lcd.print("Boisson : ");

lcd.print(bouton);

//test choix de la boisson


- 69 -

if (bouton != 'A' && bouton != 'B' && bouton != 'C' && bouton != 'D') {

lcd.clear();

lcd.setCursor(0, 0);

lcd.print("Choix incorrect");

digitalWrite(ledRouge, HIGH); //on allume la led rouge

tone(buzzer, 200, 1000);

delay(2000);

digitalWrite(ledRouge, LOW); //on eteint la led

lcd.clear();

lcd.setCursor(0, 0);

lcd.print("A:Orange");

lcd.setCursor(9, 0);

lcd.print("B:Coca");

lcd.setCursor(0, 1);

lcd.print("C:Citron");

lcd.setCursor(9, 1);

lcd.print("D:Eau");

} while (bouton != 'A' && bouton != 'B' && bouton != 'C' && bouton != 'D');

//choix de la boisson correcte

switch (bouton) {

//si on choisit la boisson A

case 'A':
- 70 -

digitalWrite(ledJaune, HIGH);

lcd.clear();

lcd.setCursor(0, 0);

lcd.print("Boisson:Orange");

lcd.setCursor(1, 1);

lcd.print("Prix:300Fc");

delay(3000);

lcd.clear();

lcd.setCursor(0, 0);

lcd.print("Tapez 'A' pour ");

lcd.setCursor(1, 1);

lcd.print("valider");

char cle;

do {

cle = clavier.getKey();

if (cle != NO_KEY) {

digitalWrite(ledJaune, LOW);

if (cle != 'A') {

lcd.clear();

lcd.setCursor(0, 0);

lcd.print("Tapez 'A' pour ");

lcd.setCursor(1, 1);

lcd.print("valider");

delay(1500);
- 71 -

} while (cle != 'A');

//detection de la presence du verre

float duration, distance;

do {

digitalWrite(trigPin, LOW); // DEFINITION DU SIGNAL PWM EMIS

delayMicroseconds(2); // pour s'assurer d'avoir bien o à trig pin

digitalWrite(trigPin, HIGH);

delayMicroseconds(10); // pour maintenir le 1 à trig pendant 10us pour l'envoie du PING

digitalWrite(trigPin, LOW);

duration = pulseIn(echoPin, HIGH);//mesure de la durée haut du signal sur Echo

distance = duration / 58.0; // conversion du temps en cm

lcd.clear();

lcd.print("......................");

Serial.print("Distance in cm= ");

Serial.print(distance);

Serial.println(" cm");

delay(1000);

} while (distance >= 5);

digitalWrite(ledVerte, HIGH);

delay(2000);

digitalWrite(ledVerte, LOW);

//On commande la pompe par le relais


- 72 -

state = !state;

digitalWrite(relais, state);

Serial.println(state);

digitalWrite(ledJaune, HIGH);

lcd.clear();

lcd.print("Servir Orange");

digitalWrite(ledBleu, HIGH); //on allume la led rouge

delay(10000);

digitalWrite(ledBleu, LOW); //on eteint la led

state = !state;

digitalWrite(ledJaune, LOW);

lcd.clear();

delay(2000);

lcd.setCursor(5, 0);

lcd.print("MERCI!!");

lcd.setCursor(4, 1);

lcd.print("bye bye");

delay(2000);

break;

//Si on choisit la boisson B

case 'B':

digitalWrite(ledJaune, HIGH);

lcd.clear();

lcd.setCursor(0, 0);
- 73 -

lcd.print("Boisson:Coca");

lcd.setCursor(1, 1);

lcd.print("Prix:500Fc");

delay(3000);

lcd.clear();

lcd.setCursor(0, 0);

lcd.print("Tapez 'B' pour ");

lcd.setCursor(1, 1);

lcd.print("valider");

char key;

do {

key = clavier.getKey();

if (key != NO_KEY) {

digitalWrite(ledJaune, LOW);

if (key != 'B') {

lcd.clear();

lcd.setCursor(0, 0);

lcd.print("Tapez 'B' pour ");

lcd.setCursor(1, 1);

lcd.print("valider");

delay(1500);

}
- 74 -

} while (key != 'B');

//detection de la presence du verre

float durations, distances;

do {

digitalWrite(trigPin, LOW); // DEFINITION DU SIGNAL PWM EMIS

delayMicroseconds(2); // pour s'assurer d'avoir bien o à trig pin

digitalWrite(trigPin, HIGH);

delayMicroseconds(10); // pour maintenir le 1 à trig pendant 10us pour l'envoie du PING

digitalWrite(trigPin, LOW);

durations = pulseIn(echoPin, HIGH);//mesure de la durée haut du signal sur Echo

distances = duration / 58.0; // conversion du temps en cm

lcd.clear();

lcd.print("......................");

Serial.print("Distance in cm= ");

Serial.print(distances);

Serial.println(" cm");

delay(1000);

} while (distances >= 5);

digitalWrite(ledVerte, HIGH);

delay(2000);

digitalWrite(ledVerte, LOW);

state = !state;

digitalWrite(relais, state);
- 75 -

Serial.println(state);

digitalWrite(ledJaune, HIGH);

lcd.clear();

lcd.print("Servir Coca");

digitalWrite(ledBleu, HIGH);

delay(10000);

digitalWrite(ledBleu, LOW); //on eteint la led

state = !state;

digitalWrite(relais, state);

digitalWrite(ledJaune, LOW);

lcd.clear();

delay(2000);

lcd.setCursor(5, 0);

lcd.print("MERCI!!");

lcd.setCursor(4, 1);

lcd.print("bye bye");

delay(2000);

break;

case 'C':

digitalWrite(ledJaune, HIGH);

delay(3000);

digitalWrite(ledJaune, LOW);

break;

case 'D':
- 76 -

digitalWrite(ledJaune, HIGH);

delay(3000);

digitalWrite(ledJaune, LOW);

break;

default:

digitalWrite(ledJaune, HIGH);

delay(3000);

digitalWrite(ledJaune, LOW);

break;

else {

lcd.clear();

lcd.setCursor(0, 0);

lcd.print("Accces refuse");

digitalWrite(ledRouge, HIGH);

tone(buzzer, 200, 1000);

delay(3000);

digitalWrite(ledRouge, LOW);

lcd.clear();

}
- 77 -

TABLE DES MATIERES

EPIGRAPHE ........................................................................................................................................... i
DEDICACE .............................................................................................................................................ii
REMERCIEMENTS ...............................................................................................................................iii
LISTE DES FIGURES.......................................................................................................................... iv
LISTE DES TABLEAUX ......................................................................................................................v
RESUME ................................................................................................................................................ vi
ABSTRACT .......................................................................................................................................... vii
SIGLES ET ABREVIATIONS .......................................................................................................... viii
INTRODUCTION GENERALE...................................................................................................... - 1 -
1. Problématique........................................................................................................................ - 1 -
2. Hypothèses ............................................................................................................................. - 2 -
3. Objectif ................................................................................................................................... - 2 -
4. Choix et intérêt du sujet ........................................................................................................ - 3 -
5. Méthodologie et technique de recherche ............................................................................. - 3 -
6. Délimitation du sujet ............................................................................................................. - 4 -
7. Subdivision du travail ........................................................................................................... - 4 -
CHAP I : NOTIONS THEORIQUES DE BASE............................................................................ - 5 -
I.1. Introduction............................................................................................................................. - 5 -
I.2. Automatismes .......................................................................................................................... - 5 -
I.2.1. Objectifs de l’automatisation .......................................................................................... - 5 -
I.2.2. Structure d’un système automatisé ................................................................................ - 6 -
I.2.3. Conduite et surveillance d’un système automatisé ....................................................... - 8 -
I.2.4. Exemples d’automatismes ............................................................................................... - 8 -
I.2.5. Représentation des automatismes .................................................................................. - 8 -
I.3. Distributeur automatique..................................................................................................... - 10 -
I.3.1. Historique ....................................................................................................................... - 11 -
I.3.2. Techniques d’automatisation ........................................................................................ - 12 -
I.3.3. Types de distributeurs de boissons ............................................................................... - 13 -
I.3.4. Système de paiement ...................................................................................................... - 13 -
I.3.5. Durée de vie et Sécurité ................................................................................................. - 14 -
I.4. Arduino .................................................................................................................................. - 15 -
I.4.1. Historique ...................................................................................................................... - 15 -
I.4.2. Matériel Arduino .......................................................................................................... - 16 -
- 78 -

I.4.3. Capteurs et actionneurs................................................................................................ - 18 -


I.4.4. Langage Arduino .......................................................................................................... - 19 -
I.5. Conclusion partielle .............................................................................................................. - 21 -
CHAP II : CONCEPTION ET MODELISATION DU SYSTEME DE DISTRIBUTION DE
BOISSON ......................................................................................................................................... - 22 -
II.1. Introduction ......................................................................................................................... - 22 -
II.2. Cycle de développement des applications informatiques ................................................ - 22 -
II.3. Analyse des besoins ............................................................................................................. - 23 -
II.4. Spécifications globales......................................................................................................... - 24 -
II.4.1 Syntaxe de la méthode SA-RT...................................................................................... - 24 -
II.4.2. Analyse SA-RT du système de distribution automatique de boisson....................... - 26 -
1. Diagramme de contexte................................................................................................... - 26 -
2. Diagramme préliminaire ................................................................................................ - 27 -
3. Diagramme d’état-transition .......................................................................................... - 29 -
4. Spécification des processus fonctionnels primitifs........................................................ - 31 -
II.5. Conception préliminaire et détaillée .................................................................................. - 35 -
II.5.1. Introduction .................................................................................................................. - 36 -
II.5.2. Conception avec DARTS du système de distribution automatique de boisson ...... - 38 -
II.6. Modélisation de la base de données ................................................................................... - 41 -
II.7. Conclusion partielle............................................................................................................ - 42 -
CHAP III : IMPLEMENTATION ET REALISATION DU SYSTEME .................................. - 43 -
III.1. Introduction ....................................................................................................................... - 43 -
III.2. Fonctionnement du système .............................................................................................. - 43 -
III.3. Environnement de développement ................................................................................... - 45 -
III.3.1. Environnement logiciel ............................................................................................... - 45 -
III.3.2. Environnement matériel et les composants .............................................................. - 46 -
III.3.3. Réalisation du système................................................................................................ - 54 -
III.4. Estimation du coût des matériels...................................................................................... - 59 -
III.5. Conclusion partielle ........................................................................................................... - 59 -
CONCLUSION GENERALE ........................................................................................................ - 60 -
BIBLIOGRAPHIE .......................................................................................................................... - 61 -
a. Références ................................................................................................................................. - 61 -
b. Liens........................................................................................................................................... - 61 -
ANNEXES ........................................................................................................................................ - 63 -
TABLE DES MATIERES .............................................................................................................. - 77 -

Vous aimerez peut-être aussi