République Française

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique

Université d’Evry Paris-Saclay

Rapport de Stage

Master02 : Ingénierie des systèmes complexes parcours Robotique Industrielle

Réalisé par

AOUDIA Massinissa

Développement soft ligne process

Encadrant Référent : Erwan tallec [email protected]

Encadrant Contact : Nicolas SEGUY [email protected]

Réalisé au sein de Université d’Evry-val d’Essonne 2024/2025

Année Universitaire 2024 - 2025

Remerciements

Je remercie chaleureusement toutes les personnes qui ont contribué de près ou

de loin à la réalisation de ce travail.

Je suis profondément reconnaissant envers mes encadrants académiques,

Monsieur Erwan Tallec et Monsieur Nicolas Seguy, pour leur

disponibilité, leurs conseils avisés et leur accompagnement tout au long de ce

projet.

J’exprime toute ma gratitude à l’ensemble de l’équipe pédagogique du Master 2

Robotique Industrielle de l’Université d’Évry Paris-Saclay, ainsi qu’à tous mes

enseignants depuis mes premières années d’études, qui ont su m’inculquer les

savoirs et les valeurs nécessaires à mon parcours.

Je remercie également mes parents, AOUDIA Daou et ZENNOUCHE

Lynda, pour leur soutien indéfectible, leur patience et leur amour tout au long
de mon parcours.

Je n’oublie pas mes amis et collègues pour leur soutien moral, leur aide

précieuse et les moments partagés durant ce chemin.

À toutes ces personnes, je dis sincèrement : merci.

i
Table des matières

Introduction générale 1

1 Découverte du CMQ-IDF et Technologies Innovantes 2

1.1 Le Centre d’Innovation 4.0 d’Évry : un outil au service du CMQE IDF . . . . . . . . . 4
1.2 Organigramme de l’équipe du Centre d’Innovation 4.0 . . . . . . . . . . . . . . . . . . 4
1.3 Structure et Organisation du CMQ-IDF . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Présentation des Lignes de Production et Technologies . . . . . . . . . . . . . . . . . . 6
1.5 Missions et Activités Réalisées pendant le Stage . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Veille Technologique et Projets Transversaux . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Automatisation et intégration d’une nouvelle ligne de fabrication de boissons 8

2.1 Schéma P&ID : Modélisation et Conception . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Schémas Électriques : Étude et Conception . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Choix de la tuyauterie et modélisation de l’installation . . . . . . . . . . . . . . . . . . 11
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Introduction aux Systèmes Automatisés 15

