Version Finale PFE

République Tunisienne
Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique
Université de Carthage
Institut Supèrieur des Technologies de
l’Information et de la Communication
Rapport de Projet de Fin d’Etudes

Présenté en vue de l’obtention de la
Licence Appliquée en Informatique Industrielle
Mention : Informatique Industrielle
Spécialité : Systèmes Embarqués
Conception, réalisation et mise en place

d’un système de suivi de performance d’une
ligne de production
par
Oumaima Berrima
Réalisé au sein des Laboratoires Teriak
Soutenu publiquement le 27 Mai 2019 devant le jury composé de :

Président : Firas Lachhab Eleonetech
Rapporteur : Wafa Fouratti Istic
Examinateur : Emna Akkari Istic
Encadrant professionnel : Asma Sellami Teriak
Encadrant académique : Hassène Gritli Istic
Invité : Amine Krichène Mckinsey Electronics
Année Universitaire : 2018 - 2019

République Tunisienne
Ministère de l’Enseignement Supérieur
et de la Recherche Scientifique
Université de Carthage
Institut Supérieur des Technologies de
l’Information et de la Communication
Rapport de Projet de Fin d’Etudes

Présenté en vue de l’obtention de la
Licence Appliquée en Informatique Industrielle
Mention : Informatique Industrielle
Spécialité : Systèmmes Embarqués
Conception, réalisation et mise en place

d’un système de suivi de performance d’une
ligne de production
par
OUMAIMA BERRIMA
Réalisé au sein des Laboratoires Teriak
Autorisation de dépôtt du rapport de Projet de Fin d’Etudes :
Encadrant professionnel : Encadrant académique :

Sellami Asma Gritli Hassène
Le 17 Mai 2019 Le 17 Mai 2019
Signature : Signature :
DÉDICACES
Je dédie ce travail particulièrement
À ma chère maman la plus passionnée Souad, ma clé vers le succès, pour tous les
sacrifices qu’elle m’a faits et pour tout le soutien qu’elle m’a offert tout au long de mes
années d’étude.
À mon cher papa Elyes pour ses encouragements à me battre jusqu’au bout. Lui ho-
norer avec ma réussite était toujours mon ultime objectif.
À mon grand frère Ghassen pour son aide et son soutien.
À mes jumelles Samar et Sahar pour leur présence toujours pour me supporter.
À mes amis et mes collègues qui ont été présents durant tout mon cycle d’étude.
Finalement À tous ceux qui m’aiment et me supportent.
i
REMERCIEMENTS
Les remerciements les plus sincères iront tout d’abord à mes deux encadrants : -Mme .
Sellami Asma, Directrice des Opérations Industrielles aux laboratoires Teriak, pour son
aide et ses conseils tout le long du stage , sa vision basée sur l’amélioration industrielle
continue a fait naître notre sujet du projet de fin d’études, -M. Gritli Hassène Maitre-
Assistant à l’ISTIC, pour la confiance qu’il nous a accordé pour son soutien inconditionnel
et surtout pour tout son dynamisme et ses compétences scientifiques qui nous ont permis
d’accomplir ce travail.
Un grand Merci également à Mme . Gouddi Amira, la Pharmacienne Responsable

Production pour sa collaboration ainsi que pour ses qualités professionnelles et humaines.
Nous remercions également M. El Gharbi Arbi, Responsable Informatique pour son

entière disponibilité, et sa générosité en matière de formation ainsi que son équipe.
Nous remercions tout particulièrement M. Samti Sofiene, Responsable Maintenance

Process, M. Smida Montassar, Assistant Maintenance Process, et toute l’équipe de la
maintenance pour nous avoir soutenus durant la période de notre projet et pour leurs
aides précieuses.
Nous tenons à remercier infiniment Mme . Ouederni Meriem, Ingénieur Améliora-

tion Continue, pour son professionnalisme, pour son soutien moral et pour l’ambiance très
motivante et encourageante que nous a apportée.
Nous tenons à remercier chaleureusement toute l’équipe de l’entreprise Teriak pour

leur esprit professionnel sans oublier de remercier toute l’équipe pédagogique de l’Institut
Supérieur des Technologies de l’Information et de la Communication pour l’aide théorique
et pratique qu’ils ont apporté pour le bon déroulement du stage.
Nos remerciements s’adressent également à monsieur le président et les membres du