3.1 Introduction aux Systèmes Automatisés . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Les Automates Programmables Industriels (API) . . . . . . . . . . . . . . . . . . . . . 21
3.3 Évolution et historique des automates programmables . . . . . . . . . . . . . . . . . . 21
3.4 Utilisation des automates programmables . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Les types d’automates programmables industriels . . . . . . . . . . . . . . . . . . . . . 27
3.6 Normalisation de la programmation des automates : la norme CEI 61131-3 . . . . . . . 28
3.7 Les langages de programmation d’un API . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.8 Interface Homme-Machine (HMI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 Développement logiciel de l’automatisme et de la supervision 40

4.1 Introduction générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Objectifs généraux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3 Présentation du cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4 Analyse fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5 Modélisation 3D du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

ii
 4.6 Partie Préparation du Produit – Définition des Besoins en Matériel . . . . . . . . . . . 46
4.7 Objectif du Processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.8 Constitution du Système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.9 Circulation des Liquides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.10 Modes de Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.11 Liste des Électrovannes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.12 Spécifications de Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.13 Choix des langages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.14 Interface Homme-Machine (IHM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.15 Choix des protocoles de communication . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.16 Architecture fonctionnelle du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.17 Justification des choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5 Gestion et organisation du projet 71

5.1 Méthodologie PDCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2 Utilisation du diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.3 Difficultés rencontrées et ajustements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.4 Suivi quotidien avec Google Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Conclusion générale 76

Annexes 77
Annexe 2. Entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Annexe 2. Choix de matériel et chiffrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Annexe 2. Entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Annexe 2. Entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Annexe 4. Déclaration des variables automates . . . . . . . . . . . . . . . . . . . . . . . . . 80
Annexe 5. Entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

iii
Table des figures

1.1 Organigramme de CMQeIDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Quelques partenaires industriels du Centre d’inovation d’évry 4.0 . . . . . . . . . . . . 6

2.1 PID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Modélisation 3D des cuves – première configuration . . . . . . . . . . . . . . . . . . . . 12
2.3 Schéma de principe de fonctionnement de la ligne de production . . . . . . . . . . . . 13

3.1 Structure d’un système automatisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Exemples de Pré-actionneurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Exemples d’Actionneurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Exemples de Capteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5 Solutions de contrôle selon les fonctionnalités requises . . . . . . . . . . . . . . . . . . 23
3.6 Architecture compacte des automates programmables . . . . . . . . . . . . . . . . . . . 24
3.7 Architecture modulaire des automates programmables . . . . . . . . . . . . . . . . . . 25
3.8 Exemple d’un réseau Ladder utilisant un bloc RESET pour définir la direction. . . . . . 29
3.9 Exemples de Ladder Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.10 Exemples de GRAFCET programmation . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.11 Exemples de langages de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.12 Le PC industriel ultra-compact de la série C60 . . . . . . . . . . . . . . . . . . . . . . 35
3.13 La liste des variable SUR Twinca t3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.14 La liste des variable SUR Twinca t3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1 diagramme analyse fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2 Schéma fonctionnel du système sous AutoCAD Plant 3D . . . . . . . . . . . . . . . . . 45
4.3 Architecture typique d’un projet TwinCAT 3 . . . . . . . . . . . . . . . . . . . . . . . 60
4.4 Représentation partielle du programme LineModes en SFC (TwinCAT 3) . . . . . . . . 62
4.5 Extrait du bloc fonctionnel abstrait Machine . . . . . . . . . . . . . . . . . . . . . . . . 63
4.6 Séquence de communication entre les GRAFCET de la ligne (avec la machine de remplissage)
et la partie préparation du produit (cuves) . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.7 Prototype N :01 d’IHM sur PowerPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.8 SUIT de Prototype N :01 d’IHM sur PowerPoint . . . . . . . . . . . . . . . . . . . . . 65
4.9 Essai de l’IHM dans l’environnement de simulation TwinCAT . . . . . . . . . . . . . . 66

iv
4.10 SUIT Essai de l’IHM dans l’environnement de simulation TwinCAT . . . . . . . . . . . 66
4.11 l’implémentation du protocole de communication entre les différents appareils du système
de la ligne de production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.1 PDCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2 Diagramme de GANTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.3 L’Agenda Quotidien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Annexe 2.1 Logo d’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Annexe 2.1 Logo d’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.2 Liste de chiffrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Annexe 2.1 Logo d’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Annexe 2.1 Logo d’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.4 Diagramme GEMMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Annexe 5.1 Logo d’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.5 LADDERS tep0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.6 LADDERS tep1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.7 LADDERS tep2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.8 LADDERS tep3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.9 LADDERS tep4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.10 LADDERS tep5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.11 LADDERS tep6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

v
Liste des tableaux

4.1 Types de cuves disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Capteurs utilisés pour le contrôle qualité . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 Spécification des tuyauteries utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4 Liste des électrovannes actives dans le processus . . . . . . . . . . . . . . . . . . . . . . 48
4.9 Étapes du processus automatisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

vi
Liste des abréviations
Campus des Métiers et des Qualifications d’Excellence Industrie du futur d’I-le-De
— CMQE-IDF
=
France
— GEMMA= Graphe d’Evénements, de Modes et de Mécanismes Associés

— IHM = Interface Homme-Machine

— RA = Réalité Augmentée

— RV = Réalité Virtuelle

vii
Introduction générale

L’évolution rapide des technologies industrielles a profondément transformé les méthodes de

production, en mettant au cœur des préoccupations des entreprises des notions telles que la performance,
la flexibilité, la qualité et la durabilité. Dans ce contexte, l’automatisation et la robotique industrielle
occupent une place de plus en plus stratégique. Elles permettent de répondre efficacement aux exigences
du marché tout en assurant la sécurité des opérateurs, la traçabilité des produits et l’optimisation des
ressources.
L’Industrie 4.0, ou quatrième révolution industrielle, repose sur la convergence des technologies
numériques, des systèmes cyber-physiques, de l’Internet des objets (IoT) et de l’intelligence artificielle.
Cette révolution transforme en profondeur les usines, les processus et les métiers. Dans cette dynamique,
les systèmes automatisés intelligents et les interfaces Homme-Machine (IHM) jouent un rôle
clé pour assurer la cohérence, la supervision et la prise de décision en temps réel.
C’est dans ce cadre que s’inscrit mon stage de fin d’études réalisé au sein du Centre d’Innovation
4.0 de l’Université d’Évry, qui constitue l’un des piliers technologiques du Campus des Métiers
et des Qualifications d’Excellence – Industrie du Futur Île-de-France (CMQ-IDF). Le
CMQ-IDF regroupe un réseau d’établissements de formation, de laboratoires de recherche et de partenaires
industriels, et a pour mission de favoriser la montée en compétences autour des technologies avancées
de production.
Le Centre d’Innovation 4.0 se présente comme une véritable usine-école, équipée de lignes
de production automatisées, de robots collaboratifs, de plateformes de réalité augmentée et virtuelle,
et de systèmes de supervision avancés. Il offre un environnement idéal pour expérimenter, concevoir et
valider des solutions technologiques dans un cadre pédagogique et industriel.
Le présent rapport retrace l’ensemble des travaux réalisés durant ce stage, qui ont porté sur la
modélisation, l’automatisation et le développement d’une ligne de fabrication de boissons.
Les principales missions ont consisté en l’élaboration des schémas P&ID, la modélisation 3D de
l’installation via AutoCAD Plant 3D, la conception des schémas électriques, le choix et la programmation
d’un automate Beckhoff, ainsi que la mise en place d’une interface IHM dédiée au pilotage du
système.
Au-delà de l’aspect technique, ce stage m’a permis de m’intégrer dans une équipe pluridisciplinaire,
de participer activement à des projets collaboratifs, et de mieux comprendre les exigences réelles de
l’automatisation industrielle dans un environnement professionnel.

1
 Chapitre 1

Découverte du CMQ-IDF et
Technologies Innovantes

Plan
1 Le Centre d’Innovation 4.0 d’Évry : un outil au service du CMQE IDF . . 4

2 Organigramme de l’équipe du Centre d’Innovation 4.0 . . . . . . . . . . . . 4

3 Structure et Organisation du CMQ-IDF . . . . . . . . . . . . . . . . . . . . . 4

4 Présentation des Lignes de Production et Technologies . . . . . . . . . . . 6

5 Missions et Activités Réalisées pendant le Stage . . . . . . . . . . . . . . . . 6

6 Veille Technologique et Projets Transversaux . . . . . . . . . . . . . . . . . 7

7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapitre 1. Découverte du CMQ-IDF et Technologies Innovantes

sectionLe Campus des Métiers et des Qualifications d’Excellence - Industrie du Futur Île-de-France
(CMQE IDF)

1.0.1 Définition et Objectifs

Le Campus des Métiers et des Qualifications d’Excellence (CMQE) Industrie du futur d’Île-de-France
est un réseau structurant au service de la transformation industrielle et numérique de la région. Il répond
à un enjeu économique stratégique régional en accompagnant les mutations de l’industrie à travers la
formation, l’emploi et l’innovation.
Le CMQE IDF a obtenu le label « Campus des Métiers et des Qualifications » le 1er août
2018 pour une durée de 4 ans, renforcé en 2022 par le label d’excellence. Ce label est attribué par
une commission interministérielle impliquant les rectorats, les ministères de l’Éducation nationale, de
l’Enseignement supérieur, du Travail et de l’Économie, ainsi que les collectivités territoriales.

1.0.2 Un Réseau de Partenaires

Porté par l’Université d’Évry, le CMQE IDF regroupe un large réseau francilien de partenaires
publics et privés, incluant :

— des établissements d’enseignement secondaire et supérieur,

— des centres de formation des apprentis (CFA),

— des laboratoires de recherche,

— des entreprises industrielles,

— les rectorats de Créteil, Versailles et Paris,

— la Région Île-de-France.

1.0.3 Missions du CMQE IDF

— Favoriser la montée en compétences des étudiants, des salariés en poste ou en reconversion.

— Soutenir l’innovation pédagogique et technologique dans la filière industrielle.

— Développer des passerelles entre formation initiale, continue, et besoins économiques.

— Contribuer à l’industrialisation et à la réindustrialisation grâce aux technologies de l’Industrie

du Futur.

3
Chapitre 1. Découverte du CMQ-IDF et Technologies Innovantes

1.1 Le Centre d’Innovation 4.0 d’Évry : un outil au service du

CMQE IDF

1.1.1 Présentation générale

Lieu totem du CMQE IDF, le Centre d’innovation 4.0 d’Évry est une plateforme technologique
de démonstration, de formation et de recherche dédiée à l’Industrie du Futur.
Il constitue une véritable usine-école où sont appliquées les technologies avancées de l’industrie
4.0 dans des conditions proches du réel. Ce centre symbolise la transition numérique et technologique
des entreprises industrielles.

1.1.2 Une plateforme technologique innovante

Le centre intègre une chaîne de production complète autour de l’assemblage et du désassemblage

de produits industriels tels que des sèche-linges et des scooters. Cette diversité permet de :

— illustrer la flexibilité des procédés industriels modernes,

— tester différentes configurations de production,

— sensibiliser aux enjeux de la durabilité et de l’économie circulaire.

1.1.3 Objectifs du centre

— Permettre la formation immersive des étudiants et professionnels aux technologies de l’Industrie

4.0.

— Proposer un espace d’expérimentation pour les projets collaboratifs entre laboratoires, entreprises
et formateurs.

— Servir de vitrine technologique pour démontrer l’impact des innovations (robotique, cobotique,
jumeaux numériques, IoT industriel, IA, etc.).

1.2 Organigramme de l’équipe du Centre d’Innovation 4.0

1.3 Structure et Organisation du CMQ-IDF

Le CMQ-IDF est structuré autour de pôles technologiques disposant d’équipements de pointe :

— Lignes de production industrielles (continue et discret) ;

— Laboratoires d’expérimentation et d’automatisation ;

4
Chapitre 1. Découverte du CMQ-IDF et Technologies Innovantes

— Espaces de formation collaboratifs ;

— Zones de démonstration pour les visites et ateliers pédagogiques.

1.3.1 Équipe du CMQ-IDF

L’équipe est composée de formateurs, d’ingénieurs et de chercheurs spécialisés en robotique,

réalité virtuelle/augmentée, automatisation et innovation industrielle.

Figure 1.1 : Organigramme de CMQeIDF

1.3.2 Partenaires Institutionnels et Industriels

Le CMQ-IDF collabore avec des partenaires stratégiques dans les domaines de l’automatisation,
de la connectivité et de l’intelligence artificielle :
Fournisseurs et partenaires industriels
Partenaires institutionnels : Gouvernement, Région Île-de-France, Grand Paris Sud, Territoires
d’Industrie, France 2030,

5
Chapitre 1. Découverte du CMQ-IDF et Technologies Innovantes

1.3.3 Présentation Visuelle des Partenaires

Figure 1.2 : Quelques partenaires industriels du Centre d’inovation d’évry 4.0

1.4 Présentation des Lignes de Production et Technologies

1.4.1 Ligne de Production avec un process discret

Cette ligne nécessite une configuration précise avant chaque démarrage :

— Mise sous tension des équipements ;

— Vérification des capteurs et systèmes de sécurité ;

— Calibration et synchronisation des robots.

1.4.2 Technologies Innovantes Disponibles

— Robot collaboratif Baxter : utilisé pour la formation, l’automatisation flexible et les démonstrations
pédagogiques.

— Réalité augmentée (RA) avec HoloLens : superposition d’éléments virtuels dans un environnement
réel.

— Réalité virtuelle (VR) avec HTC Vive : immersion complète pour la formation et la
simulation industrielle.

— Robot mobile autonome MiR : logistique interne, transport automatisé et reconfiguration

rapide.

1.5 Missions et Activités Réalisées pendant le Stage

1.5.1 Tâches techniques sur la ligne de production

— Supervision du démarrage de la ligne discontinue ;

— Réglage et assurés le bons états des informations échangées avec les autres systèmes des équipements ;

— Application des procédures de sécurité.

6
Chapitre 1. Découverte du CMQ-IDF et Technologies Innovantes

1.5.2 Animation d’ateliers technologiques

— Réalité augmentée et réalité virtuelle ;

— Présentation des robots collaboratifs (ex : Baxter) ;

— Démonstrations des robots mobiles MiR.

1.5.3 Formation des stagiaires et opérateurs

— Encadrement des stagiaires sur la ligne de production (scutere et séchlenge) ;

— Ateliers de sensibilisation à la sécurité industrielle ;

— Sessions de formation sur la conception mécanique (via des logiciels comme SolidWorks, 3D
Dassault systémes , etc.).

1.5.4 Animation de visites au sein du centre

Participation active à la présentation du centre d’innovation aux visiteurs (élèves, professeurs,

professionnels), en valorisant les projets du CMQ et les nouvelles technologies.

1.5.5 Participation aux réunions hebdomadaires

Tous les vendredis, je prends part à des réunions d’équipe afin de proposer des solutions
innovantes, contribuer à l’amélioration continue du centre et échanger sur les axes de développement.

1.6 Veille Technologique et Projets Transversaux

— Recherches sur les dernières tendances en robotique, RA/VR et intelligence artificielle ;

— Analyse des nouvelles solutions logicielles en automatisation industrielle ;

— Détection des outils pouvant être intégrés aux formations futures.

1.7 Conclusion

Ce premier chapitre m’a permis de découvrir le fonctionnement du CMQ-IDF, ses installations,

ses partenaires et ses ambitions. Grâce à l’encadrement reçu et aux ressources technologiques mises à
disposition, j’ai pu contribuer à diverses missions et enrichir mes compétences. Ce cadre d’innovation
représente un véritable atout pour comprendre les enjeux de l’industrie 4.0 avant d’aborder, dans le
prochain chapitre, mon travail sur l’intégration d’une nouvelle ligne de production continue.

7
 Chapitre 2

Automatisation et intégration d’une

nouvelle ligne de fabrication de
boissons

Plan
1 Schéma P&ID : Modélisation et Conception . . . . . . . . . . . . . . . . . . 9

2 Schémas Électriques : Étude et Conception . . . . . . . . . . . . . . . . . . . 10

3 Choix de la tuyauterie et modélisation de l’installation . . . . . . . . . . . 11

4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Chapitre 2. Automatisation et intégration d’une nouvelle ligne de fabrication de boissons

II.1 Introduction

Dans ce chapitre, nous présentons notre projet portant sur l’automatisation et l’intégration
d’une nouvelle ligne de fabrication de boissons non alcoolisées. Cette initiative s’inscrit dans une
démarche d’optimisation industrielle visant à améliorer la productivité, la qualité, la traçabilité et
la sécurité dans l’environnement de production.
La ligne de production envisagée est constituée de deux phases principales :

— La phase de préparation du produit : elle comprend le dosage, le mélange et le traitement

de la boisson, en fonction de paramètres physico-chimiques tels que le pH, la viscosité et le
niveau de coloration.

— La phase de remplissage ( conditionnement automatisé) : elle assure le conditionnement

automatique du produit dans des bouteilles de 50 cl, en respectant des normes strictes d’hygiène
et de précision de volume.

La mise en place d’un tel système de production en continu nécessite une étude d’installation
rigoureuse dès les premières étapes du projet. Cette phase initiale est essentielle pour garantir une
conception efficace, sécurisée et conforme aux exigences industrielles. Étant donné que certains équipements,
tels que les cinq cuves de préparation, étaient déjà disponibles, notre travail a débuté par l’élaboration
du schéma PID (Piping and Instrumentation Diagram), qui représente l’ensemble des équipements, des
canalisations, ainsi que les instruments de mesure et de contrôle du procédé.
Cette modélisation a ensuite été complétée par la conception des schémas électriques indispensables
à l’automatisation de l’installation. Pour ce faire, nous avons utilisé deux logiciels développés par
Autodesk : AutoCAD Electrical, pour la réalisation des schémas électriques détaillés, et AutoCAD
Plant 3D, pour la modélisation des installations de tuyauterie et d’instrumentation en trois dimensions.
L’utilisation conjointe de ces outils nous a permis d’assurer une intégration cohérente et conforme aux
standards industriels.
Les sections suivantes détaillent les différentes étapes de conception, les logiciels utilisés, les choix
techniques effectués, ainsi que les tâches concrètes menées dans le cadre de ce projet d’automatisation.

2.1 Schéma P&ID : Modélisation et Conception

Le schéma P&ID représente les connexions entre les différents équipements, notamment les
cuves, les pompes, les vannes et les capteurs. Il permet de :

— Visualiser les flux de liquides dans le système.

— Identifier les équipements principaux et leur interconnexion.

9
Chapitre 2. Automatisation et intégration d’une nouvelle ligne de fabrication de boissons

— Faciliter l’intégration des instruments de mesure et de contrôle.

Figure 2.1 : PID

2.1.1 Méthodologie de Réalisation

— 1 Recensement des équipements disponibles et de leur disposition.

— 2 Identification des connexions nécessaires (tuyauterie, capteurs, vannes).

— 3 Utilisation de AutoCAD Electrical 2025 pour la conception du schéma.

— 4 Validation du schéma avec les normes industrielles en vigueur.

2.2 Schémas Électriques : Étude et Conception

Après l’élaboration du schéma P&ID, nous avons conçu les schémas électriques permettant
l’automatisation du processus. Ceux-ci incluent :

— L’alimentation et la distribution électrique des équipements.

— Le câblage des capteurs et actionneurs.

— L’intégration des automates programmables (PLC) pour la gestion du process.

2.2.1 Utilisation de AutoCAD Electrical 2025

L’outil permet de générer des schémas électriques précis en intégrant des bibliothèques de
composants standards. Les étapes de conception incluent :

— Définition des circuits électriques et de leur alimentation.

10
Chapitre 2. Automatisation et intégration d’une nouvelle ligne de fabrication de boissons

— Insertion des composants (contacteurs, relais, automates, capteurs).

— Numérotation et annotation des fils pour assurer une lisibilité optimale.

— Génération de la nomenclature et des câblages nécessaires.

2.3 Choix de la tuyauterie et modélisation de l’installation

Après avoir identifié les équipements déjà disponibles, notamment les cinq cuves de préparation,
notre travail s’est concentré sur le choix des éléments de tuyauterie nécessaires pour assurer les
connexions entre ces différentes unités. Cette étape est essentielle afin de garantir un écoulement
optimal du produit, tout en respectant les contraintes d’espace, d’hygiène et de maintenance.
Nous avons utilisé le logiciel AutoCAD Plant 3D pour modéliser l’ensemble de l’installation
et déterminer avec précision :

— Les distances entre les cuves, en tenant compte de leur position réelle dans l’atelier de production ;

— Les hauteurs de passage des tuyaux, pour assurer un bon écoulement par gravité ou via
pompage, tout en évitant les conflits avec d’autres équipements ou structures ;

— Le diamètre des tuyaux, défini en fonction du débit requis, de la nature du produit (viscosité,
pression) et des normes sanitaires applicables ;

— Les types de raccords et de matériaux, adaptés aux produits alimentaires, avec une préférence
pour l’acier inoxydable en raison de sa résistance à la corrosion et sa conformité aux normes
d’hygiène.

La modélisation 3D nous a permis d’anticiper les contraintes techniques, d’optimiser l’agencement

de la tuyauterie et d’obtenir une estimation précise de la longueur totale de tuyaux nécessaires à
l’installation. Cette étape a également facilité la validation du design par les responsables techniques
avant le passage à la phase d’implémentation.

11
Chapitre 2. Automatisation et intégration d’une nouvelle ligne de fabrication de boissons

Figure 2.2 : Modélisation 3D des cuves – première configuration

Une fois cette phase de conception et de modélisation de la tuyauterie finalisée, l’ensemble du

réseau est relié directement à la machine de remplissage située en aval du procédé. Cette machine
constitue le point d’entrée de la seconde partie de la ligne de production, à savoir la ligne robotisée
de conditionnement. Cette liaison a été conçue de manière à assurer une continuité de flux sans
perte de produit, avec un contrôle précis des débits, en vue de garantir une alimentation stable et
homogène de la ligne de remplissage automatisée.

12
Chapitre 2. Automatisation et intégration d’une nouvelle ligne de fabrication de boissons

Figure 2.3 : Schéma de principe de fonctionnement de la ligne de production

Comme illustré dans la figure 2.3, la ligne de production est structurée en deux grandes parties.
La première concerne la préparation du produit, réalisée au niveau des cuves, interconnectées
par un réseau de tuyauterie conçu à l’aide du logiciel AutoCAD Plant 3D.
La seconde partie est dédiée à la ligne de remplissage robotisée, où le produit est automatiquement
conditionné dans des bouteilles grâce à une machine de remplissage assistée par un robot
collaboratif (Cobot).
Ce schéma met en évidence les flux de matière ainsi que les liaisons fonctionnelles entre
les différentes unités de l’installation.

Par ailleurs, l’analyse du processus et des observations terrain a permis de représenter la logique
de fonctionnement de cette ligne, découpée en cinq phases principales :

• Phase 1 : Approvisionnement des bouteilles vides

Le cobot prélève les bouteilles vides depuis une caisse, puis les place dans des godets destinés
au remplissage.

• Phase 2 : Remplissage
Les bouteilles, positionnées dans les godets, sont remplies automatiquement à l’aide d’une
machine de remplissage.

• Phase 3 : Pose des bouchons

Le cobot saisit les bouchons et les dépose sur les bouteilles pleines.

13
Chapitre 2. Automatisation et intégration d’une nouvelle ligne de fabrication de boissons

• Phase 4 : Bouchage automatique

Les bouteilles passent dans une machine de bouchage qui fixe et visse les bouchons.

• Phase 5 : Palettisation
Les bouteilles bouchées sont ensuite palettisées dans des caisses vides, prêtes à être stockées
ou expédiées.

2.4 Conclusion

La réalisation des schémas P&ID et électriques constitue une étape fondamentale dans le
développement de la ligne de process continu. Ces documents servent de base pour l’étape suivante,
qui concernera l’étude du logiciel de contrôle et l’implémentation de l’automatisation du système.

14
 Chapitre 3

Introduction aux Systèmes

Automatisés

Plan
1 Introduction aux Systèmes Automatisés . . . . . . . . . . . . . . . . . . . . . 16

2 Les Automates Programmables Industriels (API) . . . . . . . . . . . . . . . 21

3 Évolution et historique des automates programmables . . . . . . . . . . . . 21

4 Utilisation des automates programmables . . . . . . . . . . . . . . . . . . . . 22

5 Les types d’automates programmables industriels . . . . . . . . . . . . . . . 27

6 Normalisation de la programmation des automates : la norme CEI 61131-3 28

7 Les langages de programmation d’un API . . . . . . . . . . . . . . . . . . . 29

8 Interface Homme-Machine (HMI) . . . . . . . . . . . . . . . . . . . . . . . . 37

Chapitre 3. Introduction aux Systèmes Automatisés

3.1 Introduction aux Systèmes Automatisés

3.1.1 Introduction

L’automatisation désigne l’ensemble des techniques permettant de rendre automatiques des

opérations autrefois réalisées manuellement. Elle vise à remplacer, totalement ou partiellement, l’intervention
humaine dans des tâches généralement simples, répétitives, mais exigeant précision, rigueur et régularité.
Historiquement, l’évolution s’est faite en plusieurs étapes : on est passé de systèmes manuels,
dans lesquels l’opérateur effectuait directement l’action, à des systèmes mécanisés où les outils assistaient
l’humain, pour enfin atteindre les systèmes automatisés, capables de fonctionner de manière autonome
selon un cycle défini.
Aujourd’hui, les systèmes automatisés sont omniprésents, que ce soit dans l’industrie, les transports,
la domotique ou encore les services. Comprendre leur fonctionnement est devenu essentiel pour s’adapter
aux environnements technologiques modernes et pour concevoir des solutions innovantes et efficaces.

3.1.2 Définition des Systèmes Automatisés

Un système est dit automatisé lorsqu’il est capable d’exécuter un cycle de travail de manière
autonome, après avoir reçu une consigne initiale de la part d’un opérateur. Ce dernier se limite
généralement à des fonctions de supervision, comme le démarrage ou l’arrêt du processus.
Le système automatisé réalise ensuite une suite d’opérations logiques et/ou physiques, selon une
séquence prédéfinie, sans nécessiter d’intervention humaine durant le déroulement du cycle. Il s’appuie
pour cela sur des dispositifs de commande (tels que les automates programmables), des capteurs, des
actionneurs, et parfois une interface homme-machine (IHM) pour l’interaction et la surveillance.

3.1.3 Description d’un Système Automatisé

Un système automatisé se compose généralement de trois sous-ensembles principaux, chacun

jouant un rôle spécifique dans le fonctionnement global du système :

— La Partie Commande (PC) : Il s’agit du cerveau du système. Elle assure la gestion et la

coordination de l’ensemble du processus automatisé. Elle prend en compte les informations
provenant des capteurs, traite les données selon un programme prédéfini, puis envoie les ordres aux
actionneurs. La partie commande est souvent constituée d’un automate programmable industriel
(API), d’un microcontrôleur, ou d’un système informatique embarqué.

— La Partie Opérative (PO) : C’est la partie physique du système automatisé. Elle comprend
l’ensemble des éléments qui réalisent concrètement les actions : moteurs, vérins, convoyeurs,

16
Chapitre 3. Introduction aux Systèmes Automatisés

machines-outils, etc. Elle reçoit les ordres de la PC et agit sur l’environnement réel. Elle comprend
aussi les capteurs qui informent la PC sur l’état du système.

— La Partie Dialogue (Interface Homme-Machine - IHM) : Elle permet la communication

entre l’utilisateur (opérateur ou technicien) et la machine. Cette interface peut être un écran
tactile, un pupitre de commande, un tableau de bord ou un logiciel de supervision. Elle permet
d’afficher des informations en temps réel, de saisir des consignes, et de surveiller l’état du système.

Figure 3.1 : Structure d’un système automatisé

3.1.4 La partie commande

La partie commande d’un système automatisé a pour rôle principal de transmettre des ordres
aux actionneurs. Ces ordres sont générés à partir des informations reçues des capteurs, des consignes
saisies par l’opérateur, ou bien issues du programme embarqué dans le système.
Cette unité est généralement constituée de pré-actionneurs, ainsi que d’ordinateurs industriels
intégrant des mémoires et des programmes. L’élément central de cette structure est souvent un automate
programmable industriel (API), qui est un ordinateur spécialisé conçu pour le pilotage de systèmes
automatisés source1.
Parmi les pré-actionneurs les plus couramment utilisés, on retrouve :

— les contacteurs pour le contrôle des moteurs électriques ;

17
Chapitre 3. Introduction aux Systèmes Automatisés

— les distributeurs pour le pilotage des vérins pneumatiques ou hydrauliques, etc.

Ces dispositifs ont pour fonction d’acheminer l’énergie (qu’elle provienne du réseau électrique,
de batteries, ou de systèmes pneumatiques/hydrauliques) vers les actionneurs. Ils permettent ainsi
l’exécution d’un mouvement précis, conforme aux besoins du processus .

Figure 3.2 : Exemples de Pré-actionneurs

3.1.5 La partie opérative

Appelée aussi partie puissance d’un système automatisé, c’est la partie qui effectue et exécute
les ordres reçus de la partie commande. Elle consomme selon le type de technologie utilisé de l’énergie
électrique, pneumatique ou hydraulique, elle comporte des capteurs et des actionneurs .

3.1.5.1 a) Actionneurs

Les actionneurs sont le plus souvent des moteurs, des électrovannes, des vérins, capables de
produire un phénomène physique, tel qu’un déplacement linéaire ou rotatif, un dégagement de chaleur
ou une émission de lumière à partir de l’énergie qu’ils reçoivent .

18
Chapitre 3. Introduction aux Systèmes Automatisés

Figure 3.3 : Exemples d’Actionneurs

3.1.5.2 b) Capteurs

Un capteur est un élément de la partie opérative qui permet de recueillir des informations et de
les transmettre à la partie commande, il est capable de détecter avec ou sans contact un phénomène
physique dans son environnement (présence ou déplacement d’un objet, chaleur, lumière).

Figure 3.4 : Exemples de Capteurs

19
Chapitre 3. Introduction aux Systèmes Automatisés

3.1.6 La partie dialogue

Elle représente le pupitre de dialogue homme-machine équipé des organes de commande permettant
la mise en/hors énergie de l’installation, la sélection des modes de marche, la commande manuelle des
actionneurs, la mise en référence, le départ des cycles, l’arrêt d’urgence, etc. Elle permet également
la visualisation de l’état du processus à tout instant. Elle doit être sous tension dans le cas d’une
technologie câblée et en mode « RUN » du programme en cas d’une technologie programmée

3.1.7 Le but de l’automatisme

— Effectuer une production qualitative. (Pas d’erreur humaine : Zéro défaut.) ;

— Effectuer une production quantitative. (rapidité) ;

— Suppression des tâches ou actions physiques peu ou pas gratifiantes pour l’homme ;