jury pour avoir acceptés d’évaluer ce rapport avec l’espoir d’être à la hauteur de leurs
attentes.
Enfin, je remercie toutes les personnes qui ont contribué de près ou de loin à la réali-
sation de ce travail.
ii
TABLE DES MATIÈRES
Dédicaces i
Remerciements ii
Introduction Générale 1
1 Présentation des laboratoires TERIAK et analyse du projet 3

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation de l’organigramme d’accueil . . . . . . . . . . . . . . . . . . 3
1.2.1 Historiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Description du process de fabrication : . . . . . . . . . . . . . . . . 4
1.2.3 La progression dans Teriak . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Présentation de la ligne de production : blistéreuse + encartonneuse 8
1.3.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Spécification matérielle et logicielle du projet 13

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Choix des matériels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Choix des logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.1 ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.2 ARES vs Altium Designer . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.3 Arduino IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.4 LabVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.5 SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Spécification détaillée et conception de l’application informatique 24

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Méthodologies adoptées . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Analyse structurée (SA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1 Description de la méthode SA . . . . . . . . . . . . . . . . . . . . . 26
3.3.2 SA de la première application informatique de la carte d’interfaçage 26
iii
TABLE DES MATIÈRES
3.3.3 SA de la deuxième application informatique . . . . . . . . . . . . . 33

3.4 Conception UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . 36
3.4.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.3 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4 Réalisation pratique 40
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2 Prototype sur une plaque perforée . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Conception et réalisation de la carte d’interfaçage . . . . . . . . . . . . . . 43
4.3.1 Conception du PCB . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.2 Réalisation du circuit imprimé . . . . . . . . . . . . . . . . . . . . . 46
4.4 Conception et réalisation du circuit du module NRF côté récepteur avec
l’Arduino UNO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4.1 Saisie du schéma électrique . . . . . . . . . . . . . . . . . . . . . . . 48
4.5 Réalisation des trois applications informatique . . . . . . . . . . . . . . . . 50
4.5.1 Développement des programmes implémentés dans les microcontrô-
leurs Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.5.2 Application LabVIEW . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.5.2.1 L’architecture de la transmission de données de l’applica-
tion informatique . . . . . . . . . . . . . . . . . . . . . . . 53
4.5.2.2 Interaction avec l’application informatique . . . . . . . . . 56
4.6 Validation et suivi du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Conclusion Générale 64
Bibliographie 66
Annexes 67
A Détails de TRS 68
B Réalisation de la carte d’interfaçage 70
iv
TABLE DES FIGURES
1.1 Groupe fondateur des laboratoires Teraiak « Groupe KILANI » . . . . . . 4

1.2 Process de fabrication d’un médicament . . . . . . . . . . . . . . . . . . . 5
1.3 Schèma de principe de l’installation Trigénération . . . . . . . . . . . . . . 5
1.4 Réunion journalière de suivi des indicateurs de performance : -Méthode
QRQC- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Blistéreuse IMA1217 dans le local conditionnement primaire . . . . . . . . 8
1.6 Principaux cycles du travail de la blistéreuse IMA1217 . . . . . . . . . . . 9
1.7 Constitutions de la blistéreuse . . . . . . . . . . . . . . . . . . . . . . . . 10
1.8 Encartonneuse dans le local conditonnement secondaire . . . . . . . . . . 11
2.1 Schéma utilisation de l’optocoupleur . . . . . . . . . . . . . . . . . . . . . 15

2.2 Différentes étapes pour la transmission des informations . . . . . . . . . . . 16
2.3 Module de transmission de données radio NRF24L01 . . . . . . . . . . . . 17
2.4 Schéma électrique du régulateur LM317 sur ISIS . . . . . . . . . . . . . . 19
2.5 PC Tactile Lenovo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1 Schéma explicatif des trois applications informatiques du projet . . . . . . 25

3.2 Diagramme de contexte de l’application «Superviser ligne production côté
émetteur» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Diagramme de flots de données pour l’analyse du processus №0 . . . . . . . 28
3.4 Diagramme de contexte «Echanger Données Coté Récepteur» . . . . . . . 33
3.5 Diagramme de flots de données pour l’analyse du processus №4 . . . . . . . 33
3.6 Diagramme de cas d’utilisation de l’application LabVIEW . . . . . . . . . 36
3.7 Diagramme de classes de l’application LabVIEW . . . . . . . . . . . . . . 37
3.8 Diagramme de séquence de l’application LabVIEW . . . . . . . . . . . . . 38
4.1 Simulation de 3 entrées avec un transformateur 24V DC alimentés par une

alimentation 5V DC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Carte Arduino UNO avec le module NRF côté récepteur branchée au PC . 41
4.3 Prototype sur une plaque perforée avec 3 entrées de l’automate de la blis-
téreuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4 Le premier essai d’une interface LabVIEW avec la machine . . . . . . . . . 43
4.5 Schématique de la carte d’interfaçage réalisé par l’intermédiaire du logiciel
ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.6 Carte d’interfaçage prête . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
v
TABLE DES FIGURES
4.7 Carte d’interfaçage avec l’arduino Mega connecté . . . . . . . . . . . . . . 47

4.8 Conception mécanique à l’aide du SolidWorks et confection du boîtier pour
la carte d’interfaçage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.9 Schématique du circuit du module NRF côté récepteur avec l’Arduino UNO
par l’intermédiaire du logiciel ISIS . . . . . . . . . . . . . . . . . . . . . . 49
4.10 Circuit du module NRF soudé sur la plaque perforée installé sur Arduino
UNO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.11 Simulation de la carte d’interfaçage par le transformateur 24V DC . . . . . 51
4.12 Installation de la carte d’interfaçage avec l’automate de la blistéreuse . . . 52
4.13 Liaison locale des sources de données entre LabVIEW et SQL Server . . . 54
4.14 Création d’une source de données . . . . . . . . . . . . . . . . . . . . . . . 55
4.15 Liaison des sources de données entre LabVIEW et SQL Server réalisé sur
le serveur de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.16 Test de réception du rapport journalier Excel généré par LabVIEW . . . . 57
4.17 Alerte d’une panne envoyé par Email à l’équipe maintenance par notre
application LabVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.18 L’interface "Début du poste" . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.19 L’interface « Détail du lot » . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.20 L’interface « Arrêt » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.21 L’interface « Choisir un arrêt » . . . . . . . . . . . . . . . . . . . . . . . . 60
4.22 Insertion des informations sur la cause d’arrêt dans la base de données . . 60
4.23 L’interface "TRS" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.24 L’interface "Supervision" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.25 La page Web de notre application LabVIEW sur le PC et sur le téléphone 62
A.1 Arrêts IMA 1217 en pourcentage du premier trimestre 2019 . . . . . . . . . 68

A.2 Arrêts IMA 1217 en heures du premier trimestre 2019 . . . . . . . . . . . 69
B.1 Circuit imprimé de la carte d’interfaçage par Altium Designer . . . . . . . 70

B.2 Circuit imprimé de la carte d’interfaçage par ARES . . . . . . . . . . . . . 71
B.3 Top Layer du PCB par ARES . . . . . . . . . . . . . . . . . . . . . . . . . 72
B.4 Bottom Layer du PCB par ARES . . . . . . . . . . . . . . . . . . . . . . . 73
B.5 Le typon de la carte électronique sur une feuille transparente (Top Layer) . 74
B.6 Circuit imprimé réalisé (Top Layer) . . . . . . . . . . . . . . . . . . . . . 75
B.7 Circuit imprimé réalisé (Bottom Layer) . . . . . . . . . . . . . . . . . . . . 76
vi
LISTE DES TABLEAUX
2.1 Les différentes entrées de l’automate . . . . . . . . . . . . . . . . . . . . . 14

2.2 Relais électromécanique vs optocoupleur . . . . . . . . . . . . . . . . . . . 15
2.3 Caractéristiques du microcontrôleur Arduino Mega . . . . . . . . . . . . . 16
2.4 Modules Radio-Fréquences . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Les pins du circuit NRF24L01 . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 Altium designer vs ARES Proteus . . . . . . . . . . . . . . . . . . . . . . 21
2.7 Les différents types de SGBD . . . . . . . . . . . . . . . . . . . . . . . . . 23
vii
INTRODUCTION GÉNÉRALE
L’excellence opérationnelle est une démarche d’amélioration continue de toutes les or-
ganisations qui cherchent un changement durable. C’est un cheminement qui se focalise
sur l’optimisation du fonctionnement productif.
Les projets et les outils sont un bon point de départ, mais ils ne suffisent pas à at-
teindre cette excellence. En effet, l’ultime vision d’une entreprise est de maximiser sa
performance en production tout en minimisant les coûts. Cela est achevé par le biais de
l’optimisation et l’amélioration continues de son procès.
L’entreprise, généralement, se trouve dans l’obligation de satisfaire les impératifs :

qualité, coût et délais. Dans cette optique, elle doit mener des recherches à éliminer tous
les disfonctionnements qui figurent dans ses activités de production et dans ses opérations
industrielles.
La maîtrise et la considération des moyens d’amélioration s’avèrent donc capitales.

Cependant, avant de commencer la mise en œuvre d’outils, méthodes et démarches d’amé-
lioration, il est indispensable de comprendre le fonctionnement du système de production
en se basant sur des indicateurs industriels. Il faut également avoir une vision globale du
processus en dévoilant tous les indicateurs clés qui peuvent nous informer de la situation
de l’entreprise par rapport à ses concurrents et nous permet de tracer les axes de progrès
relatifs à la réalisation de notre projet.
Le stage de projet de fin d’études est le contact de l’étudiant avec le monde profes-
sionnel, cette phase est primordiale dans la formation car elle lui permet d’acquérir les
talents et les attitudes nécessaires à la satisfaction des exigences du marché de travail.
Dans cette perspective, nous avons réalisé notre projet au sein de l’entreprise (des labo-
ratoires) Teriak.
Actuellement, la méthode de travail de Teriak est totalement manuelle et il y a une

perte du temps inexplicable et est devenue un soucis journalier et aussi hebdomadaire. Es-
sentiellement, la productivité et le rendement sont mesurés à travers l’indicatenur "Taux
de Rendement Synthétique" (TRS). Toutefois, cet indicateur ne se concorde pas avec l’in-
dicateur des produits manufacturés de l’entreprise.
1
Introduction Générale
L’objectif du projet présent est de concevoir un système de supervision et d’indication

de tous les états d’une ligne de production qui servira à crayonner un tableau de marche
rigoureux afin de suivre son rendement industriel.
Ainsi, afin de réaliser le système de supervision, nous allons concevoir et réaliser une
solution électronique embarquée afin d’acquérir toutes les informations nécessaires. Cette
solution doit acheminer les données acquises de la ligne de production au PC et donc à l’in-
terface graphique de la supervision. En outre, afin d’avoir un historique et une traçabilité
des différents intervenants au niveau de la ligne de production, ces données requises, entre
autres, seront enregistrées dans une base de données. De plus, un autre objectif désiré est
de permettre au responsable de l’entreprise ou de la ligne de la production d’accéder à
distance à cette interface graphique afin de contrôler les indicateurs de production.
Dans l’intension d’aborder à la conception de ce système de supervision, nous essayerons
en premier lieu d’élucider l’état actuel de la ligne de production au regard des besoins
demandés par l’entreprise.
Ce rapport comporte quatre chapitres présentant la démarche suivie pour la mise au

point et l’organisation de notre mission. Le premier chapitre est consacré à la présentation
de l’organisme d’accueil, la progression des projets dans Teriak ainsi qu’à la description
du problème et du besoin de notre projet. Le second est réservé pour une spécification
matérielle et une autre logicielle. Le troisième chapitre a comme objectif la décomposition
de notre système en trois applications informatiques qui seront schématisées par la suite
en utilisant l’Analyse Structurée (SA) et le Langage de Modélisation Unifié (UML). Nous
clôturons ce rapport par la conception du circuit imprimé de la carte d’interfaçage, le
développement du côté logiciel de l’interface grahique de supervision et les étapes de
validation du projet selon les normes pharmaceutiques.
2
CHAPITRE 1
PRÉSENTATION DES LABORATOIRES TERIAK ET
ANALYSE DU PROJET
1.1 Introduction
Dans ce chapitre introductif, nous allons faire dans une première partie une descrip-
tion générale des laboratoires Teriak, son process de fabrication et ses principaux projets
exploités. Une étude de l’existant occupe une deuxième partie pour mettre en évidence
les besoins et la problématique que nous allons résoudre dans l’usine. Finalement, nous
proposerons le besoin afin de remédier aux différents problèmes identifiés.
1.2 Présentation de l’organigramme d’accueil

1.2.1 Historiques
Les Laboratoires TERIAK est une filiale du groupe KILANI. Ce groupe, fondé en 1986,
figure aujourd’hui parmi les acteurs majeurs du domaine de la santé, de la beauté et du
marketing en Tunisie. Il souhaite renforcer sa position dans les secteurs pharmaceutiques
cosmétiques et parapharmaceutiques et de consolider son développement à l’international
en particulier en Afrique et au Moyen Orient. Le schéma 1.1 illustre la stratégie exploitée
par le groupe à long terme.
Cette diversité des activités de ce groupe fait naître les laboratoires Teriak, un cata-
lyseur primordial de l’industrie pharmaceutique tunisienne, en 1996. TERIAK dispose de
trois sites de production. Les sites ont été entièrement conçus conformément aux normes
BPF (Bonnes Pratiques de Fabrication) et sont régulièrement audités par les bailleurs de
licence et les autorités de santé.
. Site Jebel Ouest (Tunisie) : formes sèches : comprimés, comprimés enrobés,
sachets de poudre, sachets de liquides, gélules, sirops secs, formes liquides, formes
pâteuses et suppositoires
. Site El Fejja (Tunisie) : Dry Powder Inhaler (DPI)
. Site Cinpharm (Cameroun, Douala) : formes liquides ; comprimés, comprimés
enrobés, sachets de poudre, sachets de liquides, gélules, sirops secs ; ainsi que les
formes β − lactames
3
CHAPITRE 1. PRÉSENTATION DES LABORATOIRES TERIAK ET ANALYSE
DU PROJET
Figure 1.1 – Groupe fondateur des laboratoires Teraiak « Groupe KILANI »
1.2.2 Description du process de fabrication :

Le site Jebel Ouest est localisé sur une superficie totale de 20 000 m2 dont 10 000 m2
surface construite. L’usine comporte :
♦ Zone de fabrication et de packaging (2 600m2 ),
♦ Magasin matières premières (600 m2 ),
♦ Magasin articles de conditionnement (400 m2 ),
♦ Magasin produits finis (700 m2 ),
♦ Laboratoire de contrôle (200 m2 ),
♦ Bureaux (1 600 m2 ),
♦ Zones et locaux techniques (3 900 m2 ).
La description générale des opérations de process est présentée dans le schéma 1.2.
1.2.3 La progression dans Teriak

Teriak est renommée par sa croissance continue grâce aux fortes expériences des pro-
jets. Si on met l’accent sur le dernier projet "Trigénération" : il a un coût d’investissement
de 2.5 milliards pour un gain de suite sur sa facture de consommation d’énergie de 40%
avec un temps de retour entre 4 et 5 ans.
La trigénération produit simultanément de l’énergie mécanique (souvent convertie en

électricité à l’aide d’un alternateur), de la chaleur et du froid. Elle peut être utilisée à des
fins de chauffage, climatisation, eau chaude sanitaire, etc. Le plan 1.3 montre son principe
de fonctionnement.
En outre, l’usine a opté pour l’éclairage une substitution des lampes par des lampes
LED à une même luminosité, faible consommation de puissance et durée de vie 10 fois
plus longue par rapport à l’existant. Les gains peuvent être de 50% du poste éclairage
qui représente environ 8% de la facture électrique. C’est un projet qui a déclenché l’année
dernière pour s’accomplir cette année.
4
DU PROJET
Figure 1.2 – Process de fabrication d’un médicament
Figure 1.3 – Schèma de principe de l’installation Trigénération
Pour les prochains projets qui sont déjà lancés, on trouve l’automatisation des lignes
de conditionnement primaire et secondaire :
— Pour les formes sèches : acquisition d’une compte pièces et bouchonneuse automa-
tique.
5
DU PROJET
— Pour les formes liquides : acquisition d’une ligne complète comprenant une étique-
teuse, une encartonneuse et une pose vignettes
En effet, l’objectif en cours de Teriak vise à élargir sa technologie afin d’atteindre la

4ème révolution d’aujourd’hui pour devenir "Teriak 4.0".
Afin de transformer les modes de communication, la production industrielle travaille à

parvenir une nouvelle dimension d’interconnecter la machine, le process et l’être humain
sans relier entre eux en temps réel. Il est la question de notre projet de fin d’études.
1.3 Cadre du projet

1.3.1 Etude de l’existant
Le Taux de Rendement Synthétique (TRS) est certainement un des indicateurs le plus
suivi dans l’entreprise. Son intérêt principal réside dans son pouvoir à illustrer une vision
synthétique et sévère de la performance, en un seul chiffre. [1] Chaque organisation peut
définir la méthode à le calculer selon la ligne de production.
Dans les Laboratoires Teriak, on trouve que le TRS se base sur la réactivité durable : le
QRQC (Quick Response Quality Control). Cet outil est un mode de management japonais
qui réduit de manière immédiate des anomalies de qualité rencontrées sur le terrain. Il a
été introduit en Europe et en France par l’industrie automobile dès le début des années
2000. [2]
La figure 1.4 met en évidence les principales caractéristiques de la réunion QRQC pour
qu’elle soit continue et efficace :
~ La réunion est déroulée sur le terrain afin de constater où se passent les problèmes,
pouvoir interroger les opérateurs et travailler avec eux. (la salle de réunion est
proscrite).
~ Faire le diagnostic avec toutes les données, produits, dossiers du lot,... On parle ici
des données mémorisées et des faits comme mentionné dans le tableau de la figure
1.4.
~ Au cours de la réunion, il faut prendre des réactions rapides et des mesures pré-
ventives et correctives dans le lendemain. (Exemple les actions de la figure 1.4)
~ Avoir un raisonnement structuré et logique pour trouver les causes racines par une
validation de tous les acteurs. Chacun prend sa part d’actions.
~ Le rôle de l’encadrement est de former, supporter, encourager et transmettre sur
le terrain. [3]
Depuis décembre 2018, cette méthode est appliquée dans deux lignes de production
IMA 1216 et IMA 1217. Chaque ligne occupe une blistéreuse, une encartonneuse, une
trieuse pondérale et une pose vignettes.
Les opérateurs jouent un rôle crucial dans l’action. Ils préparent un compte rendu chaque
jour pour le superviseur pour identifier les causes de chaque arrêt en mentionnant sa du-
rée. Ils indiquent les temps d’arrêts calculés manuellement. Ensuite, ce superviseur peut
faire le calcul de TRS avec les deux méthodes suivantes :
Quantité Produite
TRS1 = × 100
Temps d’Ouverture (TO) × Cadence
6
DU PROJET
Figure 1.4 – Réunion journalière de suivi des indicateurs de performance : -Méthode

QRQC-
Temps Utile (TU)

TRS2 = × 100
Temps d’Ouverture (TO)
Sachant que :
7
DU PROJET
./ Temps d’Ouverture = Temps total (24 heures sur une journée) - 2 heures (pause
d’une heure le matin et la nuit)
./ Cadence = Nombre de blisters par minutes
./ Temps Utile = Temps d’Ouverture - Somme des durées des arrêts déterminés par
l’opérateur
Si les opérateurs ont bien marqué les durées, on trouve que les deux résultats coïn-
cident. Ce n’est pas toujours le cas : chaque journée il y a des heures de sous-performances.
D’où vient la cause du problème qui se pose au cours de la réunion quotidienne de QRQC
qui dure 20 minutes maximum. Le but de ces réunions est de distinguer l’origine de la
non-qualité et proposer les plans d’actions à mettre en place afin de la corriger.
Une heure d’arrêt coûte chère pour l’entreprise. En janvier 2019, l’entreprise a perdu
61 heures de sous-performances (SP) qui est équivalent à quelques millions de dinars. Les
figures A.1 et A.2 de l’annexe A mettent en évidence ces zones d’ombres de la SP du mois
février et mars du premier trimestre de cette année en pourcentages et en heures.
1.3.2 Présentation de la ligne de production : blistéreuse + en-

cartonneuse
La ligne de production comporte :
— Une blistéreuse IMA 1217 TR130S (figure 1.5) qui est destinée au conditionnement
primaire des comprimés et des gélules et permet de réaliser l’opération de mise sous
blisters détaillée dans la figure 1.6.
Figure 1.5 – Blistéreuse IMA1217 dans le local conditionnement primaire
8
DU PROJET
Figure 1.6 – Principaux cycles du travail de la blistéreuse IMA1217
La décomposition de la blistéreuse est illustrée dans la figure 1.7.
Elle est composée :

1. D’une unité de thermoformage,
2. D’une trémie d’alimentation en comprimés / gélules (bol vibrant rotatif) per-
mettant l’alimenation du film thermoformé à travers une unité des canaux de
descente,
3. D’une unité de thermo scellage,
4. D’un module de marquage des blisters,
5. Module de découpe des blisters,
6. Et d’un terminal de commande de la blistéreuse.
9
DU PROJET
Figure 1.7 – Constitutions de la blistéreuse
— Une encartonneuse (figure 1.8) qui est destinée au conditionnement secondaire

et permet la mise en forme des étuis et des boîtes pliantes prédécoupées pour y
introduire la notice et le(s) blister(s) à emballer.
1.3.3 Solution proposée

Chaque entreprise vise la gestion du temps comme un enjeu stratégique pour une
source d’optimisation de la performance et du gain temporel.
10
DU PROJET
Figure 1.8 – Encartonneuse dans le local conditonnement secondaire
Dans ce cadre vient notre projet : conception, réalisation et mise en place d’un sys-
tème de suivi de performance d’une ligne de production IMA 1217. A distance, celui qui
a l’accès de contrôle peut savoir l’état des machines, le TRS, la cause d’arrêt, la quantité
produite, la quantité éjectée, etc. Ainsi, les responsables peuvent intervenir rapidement à
n’importe quel moment dans la journée pour la prise de décision des actions. Cela met en
relief l’objectif principal de la méthodologie QRQC qui sert à réagir le plus rapidement
possible à un problème et de traiter les failles de production dès leur apparition.
L’industrie cherche à digitaliser les équipements de production et éliminer les écritures
manuscrites sur un document papier : ,→ Les opérateurs effectuent des saisies informa-
tiques.
Par conséquent, notre application doit offrir une session pour l’opérateur pour la tra-
çabilité des renseignements à propos le lot (désignation, numéro, température de scellage,
...) et de choisir la cause de l’arrêt si elle est provoquée par lui-même. A l’avenant, l’ap-
plication doit fournir l’enregistrement du début et de la fin de poste de chacun d’eux.
En outre, ce qui concerne le gain de temps en cas d’une panne, il suffit d’avertir l’équipe
maintenance à travers un bouton de l’interface réalisée.
11
DU PROJET
Les évènements, les actions opérateur et les quantités produites sont automatiquement
sauvegardés dans une base de données qui est hébergée dans le serveur de Teriak et ac-
cessible pour consulter les historiques.
Notre système aura l’initiative d’émettre des rapports journaliers de fonctionnement

par email.
1.4 Conclusion
Après avoir une idée sur l’entreprise et découvrir ses historiques, son process de fa-
brication et ses différents projets, on a présenté le cadre de notre projet en mentionnant
une étude de l’existant pour analyser les besoins, et par la suite trouver une solution. Le
chapitre suivant englobe une spécification détaillée du système où nous ferons le choix des
matériels et des logiciels.
12
CHAPITRE 2
SPÉCIFICATION MATÉRIELLE ET LOGICIELLE DU
PROJET
2.1 Introduction
Après avoir détailler le cahier des charges du projet dans le premier chapitre, nous
allons effectuer une spécification des matériels et des logiciels. Cette sélection sera argu-
mentée par des critères bien déterminés.
2.2 Choix des matériels

Dans la ligne de production, il y a deux types d’arrêt : soit propre à la machine, soit
provoqué par l’opérateur. En se basant sur le compte rendu EXCEL du mois Janvier,
Février et Mars 2019 de notre ligne de production, on fait ressortir les arrêts les plus
fréquents. Pour le premier type d’arrêt qui est propre à la machine, à l’aide du manuel
d’instructions TR130 S de la machine à blisters, nous avons souligné les entrées de l’au-
tomate qui nous donne les causes voulues ainsi que le capteur des blisters conformes et
l’électrovanne des blisters éjectés. Pour le deuxième type d’arrêt, on détecte l’immobilité
de la machine par le bouton appuyé d’arrêt en phase. Mais la cause sera éditée par l’opé-
rateur à travers l’application. Il va trouver cinq groupes (arrêt induit, arrêt programmé,
arrêt propre, non-qualité et manque charge) suivis des sous-groupes chacun. Il suffit qu’il
choisisse. Dans notre système AC1 représente l’automate maître et AC2 son esclave.
Le tableau 2.1 mentionne tous les signaux nécessaires pour notre système.
Chaque machine de la ligne de production fonctionne avec une tension de commande
24 V DC fournie par le transformateur. Notre microcontrôleur est alimenté avec 5 V DC.
Il faut trouver un composant qui transmet le signal de l’automate au système sans qu’il
y ait de contact galvanique entre eux. On parle dans ce cas de l’isolation galvanique ou
électrique. Ce rôle se confond avec la fonction d’un optocoupleur. Il est formé d’une LED
et d’un phototransistor ou une photodiode. Quand le courant circule dans la LED, elle
brille (émet de l’infrarouge) dans un boitier bien hermétique à la lumière. Ce signal op-
tique émis est reçu par un phototransistor qui ferme alors le circuit de sortie. [4]
13
CHAPITRE 2. SPÉCIFICATION MATÉRIELLE ET LOGICIELLE DU PROJET
Table 2.1 – Les différentes entrées de l’automate

Localisation du signal Fonction
I09, AC1 +24V DC impulse Présence blister conforme
Vérification des états des entrées de l’automate
I31, AC2 24V DC Arrêt de l’encartonneuse

I27, AC2 24V DC Manque de l’air comprimé
I12, AC2 24V DC Couvercle ouvert
I04, AC2 +24V DC Alarme zéro encodeur
I18, AC2 24V DC Variateur bloqué
I15, AC1 24V DC Produit hors alvéole
I13, AC2 24V DC Déclenchement thermique
I04, AC1 24V DC Arrêt d’urgence
I26, AC2 24V DC impulse Fin film de formage
I25, AC2 24V DC Fin film aluminium
I08, AC2 24V DC Rouleau de scellage Hors position
Cause de l’arrêt provoqué par l’opérateur :
Q07, AC1 24V DC impulse Bouton arrêt en phase
Q11, AC1 +24V DC impulse Bouton mise en marche
Electrovanne Q03, AC2 DC Blister éjecté
Par contre, dans l’industrie, on trouve l’utilisation fréquente des relais électroméca-
niques. Ces organes électriques permettent l’ouverture et la fermeture d’un circuit élec-
trique par un second circuit complètement isolé (bien évidemment c’est l’isolation galva-
nique). Mais il est différent par rapport à l’optocoupleur. Le tableau comparatif 2.2 est
pour décider le meilleur choix.
C’est pour ces raisons, nous avons choisi de travailler avec des optocoupleurs. Plus
précisément avec le type 4N35 qui est caractérisé d’un taux de transfert minimal (CTR)
100%
avec
courant sortie dans le transistor
CTR =
courant dans la LED
Il faut que le courant d’entrée soit faible pour trouver le même courant à la sortie. Ça
dépend du choix de la résistance R1.
U = 24Volts = R × I
⇐⇒ R = 2.2KOhm → I = 11mA.
La figure 2.1 illustre le schéma électrique d’un optocoupleur sur l’ISIS.
On trouve une diode pour la protection de la LED de l’optocoupleur et une résistance
10 KOhms pour la sécurité du son phototransistor. Nous détaillerons par la suite dans ce
rapport la réalisation du circuit imprimé.
14
Table 2.2 – Relais électromécanique vs optocoupleur

Critères Relais électromécanique Optocoupleur
Taille Encombrement mécanique Assez petit mais efficace
Rapidité la rapidité de la mise en Commuter plus rapidement
contact franc, dépend du courant et permettre une vraie
de commande circulant dans séparation électrique
la bobine.
Les deux circuits sont couplés
Mobilité Des éléments sont en mouvement. Pas d’usure
Usure de contact
Courant 1A Quelques mA
Durée de vie Faible Indéterminé
Coût 8.100 TND 0.500 TND
Figure 2.1 – Schéma utilisation de l’optocoupleur
Nous avons choisi ATMega 2560 comme microprocesseur. D’emblée, l’idée était de
créer notre propre microcontrôleur à base de microprocesseur adéquat mais nous avons
trouvé que ce dernier n’est pas vendu dans le marché tunisien.
En continuant notre recherche nous avons constaté que l’Atmega est le cœur de l’Ar-
duino, en particulier Arduino Mega qui est disponible, facile à programmer et nous pou-
vons l’interfacer avec d’autres circuits, ce qui est convenable dans notre cas. Finalement
avec Arduino Mega nous n’aurons besoin que d’un outil de développement.
Le tableau 2.3 montre les caractéristiques envisagées pour notre carte.

A peu près, nous avons marqué toutes les fonctions exigées par notre application. Mais
si on compare son prix à 70 TND avec notre première solution de créer une, elle sera bien
évidemment plus chère.
En ce qui concerne le langage de programmation, il suffit qu’on maitrise le C ou le

C++ pour le développement. En outre, Arduino offre des références du langage ouvert et
de nombreuses librairies disponibles.
15
Table 2.3 – Caractéristiques du microcontrôleur Arduino Mega

Microcontrôleur ATMega2560
Alimentation externe Connexion à travers une alimentation
à découpage 5V
Bus de communication SPI pour alimenter NRF24L01
Mémoire Flash 256kB,Stocker les programmes à exécuter
Mémoire SRAM 8KB, Stocker les données temporaires
(mémoire volatile)
Mémoire EEPROM 4KB, Stocker des données persistances
(mémoire non volatile)
54 broches numériques Notre système nécessite 24 pins
d’entrées/sorties
Gestion des interruptions Pour le capteur de quantité produite,
la cadence peut atteindre 150 blisters/minute
Intensité par entrées/sorties 40mA
Cadencement 16MHz
Pour la transmission de données, l’information suit les différentes étapes illustrées par
la figure 2.2.
Figure 2.2 – Différentes étapes pour la transmission des informations
L’envoi des données peut être une communication série entre le premier microcontrô-
leur et le PC à travers un câble USB sans avoir besoin des autres composants présentés
dans le schéma. Mais, cette solution n’est pas pratique pour les opérateurs et elle pose un
encombrement au niveau de son placement. C’est pourquoi, nous avons concentré sur le
deuxième type de communication qui se base sur des modules radiofréquences.
Pour le choix de cette méthode sans fils, les principales caractéristiques qu’il faut
considérer sont :
— La consommation d’énergie
— Etendu d’un réseau
— Débit de données
16
Table 2.4 – Modules Radio-Fréquences
Protocole Zigbee Bluetooth Wifi NRF24L01

IEEE 802.15.4 802.15.1 802.11a/b/g -
Autonomie avec pile Années Jours Heures Années
Nombre de nœuds 250 Kbps 1 Mbps 11 – 54 – 108 Mbps 2 Mbps
Portée 100 m 10 – 100 m 300 m 100 m
Prix 100 TND 30 TND 25 TND 13 TND
(Emetteur/Récepteur )
Après avoir une idée sur les différents standards possibles à notre application, nous
essayons de faire un tableau 2.4 de comparaison récapitulatif afin de pouvoir faire le choix
le plus judicieux.
Le choix d’une technologie dépend des services proposés, ainsi que nos besoins du ré-
seau. Notre système demande un compromis entre le débit, la consommation d’énergie et
le coût.
Quoique le ZigBee est à faible consommation énergétique dans le réseau, son débit est
faible (250 Kbits/s maximum) et cela provoque des délais importants.
Le Bluetooth établit une connexion sécurisée de proximité. Bien que cela puisse appa-
raître comme une des limites de ce protocole : le transfert de données ne pourrait se faire
que sur de faible distance, il faut que les appareils soient proches les uns des autres.
Tandis que le Wifi est totalement écarté puisqu’il utilise un réseau avec une large
bande passante et par conséquent requiert beaucoup d’energie.
Ce qui nous laisse choisir le NRF24L01 qui permet un bon compromis entre le débit,
la consommation et le coût qui est bien plus faible que les autres.
La famille NRF24 du constructeur norvégien Nordic Semiconductor regroupe des puces

utilisant la bande de 2.4 GHz. Dans cette famille, le chipset NRF24L01, mentionné dans
la figure 2.3, connaît un succès important. [5]
Figure 2.3 – Module de transmission de données radio NRF24L01
17
Table 2.5 – Les pins du circuit NRF24L01

Pin Nom Fonction Description
1 GND Alimentation 0 V
2 VCC Alimentation 1.9 V à 3.6 V DC
3 CE Entrée Chip Enable permet de sélectionner
le mode RX ou TX
4 CSN Entrée SPI Chip Select (Chip Select Not)
ce pin est normalement en état bas
pour activer le bus SPI du module
5 SCK Entrée SPI Clock
6 MOSI Entrée SPI Slave Data Input
7 MISO Sortie SPI Slave Data Output
8 IRQ Sortie Interrupt pin. Active en état bas
Le NRF24L01 offre une communication radio accessible via une interface SPI stan-
dard. Le module dispose d’une antenne incorporée (visible en zigzag sur le circuit) et un
débit pouvant aller jusqu’à 2Mbps avec une consommation de 13.5 mA. La distance qui
sépare l’émetteur au récepteur est à 10 mètres sans prendre en considération les obstacles
dans la salle de production, 100 mètres répond donc à nos besoins.
Le module dispose aussi :

— d’un régulateur 3.3 V DC acceptant des tensions de 3.3 V DC à 7 V DC
— d’une antenne céramique 2.4GHz
— des pins : VCC, CE, CSN, SCK, MOSI, MISO, IRQ, GND
Le tableau 2.5 illustre les détails de ces différentes pins.
Nous avons besoin d’un régulateur de tension pour abaisser 5 V DC de l’arduino jus-
qu’à 3.3 V DC pour l’alimentation du module. C’est le rôle de LM317. C’est un régulateur
série à 3 pattes capable de fournir 1.5 A sur une tension de sortie qui va de 1.25 V DC
à 37 V DC. Il a comme des broches Vout : sortie (relié au boitier), VIN : entrée, ADJ :
patte d’ajustement. Le câblage est présenté dans le schéma 2.4
Les règles à prendre en considération :

— La tension de sortie vaut :
R2
1.25V × (1 + )
R1
— R1 ne doit pas dépasser 240 Ohms pour garantir au moins 5 mA de courant de
sortie. Si cela n’est pas respecté, la tension de sortie devient plus élevée et n’est
plus régulée.
18
Figure 2.4 – Schéma électrique du régulateur LM317 sur ISIS
Pour arriver au PC, le NRF24L01 reçoit les données de l’émetteur pour les lire avec un
deuxième microcontrôleur afin de pouvoir les visualiser. En mettant en relief une autre
caractéristique de l’Arduino, on constate qu’elle offre une variété des différents modèles
des cartes à différentes fonctions :
— Arduino Mega
— Arduino Nano
— Aruino UNO
— Arduino USB
— Ect
L’Arduino UNO de cœur ATmega328 est suffisant pour atteindre l’objectif puisqu’elle est
branchée seulement avec le module de communication récepteur. Elle va jouer le rôle d’es-
clave par la communication série avec le PC. L’application comme étant maître interroge
l’arduino et dans ce stade cette dernière envoie les messaages reçus.
A ce niveau, nous avons réfléchi à une interface Homme-Machine que l’opérateur va

réagir avec elle. Dans un premier stade nous avons cherché des tablettes industrielles mais
Teriak nous a proposé ce PC dans la figure 2.5. Il l’utilise dans des différentes applications.
Ce PC est caractérisé par un écran 21.5" ; LCD Tactile, un processeur Intel core i3-
4160T, 3.1 GHz, 3 Mo de mémoire cache, Mémoire 4 Go, Disque 500 Go, Carte Graphique
Nvidia Geforce 800M, 1Go de mémoire dédiée, graveur DVD, lecteur de carte - Wifi -
HDMI - Webcam integrée, audio Dolby, clavier, Souris USB. Son coût est de l’ordre de
1 400 TND.
Il sera encastré par la suite dans le panneau du local de la blistéreuse.
Il n’existe pas aujourd’hui de solution idéale, mais plutôt une combinaison qui permet
de répondre aux besoins.
19
Figure 2.5 – PC Tactile Lenovo
2.3 Choix des logiciels

2.3.1 ISIS
On commence la partie des logiciels de notre système par l’ISIS qui nous a permis
d’éditer des schémas électriques et les simuler afin de détecter s’il y a certaines erreurs
dès l’étape de conception.
ISIS appartient à une suite du logiciel "Proteus" qui est développée par la société Labcenter
Electronics. Ces logiciels permettent la conception assistée par ordinateur (CAO) dans le
domaine électronique. [6]
2.3.2 ARES vs Altium Designer

ARES représente l’un des logiciels principaux de Proteus. Celle-ci permet d’importer
facilement le schéma réalisé sur ISIS pour en réaliser le Printed Circuit Board (PCB) de la
carte électronique. Il suffit qu’on choisit l’emplacement convenable de chaque composant,
on peut commencer le routage soit automatique soit manuel.
Il existe de nombreux logiciels de CAO parmi lesquels Altium Designer aussi. Ce der-
nier a la capacité d’utiliser des nombreuses bibliothèques des composants, de réaliser un
prototype grâce aux différents outils et de créer des modèles 3D très précis d’assemblage
des circuits imprimés et d’exporter cela sous un format standard de l’industrie de telle
manière d’être certains que le circuit imprimé va s’insérer dans le châssis mécanique dès
le premier essai.
Au début nous avons choisi de travailler avec Altium Designer. Mais lorsque le plan
rencontre la réalité, nous avons envisagé des contraintes avec Altium.
Le tableau 2.6 souligne ces difficultés par rapport à ARES.
20
Table 2.6 – Altium designer vs ARES Proteus
Contraintes Altium Designer ARES

Si la connexion virtuelle entre Le retour à la schématique Après la modification
2 composants connectés n’est invoque la récréation d’un convenable, il suffit de faire
pas établie entre leurs pads. nouveau document PCB pour l’enregistrement dans l’ISIS
⇒ Il faut vérifier la refaire tous les étapes de puis passer à l’ARES et
schématique nouveau. l’interconnexion sera corigée.
et la corriger.
Après le placement des Les dimensions de la carte sont La taille de la carte est
composants, on constate qu’il configurés une seule fois rectifiée selon le choix.
faut élargir la carte. au début. Pour les modifier,
il faut créer un nouveau
document PCB.
2.3.3 Arduino IDE

Arduino est un IDE qui rend en charge une vaste gamme de cartes Arduino, dans
notre cas Uno et Mega afin d’écrire, compiler et téléverser le programme. Les langages
universels pour Arduino sont le C et le C ++.
Des fonctionnalités telles que la coloration syntaxique, l’indentation automatique et la
correspondance d’accolades en font une alternative moderne aux autres IDE.
2.3.4 LabVIEW
Pour le développement de notre application, nous devons choisi un environnement
convenable qui assure son bon fonctionnement. Les logiciels les plus utilisés pour la créa-
tion des interfaces Homme- Machine sont :
— Microsoft Visual Studio : est un environnement de développement intégré (IDE)
de Microsoft. Il permet de développer des applications pour Android, iOS, MAC,
Windows, le web et le cloud à travers un langage de programmation textuelle.
— LabVIEW : Laboratory Virtual Instrument Engineering WorkBench est un logiciel
conçu pour accélérer le développement de toute application de test, de mesure ou
de contrôle/commande à travers un langage de programmation graphique.
Il est à noter que ces deux logiciels sont capables de répondre aux exigences de l’inter-
face Homme-Machine. Alors que nous avons constaté que LabVIEW sera le choix le plus
convenable puisqu’il a surmonté le Microsoft Visual Studio dans l’intégration matérielle
extensive et rapide disponible, aussi bien pour les instruments sur table et les cartes d’ac-
quisition de données sur PC, que pour les radios logicielles et les ordinateurs embarqués
à base de FPGA.
— LabVIEW est une plate-forme de National Instruments (NI) éprouvée depuis plus
de 25 ans et devenue une norme dans l’industrie.
— La programmation graphique de LabVIEW offre la possibilité de programmer en
suivant le fil des idées en utilisant une méthode similaire à un organigramme –
appelée représentation graphique du flux de données- pour déplacer les données
d’une fonction à l’autre.
21
— LabVIEW recompile son code à chaque action de votre part, ce qui signifie que
vous pouvez détecter et corriger les erreurs de codage au fur et à mesure qu’elles
surviennent plutôt que d’avoir à compiler votre code avant de pouvoir les corriger.
— LabVIEW représente naturellement le parallélisme dans le code, et sa nature gra-
phique permet de le visualiser facilement.
— Les utilisateurs peuvent surveiller et contrôler à distance des applications embar-
quées grâce aux services Web offerts par LabVIEW.
2.3.5 SQL Server

L’application LabVIEW va insérer des informations à la base de données à chaque
fois l’opérateur interagit avec l’application ou en cas d’acquésition du système d’un signal
d’un arrêt propre à la machine afin d’enregistrer les types, les causes et les durées des
arrêts. De plus, notre application/interface Labview doit donner la possibilité pour insérer
des informations pour chaque lot et chaque début et fin du poste de l’opérateur.
On doit utiliser un langage de requête qui est un langage informatique et un Système

de Gestion de Base de Données (SGBD). Notre base de données est de type relationnel,
c’est à dire l’information est organisée dans des tables et chaque table comporte des plu-
sieurs types de données.
Il existe cependant de nombreux types de SGBD sur le marché, offrant chacun leurs
propres avantages et inconvénients.
Le tableau 2.7 représente une étude comparative entre eux.
Si nous faisons une synthèse de choix, l’oracle est le plus complet mais le moins évident
à utiliser puisque c’est inutile d’acheter une licence oracle pour un projet de petite taille.
De plus, ces performances ne seront pas bien différentes de celle de MySQL et SQL Server.
D’autre part, nous n’avons pas besoin de Microsoft Access pour faire une conception d’une
interface graphique. SQL Server est bien évidemment le logiciel avec lequel la prise en main
est facile et rapide. C’est le choix le plus raisonnable et le plus adapté à nos besoins.
2.4 Conclusion
Ce chapitre est consacré pour le choix des matériels et des logiciels que nous avons
utilisé pour notre système informatisé.
Dans le chapitre suivant, nous allons faire une conception UML et une analyse structurée
pour une vision et une spécification plus détaillées du projet.
22
Table 2.7 – Les différents types de SGBD
Microsoft - Destiné au grand public et aux Petites Moyennes Entreprises (PME)

Access - Simple d’utilisation, dispose d’une interface graphique conviviale
- Budget beaucoup plus faible que les autres SGBDR puisque Access
est livré avec Microsoft Office pour Windows en standard
- Peu performant pour les bases très volumineuses car non adapté
à ces dernières et ne permet pas de créer des applications
multiplateformes car il n’est compatible qu’avec les systèmes
d’exploitation Microsoft.
Microsoft -Destiné à des applications beaucoup plus volumineuses et complexes,
SQL Server SGBDR beaucoup plus professionnelle qu’Access
- Possède de fonctions client/serveur évoluées lui permettant
ainsi d’être utilisé dans de grosses infrastructures informatiques
- Peut facilement être interfacé avec les principaux langages
de programmation comme le C++,l’ASP notamment grâce à la suite
Visual Studio destinée aux développeurs.
MySQL -MySQL est une base de données Open Source, c’est à dire qu’elle
est totalement gratuite et qu’elle donne la possibilité aux développeurs
expérimentés de la modifier à volonté pour étendre ses capacités.
- Ce SGBDR est donc destiné à tout public, sauf pour les grosses
infrastructures à cause de son manque de maturité
- MySQL est très simple d’utilisation
Oracle -Oracle est le maitre des bases de données, il est le SGBDR le plus
abouti et utilisé dans les grosses entreprises notamment grâce à sa
fiabilité sur des bases très volumineuses.
- Mais il est payant
23
CHAPITRE 3
SPÉCIFICATION DÉTAILLÉE ET CONCEPTION DE
L’APPLICATION INFORMATIQUE
3.1 Introduction
Après avoir présenté la spécification des matériels et des logiciels à utiliser dans le
deuxième chapitre, nous allons planifier le travail. Cette phase primordiale du projet est
la conception. Elle envisage une modélisation du système avant sa réalisation et assure
la bonne compréhension de son fonctionnement. Nous allons réaliser dans ce chapitre
une spécification de notre application informatique en utilisant la méthode de l’analyse
structurée (Sturcture Analysis SA) et aussi en adoptant le langage de modélisation l’UML
(«Unified Modeling Language»).
3.2 Méthodologies adoptées

Notre système de supervision et de contrôle de la production comporte 3 applications
informatiques comme mentionné dans le schéma 3.1 :
1. Un programme implémenté dans le microcontrôleur Arduino Mega qui représente
l’émetteur dans notre carte d’interfaçage pour l’acquisition des données de l’auto-
mate.
2. Un programme implémenté dans le microcontrôleur Arduino UNO qui reçoit les
données du module NRF récepteur et les envoie à travers un câble USB au PC.
3. L’application LabVIEW qui sera dédiée à la supervision de la ligne de production.
Pour élaborer la spécification détaillée et la conception des deux premières applica-

tions au niveau des deux microcontrôleurs Arduino, nous allons choisir la méthode SA.
En revanche, pour la troisième application informatique LabVIEW, nous allons adopter
le langage UML.
En fait, nous pouvons utiliser la même méthode pour les trois parties de notre pro-
jet, mais la modélisation des données peut être dessinée sous différentes perspectives plus
approfondies selon les vues que le constructeur veut transmettre aux utilisateurs du sys-
tème.
24
CHAPITRE 3. SPÉCIFICATION DÉTAILLÉE ET CONCEPTION DE
Figure 3.1 – Schéma explicatif des trois applications informatiques du projet
En effet, les deux programmes (1) et (2) des microcontrôleurs sont inexploitables par
l’opérateur. En revanche ce dernier joue un rôle crucial dans l’application LabVIEW (3).
Donc, on doit choisir une conception qui définit clairement ses fonctionnalités à effec-
tuer. C’est une caractéristique de la modélisation UML qui est étroitement lié au dégré
d’intervention des acteurs.
25
3.3 Analyse structurée (SA)

3.3.1 Description de la méthode SA
L’analyse structurée d’un système définit l’ensemble des moyens, des procédures et
des structures permettant de développer et réaliser les fonctionnalités depuis une étude
détaillée du projet. [7] Cette méthode graphique est structurée de manière hiérarchique
descendante, par raffinements successifs des processus. Elle comporte 4 parties :
— Diagramme de Contexte DC : Niveau le plus haut qui est accordé à l’interac-
tion du système avec l’environnement.
— Diagramme de Flots de Données DFD : Niveau plus inférieur qui est la décom-
position du diagramme du contexte à des processus fonctionnels complémentaires,
en respectant les flots de données entrants et sortants. Les processus obtenus sont
appelés des processus primitifs, qui sont en fait non décomposables.
— Dictionnaire de Données DD : précise la définition des flots de données (dési-
gnation, rôle, type et domaine).
— Spécification des processus primitifs : Chaque procesus dans le DFD est spé-
cifié par un algorithme simple ayant pour but de préciser comment les sorties sont
produites à partir des entrées. De plus, cet algorithme sera traduit par le program-
meur (qui est moi dans ce projet) au langage désiré (qui est le C pour l’Arduino)
à implémenter.
3.3.2 SA de la première application informatique de la carte

d’interfaçage
D’emblée, nous nous intéressons à l’analyse structurée de la première application infor-
matique de la carte d’interfaçage qui lie l’automate au module NRF Émetteur. L’objectif
est alors d’introduire les chemins des signaux de l’automate jusqu’à atteindre le module
NRF côté émetteur.
¶ Diagramme de contexte
Le Diagramme de Contexte (DC) de la figure 3.2 traduit la première étape de la méthode

de spécification SA.
Le processus №0 traduit l’application à réaliser : « Superviser ligne production Côté

Emetteur ». Autour de ce processus fonctionnel, un ensemble des éléments modélise les
cheminements du flot de données sous formes des arcs orientés et des rectangles pour
les entités externes du système. Ces entités sont matérielles dans notre cas : les capteurs
inductifs, l’électrovanne, les boutons poussoirs et les différentes entrées de l’automate.
Le type, le domaine et le rôle de chaque donnée seront désignés dans le Dictionnaire de
Données (DD) par la suite.
26
Figure 3.2 – Diagramme de contexte de l’application «Superviser ligne production côté

émetteur»
· Diagramme de flots de données
Le Diagramme de Flots de Données (DFD) de la figure 3.3 est la décomposition du

diagramme du contexte. Il représente la liste des processus fonctionnels nécessaires à l’ap-
plication avec les flots de données correspondants.
— Le processus fonctionnel (1) permet l’acquisition des entrées venant de la blistéreuse

(blister conforme, blister éjecté, arrêt propre à la machine, arrêt opérateur, signal
marche).
— Le processus fonctionnel (2) permet l’acquisition du signal du capteur inductif de
l’encartonneuse pour détecter la sortie d’une boîte conforme.
— Le processus fonctionnel (3) permet le traitement des données reçus (entrées blisté-
reuse et boîte) où on teste l’état de la machine, trouve la cause d’arrêt et compte la
quantité produite des blisters conformes, le nombre des blisters éjectés et le nombre
des boîtes produites chaque minute.
⇒ Ces trois processus fonctionnels qui sont primitifs (non décomposables) traduisent
les fonctions que nous allons les programmer pour notre première application infor-
matique. L’algorithme définissant la fonction de chaque processus sera décrit dans
la partie "Spécification des processus primitifs".
27
Figure 3.3 – Diagramme de flots de données pour l’analyse du processus №0
28
¸ Dictionnaire de données
1. Blister conforme : signal entrée

. Rôle : signal logique fourni par le capteur inductif de la blistéreuse
. Type : entier sur 1 bit
. Domaine : 0/1
2. Blister éjecté : signal entrée

. Rôle : signal logique fourni par l’électrovanne
. Domaine : 0/1
3. Arrêt propre à la machine : signal entrée

. Rôle : signaux logiques des causes d’arrêt propre à la machine (blistéreuse) :
arrêt de l’encartonneuse, manque de l’air comprimé, couvercle ouvert, alarme
zéro encodeur, variateur bloqué, produit hors alvéole, déclenchement thermique,
arrêt d’urgence, fin film de formage, fin film aluminium et rouleau de scellage
hors position
. Type : T[12] des entiers sur 1 bit chacun
. Domaine : T[12]
4. Arrêt opérateur : signal entrée

. Rôle : signal logique fourni par le bouton d’arrêt en phase de la machine
. Domaine : 0/1
5. Signal marche : signal entrée

. Rôle : signal logique fourni par le bouton mise en marche
. Domaine : 0/1
6. Boîte conforme : signal entrée

. Rôle : signal logique fourni par le capteur inductif de l’encartonneuse
. Domaine : 0/1
7. Entrées Blistéreuse : flot de données interne

. Rôle : signaux venant de la blistéreuse pour les traiter par le processus №3
. Type : tableau des entiers sur 1 bit chacun
. Domaine : T[6]
8. Boîte : flot de données interne

. Rôle : signal venant de l’encartonneuse pour mentionner la présence ou non de
la boîte au processus №3
. Domaine : 0/1
29
9. Marche : signal sortie

. Rôle : état de la machine, si le signal vaut 0 la machine en arrêt sinon la
machine est en marche
. Domaine : 0/1
10. Description d’arrêt : signal sortie

. Rôle : message pour distinguer la cause de l’arrêt s’il est propre à la machine
ou provoqué par l’opérateur.
. Type : chaîne de caractères
. Domaine : Ch[9]
11. Nombre blisters conformes : signal sortie

. Rôle : nombre de quantité produite par minute
. Type : entier sur 8 bits
. Domaine : [0.. 28 -1]
12. Nombre blisters éjectés : signal sortie

. Rôle : nombre de blisters éjectés par minute
. Domaine : [0.. 28 -1]
13. Nombre boîtes produites : signal sortie

. Rôle : nombre de boîtes produites par minute
. Domaine : [0.. 28 -1]
14. Quantités : signal sortie

. Rôle : message qui englobe le nombre de blisters conformes et éjectés et les
boîtes produites par minute
. Domaine : ch[50]
¹ Spécification des processus primitifs
Les processus primitifs doivent être spécifiés textuellement.
♦ Processus fonctionnel : Acquérir les entrées de la blistéreuse (№1)

Entrées : Blister conforme, Blister éjecté, Arrêt propre à la machine, Arrêt opé-
rateur, Signal marche
Sorties : Entrées Blistéreuse
Nécessité (T[12]= {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0} ; indice_cause_arret =20,

i=0 ; Entrées Blistéreuse[6] ={0, 0, 0, 0, 0, 0})
Description :
30
Début
Faire toujours
{ Acquérir Blister conforme
Acquérir Blister éjecté
Acquérir Arrêt propre à la machine
Répéter
{ si (i == 1) alors
indice_cause_arret = i ;
i++ ;
} jusqu’à ((i>12) || (indice_cause_arret != 20))
Acquérir Arrêt opérateur

Acquérir Signal marche
Entrées Blistéreuse[0] = Blister conforme ;
Entrées Blistéreuse[1] = Blister éjecté ;
Entrées Blistéreuse[2] = Arrêt propre à la machine ;
Entrées Blistéreuse[3] = Arrêt opérateur ;
Entrées Blistéreuse[4] = Signal marche ;
Entrées Blistéreuse[5] = indice_cause_arret ;
Envoyer Entrées Blistéreuse vers le processus №3
}
Fin
♦ Processus fonctionnel : Acquérir la présence de la boîte dans l’encartonneuse (№2)

Entrées : Boîte conforme
Sorties : Boîte
Nécessité (Boîte = 0 ;)
Description :
Début
Faire toujours
{ Acquérir Boîte conforme
Si (Boîte conforme ==1)
{ Boîte =1 ;
}
Sinon Boîte = 0 ;
Envoyer Boîte vers le processus №3 ;
}
Fin
31
♦ Processus fonctionnel : Traiter Données et Envoyer par le module NRF Emetteur

(№3)
Entrées : Entrées Blistéreuse, Boîte
Sorties : Marche, Description d’arrêt, Nombre blisters conformes, Nombre blisters
éjectés, Nombre boîtes produites
Nécessité( minute = 60000 ; temps_écoulé =0)
Description :
Début
Faire toujours
{ si (Entrées Blistéreuse[4] == 1) alors
{Marche = 1 ;
EnvoyerNRF_Emetteur (Marche) ;
Si (Entrées Blistéreuse[3] == 1) alors
{Marche == 0 ;
Description d’arrêt = ‘Arrêt opérateur’ ;
EnvoyerNRF_Emetteur (Description d’arrêt) ; }
Sinon si (Entrées Blistéreuse != 20)
{Marche == 0 ;
Description d’arrêt = DonnerDesriptionCauseArret(Entrées Blistéreuse[5]) ;
EnvoyerNRF_Emetteur (Description d’arrêt) ; }
}
Tant que (temps_écoulé < minute)

{ temps_écoulé=TempsEnMs() ;
{Nombre Blisters conformes ++ ; }
{Nombre Blisters éjectés ++ ; }
Si (Boîte == 1) alors
{Nombre boîtes produites ++ ; }
}
EnvoyerNRF_Emetteur(«Blister conformes= ») ;
EnvoyerNRF_Emetteur(Nombre Blisters conformes) ;
EnvoyerNRF_Emetteur(«Blister éjectés= ») ;
EnvoyerNRF_Emetteur(Nombre Blisters éjectés) ;
EnvoyerNRF_Emetteur(«Boîtes conformes= ») ;
EnvoyerNRF_Emetteur(Nombre boîtes produites) ;
Nombre Blisters conformes =0 ;
Nombre Blisters éjectés =0 ;
Nombre boîtes produites =0 ;
Temps_écoulé =0 ;
}
Fin
32
3.3.3 SA de la deuxième application informatique

Maintenant, nous allons nous intéresser à l’analyse structurée de la deuxième applica-
tion informatique de notre projet (voir figure 3.1). Cette application fait la liaison entre
le module NRF récepteur et le PC (comme étant une entité externe de sortie).
¶ Diagramme de contexte
De la même manière, on va commencer par le diagramme de la figure 3.4 de contexte de

processus fonctionnel №4 qui a pour rôle d’échanger les données côté récepteur.
Figure 3.4 – Diagramme de contexte «Echanger Données Coté Récepteur»
· Diagramme de flots de données
On dissocie ce processus global pour avoir le diagramme de la figure 3.5 de flots de

données.
Figure 3.5 – Diagramme de flots de données pour l’analyse du processus №4
33
— Le processus fonctionnel (5) permet l’acquisition par le module NRF récepteur des
entrées (marche et description d’arrêt) envoyées à travers le module NRF émetteur.
— Le processus fonctionnel (6) permet l’acquisition par le module NRF récepteur
des quantités (le nombre de blisters conformes et éjectés et le nombre de boîtes
produites) envoyées à travers le module NRF émetteur.
— Le processus fonctionnel (7) permet l’envoi des données par le microcontrôleur
Arduino UNO, où est implémenté notre programme, vers le PC à travers un câble
USB.
⇒ Ces processus fonctionnels représentent notre deuxième application informatique
qui est décrit par la suite sous forme des processus primitifs spécifiés dans un al-
gorithme.
¸ Dictionnaire de données
1. Etat Machine : flot de données interne

. Rôle : état de la machine en mentionnant la cause d’arrêt en cas d’arrêt
. Domaine : ch[20]
2. Nombre : flot de données interne

. Rôle : quantité produite en blisters et boîtes, nombre des blisters éjectés
. Domaine : ch[50]
3. Message : flot de sortie

. Rôle : notification qui comporte la quantité produite en blisters et boîtes, le
nombre des blisters éjectés chaque minute, la mise en marche de la machine et
la description d’arrêt
. Domaine : ch[50]
¹ Spécification des processus primitifs
♦ Processus fonctionnel : Acquérir les signaux du Module NRF Récepteur (№5)

Entrées : Marche, Description d’arrêt
Sorties : Etat Machine
Nécessité ()
Description :
Début
Faire toujours
{ Acquérir Marche
Acquérir Description d’arrêt
si (Marche == 1)
{ Etat Machine = "Marche" ; }
34
sinon Etat Machine = Description d’arrêt ; }
Fin
♦ Processus fonctionnel : Acquérir la quantité produite des blisters et des boîtes (№6)
Entrées : Quantités
Sorties : Nombre
Nécessité ()
Description :
Début
Faire toujours
{ Acquérir Quantités
Nombre = Quantités ;
}
Fin
♦ Processus fonctionnel : Envoyer par le microcontrôleur vers le PC (№7)

Entrées : Etat Machine, Nombre
Sorties : Message
Nécessité ()
Description :
Début
Faire toujours
{ Message = Concatenate("La machine est en", Etat Machine, "Quantité=", Nombre) ;
EnvoiPC(Message) ;
}
Fin
La SA nous a permis de modéliser les deux premières applications du système (Acqui-

sition des signaux de l’automate par la carte d’interfaçage transmis via les NRF jusqu’au
PC). Dans la troisième partie, nous présentons les actions au niveau de l’application Lab-
VIEW que nous allons la créer.
3.4 Conception UML

Pour l’application LabVIEW développée, nous avons choisi le langage de modélisation
le plus adopté UML pour plus de raisons :
. La représentaton sous forme de diagrammes complémentaires facilite la compré-
hension et le déchiffrement en détails l’utilisation de notre application.
. UML est un langage universel pouvant servir de support pour tout langage orienté
objet.
35
En fait, l’UML offre une notation graphique simple et compréhensible. C’est également
un bon moyen de maîtriser la complexité et d’assurer la cohérence d’un système.
3.4.1 Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation de la figure 3.6 représente la structure des grandes
fonctionnalités nécessaires aux utilisateurs de notre application.
Figure 3.6 – Diagramme de cas d’utilisation de l’application LabVIEW
Les acteurs externes de notre système sont :

— Le superviseur : Il contrôle l’application à distance.
— L’opérateur : Les fonctionnalités qu’il peut interagir incluent l’authentification
⇐⇒ il doit se connecter afin de les exploiter.
— Le responsable informatique intervient pour ajouter un nouvel utilisateur dans
l’application. En outre, il a l’accès à exporter un fichier de la base de données s’il
est nécessaire.
— Le serveur : Il englobe la base de données hébergée.
3.4.2 Diagramme de classe

Le diagramme 3.7 de classes met en relief l’architecture conceptuelle du système : il
décrit les classes utilisées, ainsi que leurs différentes interactions.
36
L’application est accessible à un groupe des opérateurs. L’utilisateur appartient à

ce groupe et peut se connecter à condition que ses droits d’accès soient vérifiés. Un ou
plusieurs superviseurs peuvent consulter l’application. L’envoi des données à l’interface se
fait à travers la classe « Carte d’interfaçage » qui figure la classe principale dans notre
projet. Ces signaux sont acquis par l’automate.
Figure 3.7 – Diagramme de classes de l’application LabVIEW
3.4.3 Diagramme de séquence

Le diagramme 3.8 de séquence représente la succession chronologique des fonctionna-
lités réalisées par les acteurs. Il indique les objets que ce dernier va manipuler.
Le diagramme de séquence explique le déroulement de l’application en détails :
— Pour utiliser l’application une authentification est requise. L’identifiant et le temps
de sa connexion sont enregistrés dans la base de données.
— Le début de chaque Lot passe par une phase d’essai de réglage : Il s’agit d’un fonc-
tionnement de la machine à vide (blisters produites sans comprimés). L’opérateur
remplit les renseignement relatifs au Lot dans l’Application : La désignation et le
numéro du lot, la date, l’heure du départ, les différentes températures sont stockées
dans la base de données.
37
Figure 3.8 – Diagramme de séquence de l’application LabVIEW
38
— La fin du Lot doit être signalée pour que des détails complémentaires soient sau-
vegardés dans la base de donnée : date et heure de la fin, quantité produite des
blisters, nombre de blisters éjectés, boîtes produites, durée de fonctionnement,
durée des arrêts provoqués, cadence, TRS, opérateur,. . . ). S’il y a une panne, il
avertit instantanément l’équipe de la maintenance en envoyant un email à travers
l’application
— Si l’opérateur provoque un arrêt, il doit mentionner sa cause. Dès qu’il remet la
machine en marche, la description, la date, l’heure et la durée de l’arrêt seront
transcrits dans la table « Types d’Arrêts ». Cette étape est similaire dans le cas où
l’arrêt est propre à la machine sauf que la description est reçue automatiquement
par le NRF récepteur (pas d’action entre l’opérateur et l’application).
— A la fin, l’opérateur indique que son travail est achevé, l’heure de cette action est
retrouvée dans la base.
— Un rapport contenant toutes les informations concernant le personnel, la durée du
travail, Le TRS et les détails du lot est envoyé automatiquement en pièce jointe à
un email adressé aux individus concernés.
3.5 Conclusion
Tous au long de ce chapitre, nous avons créé dans une première phase une analyse
structurée, de deux programmes qui seront implémentées dans les microcontrôleurs Ar-
duino Mega et UNO, pour présenter la transmission de données de l’automate passant
par la carte d’interfaçage arrivant au PC. Pour achever la phase de la conception, le lan-
gage de modélisation UML détaille les fonctionnalités et les interventions des acteurs dans
l’application LabVIEW.
Dans le chapitre suivant, nous allons détailler la réalisation de la carte d’interfaçage et les
trois applications informatiques.
39
CHAPITRE 4
RÉALISATION PRATIQUE
4.1 Introduction
Après la conception approfondie des trois applications informatiques, nous allons pré-
senter un prototype pour l’étude de faisabilité du notre projet. L’étape suivante consiste
à réaliser le circuit imprimé connecté avec l’automate, ainsi que la plaque perforée conçue
pour l’alimentation du module NRF côté récepteur, puis programmer les deux microcon-
trôleurs Arduino Mega et Arduino UNO. Au niveau de LabVIEW, nous allons détailler
l’architecture de transmission de données du côté récepteur arrivant au PC vers la base de
données jusqu’à l’envoi d’Email. D’autre part, les interfaces de l’application seront intro-
duites. Sans oublier bien évidemment que nous allons expliquer les étapes de validation
suivies par notre projet selon les normes pharmaceutiques.
4.2 Prototype sur une plaque perforée

La réduction du risque fait partie du plan de développement d’un système. C’est pour-
quoi, nous avons fait une étude des différents scénarios possibles. Le résultat illustre que
la validation est assurée par les tests avec la machine afin d’examiner la faisabilité du
projet.
Pour simuler ceci :

1. Nous avons soudé trois optocoupleurs avec leurs résistances et leurs diodes (voir
figure 2.1) et un module NRF émetteur avec son régulateur LM317 (voir figure 2.4)
sur une plaque perforée qui est connectée sur les pins du microcontrôleur Arduino.
2. En utilisant un transformateur 24 V DC pour personnifier les signaux venant de
l’automate de la blistéreuse, un capteur inductif pour détecter la présence des blis-
ters corrects, une plaque d’essai contenant deux boutons poussoirs pour la marche
et l’arrêt, une alimentation 5V DC pour alimenter le microcontrôleur arduino, le
module NRF émetteur et les optocoupleurs comme indiqué dans la figure 4.1.
40
CHAPITRE 4. RÉALISATION PRATIQUE
Figure 4.1 – Simulation de 3 entrées avec un transformateur 24V DC alimentés par une
alimentation 5V DC
3. Côté récepteur, sur une plaque perforée nous avons soudé le régulateur LM317 avec
le module NRF. Les pins de la configuration du NRF sont connectés directement
avec l’Arduino qui est relié sur le PC par un câble USB comme illustré sur la figure
4.2
Figure 4.2 – Carte Arduino UNO avec le module NRF côté récepteur branchée au PC
4. Nous avons implémenté le programme de l’envoi de données (notre première appli-

cation informatique) et le programme de réception (notre deuxième application)
sur les deux microcontrôleurs Arduino.
5. Au niveau de la troisième application, nous avons préparé sous LabVIEW un pro-
gramme pour l’acquisition de ces trois entrées.
41
Le problème que nous avons rencontré au début réside dans les parasites provoqués
par les boutons poussoirs qui excitent une suite d’impulsions une fois un bouton poussoir
a été actionné : Ce comportement étrange et non désiré est connu par le rebond. Ce phé-
nomène nous a empêché dans notre application l’envoi massif de l’état. Par exemple, le
programme retourne 20 fois le même message lors d’un simple clic sur le bouton.
Nous avons remédié ceci au niveau du programme. En effet, en prenant en considé-