— Pouvoir accéder à des milieux de travail hostiles. (chimique, nucléaires . . .) ou des sites inaccessibles
à l’homme (mer, espace) ;

— Augmenter la sécurité ;

— Superviser les installations et les machines et les processus de production source1.

Nous comptons quatre révolutions industrielles :

— La première au XVIIIe siècle avec la machine à vapeur,

— Puis l’arrivée de l’électricité à la fin du XIXe siècle,

— La troisième au XXe siècle avec les automates programmables et l’internet,

— La quatrième serait sûrement fondée sur l’usine intelligente.

Tout au début, les parties commandes étaient réalisées avec une technologie câblée basée
sur l’utilisation de l’électronique, des relais électromagnétiques et de systèmes pneumatiques où ces
différentes parties étaient interconnectées par un câblage représentatif de la machine.
En rapport avec les contraintes technologiques d’un circuit câblé, ce type d’équipement présente
des inconvénients tels qu’un manque de souplesse compliquant la mise au point du dispositif et rendant
difficile toute modification. Le câblage des séquenceurs est parfois très complexe et encombrant lorsque
plusieurs coffrets ou armoires sont nécessaires pour la protection mécanique des châssis, ajouté à cela,
la difficulté d’y intégrer des fonctions externes, telles que des temporisateurs, des compteurs ou des
multiplexeurs. La réalisation en logique câblée représente une solution figée qui nécessite d’être reprise
intégralement en cas de modification du cycle de fonctionnement du système automatisé.
L’avènement de la technologie programmée, notamment avec l’apparition des automates programmables,
permet une meilleure fluidité vis-à-vis des modifications à effectuer, car il s’agit de remplacer seulement

20
Chapitre 3. Introduction aux Systèmes Automatisés

le programme à exécuter et contient aussi des fonctions internes à l’automate, telles que des temporisateurs,
compteurs décompteurs, fonctions logiques, etc.
En logique programmée, le fonctionnement d’un équipement initialement représenté par un
schéma électrique à contact, un logigramme ou un diagramme fonctionnel est traduit en équations
booléennes et en un programme d’instructions. Dans la méthode générale de conception en logique
programmée, l’algorithme et sa représentation graphique en algorigramme permettent de bien définir la
structure générale des différents programmes. L’évolution de la logique programmée est liée à l’évolution
des opérateurs complexes en technologie intégrée .

3.2 Les Automates Programmables Industriels (API)

3.3 Évolution et historique des automates programmables

Au-delà de leur intérêt technologique, comprendre les origines et l’évolution des automates
programmables est essentiel pour saisir leur rôle actuel dans l’industrie. L’introduction de nouvelles
technologies dans le secteur industriel est souvent freinée par la complexité de la formation du personnel,
ce qui explique la persistance de certains paradigmes de programmation aujourd’hui dépassés mais
encore utilisés.
L’histoire moderne du contrôle automatisé débute au xviie siècle avec les premiers régulateurs de
vitesse mécaniques employés dans les moulins, puis s’enrichit au xviiie siècle avec les machines à vapeur.
Au début du xxe siècle, l’essor de l’électricité et des techniques de traitement du signal permet la mise
au point des régulateurs PID (Proportionnel, Intégral, Dérivé), capables de maintenir automatiquement
une trajectoire ou une consigne — comme celle d’un navire — malgré des perturbations externes (vent,
courants, etc.).
Parallèlement, apparaissent les systèmes de logique câblée, ou logique à relais, fondés sur
l’utilisation de relais électromagnétiques commutant les signaux selon une logique prédéfinie. Ces
systèmes, purement combinatoires, ont dominé l’industrie jusqu’à la fin des années 1960. Face à la
complexité croissante des lignes de production et à la nécessité d’adaptabilité, un ingénieur de General
Motors a formulé le besoin d’un système reconfigurable sans modifications physiques constantes des
relais ou des câblages. En réponse, l’entreprise Bedford Associates a conçu en 1969 le premier PLC
(Programmable Logic Controller) baptisé MODICON (MOdular DIgital CONtroller ).
Initialement programmés en langage assembleur ou en Fortran, les PLC ont rapidement
adopté un langage graphique inspiré de la logique à relais : le ladder diagram. Ce choix visait à faciliter
leur prise en main par les automaticiens sans nécessiter une formation approfondie en programmation
informatique.

21
Chapitre 3. Introduction aux Systèmes Automatisés

Aujourd’hui, de nombreux fabricants proposent des automates avec leurs propres environnements
de programmation et architectures matérielles. Pour répondre à cette diversité et favoriser l’interopérabilité,
la norme CEI 61131-3 a été introduite. Elle définit un ensemble de langages standards pour la
programmation des automates, facilitant ainsi leur utilisation dans des environnements industriels
hétérogènes.

3.4 Utilisation des automates programmables

Les automates programmables industriels (PLC : Programmable Logic Controllers) sont largement
utilisés dans l’industrie pour le contrôle et la supervision de processus automatisés. Ils permettent
d’assurer le bon déroulement d’une séquence d’actions, en activant des sorties digitales ou analogiques
selon une logique déterminée. De plus, ils intègrent les signaux provenant de capteurs — connectés
aux entrées du système — afin d’adapter le comportement de la chaîne de production, notamment en
matière de sécurité.
Le choix d’un PLC dépend de plusieurs critères : la facilité d’implémentation, les fonctionnalités
attendues, le coût, ainsi que la fiabilité. En effet, certaines applications critiques requièrent des contrôleurs
conformes à des normes strictes de sûreté et de fonctionnement. La figure 3.5 illustre les différentes
solutions de contrôle envisagées selon les exigences fonctionnelles du système.
Un aspect important dans cette évolution est l’émergence de solutions hybrides : certains
automates récents intègrent désormais une couche logicielle s’exécutant sur un environnement de type
PC. Cette architecture combine les avantages d’un ordinateur classique (interface graphique, traitement
de données avancé) avec la robustesse et la sécurité des systèmes industriels.
Cependant, les différences fondamentales entre un PLC et un ordinateur persistent. Alors qu’un
programme sur PC s’exécute linéairement jusqu’à la fin de l’instruction, un automate PLC exécute
l’intégralité de son code à chaque cycle d’horloge. Cette exécution cyclique permet une mise à jour
continue des états de sortie à partir des entrées lues, assurant ainsi une réactivité et une cohérence
nécessaires au bon fonctionnement d’un système automatisé.

3.4.1 Architecture des Automates Programmables

3.4.1.1 Présentation Générale

L’apparence extérieure des automates programmables varie selon les fabricants et les modèles,
mais leur configuration peut généralement être classée en deux grandes catégories : les automates de
type compact et les automates de type modulaire.

22
Chapitre 3. Introduction aux Systèmes Automatisés

Figure 3.5 : Solutions de contrôle selon les fonctionnalités requises

3.4.1.2 Automates de Type Compact

Les automates dits compacts sont aussi appelés micro-automates. Ils regroupent dans un seul
boîtier l’ensemble des composants essentiels :

— le processeur (unité centrale de traitement) ;

— le bloc d’alimentation ;

— les modules d’entrées et de sorties numériques ou analogiques.

Ce type d’automate est capable d’exécuter des fonctions simples telles que le comptage rapide
ou le traitement de signaux analogiques. Il est parfois possible d’ajouter quelques modules d’extension,
mais leur capacité d’évolution reste limitée.
Les automates compacts sont principalement utilisés pour piloter de petits systèmes automatisés,
où les exigences en termes de traitement et de modularité sont réduites. Leur simplicité d’installation

23
Chapitre 3. Introduction aux Systèmes Automatisés

et leur faible coût en font une solution idéale pour les applications locales et autonomes.

Figure 3.6 : Architecture compacte des automates programmables

3.4.1.3 Automates de Type Modulaire

Les automates dits modulaires sont constitués de plusieurs éléments distincts :

— un module processeur (CPU) ;

— un module d’alimentation électrique ;

— des modules d’entrées/sorties numériques ou analogiques ;

— des connecteurs et un bus de communication interne assurant l’échange de données entre les
différents modules.

Cette architecture modulaire permet une grande flexibilité. L’utilisateur peut adapter la configuration
de l’automate en fonction des besoins spécifiques de l’application : ajout de nouveaux modules, remplacement
de composants défectueux, ou extension du système.
Les automates modulaires sont principalement utilisés dans les installations industrielles complexes
qui exigent une puissance de traitement élevée, une grande capacité de mémoire, et de nombreuses
entrées/sorties. Ils sont également adaptés aux systèmes évolutifs où les besoins peuvent changer avec
le temps.

24
Chapitre 3. Introduction aux Systèmes Automatisés

Figure 3.7 : Architecture modulaire des automates programmables

3.4.1.4 Architecture interne des automates programmables

Qu’ils soient de type compact ou modulaire, les automates programmables industriels (API)
sont composés de plusieurs sous-ensembles fondamentaux assurant leur fonctionnement :

— L’unité centrale de traitement (CPU) : elle exécute les opérations logiques et arithmétiques
à partir du programme enregistré en mémoire. Elle traite les variables issues des entrées et génère
les ordres de commande à appliquer aux actionneurs.

— La tête de rack (ou tête de bac) : elle assure la communication entre l’unité centrale et
les différents modules d’interface. Elle gère également l’alimentation et la synchronisation du
système.

25
Chapitre 3. Introduction aux Systèmes Automatisés

— Les modules d’entrées : ces interfaces permettent de recevoir les signaux provenant des
capteurs (capteurs de position, de température, de présence, etc.). Ces signaux sont ensuite
convertis dans un format compréhensible par l’automate.

— Les modules de sorties : ils traduisent les ordres issus du programme de l’API en signaux
électriques exploitables par les actionneurs (moteurs, vérins, électrovannes, etc.), permettant
ainsi la réalisation des opérations physiques.

3.4.1.5 Détails des composants fonctionnels de l’automate programmable

Les automates programmables industriels (API) se composent de divers éléments fonctionnels

indispensables à leur bon fonctionnement. Ces éléments sont détaillés comme suit :

a) L’unité centrale de l’automate (CPU)

La CPU est le cœur de l’automate. Elle se compose de :

— L’unité de traitement (UT) : également appelée processeur ou unité arithmétique et logique

(UAL), elle assure le contrôle global de l’automate et exécute les traitements logiques définis dans
le programme. Elle est connectée aux mémoires et aux interfaces E/S par des bus parallèles.

— La mémoire centrale : elle permet de stocker des instructions, des données et le logiciel de
base. On y distingue plusieurs types :

— RAM (Random Access Memory) : mémoire vive, rapide, mais volatile.

— ROM (Read Only Memory) : mémoire morte, non volatile.

— PROM : programmable une seule fois.

— EPROM : effaçable par rayonnement UV.

— EEPROM : effaçable électriquement.

— Zone programme : de type RAM, elle contient les instructions à exécuter.

— Zone de données : elle contient :

— les variables d’entrée acquises ;

— les variables intermédiaires et résultats ;

— les données de sortie.

b) Bus de liaison
Le bus est un ensemble de connexions (souvent sur un circuit imprimé) reliant les différents éléments
de l’automate : CPU, mémoire et modules E/S. Les cartes électroniques appelées coupleurs assurent
les interfaces avec le procédé.

26
Chapitre 3. Introduction aux Systèmes Automatisés

c) Système d’entrées/sorties (E/S)

Ce système permet la communication entre l’automate et le procédé :

— Interfaces d’entrées :

— Entrées TOR (tout ou rien) : boutons, interrupteurs, capteurs de position.

— Entrées analogiques : convertisseur analogique/numérique (CAN), pour tensions ou courants

variables (ex : potentiomètre, débitmètre).

— Interfaces de sorties :

— Sorties TOR : pour actionneurs comme contacteurs ou voyants.

— Sorties analogiques : convertisseur numérique/analogique (CNA), pour générer des signaux

analogiques.

d) Périphériques de l’automate programmable

— Console de programmation : permet l’édition, le téléchargement et la modification du programme.

— Boîtier test : utilisé pour :

— visualiser et exécuter manuellement des instructions ;

— afficher le contenu de registres ou l’état logique du programme.

— Unité de dialogue en ligne (UDEL) :

— modification de constantes ;

— réglage de temporisations ;

— accès sécurisé aux paramètres.

— Imprimante parallèle : pour éditer des résultats de fonctionnement ou des messages d’erreur.

3.5 Les types d’automates programmables industriels

3.5.1 Les automates de petite gamme

Les automates de petite gamme sont principalement conçus pour des applications simples.
Leur nombre d’entrées/sorties (E/S) ne dépasse généralement pas 48. Ces automates se présentent
dans des boîtiers compacts où tous les modules (CPU, alimentation, modules d’E/S et interfaces de
communication) sont intégrés dans un seul boîtier. Ils ne disposent d’aucune possibilité d’extension, ce
qui les rend adaptés à des systèmes peu complexes .

27
Chapitre 3. Introduction aux Systèmes Automatisés

3.5.2 Les automates de moyenne gamme

Les automates de moyenne gamme sont conçus pour des applications de taille moyenne, où le
nombre d’entrées/sorties peut atteindre jusqu’à 400. Ces automates possèdent une structure modulaire
qui permet une certaine extensibilité, offrant ainsi une flexibilité pour s’adapter à des besoins croissants
en termes de capacité et de fonctionnalités .

3.5.3 Les automates de haute gamme

Les automates de haute gamme sont des systèmes hautement performants, capables de gérer
jusqu’à 2024 E/S, voire plus. Ils disposent d’une architecture modulaire, offrant une grande souplesse
d’adaptation aux besoins complexes et évolutifs des industries de grande envergure. Ces automates
sont utilisés dans des applications nécessitant des performances exceptionnelles et une haute fiabilité .

3.6 Normalisation de la programmation des automates : la norme

CEI 61131-3

3.6.1 Contexte et motivations de la normalisation

Depuis leur apparition, les automates programmables industriels (PLC) ont été développés par
différents constructeurs, chacun proposant ses propres langages de programmation, avec des mots-clés,
syntaxes et logiques spécifiques. Cette diversité a engendré une certaine complexité pour les automaticiens
amenés à travailler sur des automates de marques différentes, rendant difficile la standardisation des
compétences et la portabilité des programmes.
Dans un contexte industriel en pleine transformation vers l’industrie 4.0, où l’interopérabilité
entre équipements est devenue essentielle, cette hétérogénéité des langages constituait un obstacle
majeur. Pour répondre à ce besoin croissant de compatibilité et de flexibilité, une initiative de normalisation
a vu le jour.
En 1993, la Commission Électrotechnique Internationale (CEI) a introduit la norme CEI
61131-3, visant à définir un standard international pour la programmation des automates. Cette
norme a été mise à jour en 2013 afin de mieux répondre aux exigences modernes. Elle impose aux
fabricants de PLC de proposer un environnement compatible avec cinq langages de programmation
standards, facilitant ainsi la formation, la maintenance et la migration entre différents systèmes.

28
Chapitre 3. Introduction aux Systèmes Automatisés

3.7 Les langages de programmation d’un API

Les langages utilisés pour la programmation des automates programmables industriels (API) ont
pour objectif d’être accessibles à tout technicien après une formation relativement courte. La rédaction
d’un programme consiste à élaborer une liste d’instructions permettant l’exécution des opérations
nécessaires au bon fonctionnement du système . Actuellement, les API intègrent en tout ou en partie
les langages de programmation suivants :

3.7.1 Langage LD (Ladder Diagram) : Programmation graphique inspirée

des relais

Le Ladder Diagram (LD) est un langage de programmation graphique dérivé historiquement des
schémas à relais électromécaniques. Il a été conçu pour reproduire visuellement le fonctionnement des
circuits électriques classiques, ce qui le rend particulièrement intuitif pour les électriciens et techniciens
de maintenance.

Dans un programme LD, les réseaux sont lus et exécutés de haut en bas, simulant un courant
de puissance qui circule de la gauche (alimentation) vers la droite (sorties). Chaque réseau est constitué
d’un ensemble de contacts (entrées) et de bobines (sorties), reliés entre eux par des lignes verticales et
horizontales symbolisant des connexions électriques.

Bien que le Ladder Diagram soit centré sur les signaux binaires, il permet également l’intégration
de blocs de fonctions spécifiques comme les temporisateurs (TON, TOF) ou les blocs de contrôle tels que
SET et RESET. Les instructions de saut, de branchement conditionnel ou de rétroaction sont également
gérables, souvent de manière implicite.

Un exemple typique de réseau LD est illustré à la Figure 3.8, dans lequel un bloc de fonction
RESET est utilisé pour modifier l’état d’une variable booléenne déterminant une direction.

Figure 3.8 : Exemple d’un réseau Ladder utilisant un bloc RESET pour définir la direction.

Il est important de noter que le langage LD est historiquement plus utilisé aux États-Unis
qu’en Europe. Une version enrichie y a d’ailleurs été développée, bien que les extensions spécifiques à

29
Chapitre 3. Introduction aux Systèmes Automatisés

cette version ne soient généralement pas incluses dans la norme CEI 61131-3.

Figure 3.9 : Exemples de Ladder Diagram

3.7.2 Langage FBD (Function Block Diagram)

Le langage FBD permet la programmation graphique via des blocs fonctionnels, soit prédéfinis,
soit personnalisables, qui sont reliés entre eux pour réaliser des opérations complexes. Ce langage
est particulièrement adapté pour modéliser des systèmes à logique complexe en associant des blocs
d’exécution pour différentes fonctions .

3.7.3 Langage List IL (Instruction List)

Le langage IL est très proche de l’assembleur et permet d’utiliser l’intégralité des fonctions
d’un API. Tous les programmes définis dans d’autres langages sont compilés sous forme d’IL. Il est
principalement utilisé dans des contextes où des opérations bas-niveau ou des performances optimisées
sont requises .

30
Chapitre 3. Introduction aux Systèmes Automatisés

3.7.4 Langage littéral structuré ST (Structured Text)

Le langage ST, également connu sous le nom de SCF (Structured Control Language), présente
des similitudes avec le langage C. Il est structuré et convient particulièrement bien pour les applications
nécessitant des calculs complexes ou le traitement de chaînes de caractères. Ce langage permet de
programmer une large gamme d’algorithmes, qu’ils soient simples ou plus sophistiqués .

3.7.5 Langage GRAFCET

Le GRAFCET (GRAphe Fonctionnel de Commande des Étapes et Transitions), également

connu sous le nom de Sequential Function Chart (SFC), est un outil graphique qui permet de décrire les
différents comportements et l’évolution d’un automatisme. Il constitue une méthode de représentation
et d’analyse particulièrement adaptée aux systèmes à évolution séquentielle, c’est-à-dire décomposables
en étapes successives. Ce langage est largement utilisé pour modéliser des processus automatisés ayant
une progression logique et ordonnée, facilitant ainsi la compréhension et la gestion des différentes phases
d’un système automatisé .

Figure 3.10 : Exemples de GRAFCET programmation

31
Chapitre 3. Introduction aux Systèmes Automatisés

Figure 3.11 : Exemples de langages de programmation

3.7.6 Comparaison

Dans le cadre du développement d’une application conforme à la norme IEC 61131-3, plusieurs
langages sont disponibles, chacun présentant des forces spécifiques selon le type d’opération à réaliser.
Pour notre projet, nous avons choisi de travailler conjointement avec le Ladder et le GRAFCET,
car ces deux langages se complètent efficacement.
Le GRAFCET permet de modéliser clairement les séquences et étapes d’un processus automatisé,
facilitant la représentation des transitions et la gestion des états successifs. En revanche, le Ladder est
particulièrement adapté pour représenter les logiques combinatoires simples, comme les conditions
booléennes, de manière intuitive et proche des schémas électriques traditionnels.
Ainsi, certaines opérations, comme le pilotage d’une séquence complexe, sont plus aisées à
exprimer en GRAFCET, tandis que des conditions logiques telles qu’une opération OU sont plus
facilement représentées en Ladder.
Bien qu’il soit tentant de classer ces langages selon leur efficacité, il n’existe pas de choix absolu
ni unique. La richesse de la norme IEC 61131-3 réside justement dans la possibilité d’intégrer plusieurs
langages au sein d’un même programme, en tirant parti des avantages propres à chacun.
Le choix d’utiliser à la fois Ladder et GRAFCET dépend donc du type de fonctionnalité à
implémenter, des compétences de l’équipe et des pratiques courantes dans l’environnement industriel
concerné.

32
Chapitre 3. Introduction aux Systèmes Automatisés

3.7.7 Éléments fondamentaux de la norme CEI 61131-3

Pour maîtriser efficacement la programmation selon la norme CEI 61131-3, il est essentiel
de comprendre les éléments fondamentaux qui la composent. Certains de ces éléments sont largement
répandus dans les langages de programmation classiques, tandis que d’autres présentent des caractéristiques
spécifiques au contexte industriel.
Cette familiarisation est primordiale pour pouvoir analyser, modifier ou développer un code
conforme à cette norme. Une attention particulière sera donc portée aux concepts les plus caractéristiques
ou novateurs introduits par la norme.
Pour ceux souhaitant approfondir davantage ces notions, il est recommandé de consulter la
documentation spécifique à l’automate utilisé ou des ouvrages spécialisés dans le domaine de la
programmation industrielle.

3.7.8 Choix d’un automate programmable

Le choix d’un automate programmable dépend en premier lieu des préférences d’un groupe ou
d’une entreprise, souvent influencées par des relations commerciales établies ou des retours d’expérience
positifs. Cependant, des critères techniques doivent également être pris en compte pour garantir la
cohérence et la performance du système automatisé.
Il est important que le personnel de maintenance soit formé sur les équipements choisis. Une
trop grande diversité de matériels peut engendrer des difficultés lors des interventions et compromettre
la fiabilité du système. Il est également recommandé d’opter pour des automates prenant en charge des
langages standards tels que le GRAFCET, afin de faciliter les phases de mise au point et de dépannage.
La disponibilité d’un logiciel de programmation performant, idéalement accompagné d’outils de
simulation, constitue un atout économique important, tant pour l’acquisition que pour la formation
du personnel.
Le choix final doit reposer sur une évaluation rigoureuse des besoins spécifiques :

— Nombre d’entrées/sorties : leur volume influence le nombre de cartes et de racks nécessaires.

— Type de processeur : ses capacités (taille mémoire, rapidité, fonctions avancées) orientent le
choix vers une gamme adaptée.

— Modules spécialisés : certaines fonctions (commande d’axes, pesage, etc.) peuvent être externalisées
via des modules spécifiques pour alléger la charge du processeur principal.

— Fonctions de communication : l’automate doit pouvoir s’intégrer à un réseau d’automates ou

à un système de supervision, via des protocoles standardisés comme Profibus.

33
Chapitre 3. Introduction aux Systèmes Automatisés

Dans notre cas, nous avons choisi de travailler avec des automates de la marque Beckhoff.
En effet, notre établissement dispose d’un partenariat et de conventions de collaboration avec cette
entreprise, ce qui facilite l’accès aux ressources techniques, aux logiciels, ainsi qu’au support. De plus,
Beckhoff propose une architecture modulaire et ouverte, compatible avec les langages de programmation
normalisés (IEC 61131-3), tout en offrant des performances adaptées à une large gamme d’applications
industrielles.

3.7.9 Principaux constructeurs d’API

Le marché des automates programmables industriels (API) est dominé par plusieurs constructeurs
de renommée internationale, originaires principalement d’Allemagne, des États-Unis, de France, du
Japon et de Suède. Ces fabricants proposent une large gamme d’automates répondant aux besoins
variés des industries en matière d’automatisation, de communication industrielle et de performances.
Parmi les acteurs les plus connus, on peut citer : ABB, Allen-Bradley, Beckhoff Automation,
Bosch Rexroth, Festo, GE Fanuc, Honeywell, VIPA, Omron, Schneider Electric, Siemens,
et Mitsubishi Electric.
Ces entreprises se distinguent par la fiabilité de leurs équipements, la richesse de leur environnement
logiciel, ainsi que par le support technique et les solutions innovantes qu’elles proposent dans le domaine
de l’automatisation industrielle. ref1

3.7.10 Description de l’automate C6032-0080 | PC Industriel Ultra-Compact

– Beckhoff

Le C6032-0080 est un PC industriel ultra-compact de la série C60xx de Beckhoff, conçu pour

offrir des performances de calcul élevées dans un format extrêmement réduit. Grâce à l’intégration
de processeurs Intel® Core™ i de dernière génération, il est parfaitement adapté aux applications
d’automatisation avancées telles que le contrôle d’axes multivariables, les interfaces homme-machine
complexes (IHM), les traitements de volumes importants de données et les processus nécessitant des
temps de cycle très courts.
Sa conception modulaire permet l’ajout d’extensions fonctionnelles via un second niveau
de carte, connecté à la carte mère principale, entièrement développée en interne par Beckhoff. Cette
architecture garantit robustesse, compacité et évolutivité, tout en maintenant une excellente fiabilité.
Le montage flexible du C6032 autorise une installation sur rail DIN ou sur panneau arrière
d’armoire électrique, avec des interfaces orientables pour un câblage optimal, même dans les espaces
restreints.
La compatibilité complète avec TwinCAT et EtherCAT permet une intégration aisée

34
Chapitre 3. Introduction aux Systèmes Automatisés

dans les systèmes d’automatisation existants, faisant du C6032 une solution universelle pour les
architectures centralisées ou distribuées.
Enfin, le C6032 bénéficie d’un excellent rapport qualité/prix grâce à un design optimisé
en termes de coût de production, sans compromis sur les standards industriels, la durabilité ou la
performance. Beckhoff, fort de son expertise en matériel informatique industriel depuis 1986, garantit
ainsi une continuité technologique, une disponibilité à long terme et des configurations personnalisables.

Figure 3.12 : Le PC industriel ultra-compact de la série C60

3.7.11 Unités d’organisation du programme (POU)

Les Program Organisation Units (POU), ou unités d’organisation du programme, constituent

les éléments fondamentaux qui structurent un projet conforme à la norme CEI 61131-3. Ces blocs
permettent de construire la logique d’automatisation en divisant le programme en composants réutilisables.
Hérités du standard DIN 19239, les POUs ont été simplifiés dans la norme pour ne retenir que
trois types de blocs :

— Programme : bloc principal exécuté par le système, il gère l’accès aux entrées/sorties physiques
et peut appeler d’autres blocs (fonctions et blocs de fonctions).

— Fonction (Function) : unité sans mémoire interne, elle prend des entrées et retourne une valeur
de sortie. Son comportement est purement fonctionnel.

— Bloc de fonction (Function Block) : bloc encapsulant de la logique avec mémoire persistante.
Il peut stocker des états entre les exécutions.

35
Chapitre 3. Introduction aux Systèmes Automatisés

Les blocs de fonctions représentent une avancée significative vers la programmation orientée objet
dans le contexte des automates. On peut établir un parallèle clair avec le concept de classes en
informatique moderne, notamment grâce aux propriétés suivantes :

— Avant toute utilisation, un bloc de fonction doit être instancié.

— Des méthodes peuvent être définies pour manipuler les variables internes du bloc.

— Le mot-clé EXTENDS permet de définir des blocs parents et de créer des blocs enfants qui héritent
de leurs propriétés.

— Des propriétés peuvent être créées, jouant le rôle de getters/setters.

— Des interfaces, via le mot-clé IMPLEMENTS, permettent d’imposer un ensemble de méthodes à

définir, assurant ainsi une cohérence dans la conception.

Ces fonctionnalités montrent que la norme CEI 61131-3 encourage de plus en plus l’usage d’approches
orientées objet dans le développement des programmes industriels. L’objectif est clair : réduire l’écart
entre les langages utilisés dans les automates et ceux des environnements informatiques classiques.
Il est intéressant de noter que certaines de ces propriétés, notamment l’héritage et les interfaces,
peuvent également s’appliquer aux blocs de type Programme, bien que leur usage reste plus courant
avec les blocs de fonction.

3.7.12 Déclaration des variables et gestion des types de données

La norme CEI 61131-3 définit un ensemble structuré de règles pour la déclaration et l’utilisation
des variables dans les programmes d’automates. Chaque variable possède un type de données qui
détermine sa nature, son interprétation et la quantité de mémoire qui lui est allouée.

Parmi les types de base disponibles, on retrouve :

— BOOL : pour les valeurs logiques (vrai/faux),

— INT, DINT, UINT, REAL, etc. : pour les entiers et les nombres réels,

— STRING, WSTRING : pour les chaînes de caractères,

— TIME, DATE, TIME_OF_DAY : pour les représentations temporelles.

La norme autorise également la définition de types de données personnalisés, incluant :

— ENUM : énumérations,

— STRUCT : structures regroupant plusieurs variables sous un même nom,

— ARRAY : tableaux indexés.

36
Chapitre 3. Introduction aux Systèmes Automatisés

Lors de la déclaration d’une variable, il est obligatoire de spécifier au minimum son identifiant
(nom) et son type. Il est également possible d’assigner une adresse mémoire fixe, utile pour le
mappage des entrées/sorties physiques, et de définir une valeur initiale.

Voici deux exemples illustrant la déclaration d’une sortie et d’une entrée booléenne avec affectation
d’adresse :

myBoolOutput AT %Q* : BOOL := TRUE; // Sortie booléenne initialisée à TRUE

myBoolInput AT %I* : BOOL; // Entrée booléenne

Le préfixe %I désigne une entrée physique, tandis que %Q indique une sortie. Le symbole AT permet
d’associer une variable à une adresse mémoire spécifique.

Cette souplesse dans la gestion des types et des adresses fait de la norme CEI 61131-3 un outil
puissant et adaptable pour les applications industrielles modernes.

Figure 3.13 : La liste des variable SUR Twinca t3.0

3.8 Interface Homme-Machine (HMI)

Un HMI, acronyme de l’anglais Human Machine Interface, désigne un dispositif permettant

l’interaction entre un opérateur humain et le programme de la machine. Cette interaction peut se faire
via des boutons et voyants physiques, ainsi que par leurs équivalents virtuels. Dans ce travail, ces deux
types d’interfaces seront appelés respectivement HMI hardware et HMI software.

37
Chapitre 3. Introduction aux Systèmes Automatisés

L’intérêt principal d’une interface matérielle réside dans sa fiabilité et sa simplicité. En effet, il
est essentiel qu’en cas de blocage du programme automate, des commandes critiques, comme le bouton
d’arrêt d’urgence, restent opérationnelles afin d’assurer l’arrêt sécuritaire des machines.
À l’inverse, les HMI software sont indispensables pour les applications de grande envergure,
nécessitant le lancement de nombreuses actions et la surveillance de nombreux états. Dans ces cas,
une interface matérielle composée d’un grand nombre de boutons et voyants serait peu lisible, ce qui
nuirait à l’efficacité de l’opérateur.
L’utilisation combinée d’interfaces matérielles et logicielles est donc justifiée par leur complémentarité.
Toutefois, pour des applications simples ou de petite taille, il est courant de se limiter à un HMI
hardware.
Avec l’avènement de l’industrie 4.0, les solutions HMI software ont connu des innovations
majeures, redéfinissant certains concepts traditionnels. Cette évolution sera abordée plus en détail
dans le chapitre 5, consacré au choix de la solution technique.

Figure 3.14 : La liste des variable SUR Twinca t3.0

I.4 Conclusion

Le développement scientifique et technologique a profondément influencé les systèmes de production,

donnant naissance aux systèmes automatisés et aux automates programmables industriels (API).
L’automate programmable s’impose aujourd’hui comme une solution incontournable dans
l’automatisation industrielle. Il est simple à programmer, facile à connecter, et conçu pour s’adapter
aux environnements industriels exigeants. L’essor de ses capacités et la croissance de son marché en
témoignent clairement.

38
Chapitre 3. Introduction aux Systèmes Automatisés

Cependant, pour garantir une intégration réussie d’un automate dans un système de production,
plusieurs facteurs doivent être rigoureusement pris en compte :

— Une analyse approfondie du problème à automatiser ;

— Le respect strict des normes et règles d’installation ;

— Un léger surdimensionnement de la configuration pour anticiper d’éventuelles évolutions.

En conclusion, les systèmes automatisés présentent de nombreux avantages : ils améliorent les
conditions de travail, réduisent significativement les accidents, augmentent la cadence de production
tout en assurant une meilleure qualité des pièces produites. De plus, ils offrent une grande flexibilité,
avec des installations facilement modifiables et pilotables à distance via une interface de supervision
ou un terminal de dialogue. Tout cela s’accompagne toutefois d’une réduction certaine des besoins en
main-d’œuvre.
Le prochain chapitre portera sur l’instrumentation et l’appareillage électrique, éléments essentiels
pour la mise en œuvre d’un système automatisé.

39
 Chapitre 4

Développement logiciel de
l’automatisme et de la supervision

Plan
1 Introduction générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2 Objectifs généraux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3 Présentation du cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . 41

4 Analyse fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5 Modélisation 3D du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6 Partie Préparation du Produit – Définition des Besoins en Matériel . . . . 46

7 Objectif du Processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

8 Constitution du Système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

9 Circulation des Liquides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

10 Modes de Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

11 Liste des Électrovannes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

12 Spécifications de Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

13 Choix des langages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

14 Interface Homme-Machine (IHM) . . . . . . . . . . . . . . . . . . . . . . . . 61

15 Choix des protocoles de communication . . . . . . . . . . . . . . . . . . . . . 67

16 Architecture fonctionnelle du réseau . . . . . . . . . . . . . . . . . . . . . . . 68

17 Justification des choix technologiques . . . . . . . . . . . . . . . . . . . . . . 69