ration la valeur du pin de l’Arduino à lequel est connecté le bouton ; si la valeur est la
même pendant une durée temporaire prédéfinie (50 ms), on considère que l’état est stable.
A ce niveau, nous commençons le test avec la blistéreuse en branchant les 3 entrées

de l’automate (bouton marche, bouton arrêt en phase et blister conforme) vers notre
prototype comme montré dans la figure 4.3.
Figure 4.3 – Prototype sur une plaque perforée avec 3 entrées de l’automate de la
blistéreuse
42
Cet essai nous a montré que parfois une impulsion sur le bouton poussoir "Marche"
n’est pas acquise par l’entrée de l’optocoupleur. Nous avons résolu cela en changeant
l’entrée I01 de l’automate venant du bouton poussoir par la sortie Q11 qui est celle de
l’entrée du variateur.
L’interface présentée dans la figure 4.4 permet de faire la somme de quantité produite
chaque 5 secondes et mentionner l’état de la machine.
Figure 4.4 – Le premier essai d’une interface LabVIEW avec la machine
Cette étude nous a permis de vérifier le bon chemin de notre conception et il faut
généraliser cela sur les 17 entrées (voir le tableau 2.1) sur une carte électronique.
4.3 Conception et réalisation de la carte d’interfa-

çage
4.3.1 Conception du PCB
Le projet PCB (Printed Circuit Board) contient :
X Une schématique : qui décrit le schéma électrique de l’application dont les compo-
sants électriques sont prédéfinis par des symboles et reliés par des interconnexions
électriques.
X Un document PCB : qui décrit l’emplacement physique des composants dans la
carte et le routage des interconnexions.
Après avoir configurer les préférences générales de la schématique, ajouter les différents
composants selon la librairie choisie et faire les connexions électriques nécessaires, nous
avons obtenu la schématique présentée dans la figure 4.5 sous ISIS.
43
Figure 4.5 – Schématique de la carte d’interfaçage réalisé par l’intermédiaire du logiciel