Chapitre 4. Développement logiciel de l’automatisme et de la supervision

4.1 Introduction générale

Ce chapitre présente l’analyse fonctionnelle du système de production automatisée de boissons

colorées, en réponse au cahier des charges établi. Il introduit les éléments clés du processus à automatiser,
les besoins du client, les contraintes techniques, ainsi que l’approche adoptée pour répondre à ces
exigences via la solution Beckhoff TwinCAT.

4.2 Objectifs généraux

— Automatiser la préparation de boissons en intégrant des modules de contrôle des pompes,

vannes et capteurs à l’aide d’un automate Beckhoff.

— Développer un programme complet sous TwinCAT avec une logique combinatoire et

séquentielle via LD et SFC (GRAFCET).

— Créer une supervision intuitive permettant le contrôle en temps réel et la surveillance des
paramètres critiques du processus.

— Assurer la connectivité à distance (télégestion) à travers des protocoles sûrs comme OPC
UA, VPN ou ADS.

4.3 Présentation du cahier des charges

1. Contexte du projet

Le client souhaite développer un système automatisé permettant la production de boissons

colorées, à partir de paramètres sélectionnés via une interface utilisateur :

— Couleur finale désirée

— Nombre de bouteilles à produire

— Taux d’additifs (colorants, arômes)

— Viscosité du produit fini

Le système doit piloter :

— Pompes et vannes motorisées

— Processus de mélange

— Mesures de qualité

— Enregistrement et traçabilité

41
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

2. Objectifs fonctionnels

— Interface conviviale pour opérateurs

— Mélange automatique d’ingrédients liquides

— Dosage précis avec une tolérance de ±2%

— Mesures de viscosité et homogénéité

— Export CSV des données de production

— Rinçage guidé via l’IHM

3. Architecture du système

3.1 Cuves utilisées

Tableau 4.1 : Types de cuves disponibles

Type de cuve Contenance Contenu

Cuve principale 1 100 L Eau claire

Cuve principale 2 100 L Base sucrée ou concentrée
Petites cuves (x3) 5L Colorants (rouge, bleu, jaune)
Cuve mélangeuse 35 L Mélange recette
Cuve tampon 35 L Alimentation remplissage

3.2 Composants à piloter

— Pompes de transfert

— Vannes motorisées

— Capteurs (niveau, couleur, viscosité)

— API Beckhoff

— Écran tactile IHM

42
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

4.4 Analyse fonctionnelle

Figure 4.1 : diagramme analyse fonctionnelle

4. Fonctionnalités principales

— Sélection de recette

— Dosage et mélange automatiques

— Mesure qualité (viscosité)

— Transfert vers cuve tampon

— Rinçage assisté

— Archivage des données

5. Capteurs recommandés

Tableau 4.2 : Capteurs utilisés pour le contrôle qualité

Type de capteur Exemple ou fonction

Viscosité ViscoSense Compact ou équivalent

Couleur / turbidité Capteur optique Optek AF16
Niveau de cuve Capteur à flotteur ou à pression (VEGA, WIKA)

43
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

6. Tolérances de production

— Dosage : ±2%

— Viscosité : ajustée selon recette

— Homogénéité : contrôle par capteur ou visuel

7. Traçabilité – Export CSV

Chaque cycle de production génère un fichier CSV contenant :

— Lot, date/heure

— Couleur choisie

— Quantités d’ingrédients

— Nombre de bouteilles

— Mesure finale de viscosité

— Identité de l’opérateur

8. Interface Homme-Machine (IHM)

— Menu tactile simple

— Choix recette / rinçage / historique

— Historique accessible

— Export USB ou réseau

9. Procédure de rinçage

— Rinçage guidé via IHM

— Sélection manuelle des zones à nettoyer

— Commande automatique des pompes/vannes

44
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

4.5 Modélisation 3D du système

Figure 4.2 : Schéma fonctionnel du système sous AutoCAD Plant 3D

L’utilisation d’AutoCAD Plant 3D a permis de :

— Optimiser l’agencement des cuves pour minimiser les longueurs de tuyauterie

— Identifier les interférences mécaniques et contraintes d’espace

— Planifier les supports de tuyauterie et chemins fluidiques

— Faciliter le chiffrage avec les quantités exactes d’équipements (tuyaux, coudes, raccords)

Tableau des tuyauteries principales

Tableau 4.3 : Spécification des tuyauteries utilisées

Élément Détails techniques

Tuyauterie principale PVC alimentaire, Ø 40 mm, résistante à la corrosion

Tuyauterie pour colorants PVC/PTFE, Ø 20 mm, résistante aux colorants acides
Raccords Raccords à visser ou sertir, normes sanitaires
Vannes motorisées Inox, IP65, motorisées, 24V ou 230V selon modèle

45
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

4.6 Partie Préparation du Produit – Définition des Besoins en

Matériel

Dans cette section, nous présentons l’ensemble des équipements nécessaires à l’automatisation
de la partie « préparation du produit » dans une ligne de production de boisson. Cette étape regroupe
plusieurs cuves de traitement (remplissage, coloration, homogénéisation) qui doivent être commandées
automatiquement via un automate industriel Beckhoff.

4.6.1 Description du process

Le système est constitué des éléments suivants :

— Deux cuves principales : utilisées pour les liquides de base.

— Trois cuves de colorants : permettent l’ajout de colorants selon la recette.

— Une cuve tampon : régule les flux entre les phases de mélange et de remplissage.

— Une cuve mélangeuse : réceptionne tous les composants liquides pour assurer un mélange
homogène.

Chaque cuve est équipée de capteurs et d’actionneurs permettant :

— Le contrôle du niveau de liquide.

— La mesure de température (si nécessaire pour certaines recettes).

— Le remplissage ou vidange via des vannes motorisées ou électrovannes.

— Le transfert de liquide à l’aide de pompes.

— Le brassage via des agitateurs (dans les cuves principales ou mélangeuse).

4.7 Objectif du Processus

Le processus vise à automatiser la préparation d’une boisson à base de liquide principal, avec
ou sans ajout de colorants, dans un environnement contrôlé. L’opérateur peut sélectionner, via une
IHM, la source du liquide principal (eau claire ou eau colorée), la teinte finale désirée ainsi que les
paramètres de dosage. Deux modes de fonctionnement sont proposés :

— Mode standard (avec ajout de colorants, mélange et homogénéisation)

— Mode direct (remplissage sans traitement via un circuit bypass)

46
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

4.8 Constitution du Système

4.8.1 Unités principales

— 2 cuves de liquide principal :

— Cuve 1 : eau claire

— Cuve 2 : eau pré-colorée (recyclée)

— 3 cuves de colorants (correspondant aux teintes primaires)

— 1 cuve tampon (régulation de débit entre étapes)

— 1 cuve de mélange (homogénéisation finale)

4.9 Circulation des Liquides

— Transfert assuré par pompes électriques

— Tuyauterie en PVC (4 pouces, épaisseur 4 mm)

4.10 Modes de Fonctionnement

4.10.1 Mode standard (avec coloration)

— 1-L’utilisateur sélectionne la cuve principale via l’IHM (EV1 ou EV2).

— 2-La pompe P1 envoie le liquide vers la cuve tampon (EV3).

— 3-Selon la couleur souhaitée, les colorants sont injectés via les électrovannes EV4 à EV6 (MFH),
après ouverture des sécurités EV7 à EV9.

— 4-Le mélange est transféré vers la cuve de mélange via la pompe P2 (EV10).

— 5-Un agitateur homogénéise le contenu.

— 6-Le produit final est dirigé vers la ligne de remplissage via EV11.

4.10.2 Mode direct (bypass)

— 1-L’opérateur choisit une des cuves principales.

— 2-Ouverture de l’électrovanne EV12.

— 3-Le liquide est envoyé directement vers la ligne de remplissage, sans passer par les colorants ni
les cuves tampon/mélange.

47
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

Réf. Fonction Type recommandé (Festo)

EV1 Sortie Cuve 1 (eau claire) VZWF
EV2 Sortie Cuve 2 (eau colorée) VZWF
EV3 Entrée Cuve tampon (via pompe P1) VZWF
EV4 Injection colorant 1 MFH-3-1/8
EV5 Injection colorant 2 MFH-3-1/8
EV6 Injection colorant 3 MFH-3-1/8
EV7 Sécurité colorant 1 VZWF
EV8 Sécurité colorant 2 VZWF
EV9 Sécurité colorant 3 VZWF
EV10 Sortie Cuve tampon vers Cuve de mélange (via P2) VZWF
EV11 Sortie Cuve de mélange vers remplissage VZWF
EV12 Circuit direct Cuve principale → Remplissage VZWF
Tableau 4.4 : Liste des électrovannes actives dans le processus

4.11 Liste des Électrovannes

4.12 Spécifications de Production

— Volume unitaire : 50 cL par bouteille

— Cadence cible : 100 bouteilles/heure

— Volume horaire total : 50 litres/heure

Liste Globale du Matériel Utilisé dans le Procédé (avec Références

et Quantités)

1. Capteurs et Instrumentation – Marque IFM

Désignation Référence IFM Quantité Rôle/Fonction

Mesure de la
température et
Capteur de température et
TCC501 1 humidité
humidité ambiante
ambiante dans la
salle

Mesure du niveau
Capteur de niveau pour cuves LR2050 7
dans les cuves

48
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

Désignation Référence IFM Quantité Rôle/Fonction

Contrôle de la
température dans
Capteur de température en ligne TA2432 2
le mélange/cuve
tampon

Mesure du débit
Débitmètre inductif pour liquide SM6004 2 avant la cuve
mélangeuse

Surveillance de la
Capteur de pression PN7093 1 pression dans la
cuve tampon

Mesure de la
viscosité du
Capteur de viscosité (optionnel) VY5100 1
liquide
épaississant

Contrôle de la
Capteur de couleur (colorimètre) O5D100 1 couleur du
mélange

Vérification de la
Capteur de particules (turbidité) LDL100 1 propreté et de la
clarté du liquide

Validation de la
Thermomètre de process TW2000 1 température à la
sortie

Vérification de
pH-mètre pour contrôle qualité PI2790 1 l’acidité finale du
produit

2. Actionneurs / Vannes / Agitateurs – Marque Festo

Désignation Référence Festo Quantité Rôle/Fonction

49
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

Désignation Référence Festo Quantité Rôle/Fonction

Contrôle
Vannes motorisées (2 voies
VZWF-B-B-G14- 10 l’ouverture/
ON/OFF)
fermeture des flux

Injection de
Électrovannes pour dosage colorant MFH-5-1/4-B 3
colorant

Mélange dans les

Vérins rotatifs pour agitateurs DSM-16-270-P-A- 4
cuves

Agitation
Moteurs pour agitateurs (option
EMMS-AS-70-S-R 3 motorisée via
élect.)
moteur

Sécurisation des
Clapets anti-retour HGL-1/4-B 5
circuits

Contrôle manuel
Vannes papillon manuelles KVZB-B-1/2 6
en cas de besoin

3. Pompes et Organes Mécaniques – Marque IFM (Monitoring)

Référence /
Désignation Quantité Rôle/Fonction
Type

Transfert de
Type standard
Pompes à entraînement électrique 3 liquide entre les
process
cuves

Capteurs de vibration pour pompe Surveillance de

VVB001 3
(IFM) l’état des pompes

Étape 0 : Préconditions avant démarrage Les deux cuves principales sont remplies manuellement.
Le système vérifie que les niveaux bas ne sont pas atteints (via capteurs IFM LMT PIxxx).
Si niveau OK dans les deux cuves, le système peut démarrer automatiquement le process.
Sinon, une alerte ou voyant rouge s’allume et l’opérateur doit remplir la cuve concernée.
a4paper, margin=2.5cm

50
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

Étape 1 : Transfert vers la cuve mélangeuse

1. Choix de la source dans l’IHM

L’opérateur sélectionne l’origine du liquide principal :

— EV1 : Cuve d’eau claire

— EV2 : Cuve issue de batchs précédents

Une vérification de compatibilité entre les produits est réalisée. Si incompatibilité détectée, le cycle est
bloqué et une alerte est affichée.

2. Ouverture des électrovannes

— EV3 : Ouverte en permanence pendant le cycle.

— EV1 ou EV2 : selon le choix de la source.

— EV7 : Ouverte tout au long du cycle.

— EV4 / EV5 / EV6 : Ouvertures temporisées (dosage colorants rouge, jaune, bleu).

3. Activation des pompes

— /P1 : Activation en fonction de la source (EV1 ou EV2).

— /Pmb1 : Colorant rouge (via EV4)

— /Pmb2 : Colorant jaune (via EV5)

— /Pmb3 : Colorant bleu (via EV6)

Les pompes brushless fonctionnent en mode pulsé ou dosage précis selon la recette.

4. Sécurité et surveillance

— Niveau bas cuves principales : Interdiction de pomper à vide.

— Niveau haut cuve mélangeuse : Arrêt automatique du transfert.

— Capteur ultrason IFM : Surveillance continue du volume transféré.

— Vérification des états des EV : Si retour d’état disponible.

5. Récapitulatif de fonctionnement

Composant État pendant le cycle Mode de contrôle

51
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

EV1 ou EV2 Ouverte (selon choix IHM) Manuellement via IHM

EV3 Toujours ouverte Automatique

Contrôle par impulsion ou

EV4 / EV5 / EV6 Ouverture temporaire pour dosage
volume

EV7 Toujours ouverte Automatique

Automatique (si niveau

/P1 Active durant transfert principal
OK)

/Pmb1, /Pmb2, Synchronisé avec EV et

Activations brèves selon recette
/Pmb3 recette

Capteurs IFM Arrêts sécurisés

Surveillance continue
(niveau, ultrason) automatiques

Étape 2 : Transfert vers la cuve tampon

Objectif : Transférer le produit de la cuve mélangeuse vers la cuve tampon.

Conditions de départ :

— La cuve mélangeuse contient un mélange prêt à être transféré.

— La cuve tampon est vide ou à un niveau bas.

— Le transfert est déclenché manuellement ou automatiquement.

Actions automatisées :

1. Vérification du niveau haut dans la cuve tampon via un capteur de niveau IFM (ultrason
ou LMT PIxxx).
Si le niveau haut est atteint ⇒ Interdiction de transfert.

2. Ouverture de l’électrovanne EV9, reliée à la sortie de la cuve mélangeuse vers la cuve tampon.

3. Activation de la pompe /P2 (pompe centrifuge dédiée au transfert vers la cuve tampon).

4. Surveillance continue du niveau dans la cuve tampon :

— Si le niveau est inférieur au seuil haut ⇒ la pompe continue à fonctionner.

— Si le niveau haut est atteint ⇒ Arrêt immédiat de la pompe /P2 et fermeture de EV9.

Sécurités à respecter :

— Anti-pompage à vide : s’assurer que la cuve mélangeuse a un niveau minimal.

— Surveillance continue des capteurs de niveau pour éviter débordement ou arrêt à sec.

52
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

— Utilisation d’un voyant 3 couleurs sur la cuve tampon :

— Vert : niveau normal

— Jaune : niveau moyen (pré-alarme)

— Rouge : niveau haut (transfert à stopper)

Étape 4 : Transfert du produit vers la machine de remplissage

Objectif : Acheminer le produit depuis la cuve tampon vers la machine de remplissage, pour
conditionner les bouteilles de 50 cl.

Déroulement de l’étape :

1. Détection de la présence des bouteilles

— Deux capteurs de présence, C4 et C5, détectent la présence des bouteilles sur la zone de
remplissage.

— Le signal de demande est validé uniquement si C4 = 1 ET C5 = 1.

2. Ouverture de l’électrovanne EV10

— Lorsque les deux capteurs sont actifs, l’électrovanne EV10 s’ouvre.

3. Activation de la pompe /P3

— La pompe /P3 est activée pour transférer le produit vers la machine de remplissage.

4. Contrôle du volume transféré

— Un débitmètre en sortie de cuve tampon permet de mesurer la quantité de produit.

— L’objectif est de transférer exactement 3 litres (correspondant à 6 bouteilles de 50 cl).

5. Comptage des bouteilles avec le capteur Cb2

— Le capteur Cb2 effectue le comptage des bouteilles remplies.

— Lorsque 6 bouteilles sont détectées, la pompe /P3 est arrêtée automatiquement et EV10
se ferme.

Sécurités intégrées :

— Vérification du niveau bas dans la cuve tampon pour éviter le pompage à vide.

— Validation obligatoire des deux capteurs C4 et C5.

— Comptage précis par Cb2 pour garantir un remplissage exact.

53
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

Scénario de Lancement de la Production

1. L’Opérateur Lance la Production

L’opérateur initie la production via une interface Homme-Machine (IHM), soit un écran tactile,
soit un PC industriel.

— L’IHM affiche d’abord la page "Préparation du produit" (gestion des cuves).

— L’opérateur choisit ou valide une recette (par exemple : "sirop rouge" → EV4 activée).

— Il appuie sur "Démarrer la production" ce qui envoie le signal I_StartCycle à l’automate.

2. Étapes Automatiques Après le Lancement (Partie A - Préparation)

Une série d’étapes automatiques s’ensuit après le lancement de la production, détaillées comme
suit :
Tableau 4.9 : Étapes du processus automatisé
Étape Résumé rapide
S1 L’automate ouvre EV1 ou EV2 selon le cas, puis active la pompe /P1 pour
remplir la cuve mélangeuse.
S2 Activation des électrovannes EV4, EV5, EV6 et des pompes brushless Pmb1,
Pmb2, Pmb3 pour l’ajout des colorants dosés.
S3 Le liquide est mélangé soit par un agitateur, soit via temporisation.
S4 La pompe /P2 et l’électrovanne EV9 transfèrent le produit vers la cuve
tampon. L’opération s’arrête au niveau haut.
S5 Une demande de remplissage déclenchée par les capteurs C4 et C5 entraîne
l’activation de la pompe /P3 et de EV10.

À ce stade, la production est prête à être envoyée à la ligne de conditionnement

(Partie B).

3. Passage Automatique à la Ligne de Production (Partie B)

L’IHM peut changer automatiquement de page, ou l’opérateur peut appuyer sur "Passer à la
ligne".
La page de la ligne de production affiche les informations suivantes :

— État des capteurs (C4, C5, Cb2).

— État et position du robot FANUC.

— État de la machine de bouchage.

— Compteur de bouteilles remplies.

54
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

Pages de l’IHM

L’IHM est divisée en deux pages :

— Page 1 : Préparation du produit

— Choix de la recette (colorant).

— Niveaux des cuves.

— Démarrage/Arrêt de la production.

— Alarmes des cuves.

— États des pompes et électrovannes.

— Page 2 : Ligne de production

— État du robot FANUC (OK, Pause, Défaut).

— Nombre de bouteilles traitées.

— État de remplissage et bouchage.

— États des capteurs C4, C5, Cb2.

— État de la palettisation.

TwinCAT 3 permet de gérer ces pages via TwinCAT HMI ou Visualisation (Visu) dans le PLC,
avec la possibilité de naviguer entre les différentes pages.

4. Processus de Programmation dans TwinCAT

Nous allons structurer le projet étape par étape :

— 1 Définir toutes les variables d’E/S dans TwinCAT :

— Entrées : capteurs, niveaux, boutons.

— Sorties : pompes, électrovannes, voyants.

— Variables internes : états SFC, demandes, flags.

— 2 Créer le SFC du processus de cuves :

— Étapes de S0 à S5, codées bloc par bloc.

— Conditions de transition et activation des sorties.

— Gestion des temporisations et niveaux haut/bas.

— 3 Créer le SFC de la ligne de production :

— Processus allant du dépôt des bouteilles vides à la mise en caisse.

— 4 Programmer les blocs de sécurité et d’erreurs :

55
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

— Niveau bas produit.

— Absence de bouteilles.

— Alarme pompe.

— 5 Créer l’IHM :

— Conception de deux pages simples dans TwinCAT HMI ou Visualisation dans PLC.

— 6 Synchroniser les deux parties :

— Utilisation de signaux internes tels que Q_DemandeProduit, Q_BouteillesRemplies, etc.

4.13 Choix des langages

Avant de détailler la structure du programme, il est important de définir les langages de

programmation retenus. Le choix des langages, conformément à la norme IEC 61131-3, dépend du
type d’application, des contraintes techniques, ainsi que des préférences de l’utilisateur.
Dans ce travail, j’ai fait le choix d’une combinaison entre le GRAFCET (SFC) et le
Ladder, en tirant parti de leurs complémentarités :

— Le GRAFCET (SFC – Sequential Function Chart) est utilisé pour la gestion des séquences
principales. Il permet une représentation claire et structurée des enchaînements logiques, ce qui
facilite la lecture, le suivi de l’exécution et la maintenance du programme.

— Le Ladder est privilégié pour les conditions de transition et les logiques combinatoires. Il offre
une visualisation intuitive, en particulier pour les automaticiens ayant une culture électrique, et
reste efficace même pour des expressions logiques complexes.

— Enfin, le Structured Text (ST) est utilisé uniquement dans des cas bien précis, notamment
pour le traitement de fonctions avancées comme les communications TCP/IP ou la manipulation
de chaînes de caractères, lorsque les langages graphiques ne sont pas suffisants.

Cette combinaison me permet de structurer le programme de façon optimale, tout en répondant

aux besoins spécifiques de l’application et en restant cohérent avec les pratiques professionnelles.

4.13.0.1 Stratégie de développement logicielle

Dans le domaine de l’automatisation industrielle, plus un système est complexe, plus il existe
de méthodes de développement pour le modéliser et le contrôler efficacement. Ces approches diffèrent
par leur performance, leur facilité de maintenance ou leur capacité à être adaptées à d’autres projets.
Pour répondre aux exigences du projet, différentes solutions ont été envisagées et comparées. La
première stratégie mise en œuvre s’inspire directement des pratiques observées chez les automaticiens
de Citius.

56
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

4.13.0.2 Architecture modulaire orientée tâches

Cette méthode repose sur une organisation structurée du programme autour de plusieurs Unités
Organisationnelles de Programme (POUs) de type Programme, chacune correspondant à une
fonction bien définie du système automatisé :

— Bloc LineModes — Gestion des états globaux : Ce module centralise la gestion des états
principaux de la ligne de production, modélisés sous forme de GRAFCET. Il comprend notamment :

— L’état Arrêt d’urgence ;

— Le mode Buzzer (BzrRun) ;

— L’état Production.

— Blocs SFC par machine — Séquences de poste autonomes : Chaque station est modélisée
par son propre bloc basé sur le langage GRAFCET (SFC). Ces blocs implémentent les séquences
spécifiques à chaque machine, tout en surveillant les états globaux fournis par LineModes.

— Bloc principal MAIN — Orchestration conditionnelle : Ce bloc permet l’instanciation

des modules machines en fonction de certains drapeaux ou modes de fonctionnement, comme
l’activation du mode manuel.

Atout principal : Ce découpage modulaire offre une réutilisabilité accrue. Le bloc LineModes est
conçu de manière générique, ce qui permet sa réintégration facile dans de futurs projets. Il sert ainsi
de socle organisationnel robuste pour tout système automatisé complexe.

Limites de l’approche et implications pour le développement du projet Bien que cette

architecture modulaire présente des avantages notables, notamment en termes de réutilisabilité et de
lisibilité des séquences, elle présente également plusieurs limites qui ont influencé le développement du
projet.
Problèmes de relation hiérarchique entre les modules : L’interaction entre le bloc
LineModes et les programmes de chaque machine soulève une problématique de contrôle inversé. En
effet, lorsqu’un événement tel que l’activation du mode production survient (par exemple via l’appui
d’un bouton), il semble logique que ce soit le module central LineModes qui dicte le changement d’état
aux machines. Or, dans la solution initiale, ce sont les modules individuels qui doivent interroger l’état
du LineModes pour décider de leur comportement. Cela va à l’encontre d’une architecture orientée
commande centralisée, dans laquelle le module principal devrait initier les requêtes.
Manque d’encapsulation des données : Une autre faiblesse réside dans l’absence de séparation
claire entre les variables internes et externes à chaque module machine. Cela peut entraîner des effets
de bord indésirables, où une machine influence le fonctionnement d’une autre sans passer par un

57
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

mécanisme explicite de communication ou d’autorisation. Ce couplage implicite complexifie considérablement

la maintenance, le débogage, et la compréhension globale du système.
Dans un projet collaboratif, où plusieurs développeurs interviennent sur différentes parties du
programme, ce manque de cloisonnement fonctionnel peut mener à des erreurs difficilement traçables.
Une évolution non documentée dans un module peut altérer le comportement d’un autre module, sans
que la source du problème soit immédiatement évidente.
Impact sur le projet : Ces constats ont orienté les décisions prises lors du développement. Une
attention particulière a été portée à la structuration des échanges entre modules et à l’encapsulation
des données, en visant une architecture plus robuste, hiérarchisée et découplée. Le paradigme retenu
par la suite tend donc vers une architecture orientée service ou événement, où chaque composant agit
comme une entité autonome, communiquant à travers des interfaces bien définies.

4.13.0.3 Évolution vers une architecture orientée-objet

Face aux limites de l’approche traditionnelle, une refonte de l’architecture logicielle a été
envisagée en adoptant les principes de la programmation orientée objet, en accord avec les recommandations
de la norme IEC 61131-3. Cette approche a été formalisée selon les principes suivants :

— Le programme LineModes reste le noyau de pilotage de la chaîne. Il devient responsable de l’envoi

des requêtes de changement d’état aux machines, et ne change d’état qu’après avoir reçu une
confirmation explicite de la part de celles-ci.

— Un bloc de fonction abstrait nommé Machine est introduit. Il définit des attributs tels que
l’état courant et l’état requis, ainsi que des méthodes génériques comme IsTurnedOn() ou
ManualTurnOn().

— Chaque machine de la ligne hérite de ce bloc abstrait via un bloc de fonction spécifique. Ces
blocs redéfinissent les méthodes selon les particularités de leur fonctionnement. L’accès aux
entrées/sorties se fait via le mot-clé EXTERNAL, garantissant une encapsulation correcte des
ressources matérielles.

Cette structure améliore l’abstraction et renforce la lisibilité du code. Par exemple, au lieu
de vérifier directement une variable de sortie telle que O_Voyant, l’état du voyant est consulté via
Voyant.IsTurnedOn(). De plus, les transitions d’état deviennent centralisées : le module LineModes
envoie les commandes et attend les accusés de réception, assurant ainsi une synchronisation explicite.
La gestion des machines est réalisée à l’aide d’une liste de pointeurs sur objets Machine, sur
laquelle il est possible d’itérer pour propager des ordres. Ainsi, l’ajout d’une ou plusieurs machines
supplémentaires n’impacte pas la logique globale du programme.

58
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

Cependant, cette architecture orientée-objet impose une centralisation rigide de la logique de

fonctionnement : toutes les interactions inter-machines doivent transiter par le contrôleur principal.
Par exemple, la règle « Ne pas allumer l’éclairage tant que le convoyeur ne fonctionne pas » doit être
gérée par le LineModes, ce qui peut alourdir la complexité du code maître et nuire à sa lisibilité.

4.13.0.4 Approche hybride : compromis entre abstraction et flexibilité

Pour tirer avantage des points forts de chaque méthode tout en limitant leurs inconvénients,
une approche hybride a été adoptée. Elle combine la structuration orientée-objet avec la souplesse de
l’approche fonctionnelle classique :

— Les blocs de fonction dérivés du bloc abstrait Machine sont maintenus pour chaque machine.

— L’interaction avec les machines peut se faire soit via une boucle sur une liste de pointeurs
(setAllReqStates(Start, Machines.ListPtMachines)), soit directement via l’identifiant d’une
machine (Machines.Conveyor.setReqState(Start)).

Cette flexibilité permet de conserver un code modulaire tout en permettant des actions ciblées.
Ainsi, la transition d’état peut être globale ou spécifique selon le besoin fonctionnel.
Une amélioration envisagée de cette structure serait de passer toutes les entrées/sorties des
machines en tant qu’arguments, ce qui permettrait une instanciation plus massive et généralisée de
machines identiques. Toutefois, cela impliquerait une dispersion des déclarations de variables dans
le code, réduisant ainsi sa lisibilité. Dans le contexte actuel, la clarté du code a été privilégiée à
l’optimisation mémoire.

4.13.1 Organisation modulaire du projet sous TwinCAT 3

La Figure 4.3 illustre l’organisation typique des fichiers dans une application développée sous
TwinCAT 3. Cette architecture modulaire vise à structurer clairement le projet en facilitant sa maintenance,
sa lisibilité et sa réutilisabilité.
À la racine du projet, on distingue plusieurs dossiers principaux :

— DataTypes : ce répertoire regroupe tous les types de données définis par l’utilisateur, tels que
les ENUM, STRUCT ou UNION, servant à uniformiser les échanges entre modules.

— GlobalVariables : contient les listes de variables globales accessibles à l’ensemble du programme.

Ces variables sont utilisées pour centraliser les informations partagées entre les différentes unités
fonctionnelles.

— POUs (Program Organization Units) : ce dossier concentre les blocs fonctionnels, programmes
et fonctions utilisés dans l’application. Il est subdivisé en trois catégories :

59
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

— Communs : contient les éléments génériques réutilisables d’un projet à l’autre (par exemple,
gestion des erreurs, conversion de types, etc.).

— HMI : regroupe les modules spécifiques à l’interface homme-machine.

— Machines : comprend les blocs spécifiques à la logique des différentes machines de la ligne,
définis en fonction du besoin du projet en cours.

Figure 4.3 : Architecture typique d’un projet TwinCAT 3

4.13.1.1 Composants clés de l’architecture logicielle

Cette section présente les éléments fondamentaux du framework développé sous TwinCAT 3,
en mettant en lumière deux composants majeurs : LineModes et le bloc fonctionnel abstrait Machine.

LineModes – Gestion centralisée des états de la ligne Le programme LineModes incarne l’état
global de la ligne de production. Comme discuté dans la section relative au paradigme orienté-objet,
ce composant agit comme le contrôleur principal qui orchestre la transition entre les différents modes de
fonctionnement (Attente, Démarrage, Arrêt, etc.), en réponse aux requêtes de l’interface homme-machine
(HMI) ou à des signaux internes à la chaîne.

60
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

La Figure 4.4 illustre un extrait du programme LineModes écrit en langage SFC (Sequential
Function Chart) avec TwinCAT 3. Le cycle commence généralement par un état d’arrêt d’urgence, avant
de passer au mode Waiting, à partir duquel d’autres séquences peuvent être initiées. Les transitions
ne dépendent pas uniquement des commandes de l’HMI, mais également de drapeaux (flags) indiquant
la fin d’actions antérieures.
Cette approche permet notamment de représenter de manière fidèle les enchaînements définis
dans le Guide d’Étude des Modes de Marche et d’Arrêt de Citius1 , même si ces séquences sont
modélisées à un seul niveau dans le GRAFCET.

Machine – Abstraction des entités de production Le bloc fonctionnel Machine joue un rôle
central dans l’implémentation orientée-objet de l’architecture. Il s’agit d’un composant abstrait, conçu
pour ne jamais être instancié directement. Chaque machine réelle de la chaîne hérite de ce bloc
générique, en redéfinissant ses comportements spécifiques (états, transitions, méthodes d’activation,
etc.).
La Figure 4.11 présente un extrait de ce bloc, où sont déclarés notamment :

— l’état actuel de la machine,

— l’état requis dicté par le programme LineModes,

— des méthodes standards telles que IsTurnedOn() ou ManualTurnOn().

Grâce à cette abstraction, chaque composant de la ligne devient autonome dans la gestion de
ses entrées/sorties, tout en restant coordonné par le programme maître.

4.14 Interface Homme-Machine (IHM)

Dans le domaine des systèmes automatisés, l’Interface Homme-Machine (IHM) constitue un

élément essentiel pour assurer une interaction fluide et intuitive entre l’opérateur et la machine. Elle
permet la visualisation en temps réel des données, la supervision des états du système ainsi que la
possibilité d’agir directement sur les processus automatisés.
Dans le cadre de mon stage effectué au sein du centre d’innovation 4.0, j’ai été amené à concevoir
une IHM adaptée aux besoins spécifiques d’un client. L’objectif était de développer une interface
moderne, ergonomique, et compatible avec l’environnement de programmation TwinCAT 3.0, tout en
privilégiant la réutilisabilité et la simplicité de maintenance.
Pour cela, une approche basée sur les technologies web (HTML, CSS et JavaScript) a été choisie.
Cette méthode permet une personnalisation avancée de l’interface, tout en restant accessible aux
équipes techniques du client. Avant le développement final, un premier prototype a été réalisé sur

61
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

Figure 4.4 : Représentation partielle du programme LineModes en SFC (TwinCAT 3)

PowerPoint afin de visualiser la structure générale de l’IHM et d’obtenir un retour du client. Suite à la
validation de ce design, le développement a été effectué directement dans l’environnement TwinCAT
3.0.
Ce chapitre présente les différentes étapes de la conception de l’IHM, en mettant l’accent sur

62
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

Figure 4.5 : Extrait du bloc fonctionnel abstrait Machine

les choix techniques, les outils utilisés, la stratégie de communication avec l’automate via le protocole
ADS, ainsi que les avantages de la solution retenue.

63
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

Figure 4.6 : Séquence de communication entre les GRAFCET de la ligne (avec la machine de
remplissage) et la partie préparation du produit (cuves)

4.14.1 Objectif de l’IHM