ISIS
44
Nous avons fixé 24 optocoupleurs :

— 20 optocoupleurs pour la blistéreuse (16 entrées connectées à l’automate et 4 ré-
serves)
— 4 optocoupleurs pour l’encartonneuse ( une entrée connectée à l’automate et 3 ré-
serves).
Les bourniers PWM1, PWM2, COMMUNICATION, ANALOG1, ANALOG2 et DIGI-

TAL symbolisent les pins de l’Arduino Mega. En fait ce microcontrôleur va être relié à
notre carte qui représente son schield et sera simple à installer. Au niveau du programme
côté émetteur, nous allons tester à chaque fois le pin 5 de chaque optocoupleur qui est
associé à un pin prédéfini de l’Arduino en tenant en compte la logique négative que 24V
DC vaut "0" au microcontrôleur et 0V vaut "1". Ce signal est produit via les bourniers
à vis AC1, AC2 Blistéreuse, AC2 et Encartonneuse (donnés sur la figure 4.5) où sont
branchées les entrées de l’automate.
Chaque composant est défini par un symbole de schématique et une empreinte de

PCB. Une fois la saisie de la schématique est validée, nous allons faire le transfert du
design vers l’éditeur PCB.
On ne peut pas nier le temps passé à faire notre premier essai de la conception du
PCB sur Altium Designer qui est considéré l’un des logiciels de conception de cartes élec-
troniques le plus évolué. Mais les contraintes que nous avons envisagées, présentées dans
le tableau 2.6 dans le chapitre 2, nous ont laissé de travailler finalement avec ARES. Nos
besoins nécessitent la facilité de faire les choses "non de refaire" la création d’un nouveau
document PCB et le placement des composants 5 fois minimum à cause d’une simple
erreur au niveau du schéma électrique. La dernière version du PCB avec Altium est pré-
sentée dans la figure B.1 dans l’annexe B.
Au niveau de l’ARES, les pads des empreintes choisies sont très réduits. Il faut élargir
ces parties électriques pour une bonne soudure par la suite sur le circuit imprimé.
Pour se faire, nous avons créé une bibliothèque pour chaque composant (l’optocoupleur,
la résistance, la diode, la résistance variable, le régulateur LM317, le condensateur et les
différents types des borniers à vis) dans ARES puis modifier son package lié à l’éditeur
de schéma ISIS.
Après avoir associer ces empreintes générées aux éléments, nous avons les placé judi-
cieusement sur la carte afin d’optimiser le routage.
En configurant une largeur à la piste en fonction de l’intensité maximale qui peut y cir-
culer, nous avons commencer le routage pour obtenir à la fin le PCB trouvé dans la figure
B.2 de l’annexe B.
Notre circuit dispose deux faces (voir les figures B.3 et B.4 dans l’annexe B) :
— La face avant (Top Layer) avec les pistes rouges où sont placés les composants.
— La face arrière (Bottom Layer) avec les pistes bleues sur laquelle les soudures des
broches des composants.
45
4.3.2 Réalisation du circuit imprimé