Dans le cadre de ce projet, l’objectif était de développer une Interface Homme-Machine (IHM)
intuitive, réutilisable et facilement modifiable selon les besoins du client. Contrairement aux approches
classiques basées sur Windows Forms Application (WFA) ou Windows Presentation Foundation (WPF),
une méthode plus moderne et flexible a été adoptée, reposant sur les technologies HTML, CSS et
JavaScript.
Cette approche permet une séparation claire entre la structure, la logique et le style de l’interface,
tout en offrant une plus grande souplesse dans le design et la réutilisabilité du code.

4.14.1.1 Conception initiale : prototype PowerPoint

Avant de débuter le développement technique, une première maquette graphique de l’IHM a

été réalisée à l’aide de Microsoft PowerPoint. Cette étape visait à structurer les différents éléments de
l’interface (boutons, indicateurs, zones de saisie, etc.) et à proposer un premier rendu visuel au client.
L’objectif principal de cette démarche était de :

— Fournir un aperçu clair de l’interface finale.

— Faciliter la communication avec le client.

64
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

— Obtenir un retour rapide sur l’ergonomie et le visuel.

Après validation de cette maquette par le client, l’implémentation effective a été réalisée dans
l’environnement TwinCAT 3.0.

Figure 4.7 : Prototype N :01 d’IHM sur PowerPoint

Figure 4.8 : SUIT de Prototype N :01 d’IHM sur PowerPoint

4.14.1.2 Développement web intégré dans TwinCAT 3.0

Le développement de l’IHM s’est appuyé sur les fonctionnalités web intégrées à TwinCAT 3.0,
permettant d’exécuter des pages web embarquées. Ces pages, développées en HTML, stylisées via CSS,
et rendues interactives grâce au JavaScript, assurent une communication efficace avec l’automate via
le protocole ADS (Automation Device Specification).
Les avantages de cette méthode sont nombreux :

65
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

Figure 4.9 : Essai de l’IHM dans l’environnement de simulation TwinCAT

Figure 4.10 : SUIT Essai de l’IHM dans l’environnement de simulation TwinCAT

— Portabilité : l’interface est accessible depuis tout navigateur web compatible.

— Modularité et réutilisabilité : les composants sont facilement adaptables à d’autres projets.

— Indépendance vis-à-vis de l’OS : pas besoin de composants Windows spécifiques.

— Mise à jour en temps réel : les valeurs sont synchronisées dynamiquement avec l’automate.

L’architecture de l’interface repose sur :

— HTML : structure de la page, disposition des composants (boutons, tableaux, champs de texte,
etc.).

— CSS : style visuel de l’IHM (couleurs, polices, espacements).

66
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

— JavaScript : gestion des événements, rafraîchissement dynamique des valeurs, interactions avec
l’automate.

4.14.1.3 Communication avec l’automate via le protocole ADS

La communication entre l’IHM et l’automate Beckhoff repose sur le protocole ADS, qui permet
une liaison directe sans licence additionnelle. Les éléments techniques utilisés dans cette communication
incluent :

— AMSNetID : identifiant réseau de la cible.

— Port ADS : typiquement 48898 (ou 0xBF02).

— Index Group et Index Offset : pour pointer vers une variable spécifique.

— Taille des données : à lire ou écrire.

La bibliothèque TcAdsWebService.js fournie par Beckhoff permet de faciliter cette interaction

directement depuis JavaScript, rendant les échanges de données fluides et efficaces.

4.14.1.4 Avantages de l’approche adoptée

L’approche basée sur les technologies web embarquées présente plusieurs bénéfices :

— Compatibilité avec de nombreux navigateurs.

— Facilité de mise à jour et de maintenance.

— Réutilisabilité du code pour d’autres projets.

— Expérience utilisateur modernisée et personnalisable.

4.15 Choix des protocoles de communication

4.15.1 EtherCAT : Protocole principal temps réel

EtherCAT est utilisé comme bus de terrain natif de l’automate Beckhoff. Il permet une
communication rapide et déterministe, ce qui le rend idéal pour les échanges critiques avec les
éléments suivants :

— les automates esclaves Siemens (si compatibles, ou via une passerelle),

— la carte I/O-Link, souvent intégrée dans un module EtherCAT,

— les capteurs et actionneurs intelligents compatibles.

Grâce à sa faible latence et à sa précision de synchronisation, EtherCAT est particulièrement

adapté aux systèmes où la réactivité et le temps réel sont essentiels.

67
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

4.15.2 Modbus TCP/IP : Communication avec le cobot Fanuc

Modbus TCP/IP est utilisé pour assurer la communication entre l’automate Beckhoff et le
robot collaboratif Fanuc. Il s’agit d’un protocole :

— ouvert, simple et largement standardisé,

— fonctionnant sur une liaison Ethernet (via socket TCP),

— pris en charge par les cobots Fanuc via leur contrôleur ou une option logicielle.

Ce protocole permet une intégration souple du robot dans l’architecture globale tout en
assurant une indépendance fonctionnelle entre les différents équipements.

4.15.3 I/O-Link : Pour la gestion des capteurs/actionneurs intelligents

I/O-Link est utilisé pour la communication point-à-point bidirectionnelle entre un maître

I/O-Link (intégré à une carte EtherCAT) et des capteurs/actionneurs intelligents.
Il permet :

— la transmission des mesures analogiques sous forme numérique,

— le diagnostic temps réel des capteurs,

— la reconfiguration dynamique des paramètres de terrain.

Grâce à son intégration via des modules EtherCAT, I/O-Link enrichit la supervision du
système tout en facilitant la maintenance prédictive et l’optimisation des performances de
terrain.

4.16 Architecture fonctionnelle du réseau

L’architecture repose sur une topologie centralisée autour de l’automate Beckhoff, qui
gère les flux de données via ses interfaces EtherCAT et Ethernet.

— Les automates Siemens agissent en sous-systèmes, assurant des fonctions locales comme la
gestion de sécurité ou le contrôle d’équipements dédiés, tout en échangeant avec le
Beckhoff via PROFINET ou EtherCAT (selon configuration).

— Le robot collaboratif Fanuc communique via Modbus TCP/IP pour :

— la réception d’ordres de mission,

— l’envoi d’états et de positions.

— Les capteurs/actionneurs sont intégrés via I/O-Link, ce qui permet une remontée intelligente
des données (valeurs analogiques, diagnostics, etc.) vers le Beckhoff.

68
Chapitre 4. Développement logiciel de l’automatisme et de la supervision

Figure 4.11 : l’implémentation du protocole de communication entre les différents appareils du

système de la ligne de production

4.17 Justification des choix technologiques

Le choix de cette combinaison de protocoles repose sur un équilibre entre performance

temps réel, interopérabilité et modularité :

— EtherCAT : garantit un contrôle rapide et fiable des équipements critiques (capteurs, cartes
E/S, automates esclaves),

— Modbus TCP/IP : facilite l’intégration souple du robot Fanuc, sans perturber le réseau
principal temps réel,

— I/O-Link : permet une supervision avancée, un diagnostic en continu et une maintenance

facilitée des capteurs/actionneurs.

69
Conclusion du Chapitre

Ce chapitre a exposé une présentation complète du système automatisé, couvrant le matériel

utilisé, l’architecture logicielle et les interfaces de contrôle. Les capteurs et actionneurs, principalement
sélectionnés chez IFM et Festo, garantissent fiabilité et adéquation aux exigences du procédé, avec une
intégration soigneusement planifiée.
La structuration modulaire sous TwinCAT 3, mêlant GRAFCET (SFC) et Ladder, a permis
une organisation claire des séquences et une maintenance facilitée. L’approche orientée objet, bien que
plus complexe, a favorisé la réutilisabilité et la scalabilité du système.
L’Interface Homme-Machine, conçue avec des technologies web modernes (HTML, CSS, JavaScript),
assure une supervision intuitive et flexible. Les protocoles de communication (EtherCAT, Modbus
TCP/IP, I/O-Link) ont été choisis pour garantir une intégration fluide et optimiser la performance en
temps réel.
La méthodologie adoptée, combinant prototypage et modularité, a conduit à une solution
robuste, évolutive et facilement maintenable. Ce travail souligne l’importance d’une conception rigoureuse
et d’une architecture soignée pour répondre aux exigences industrielles actuelles.
En perspectives, l’intégration d’outils d’analyse de données (IIoT) pour la maintenance prédictive
et l’optimisation de la communication inter-machines pourraient renforcer encore davantage la performance
et la flexibilité du système.
En résumé, ce chapitre a posé les fondations techniques et fonctionnelles d’un système automatisé
performant, alliant robustesse matérielle et sophistication logicielle au service des besoins industriels
modernes.

70
 Chapitre 5

Gestion et organisation du projet

Plan
1 Méthodologie PDCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

2 Utilisation du diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . 73

3 Difficultés rencontrées et ajustements . . . . . . . . . . . . . . . . . . . . . . 73

4 Suivi quotidien avec Google Agenda . . . . . . . . . . . . . . . . . . . . . . . 74

5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Chapitre 5. Gestion et organisation du projet

Durant mon stage, j’ai eu l’opportunité de prendre part activement à la gestion et à l’organisation
d’un projet technique en collaboration avec l’équipe encadrante et d’autres stagiaires. Cette responsabilité
m’a permis de mettre en œuvre plusieurs outils et méthodes de gestion de projet afin de structurer le
travail, suivre l’avancement et garantir le respect des délais.

5.1 Méthodologie PDCA

Pour structurer le déroulement du projet, j’ai utilisé la méthode PDCA (Plan – Do – Check –
Act), un outil d’amélioration continue très répandu dans les environnements industriels. Voici comment
cette méthode a été appliquée :

— Plan (Planifier) : définition des objectifs du projet, des ressources nécessaires, et répartition
des tâches entre les membres de l’équipe (moi-même, les autres stagiaires, et le tuteur technique).

— Do (Faire) : mise en œuvre des tâches planifiées, développement des différentes étapes du projet
en suivant les consignes techniques et les contraintes du cahier des charges.

— Check (Vérifier) : vérification régulière de l’état d’avancement, validation technique des sous-parties
du projet, et ajustement en cas de déviations.

— Act (Agir) : adaptation du planning et mise en place de mesures correctives pour optimiser
l’efficacité et résoudre les problèmes rencontrés.

Cette approche itérative m’a permis d’améliorer progressivement le projet, tout en impliquant
activement les membres de l’équipe dans le suivi des actions.

Figure 5.1 : PDCA

72
Chapitre 5. Gestion et organisation du projet

5.2 Utilisation du diagramme de Gantt

Un diagramme de Gantt a été établi dès les premières phases du projet pour visualiser et
planifier les différentes tâches à accomplir. Cet outil m’a permis de :

— Répartir clairement les tâches entre les différents intervenants ;

— Identifier les dépendances entre les tâches ;

— Suivre l’état d’avancement du projet au jour le jour ;

— Prévoir les retards potentiels et adapter les délais en conséquence.

Figure 5.2 : Diagramme de GANTT

5.3 Difficultés rencontrées et ajustements

Il m’est parfois arrivé d’avoir des difficultés à estimer précisément la durée des tâches à effectuer.
Cela m’a obligé à ajuster et à réorganiser le planning au fur et à mesure de l’avancement du projet.
Parmi les principales raisons de cette sous-estimation, on peut citer :

— La phase de conception : elle nécessitait une modélisation à l’aide du logiciel AutoCAD. Cette
compétence n’étant pas encore maîtrisée, j’ai dû suivre une formation et réaliser des recherches
bibliographiques pour être autonome.

73
Chapitre 5. Gestion et organisation du projet

— Le choix des pompes et des différents matériels du process : cela a nécessité des échanges
réguliers avec le client afin de valider les solutions techniques proposées.

— La programmation de l’automate Beckhoff : j’ai dû suivre une formation dédiée chez

Beckhoff Automation pour comprendre l’environnement de développement TwinCAT, ce qui a
rallongé le temps prévu initialement.

— La réalisation du schéma P&ID : cette tâche était relativement éloignée de mes compétences
initiales. J’ai donc mené des recherches bibliographiques approfondies pour bien comprendre les
normes et symboles utilisés.

Tous ces éléments ont mis en lumière l’importance d’un planning flexible, permettant de réajuster
les prévisions en fonction des imprévus ou des besoins de montée en compétences.

5.4 Suivi quotidien avec Google Agenda

En complément du diagramme de Gantt, j’ai utilisé Google Agenda comme outil de suivi
journalier. Chaque journée de travail (8h) était organisée avec des blocs d’activités spécifiques, correspondant
aux tâches à réaliser, aux réunions d’équipe, ou aux périodes de documentation et de test.
Cette organisation m’a permis de :

— Garder une trace précise des activités effectuées ;

— Optimiser la gestion de mon temps ;

— Justifier, si nécessaire, mon emploi du temps auprès de mon tuteur ;

— Renforcer ma rigueur professionnelle.

Figure 5.3 : L’Agenda Quotidien

5.5 Conclusion

La gestion structurée du projet, en s’appuyant sur des outils reconnus comme le PDCA, le
diagramme de Gantt et Google Agenda, a été un véritable levier de réussite tout au long de mon stage.

74
Chapitre 5. Gestion et organisation du projet

Malgré quelques imprévus et ajustements liés à l’apprentissage de nouveaux outils ou au besoin de

clarifications techniques, j’ai su adapter ma planification pour faire avancer le projet efficacement. Cette
expérience m’a permis d’améliorer mes compétences organisationnelles, d’approfondir mes connaissances
techniques et de mieux comprendre les réalités de la gestion de projet en entreprise.

75
Conclusion générale

L’ensemble des travaux menés jusqu’à présent dans le cadre de ce stage m’a permis d’aborder
de manière concrète les différentes dimensions de l’automatisation industrielle, en passant par la
conception, la modélisation et la programmation. Nous avons réalisé avec rigueur le schéma P&ID,
modélisé l’installation via AutoCAD Plant 3D, conçu les schémas électriques, choisi et programmé
l’automate Beckhoff, et développé une première version fonctionnelle de l’interface Homme-Machine
(IHM).
Ces étapes représentent une base solide et cohérente pour l’intégration finale du système.
Toutefois, en tenant compte des contraintes budgétaires et des exigences spécifiques du client, il
a été nécessaire d’adapter le périmètre de la réalisation. Certaines fonctions ont été priorisées, d’autres
partiellement préparées pour une intégration future.
À l’heure actuelle, la phase de conception est quasiment finalisée, ce qui ouvre la voie à
la mise en œuvre progressive de la phase de réalisation physique du système. En fonction
du temps restant dans le cadre du stage, il est prévu de réaliser une première version partielle
et opérationnelle du dispositif, permettant d’effectuer les premiers essais.
Ces essais seront suivis d’une phase itérative de vérification, correction et ajustement,
essentielle pour valider le bon fonctionnement du système dans un environnement réel. Ce processus
permettra également d’identifier les points d’amélioration et de garantir une meilleure stabilité avant
déploiement final.
Dans une perspective d’évolution, plusieurs pistes d’amélioration pourront être explorées, notamment :

— L’enrichissement de l’IHM avec des fonctions de diagnostic avancé et une meilleure ergonomie ;

— L’intégration de capteurs connectés pour une maintenance prédictive ;

— La mise en place d’un accès distant sécurisé pour la supervision via des protocoles industriels
modernes (OPC-UA, MQTT) ;

— L’optimisation énergétique du processus automatisé.

Ce stage a été une expérience professionnelle et humaine très enrichissante. Il m’a permis de
mobiliser mes compétences en robotique industrielle dans un cadre réel, tout en prenant conscience des
enjeux liés à la gestion de projet, aux contraintes techniques, économiques et temporelles. Il renforce
ma volonté de poursuivre dans cette voie et de contribuer à l’essor d’une industrie plus intelligente,
flexible et connectée.

76
Annexes

Annexe 1. Exemple d’annexe

La figure annexe 1.1 présente Le logigramme général illustre le fonctionnement de la ligne de

fabrication de boissons

Figure 6.1

77
Annexes

Annexe 2. Entreprise

La figure annexe 2.1 présente Liste et le chiffrage de l’armoire automate.

Figure 6.2 : Liste de chiffrage

Annexe 3. Organigramme de vue d’ensemble

La figure annexe 3 Présentation du logigramme décrivant le fonctionnement détaillé de l’ensemble

du procédé

78
Annexes

Figure 6.3

Annexe 4. GEMMA

La figure annexe 3 Présentation Diagramme GEMMA de la ligne de production

79
Annexes

Figure 6.4 : Diagramme GEMMA

Annexe 4. Déclaration des variables automates (Entrées / Sorties)

sur TWINCAT 3.0

Annexe 4.1 Déclaration des Entrées Automates (VAR_GLOBAL)