Une fois le routage terminé et validé, nous avons créé les fichiers de sorties afin de
commencer l’impression de la carte comme trouvé dans la figure B.5 dans l’annexe B.
La fabrication de notre carte double-faces nous a donné les figures B.6 et B.7 dans l’an-
nexe B.
Avant l’emplacement des composants sur la carte, nous avons effectué un test du cir-
cuit imprimé par un multimètre. En fait, ce test est primordial afin d’assurer la continuité
des pistes ainsi que l’absence de court-circuit entre les pins et les pistes.
A ce moment, nous pouvons faire le perçage des trous de montage et la soudure des
composants électroniques sur la carte. Cette phase est présentée dans les deux figures 4.6
et 4.7.
Figure 4.6 – Carte d’interfaçage prête
46
Figure 4.7 – Carte d’interfaçage avec l’arduino Mega connecté
Nous avons fait la conception à l’aide du SolidWorks et la confection à l’aide d’une

imprimante 3D du boîtier pour notre carte d’interfaçage comme le montre la figure 4.8.
Ce boîtier a pour rôle de conserver le microcontrôleur Arduino Mega et la carte.

Avant de mettre notre carte en action, il faut vérifier la soudure des composants avec
un multimètre pour pouvoir la mettre sous tension sans aucun risque.
Une fois nous avons assuré le bon fonctionnement du matériel, il nous reste la partie
logicielle.
47
Figure 4.8 – Conception mécanique à l’aide du SolidWorks et confection du boîtier pour

la carte d’interfaçage
4.4 Conception et réalisation du circuit du module

NRF côté récepteur avec l’Arduino UNO
4.4.1 Saisie du schéma électrique
Nous avons associé le circuit du régulateur LM317 (voir figure 2.4 du chapitre 2) avec
le module NRF et le microcontrôleur Arduino UNO dans la schématique de la figure 4.9.
48
Les pins du module NRF explique dans le tableau 2.5 sont branchés avec l’Arduino
UNO comme suit :
GND le GND de l’Arduino
VCC la sortie du régulateur LM317 qui est 3.3V
CE le pin numérique 7 de l’Arduino
CSN le pin numérique 8 de l’Arduino
SCK le pin numérique 13 de l’Arduino
MOSI le pin numérique 11 de l’Arduino
MISO le pin numérique 12
Figure 4.9 – Schématique du circuit du module NRF côté récepteur avec l’Arduino UNO
par l’intermédiaire du logiciel ISIS
Puisque notre circuit est simple : il ne nécessite pas un circuit imprimé. Nous avons
soudé les différents composants sur une plaque perforée comme illustré dans la figure 4.10.
Cette plaque est connectée sur l’Arduino UNO.
Nous avons proposé un boîtier afin de loger la carte. Des ouvertures sont prévues sur
le côté de la boîte pour le connecteur USB pour l’alimentation de l’Arduino avec le PC.
49
Figure 4.10 – Circuit du module NRF soudé sur la plaque perforée installé sur Arduino
UNO
4.5 Réalisation des trois applications informatique

4.5.1 Développement des programmes implémentés dans les mi-
crocontrôleurs Arduino
La phase de tests est alternative dans notre projet. Avant l’installation de la carte avec
l’automate, nous avons simulé avec un transformateur 24V DC le capteur inductif et les
boutons poussoirs comme étant des causes d’arrêts dans notre circuit imprimé, comme
donné dans la figure 4.11.
En première partie nous avons testé le changement d’état de chaque signal acquis par
l’optocoupleur à travers l’Arduino Mega (sans considérer le module NRF).
50
Figure 4.11 – Simulation de la carte d’interfaçage par le transformateur 24V DC
Puis, nous avons ajouté au programme la partie d’envoi des signaux vers l’Arduino
UNO. L’idée est de créer un package qui comporte un tableau des entiers, qui englobe les
différentes causes d’arrêts, la somme de la quantité produite des blisters et des boîtes et
le nombre des blisters éjectés par minute, et une variable pour savoir l’état de la machine
et sera envoyé à chaque itération.
Au niveau du récepteur, la vérification se base sur le changement de l’état de la ma-

chine :
,→ Si la machine est en marche et nous avons cliqué une autre fois sur le bouton poussoir
"Mise en marche" rien ne se passe. C’est réciproque pour les arrêts : si la machine est en
arrêt mais nous avons détecté un deuxième arrêt, nous allons considérer juste le premier.
Le message qui sera envoyé à notre troisième application informatique dans LabVIEW
s’affiche après la diversification de la source d’arrêt à travers le changement des valeurs
dans le tableau.
A ce niveau, nous sommes prêtes pour commencer les essais sur la machine. Nous
avons installé la carte avec l’automate comme illustré sur la figure 4.12.
C’est le moment assez tendu dans le projet où nous sommes face aux résultats d’un
travail des mois.
En effet, nous avons commencé à envisager les imprévus :
Le programme retourne toujours à la même cause d’arrêt "Arrêt opérateur", sachant
que nous avons simulé des autres arrêts.
Quantité des blisters éjectés énormes même que la machine est en arrêt.
51
Figure 4.12 – Installation de la carte d’interfaçage avec l’automate de la blistéreuse
Nous avons utilisé un multimètre pour savoir si le courant est bien passé à la sortie
de l’optocoupleur (24V de l’automate donne 0V à l’Arduino), en ouvrant le carter par
exemple comme étant une cause d’arrêt. Le résultat prouve qu’il n’y a pas de problème
côté matériel.
C’est à nous de jouer avec le code. Nous avons essayé de refaire tout le programme :
? Tester l’état initiale de chaque entrée à l’Arduino Mega.
7→ Il y a des causes qui ne sont pas ordinaires :
— Fin film aluminium : Alternative entre l’état 1 et 0 au cours du temps, si
l’état 1 ou 0 réside au bout d’un laps du temps (de 6 à 10 secondes), la machine
s’arrête.
— Zéro encodeur : Alternative entre l’état 1 et 0 au cours du temps. Le chan-
gement vers un état précis indique un arrêt.
— Rouleau hors position : L’état initiale dépend de l’état de la machine : vaut
1 si la machine est en marche sinon vaut 0. Le rouleau est hors position quand
l’entrée retourne 0 et la machine est déjà en marche.
— L’encartonneuse : Le démarrage de la blistéreuse après un arrêt de l’encar-
tonneuse est automatique.
Nous avons rectifié le code selon nos besoins mais nous sommes encore au niveau
de l’envoi (pas de transmission de données par le module NRF)
52
? Changer la méthode d’envoi des données : Au lieu du tableau, nous avons fait le test
à l’arduino Mega et le module NRF qui va transmettre directement la marche de
la machine et la description de l’arrêt. ⇔ Notre deuxième application informatique
au niveau de l”Arduino UNO va seulement lire les données reçues et les envoyer
au PC à travers le câble USB
? Pour le nombre des blisters éjectés, nous avons constaté que nous n’avons pas pris
la sortie correcte de l’électrovanne Q00 AC1. Nous avons vérifié la nouvelle sortie
(Q00 AC2) et le problème a été résolu.
7→ Nous avons constaté aussi que la somme de nombre de blisters éjectés devient
négative : quand la machine est en marche le nombre est correct par contre en cas
d’arrêt elle retourne à des valeurs non nulles. Avec le temps, nous avons compris
que c’est dû à la présence des parasites au niveau de la sortie. Nous pouvons
prendre l’entrée I19, AC2 qui représente le blister se trouvant sur le convoyeur
après découpe : ce signal retourne tous les blisters découpés conformes ou éjectés.
Il suffit de faire la soustraction au niveau du programme pour obtenir le nombre
des blisters non conformes.
4.5.2 Application LabVIEW

4.5.2.1 L’architecture de la transmission de données de l’application infor-
matique
Dans un premier lieu nous avons consacré un temps à nous accoutumer à l’utilisation
du logiciel LabVIEW qui est la base de notre application informatique.
¶ L’acquisition des données du port USB depuis le microcontrôleur

Pour ce faire Il existe plusieurs méthodes puisque LabVIEW offre un toolkit dédié à
Arduino. Nous avons essayé :
— LIFA (Labview Interface for Arduino) : permet de commander et contrôler
l’Arduino sans passer par son propre code. La configuration des pins se fait dans
LabVIEW.
— LINX : inclut des VIs pour des fonctions indépendantes du matériel, afin d’accéder
à des périphériques tels que des entrées/sorties numériques et analogiques, PWM,
I2C, SPI et UART.
— Serial Visa : rend la programmation d’instruments série rapide et facile. Cette
méthode satisfait également aux besoins de la souplesse du logiciel, toute en rédui-
sant le temps de latence et en assurant une vitesse de transfert élevée.
Nous avons opté pour la dernière méthode citée précédemment parce que nous envisa-
geons recevoir les données de n’importe quel microcontrôleur sans se limiter à l’utilisation
de l’Arduino. ⇒ Notre application sera accessible à tout système embarqué branché en
série.
Nous avons eu des difficultés à trier les différentes informations provenant de notre
système conçu (description des arrêts, nombre de blisters produits, nombre de blisters
éjectés, nombre de boîtes produites) dans le but de faire correspondre chacune avec son
traitement.
53
· Enregistrement dans la base de données

Cette étape est cruciale car elle assure la traçabilité des données. En effet, c’est une
phase critique qui a occupé le temps nécessaire pour sa réalisation.
D’emblée, nous avons utilisé Wampserver qui est une plateforme de développement
Web sous Windows. Il est exploité à l’aide des scripts PHP et la base de données MYSQL.
Mais nous avons trouvé que celui-ci n’est pas l’idéale dans notre cas car nous n’avons réussi
qu’à envoyer des données à LabVIEW. En outre, la base utilisée dans l’entreprise est SQL-
SERVER ce qui a conclu que ce serveur n’est pas compatible à nos besoins logiciels.
Au niveau de LabVIEW, nous avons créé une datalink pour l’échange des donnés avec
SQL Server comme illustré dans la figure 4.13. Nous avons choisi ODBC driver (Open
Database Connectivity) comme fournisseur puis nous avons spécifié la source de données.
Cette dernière est créée sous « outils d’administration source de données ODBC » dans le
fichier adéquat 32bits/64bits comme le montre la figure 4.14 puis faire entrer le catalogue
initial à utiliser qui représente le choix parmi la liste des bases de données. Elle en résulte
l’enregistrement d’un fichier Microsoft Data Link (UDL).
L’une des entraves que nous avons rencontré est qu’il faut installer le ODBC driver
convenable à la version de LabVIEW avec laquelle nous travaillons.
Figure 4.13 – Liaison locale des sources de données entre LabVIEW et SQL Server
Une fois la connexion à la base de données est établie, nous avons pu exploiter le
Database Toolkit de LabVIEW.
54
Figure 4.14 – Création d’une source de données
Notre objectif depuis le début est d’héberger la base de données sur le serveur de
l’entreprise. Nous avons réussi à l’atteindre par la manipulation des sources de données
en les configurant avec l’authentification du serveur (figure 4.15)
Figure 4.15 – Liaison des sources de données entre LabVIEW et SQL Server réalisé sur
le serveur de l’entreprise
Les informations relatives à la machine sont conservées dans la base de données (ser-
veur) d’une part et dans un fichier Excel qui contient uniquement les données exploitées
au cours des réunions QRQC pour évaluer le TRS.
55
¸ Création du rapport journalier

L’idée est de générer un rapport Excel contenant les données nécessaires pour tracer
le tableau de marche et de l’envoyer automatiquement par Email au personnel concerné.
Pour ce faire il existe plusieurs façons :
Soit réaliser cette tâche depuis la base de données 99K en exportant un fichier Excel,
mais l’envoi d’un Email doit se faire indépendament. Nous pouvons créer une application
Windows pour résoudre le problème ou par l’intermédiare du langage VBA (Visual Basic
for Applications) dans Excel. L’unique souci avec cette solution est qu’elle n’assure pas
l’exécution des tâches désirées (générer le rapport et l’envoyer par email) simultanément.
Nous avons trouvé que le toolkit "Report Generation" de LabVIEW peut remédier la
situation. En effet, ce dernier permet de créer un classeur contenant plusieurs feuilles à
renommer avec des graphes.
Chaque jour, à la fin du temps d’ouverture, ce classeur renommé par la date courante
sera envoyé automatiquement par Email dont on trouve :
— Une feuille comprenant les différents types d’arrêts,
— Une feuille pour mentionner les horaires des postes des opérateurs,
— Une feuille des détails des lots produits dans cette journée,
— Une feuille pour le TRS, temps d’ouverture, temps utile, quantité produite des
blisters, nombre de blisters éjectés, nombre de boîtes produites.
La figure 4.16 illustre l’exécution d’un Excel reçu par un email.
¸ Envoi de l’Email
Nous avons essayé l’envoi par la méthode SMTP (Simple Mail Transfer Protocol) donné
par LabVIEW. Au début, elle n’a pas fonctionné, c’est pourquoi nous avons l’essayé par
la plate-forme Microsoft NET avec laquelle LabVIEW peut s’interfacer.
Suite aux plusieurs tests, nous avons observé que le blocage de l’Email est au niveau
de la sécurité Gmail pour les deux méthodes. Il faut que nous configurons dans les pa-
ramètres l’activation de IMAP (Internet Message Access Protocol) pour pouvoir accéder
à Gmail et l’autorisation de l’accès des applications moins sécurisées (LabVIEW) pour
qu’il fonctionne correctement. La figure 4.17 mentionne l’envoi de l’Email par LabVIEW
au service maintenance.
4.5.2.2 Interaction avec l’application informatique

L’application LabVIEW comporte 6 interfaces :
56
Figure 4.16 – Test de réception du rapport journalier Excel généré par LabVIEW
¶ Début du poste
L’interface de la figure 4.18 est dédiée à l’authentification de l’opérateur pour qu’il puisse
utiliser l’application. Le clic sur le bouton "Démarrer" permet :
— La vérification de l’identifiant et de son mot de passe.
— L’insertion à la table "Opérateur" de la base de données son nom et son temps de
login (le temps durant lequel l’opérateur a utilisé l’application).
— La page "Détail du lot" s’ouvre et devient accessible tant que l’opérateur est
connecté.
57
Figure 4.17 – Alerte d’une panne envoyé par Email à l’équipe maintenance par notre
application LabVIEW
Figure 4.18 – L’interface "Début du poste"
· Détail du lot
« Détail du lot » est l’interface de la figure 4.19 accessible seulement à l’opérateur pour
qu’il :
— remplisse la désignation du lot, le numéro du lot, la température thermoformage
inférieur, la température thermoformage supérieur et la température de rouleau de
scellage au début de chaque Lot.
— mentionne le début du lot.
— mentionne la fin du lot. (Ce bouton provoque l’insertion dans la table "Lot" de
la base de données, ces renseignements sont : les champs remplis par l’opérateur,
la quantité produite de blisters, le nombre de blisters éjectés, le nombre de boîtes
produites, la cadence, la durée des arrêts, le temps de fonctionnement de la machine
et le TRS.)
— indique sa fin de poste pour enregistrer le temps de logout.
58
Figure 4.19 – L’interface « Détail du lot »
¸ L’interface « Arrêt »
« Arrêt » est l’interface de la figure 4.20 qui est accessible néanmoins l’opérateur n’est
pas connecté. Elle permet de donner des informations à propos l’arrêt courant : l’heure,
la date, le type, la description et la durée de cet arrêt.
Dans le cas d’une panne, l’opérateur peut cliquer sur le bouton "Intervention maintenance"
pour avertir l’équipe de la maintenance.
Figure 4.20 – L’interface « Arrêt »
¹ Choisir un arrêt
« Choisir un arrêt » est l’interface de la figure 4.21 qui permet à l’opérateur de signaler
la cause de l’arrêt provoqué par lui même. Celle-ci apparaîtra automatiquement dès que
le module NRF récepteur a acquis le signal du bouton arrêt en phase.
59
Une fois l’utilisateur a choisi la description d’arrêt, les informations seront stockées dans
la base comme mentionné sur la figure 4.22.
Figure 4.21 – L’interface « Choisir un arrêt »
Figure 4.22 – Insertion des informations sur la cause d’arrêt dans la base de données
º TRS
L’interface TRS de la figure 4.23 permet de visualiser l’allure de TRS en fonction du
temps.
» Supervision
L’interface de la figure 4.24 est pour les superviseurs afin de consulter l’application à
distance.
60
Figure 4.23 – L’interface "TRS"
Figure 4.24 – L’interface "Supervision"
Nous avons publié l’application comme une page web pour que le superviseur la vi-
sualise à distance via le serveur Web offert par LabVIEW (figure 4.25).
61
Figure 4.25 – La page Web de notre application LabVIEW sur le PC et sur le téléphone
4.6 Validation et suivi du projet