//Commandes manuelles
M AT %I* : BOOL ; // Bouton-poussoir de démarrage (Départ cycle)
I_StartCycle AT %I* : BOOL ; // Bouton démarrage cycle
I_StopCycle AT %I* : BOOL ; // Bouton arrêt cycle / urgence

// Retour état moteur convoyeur (facultatif, selon installation)

I_MoteurConv_EnMarche AT %I* : BOOL ; // Indique si le moteur du convoyeur en marche

80
Annexes

//Présence des caisses et godets (capteurs de position)

CP AT %I* : BOOL ; // Présence Caisse
C2 AT %I* : BOOL ; // Présence du godet n°1 durant la 1ère phase
C3 AT %I* : BOOL ; // Présence du godet n°X durant la 1ère phase
C4 AT %I* : BOOL ; // Présence du godet durant la 2éme phase
C5 AT %I* : BOOL ; // Présence du godet n°X durant la 2éme phase
C6 AT %I* : BOOL ; // Présence du godet durant la 3éme phase
C7 AT %I* : BOOL ; // Présence du godet n°X durant la 3éme phase
C8 AT %I* : BOOL ; // Présence du godet durant la 4éme phase
C9 AT %I* : BOOL ; // Présence du godet n°X durant la 4éme phase
C10 AT %I* : BOOL ; // Présence du godet durant la 5éme phase
C11 AT %I* : BOOL ; // Présence du godet n°X durant la 5éme phase

//Présence des bouteilles

Cb1 AT %I* : BOOL ; // Présence des bouteilles durant la 1ère phase
Cb2 AT %I* : BOOL ; // Présence des bouteilles durant la 2éme phase
Cb3 AT %I* : BOOL ; // Présence des bouteilles durant la 3éme phase
Cb4 AT %I* : BOOL ; // Présence des bouteilles durant la 4éme phase
Cb5 AT %I* : BOOL ; // Présence des bouteilles durant la 4éme phase
// Position des vérins
A0 AT %I* : BOOL ; // Pos. repos vérin A
A1 AT %I* : BOOL ; // Pos. travail vérin A
B0 AT %I* : BOOL ; // Pos. repos vérin B
B1 AT %I* : BOOL ; // Pos. travail vérin B
C0 AT %I* : BOOL ; // Pos. repos vérin C
C1 AT %I* : BOOL ; // Pos. travail vérin C
D0 AT %I* : BOOL ; // Pos. repos vérin D
D1 AT %I* : BOOL ; // Pos. travail vérin D
E0 AT %I* : BOOL ; // Pos. repos vérin E
E1 AT %I* : BOOL ; // Pos. travail vérin E

// Capteurs de niveau
I_NiveauBas_C1 AT %I* : BOOL ; // Niveau bas cuve 1 (eau claire)

81
Annexes

I_NiveauHaut_C1 AT %I* : BOOL ; // Niveau haut cuve 1 (eau claire)

I_NiveauBas_C2 AT %I* : BOOL ; // Niveau bas cuve 2 (batch précédent)
I_NiveauHaut_C2 AT %I* : BOOL ; // Niveau haut cuve 2 (batch précédent)
I_NiveauBas_MIX AT %I* : BOOL ; // Niveau bas cuve mélangeuse
I_NiveauHaut_MIX AT %I* : BOOL ; // Niveau haut cuve mélangeuse
I_NiveauBas_TMP AT %I* : BOOL ; // Niveau bas cuve tampon
I_NiveauHaut_TMP AT %I* : BOOL ; // Niveau haut cuve tampon

//Mesures analogiques
I_Volume_MIX AT %I* : REAL ; // Capteur ultrason volume cuve mélange (IFM, 4-20mA)
I_DebitSortie_TMP AT %I* : REAL ; // Débitmètre sortie cuve tampon → remplisseuse

// Demandes externes
I_DemandeRempl AT %I* : BOOL ; // Signal machine de remplissage

// Entrées de sélection de recette par l’opérateur

I_Recette_ColorantRouge AT %I* : BOOL ; // Sélection colorant rouge
I_Recette_ColorantJaune AT %I* : BOOL ; // Sélection colorant jaune
I_Recette_ColorantBleu AT %I* : BOOL ; // Sélection colorant bleu

I_UtiliserBatchPrecedent AT %I* : BOOL ; // Oui/Non pour usage du batch précédent (cuve 2)

I_Ajouter_Epaississant AT %I* : BOOL ; // Oui/Non pour ajout d’épaississant
I_Ajouter_GrainesSesame AT %I* : BOOL ; // Oui/Non pour ajout de graines de sésame
I_LancerPreparation AT %I* : BOOL ; // Démarrage de la préparation recette

// Électrovanne 1 - Capteurs de position

I_EV1_Ouvert AT %I* : BOOL ; // Capteur indiquant que EV1 est en position ouverte

82
Annexes

I_EV1_Ferme AT %I* : BOOL ; // Capteur indiquant que EV1 est en position fermée

// Électrovanne 2
I_EV2_Ouvert AT %I* : BOOL ; // EV2 ouverte
I_EV2_Ferme AT %I* : BOOL ; // EV2 fermée

// Électrovanne 3
I_EV3_Ouvert AT %I* : BOOL ; // EV3 ouverte
I_EV3_Ferme AT %I* : BOOL ; // EV3 fermée

// Électrovanne 4
I_EV4_Ouvert AT %I* : BOOL ; // EV4 ouverte
I_EV4_Ferme AT %I* : BOOL ; // EV4 fermée

// Électrovanne 5
I_EV5_Ouvert AT %I* : BOOL ; // EV5 ouverte
I_EV5_Ferme AT %I* : BOOL ; // EV5 fermée

// Électrovanne 6
I_EV6_Ouvert AT %I* : BOOL ; // EV6 ouverte
I_EV6_Ferme AT %I* : BOOL ; // EV6 fermée

// Électrovanne 7
I_EV7_Ouvert AT %I* : BOOL ; // EV7 ouverte
I_EV7_Ferme AT %I* : BOOL ; // EV7 fermée

// Électrovanne 8
I_EV8_Ouvert AT %I* : BOOL ; // EV8 ouverte
I_EV8_Ferme AT %I* : BOOL ; // EV8 fermée

// Électrovanne 9
I_EV9_Ouvert AT %I* : BOOL ; // EV9 ouverte
I_EV9_Ferme AT %I* : BOOL ; // EV9 fermée

83
Annexes

// Électrovanne 10
I_EV10_Ouvert AT %I* : BOOL ; // EV10 ouverte
I_EV10_Ferme AT %I* : BOOL ; // EV10 fermée

// Électrovanne 11
I_EV11_Ouvert AT %I* : BOOL ; // EV11 ouverte
I_EV11_Ferme AT %I* : BOOL ; // EV11 fermée

// --- États des Pompes principales (retours d’information automate) ---

I_Pompe1_EnMarche AT %I* : BOOL ; // Pompe principale 1 en marche
I_Pompe2_EnMarche AT %I* : BOOL ; // Pompe principale 2 en marche
I_Pompe3_EnMarche AT %I* : BOOL ; // Pompe principale 3 en marche

// --- États des Pompes colorants (retours d’information automate) ---

I_PompeRouge_EnMarche AT %I* : BOOL ; // Pompe colorant rouge (PM1) en marche
I_PompeJaune_EnMarche AT %I* : BOOL ; // Pompe colorant jaune (PM2) en marche
I_PompeBleue_EnMarche AT %I* : BOOL ; // Pompe colorant bleu (PM3) en marche

// RETOURS ROBOT (signaux en entrée automate)

I_Cycle1Fini_Robot AT %I* : BOOL ; // Fin du cycle 1 : bouteilles vides posées
I_Cycle2Fini_Robot AT %I* : BOOL ; // Fin du cycle 2 : bouchons posés
I_Cycle3Fini_Robot AT %I* : BOOL ; // Fin du cycle 3 : déchargement terminé
I_RobotPret AT %I* : BOOL ; // Robot prêt à recevoir une commande
I_Fault_Robot AT %I* : BOOL ; // Erreur robot (alarme, arrêt d’urgence, etc.)

84
Annexes

// RETOURS MACHINE REMPLISSAGE

I_RemplissagePret AT %I* : BOOL ; // Machine de remplissage prête
I_RemplissageFini AT %I* : BOOL ; // Cycle de remplissage terminé
I_RemplissageErreur AT %I* : BOOL ; // Erreur sur la machine de remplissage

// RETOURS MACHINE BOUCHAGE

I_BouchagePret AT %I* : BOOL ; // Machine de bouchage prête
I_BouchageFini AT %I* : BOOL ; // Cycle de bouchage terminé
I_BouchageErreur AT %I* : BOOL ; // Erreur sur la machine de bouchage

//POUR L’IHM CHOIX ENTRE DIRECTION DE PRODUIT

I_ChoixVersMELANGEUSE AT %I* : BOOL ; // Choix de passage vers cuve mélangeuse
I_ChoixVersTAMPON AT %I* : BOOL ; // Choix de passage vers cuve tampon

Annexe 4.2 Déclaration des Sorties Automates (VAR_GLOBAL)

VAR_GLOBAL

//SORTIES (OUT) - %Q*

// Commandes moteur convoyeur

Q_MoteurConv_Active AT %Q* : BOOL ; // Commande pour démarrer le moteur du convoyeur
Q_MoteurConv_Arret AT %Q* : BOOL ; // Commande pour arrêter le moteur du convoyeur

// Commandes vérins

A_Sortie AT %Q* : BOOL ; // Vérin A en sortie (tige sortie)

A_Rentree AT %Q* : BOOL ; // Vérin A en rentrée (tige rentrée)
B_Sortie AT %Q* : BOOL ; // Vérin B en sortie
B_Rentree AT %Q* : BOOL ; // Vérin B en rentrée

85
Annexes

C_Sortie AT %Q* : BOOL ; // Vérin C en sortie

C_Rentree AT %Q* : BOOL ; // Vérin C en rentrée
D_Sortie AT %Q* : BOOL ; // Vérin D en sortie
D_Rentree AT %Q* : BOOL ; // Vérin D en rentrée
E_Sortie AT %Q* : BOOL ; // Vérin E en sortie
E_Rentree AT %Q* : BOOL ; // Vérin E en rentrée

//Commandes électrovannes
Q_EV1 AT %Q* : BOOL ; // EV cuve 1 (eau claire)
Q_EV2 AT %Q* : BOOL ; // EV cuve 2 (batch précédent)
Q_EV3 AT %Q* : BOOL ; // EV vers cuve mélangeuse
Q_EV4 AT %Q* : BOOL ; // EV colorant rouge
Q_EV5 AT %Q* : BOOL ; // EV colorant jaune
Q_EV6 AT %Q* : BOOL ; // EV colorant bleu
Q_EV7 AT %Q* : BOOL ; // EV d’entrée finale dans cuve mélangeuse
Q_EV8 AT %Q* : BOOL ; // EV transfert direct
Q_EV9 AT %Q* : BOOL ; // EV mélangeuse → cuve tampon
Q_EV10 AT %Q* : BOOL ; // EV cuve tampon → remplissage

//Commandes pompes
Q_P1 AT %Q* : BOOL ; // Pompe centrifuge cuve 1
Q_P2 AT %Q* : BOOL ; // Pompe mélangeuse → cuve tampon
Q_P3 AT %Q* : BOOL ; // Pompe cuve tampon → remplissage
Q_Pmb1 AT %Q* : BOOL ; // Pompe brushless colorant rouge
Q_Pmb2 AT %Q* : BOOL ; // Pompe brushless colorant jaune
Q_Pmb3 AT %Q* : BOOL ; // Pompe brushless colorant bleu

//Commandes COBOT CRX 10

Q_LancerCycle1_Robot AT %Q* : BOOL ; // Démarrage du cycle 1 : pose des bouteilles vides

Q_LancerCycle2_Robot AT %Q* : BOOL ; // Démarrage du cycle 2 : pose des bouchons
Q_LancerCycle3_Robot AT %Q* : BOOL ; // Démarrage du cycle 3 : déchargement/palettisation

86
Annexes

// Commandes machines (remplissage et bouchage)

Q_DemarrerCycleRemplissage AT %Q* : BOOL ; // Commande : démarrage cycle de remplissage
Q_DemarrerCycleBouchage AT %Q* : BOOL ; // Commande : démarrage cycle de bouchage

// Commandes machines de partie preparation CUVES

Q_EV11 AT %Q* : BOOL ; // EV pour épaississant

Q_P4 AT %Q* : BOOL ; // Pompe épaississant
Q_EV12 AT %Q* : BOOL ; // EV pour graines de sésame
Q_P5 AT %Q* : BOOL ; // Pompe graines de sésame

// --- Commandes des Pompes principales ---

Q_Pompe1_Demarrer AT %Q* : BOOL ; // Commande pour démarrer la pompe principale 1
Q_Pompe1_Arreter AT %Q* : BOOL ; // Commande pour arrêter la pompe principale 1

Q_Pompe2_Demarrer AT %Q* : BOOL ; // Commande pour démarrer la pompe principale 2

Q_Pompe2_Arreter AT %Q* : BOOL ; // Commande pour arrêter la pompe principale 2

Q_Pompe3_Demarrer AT %Q* : BOOL ; // Commande pour démarrer la pompe principale 3

Q_Pompe3_Arreter AT %Q* : BOOL ; // Commande pour arrêter la pompe principale 3

// --- Commandes des Pompes colorants ---

Q_PompeRouge_Demarrer AT %Q* : BOOL ; // Commande pour démarrer la pompe colorant rouge
Q_PompeRouge_Arreter AT %Q* : BOOL ; // Commande pour arrêter la pompe colorant rouge

87
Annexes

Q_PompeJaune_Demarrer AT %Q* : BOOL ; // Commande pour démarrer la pompe colorant jaune

Q_PompeJaune_Arreter AT %Q* : BOOL ; // Commande pour arrêter la pompe colorant jaune

Q_PompeBleue_Demarrer AT %Q* : BOOL ; // Commande pour démarrer la pompe colorant bleu

Q_PompeBleue_Arreter AT %Q* : BOOL ; // Commande pour arrêter la pompe colorant bleu

//VARIABLES INTERNES (Étapes / Séquences / Temporisations) --

// TEMPORISATEURS (TON/TOF/TP)

Tmr_Attente_Vissage : TON; // Temporisation vissage

Tmr_EntreDeuxEtapes : TON; // Temporisation transition

88
Annexes

Annexe 5. Exemple d’annexe

La figure annexe 5 Présentation Le Ladder de la ligne

Figure 6.5 : LADDERS tep0

Figure 6.6 : LADDERS tep1

Figure 6.7 : LADDERS tep2

Figure 6.8 : LADDERS tep3

89
Annexes

Figure 6.9 : LADDERS tep4

Figure 6.10 : LADDERS tep5

Figure 6.11 : LADDERS tep6

90
Annexes

91
Annexes

Résumé
Ce rapport présente le projet réalisé de février à juin 2025 au Centre d’Innovation du
CMQE Industrie du Futur Île-de-France, spécialisé dans l’accompagnement de projets liés à
l’industrie 4.0, en particulier dans les domaines de l’automatisation et de l’intégration de lignes
pédagogiques.
Le thème du projet était la conception et l’automatisation d’une ligne de production de
boissons destinée à la formation, incluant la modélisation des équipements process ainsi que
le développement du système automatisé de commande et de supervision.
Parmi les différentes missions effectuées, les plus importantes furent la conception de la partie
process, incluant les schémas PID (2D) et la modélisation 3D des cuves et des réseaux de
tuyauterie à l’aide du pack Autodesk (AutoCAD Plant 3D).
La seconde partie du projet a concerné l’automatisation de la ligne : le choix de l’automate, la
programmation du cycle de fonctionnement, la gestion des entrées/sorties, et la conception de
l’interface IHM pour le pilotage de la ligne.
Bien que le projet n’ait pas encore atteint la phase de test sur matériel réel, l’ensemble de la
partie logicielle (automate + IHM) a été finalisée et préparée pour une intégration future.

Abstract
This report presents the project carried out from February to June 2025 at the Innovation
Center of the CMQE Industrie du Futur Île-de-France, which specializes in supporting Industry
4.0 projects, particularly in the areas of automation and educational production line integration.
The project focused on the design and automation of a beverage production line intended for
training purposes, including the modeling of process equipment and the development of a fully
automated control and supervision system.
Among the main tasks completed, the most significant were the design of the process section,
including the creation of 2D PID diagrams and the 3D modeling of tanks and piping systems
using the Autodesk suite (AutoCAD Plant 3D).
The second part of the project dealt with automation, involving the selection of the PLC, the
programming of the operational sequence, I/O management, and the development of an HMI
interface for controlling the line.
Although the project had not yet reached the testing phase on real hardware, the entire software
part (PLC and HMI) was completed and prepared for future deployment.
92
 République Française

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique

Université Paris-Saclay

Université d’Évry-Val d’Essonne

Année Universitaire 2024 - 2025