Dans la mise en place de nouveaux projets informatisés, il faut que l’industriel du
médicament soumette aux autorités réglementaires.
A cet égard, en 1992, la première version des Bonnes Pratiques de Fabrication (BPF)
inclut une annexe spécifique aux systèmes informatisés. Cette annexe est totalement revue
en 2011 pour mettre l’accent sur le principe d’une stratégie de validation. [8]
En effet la validation du projet est importante pour plusieurs raisons :

X Satisfaction des utilisateurs
X Réduction des coûts :
• réduction des risques d’arrêt d’une partie du système conçu.
• réduction du risque de perte de données
X Meilleure maîtrise du système
X Exigence réglementaire
Le croisement de ces raisons permet de déterminer que notre système est à valider en
s’appuyant sur les diverses qualifications suivantes :
1. Qualification de Conception : Cette phase représente une spécification des
besoins et une conception détaillée du projet. (chapitres 2 et 3)
En outre
2. Qualification d’Installation : La phase qui consiste à :
62
— Générer l’application LabVIEW (.exe) et l’installeur,

— Installer SQL Server dans le PC,
— Création de la base de données au niveau du serveur de l’entreprise,
— Configurer les sources de données vérifiant l’identifiant et le mot de passe du
serveur (figure 4.15),
— Exécuter l’application.
3. Qualification Opérationnelle : Dans cette étape, nous avons testé le bon fonc-
tionnement de notre système en tenant compte du texte réglementaire des BPF
qui est basé sur la fiabilité des processus de soutien tel que la maîtrise des chan-
gements, la traçabilité des modifications et la gestion de l’archivage (Les données
seront automatiquement sauvegardées dans un fichier Excel placé sur le bureau à
l’échelle locale et sur la base de données du serveur à l’échelle globale).
4. Qualification de Performance : Cette phase nécessite une période prolongée
sous surveillance du stabilité du système en exploitation. Elle est dédiée pour un
auditeur externe qui vérifiera les critères d’acceptation des normes réglémentaires.
La requalification de l’installation et celle opérationnelle du système devront être re-
faites périodiquement pour assurer l’intégrité des données.
4.7 Conclusion
Après avoir assuré la faisabilité du projet par un prototype, nous avons passé à la
conception et la réalisation du circuit imprimé ainsi que celui du module NRF côté récep-
teur. Par la suite, nous avons détaillé la phase des divers tests des deux microcontrôleurs
Arduino Mega et Arduino UNO avec la machine. La partie logiciel est achevée avec une
présenatation approfondie de l’application LabVIEW. Finalement, le plan de validation
d’un système informatisé dans les industries pharmaceutiques, qui exige des normes bien
définis, a été structurée.
63
CONCLUSION GÉNÉRALE ET PERSPECTIVES
Au cours de notre projet, un système de surveillance d’une ligne de production (blisté-

reuse + encartonneuse) a été conçu. Nous avons abordé trois axes principaux : conception
et réalisation d’une carte d’interfaçage, développement d’une application de contrôle et
export des informations vers une base de données localisée dans le serveur.
En effet, dans une première partie, nous avons déchiffré la nature de tous les arrêts
qui peuvent se produire dans la machine et les traduire en langage binaire pour être lu au
niveau des pins du notre microcontrôleur Arduino Mega, ainsi que la quantité produite
de blisters et de boîtes.
Une deuxième partie du projet a été consacrée à la transmission à distance vers l’ap-
plication par le biais du module NRF.
Par la suite, nous avons développé une interface graphique qui permet de traiter les
données acquises cruciales aux calculs du TRS : l’indicateur clé pour suivre la performance
du fonctionnement de la machine.
Suite aux disciplines de la norme pharmaceutique 21 CFR Part 11, nous avons prévu
une gestion d’accès que l’application doit être contrôlée par une hiérarchie de ses utilisa-
teurs (responsable, superviseur, opérateur).
Pour conserver les données d’une côté, un enregistrement chronologique de tous les
actions qui se produisent au niveau de la machine sont sauvegardées dans la base de
données et d’une autre côté dans un fichier Excel trouvé sur le PC. Cet archivage assure
une traçabilité certaine des tables au cas où il y a un problème d’interconnexion entre
l’application et le serveur.
Ce projet est compatible avec les plans futurs de l’entreprise : la digitalisation de

ses lignes de production. Ce stage nous a été bénéfique, il nous a permis d’acquérir des
connaissances professionnelles et a éliminé les imperfections industrielles relatives aux
pertes de données afin de résoudre un problème majeur qui peut faire gagner en temps et
bien évidemment en coût.
En guise de perspectives, nous envisageons généraliser le système réalisé sur toutes les
lignes de production. Une autre idée qui peut apporter une amélioration à notre système
64
Conclusion Générale
conçu est d’implémenter l’utilisation d’une douchette informatique pour faire entrer les
données relatives aux produits à travers un code QR généré. Ceci permettra de limiter
plus en plus l’intervention humaine sur le process. Dans cette dernière vision, nous avons
aussi pensé au recours à l’intelligence artificielle : reconnaissance faciale pour la gestion
d’accès d’une part et prédiction des arrêts de la machine d’autre part.
Tout cela met en relief l’excellence opérationnelle adoptée par Teriak, celle qui a ap-
porté des changements racines à la culture de travail.
65
BIBLIOGRAPHIE
[1] Christian Hohmann, Le Taux de Rendement Synthétique TRS,

URL = "http://christian.hohmann.free.fr/index.php/lean-entreprise/
la-boite-a-outils-lean/296-trs-exemples-de-calcul"
[2] Quentin, Analyse de la qualité : Quick Response, Quality Control (QRQC),

Publié le 29 août 2012,
URL = "https://amdec2qrqc.wordpress.com/2012/08/29/le-qrqc/"
[3] Stéphane Loizeau – StimuL Conseil, Quick Response, Quality Control (QRQC),
Publié en 2019,
URL = "http://www.stimul-conseil.fr/la-reactivite-durable-suite-le
-qrqc-quick-response-quality-control/"
[4] L’optocoupleur : principe de fonctionnement,

Mise à jour : Le 13 Février 2016,
URL : "https://www.astuces-pratiques.fr/electronique/l-optocoupleur-
principe-de-fonctionnement"
[5] Soufiane Kaissari, Conception d’un Réseau de Capteurs sans Fil,

Publié : Juillet 2015,
URL : "https://www.researchgate.net/publication/298762567Conceptiond’un
-ReseaudeCapteurssans_Fil"
[6] Proteus (ISIS et ARES),

URL : "http://www.elektronique.fr/logiciels/proteus.php"
[7] Bernard Espinasse, Méthodes fonctionnelles : Structured Analysis SA,

URL : "http://www.lsis.org/dea/M6optionD/Exp-GL42-SA-SD.pdf"
[8] Annexe 11 : Systèmes Informatisés dans le cadre d’activités relevant des

Bonnes Pratiques de Fabrications BPF,
Publié Mai 2013, PDF = "Annexe-11Systemes-InformatisesMai2013.pdf"
66
ANNEXES
67
ANNEXE A
DÉTAILS DE TRS
Figure A.1 – Arrêts IMA 1217 en pourcentage du premier trimestre 2019
68
Figure A.2 – Arrêts IMA 1217 en heures du premier trimestre 2019
ANNEXE B
RÉALISATION DE LA CARTE D’INTERFAÇAGE
Figure B.1 – Circuit imprimé de la carte d’interfaçage par Altium Designer
70
Figure B.2 – Circuit imprimé de la carte d’interfaçage par ARES
Figure B.3 – Top Layer du PCB par ARES
Figure B.4 – Bottom Layer du PCB par ARES
Figure B.5 – Le typon de la carte électronique sur une feuille transparente (Top Layer)
Figure B.6 – Circuit imprimé réalisé (Top Layer)
Figure B.7 – Circuit imprimé réalisé (Bottom Layer)
PROJET DE FIN D’ÉTUDES
LIGNE DE PRODUCTION CONNECTÉE
Résumé
Ce rapport comporte les phases suivies pour la mise en œuvre d’un système embarqué
permettant la digitalisation d’une ligne de production, sa supervision et la connaissance
de l’origine des actions opérationnelles tout en éliminant les manuscrits. Une première
partie du travail concerne la conception d’une carte d’interfaçage qui autorise
l’acquisition des arrêts et de la quantité produite et les transmettre à distance vers une
interface graphique réalisée via LabVIEW : lieu de traitement et visualisation sur WEB
des états de la machine et envoi automatique des rapports journaliers par email. Dans
une deuxième partie nous avons créé une base de données : lieu de stockage de toutes les
informations à exploité ultérieurement.
Mots clés : Système embarqué ; Carte d’interfaçage ; LabVIEW ; WEB ; Supervision,

Base de données ; Interface graphique
Abstract
This report covers the phases followed for the realization of an embedded system
allowing the digitalization of a production line, its supervision and the track of the
origins of the operational actions while eliminating all the manuscripts. The first part of
our work consists in designing an Interface Board that authorizes the acquisition of the
machine ON/OFF signal, the produced quantity and their remote transmission to a
graphic Interface accomplished via LabVIEW where all data treatments, WEB
visualization and the automatic send of daily reports happen. As far as the second part,
it consists of database creation where data is being stored for subsequent uses.
Keywords : Embedded system ; Interface Board ; LabVIEW ; WEB ; Supervision ;

Database ; graphic interface.
Année Universitaire : 2018 - 2019

Version Finale PFE

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Version Finale PFE

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne

Ministère de l’Enseignement Supérieur

Rapport de Projet de Fin d’Etudes

Conception, réalisation et mise en place

Soutenu publiquement le 27 Mai 2019 devant le jury composé de :

Année Universitaire : 2018 - 2019

Rapport de Projet de Fin d’Etudes

Conception, réalisation et mise en place

Réalisé au sein des Laboratoires Teriak

Autorisation de dépôtt du rapport de Projet de Fin d’Etudes :

Encadrant professionnel : Encadrant académique :

Je dédie ce travail particulièrement

À mon grand frère Ghassen pour son aide et son soutien.

Un grand Merci également à Mme . Gouddi Amira, la Pharmacienne Responsable

Nous remercions également M. El Gharbi Arbi, Responsable Informatique pour son

Nous remercions tout particulièrement M. Samti Sofiene, Responsable Maintenance

Nous tenons à remercier infiniment Mme . Ouederni Meriem, Ingénieur Améliora-

Nous tenons à remercier chaleureusement toute l’équipe de l’entreprise Teriak pour

Nos remerciements s’adressent également à monsieur le président et les membres du

1 Présentation des laboratoires TERIAK et analyse du projet 3

2 Spécification matérielle et logicielle du projet 13

3 Spécification détaillée et conception de l’application informatique 24

3.3.3 SA de la deuxième application informatique . . . . . . . . . . . . . 33

B Réalisation de la carte d’interfaçage 70

1.1 Groupe fondateur des laboratoires Teraiak « Groupe KILANI » . . . . . . 4

2.1 Schéma utilisation de l’optocoupleur . . . . . . . . . . . . . . . . . . . . . 15

3.1 Schéma explicatif des trois applications informatiques du projet . . . . . . 25

4.1 Simulation de 3 entrées avec un transformateur 24V DC alimentés par une

4.7 Carte d’interfaçage avec l’arduino Mega connecté . . . . . . . . . . . . . . 47

A.1 Arrêts IMA 1217 en pourcentage du premier trimestre 2019 . . . . . . . . . 68

B.1 Circuit imprimé de la carte d’interfaçage par Altium Designer . . . . . . . 70

2.1 Les différentes entrées de l’automate . . . . . . . . . . . . . . . . . . . . . 14

L’entreprise, généralement, se trouve dans l’obligation de satisfaire les impératifs :

La maîtrise et la considération des moyens d’amélioration s’avèrent donc capitales.

Actuellement, la méthode de travail de Teriak est totalement manuelle et il y a une

L’objectif du projet présent est de concevoir un système de supervision et d’indication

Ce rapport comporte quatre chapitres présentant la démarche suivie pour la mise au

1.2 Présentation de l’organigramme d’accueil

Figure 1.1 – Groupe fondateur des laboratoires Teraiak « Groupe KILANI »

1.2.2 Description du process de fabrication :

1.2.3 La progression dans Teriak

La trigénération produit simultanément de l’énergie mécanique (souvent convertie en

Figure 1.2 – Process de fabrication d’un médicament

Figure 1.3 – Schèma de principe de l’installation Trigénération

En effet, l’objectif en cours de Teriak vise à élargir sa technologie afin d’atteindre la

Afin de transformer les modes de communication, la production industrielle travaille à

1.3 Cadre du projet

Figure 1.4 – Réunion journalière de suivi des indicateurs de performance : -Méthode

Temps Utile (TU)

1.3.2 Présentation de la ligne de production : blistéreuse + en-

Figure 1.5 – Blistéreuse IMA1217 dans le local conditionnement primaire

Figure 1.6 – Principaux cycles du travail de la blistéreuse IMA1217

La décomposition de la blistéreuse est illustrée dans la figure 1.7.

Elle est composée :

Figure 1.7 – Constitutions de la blistéreuse

— Une encartonneuse (figure 1.8) qui est destinée au conditionnement secondaire

1.3.3 Solution proposée

Figure 1.8 – Encartonneuse dans le local conditonnement secondaire

Notre système aura l’initiative d’émettre des rapports journaliers de fonctionnement

2.2 Choix des matériels

Table 2.1 – Les différentes entrées de l’automate

I31, AC2 24V DC Arrêt de l’encartonneuse

Table 2.2 – Relais électromécanique vs optocoupleur