ENSA4/GE/2024-2025

Rapport du Projet de Fin d’Année

Présenté par
HARMOUCHE Oussama
EL KOUBBA El Mahjoub

Spécialité : Génie Electrique

Thème :
CONTRÔLE-COMMANDE D’UNE
MACHINE DE PRODUCTION DES ENCRES

Encadré par : Entreprise : TEC FORGE

Pr. [Link] Encadrant à l’ENSA
M. [Link] Encadrant à l’Entreprise

Soutenu le : / / , devant la commission du jury : M. XXX

M. XXX
M. XXX
Table des matières

Table des figures iv

Liste des tableaux vi

Remerciement vi

Résumé vii

Introduction Générale 1

1 Présentation de l’entreprise et contexte générale du projet 2

I Présentation de la société d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
I.1 TEC FORGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
I.2 Fiche technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
I.3 Organigramme de l’entrprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
I.4 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
II Analyse de besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
II.1 Planification du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
II.2 Analyse fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
II.2.1 Diagramme bête à cornes . . . . . . . . . . . . . . . . . . . . . . . . . 5
II.2.2 Diagramme FAST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
II.2.3 Diagramme pieuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
III Cahier de charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
III.1 Objectifs du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
III.2 Périmètre du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
III.2.1 Fonctionnalités Attendues . . . . . . . . . . . . . . . . . . . . . . . . 8
III.2.2 Contraintes Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 8
III.2.3 Architecture Technique . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Matériels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Protocole de Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
III.2.4 Livrables du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Modélisation du système par GEMMA et élaboration des GRAFCETS 11

I GRAFCET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
I.1 Définition du GRAFCET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
I.2 Grafcet du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

i
 II GEMMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
II.1 Définition du GEMMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
II.2 Procédures du GEMMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
II.3 Description de gemma du système . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Protocole de communication 20
I Modbus TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
I.1 Architecture et Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . 20
I.1.1 Modèle client-serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
I.1.2 Encapsulation des données . . . . . . . . . . . . . . . . . . . . . . . . 21
I.1.3 La structure des trames Modbus TCP/IP . . . . . . . . . . . . . . . . 21
I.1.4 Types de données échangés via Modbus TCP/IP . . . . . . . . . . . . 22
I.1.5 Échange de Données et Gestion des Exceptions . . . . . . . . . . . . . 23
II Liaison RS232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
II.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
II.2 Caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
II.2.1 Niveaux logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
II.2.2 Protocole de transmission de la norme RS232 . . . . . . . . . . . . . . 26

4 Programmation et la supervision de la plate-forme sous TIA PORTAL 28

I Généralités sur les automates programmables industriels . . . . . . . . . . . . . . . . . 28
I.1 Définition d’une automate programmable . . . . . . . . . . . . . . . . . . . . . 28
I.2 Présentation de l’automate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
I.3 Structure interne des automates programmables . . . . . . . . . . . . . . . . . 29
I.4 Critères de choix d’un automate . . . . . . . . . . . . . . . . . . . . . . . . . . 29
I.5 Automate utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
I.6 Langage de programmation pour API . . . . . . . . . . . . . . . . . . . . . . . 30
II Description logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
II.1 Description du logiciel TIA Portal V15.1 . . . . . . . . . . . . . . . . . . . . . . 31
II.2 STEP7 sur TIA Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
II.3 Outils de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
II.3.1 Implémentation de la communication RS232 dans TIA Portal . . . . . 31
II.3.2 Implémentation de la protocole Modbus TCP/IP dans TIA Portal . . 33
III Simulateur de Balance RS232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
IV Programmation de la machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
IV.1 Tables de variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
IV.2 Blocs de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
IV.3 Programmes Ladder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
V Supervision avec une Interface Node-RED . . . . . . . . . . . . . . . . . . . . . . . . . 40
V.1 Présentation de Node-RED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
V.1.1 Définition et principes . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
V.1.2 Fonctionnalités clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
V.1.3 Architecture d’intégration dans le projet . . . . . . . . . . . . . . . . 41
V.2 Création du flow sur Node-RED . . . . . . . . . . . . . . . . . . . . . . . . . . 41
V.2.1 Flow d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

ii
 V.2.2 Flow Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
V.2.3 Flow de supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
V.2.4 Flow des alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
V.2.5 Flow des réglages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Conclusion 48

Bibliographie 50
Annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

iii
Table des figures

1.1 Logo de l’entreprise TECFORGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Diagramme de Gantt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Diagramme bête à corne du fonctionnement du système. . . . . . . . . . . . . . . . . . 5
1.4 Diagramme FAST du fonctionnement du système. . . . . . . . . . . . . . . . . . . . . 6
1.5 Diagramme pieuvre du fonctionnement du système. . . . . . . . . . . . . . . . . . . . . 7
1.6 Balance Mettler Toledo IND231. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Composantes de GRAFCET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Exemple de Macro-étape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Grafcet automatique principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Grafcet Circuit de couleur rouge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Grafcet Circuit de couleur verte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Grafcet Circuit de couleur blue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7 Grafcet Circuit de couleur blue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.8 Grafcet de mode sécurité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.9 La représentation GEMMA du système. . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.10 Mise en œuvre Gemma du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 Cycle de communication Modbus TCP/IP[4]. . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Format de message de Modbus TCP[1]. . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Transaction sans erreur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Transaction avec erreur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Connecteur femelle DB-9 (gauche) et Connecteur mâle DB-9 (droite).[5] . . . . . . . . 25
3.6 les niveau logiques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7 La trame du RS232. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.8 Exemple d’une trame du RS232 point de vue ordinateur. . . . . . . . . . . . . . . . . . 27
3.9 Exemple d’une trame du RS232 point de vue électrique. . . . . . . . . . . . . . . . . . 27

4.1 Automate programmable industriel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Structure interne d’un API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 Module CM 1242. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4 PORT CFG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5 RCV PTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.6 Chars TO String. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.7 Strg Val. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.8 Le bloc MB SERVER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

iv
4.9 Le data bloc du modbus server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.10 Interface du simulateur de balance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.11 Tableau des variables d’entrées. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.12 Tableau des variables de sortie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.13 Tableau des variables d’alarme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.14 Blocs de programmation - TIA PORTAL. . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.15 Procédure du chargement du programme dans l’API 1. . . . . . . . . . . . . . . . . . . 38
4.16 Procédure du chargement du programme dans l’API 2. . . . . . . . . . . . . . . . . . . 38
4.17 Procédure du chargement du programme dans l’API 3. . . . . . . . . . . . . . . . . . . 39
4.18 Procédure du chargement du programme dans l’API 4. . . . . . . . . . . . . . . . . . . 39
4.19 Procédure de la simulation des réseaux - TIA PORTAL . . . . . . . . . . . . . . . . . . 39
4.20 Logo Node-RED. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.21 Interface de développement de Node-RED. . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.22 Schéma d’architecture de communication avec Node-RED. . . . . . . . . . . . . . . . . 41
4.23 Flow d’accueil sur Node-RED. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.24 Vue d’accueil sur le dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.25 Flow de login sur Node-RED. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.26 Vue Login sur le dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.27 Flow de supervision sur Node-RED. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.28 Vue supervision sur le dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.29 Flow des alarmes sur Node-RED. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.30 Vue alarme sur le dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.31 Flow de réglage sur Node-RED. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.32 Vue réglage sur le dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

v
Liste des tableaux

1.1 Fiche technique de TEC Forge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Signification des symboles utilisés dans le système . . . . . . . . . . . . . . . . . . . . 16

2.2 Signification des symboles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Description de chaque champ du Modbus TCP/IP . . . . . . . . . . . . . . . . . . . . 22

3.2 Types de register du Modbus et leur description . . . . . . . . . . . . . . . . . . . . . 22
3.3 Codes de fonction Modbus et leur description . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Connecteur DB-9 et DB-25[6]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 Type TCON IP v4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

vi
Remerciement

vii
Résumé

Nous avons conçu et réalisé un système automatisé de dosage d’encre destiné à une utilisation
industrielle. Le projet a été développé autour d’un automate Siemens S7-1200, avec une balance
connectée via RS232 pour mesurer le poids en temps réel. Le processus de dosage est contrôlé par des
pompes et des vannes, gérées selon des seuils de poids fixes afin d’assurer la précision. Node-RED a été
utilisé pour développer une interface de supervision accessible depuis un navigateur web. Ce dernier
permet la visualisation des données en temps réel.
Le projet a nécessité la maı̂trise de plusieurs compétences : programmation automate (TIA Portal),
communication série, développement web avec Node-RED. Cette expérience nous a permis de renforcer
nos compétences techniques, notre capacité d’analyse et notre autonomie, tout en répondant aux
besoins industriels d’un système fiable et précis.
Mots clés : TIA PORTAL, Encres, Automatisation, Supervision, LADDER, FAST, Siemens S7-1200,
Node-Red, RS-232, Modbus TCP/IP.

viii
Introduction générale

Dans un contexte industriel en constante évolution, l’automatisation et la supervision des systèmes

de production représentent des enjeux majeurs pour améliorer la performance, la qualité et la traçabilité
des procédés. C’est dans ce cadre que s’inscrit notre projet, réalisé en collaboration avec l’entreprise
TECFORGE.

Le projet consiste à concevoir et développer une plate-forme complète d’acquisition, de traitement,

de communication et de supervision des données de pesée issues d’un simulateur de balance. Cette
plate-forme repose sur l’utilisation d’un automate programmable industriel (API) Siemens S7-1200,
programmé via le logiciel TIA Portal, et sur l’implémentation de protocoles de communication indus-
triels comme Modbus TCP/IP et RS232.

Une analyse fonctionnelle rigoureuse a été menée afin de cerner les besoins exacts de l’entreprise et
de définir les fonctionnalités attendues du système. Un cahier des charges précis a été établi, intégrant
les contraintes techniques et les exigences de performance. La modélisation des comportements de
l’installation a été réalisée à l’aide des outils GEMMA et GRAFCET, garantissant une description
claire des séquences de fonctionnement et des modes opératoires.

Par ailleurs, une interface de supervision moderne et intuitive a été développée sous Node-RED
pour visualiser en temps réel . Nous avons divisé notre travail en quatre chapitres :

Le chapitre 1 est consacré à la présentation de l’entreprise d’accueil, TECFORGE, ainsi qu’au

contexte général du projet.
Le chapitre 2 traite de la modélisation du système à l’aide des méthodes GEMMA et GRAFCET.
Le chapitre 3 est dédié à l’étude du protocole de communication. Nous y analysons les choix technolo-
giques réalisés, notamment l’utilisation de Modbus TCP/IP et de la liaison série RS232 pour assurer
un échange fiable et structuré des données entre les équipements.
Le chapitre 4 nous présentons la programmation de la plate-forme réalisée sous TIA Portal. L’auto-
mate Siemens S7-1200 a été configuré et programmé afin d’intégrer les différents éléments du système
et de répondre aux exigences fonctionnelles.
Le chapitre 5 détaille la partie supervision du projet avec la création d’une interface développée sous
Node-RED.

1
Chapitre 1

Présentation de l’entreprise et contexte

générale du projet

Introduction
Dans ce chapitre nous avons essayé de vous montrer et décrire l’entreprise d’accueil ainsi qu’on a
abordé le contexte général du projet dont on a présenté l’étude du besoin.

I Présentation de la société d’accueil

I.1 TEC FORGE
TEC Forge est une startup marocaine créée en 2020, spécialisée dans le développement de solutions
IoT pour les villes intelligentes. L’entreprise propose des solutions informatiques innovantes orientées
vers le développement de villes intelligentes en tenant compte de la réduction de l’impact environne-
mental.
Elle compte à son actif 3 marques dans le domaine de technologies numériques :
• DigitParse : Spécialisée dans le secteur du développement et IT.
• PixelParse : Spécialisée dans le domaine de la communication et la création visuelle.
• LumenParse : Spécialisée dans les technologies liées à la smart city, IoT et l’éclairage connecté.

TEC Forge est une entreprise innovante et dynamique qui a réussi à être labélisée JEUNE EN-
TREPRISE INNOVANTE de la part de l’ADD (Agence du développement du digital) établissement
public stratégique placée sous tutelle du Ministère Délégué auprès du Chef du Gouvernement Chargé
de la Transition Numérique et de la Réforme de l’Administration.

Figure 1.1 – Logo de l’entreprise TECFORGE .

2
I.2 Fiche technique

Nom/ Raison Sociale TEC Forge

Forme Juridique Startup
Adresse Route nationale N°1, TA115, Technopark Souss Massa, Aga-
dir, SOUSS MASSA 80000, MA
Téléphone (+212) 06 61 48 09 64
Email contact@[Link]
Date de création 2020
Secteur d’activité Développement de logiciels personnalisés de systèmes infor-
matiques
Spécialisations smart city, IT, Web development, energy efficiency, Cloud,
Mobile apps et IoT
Site Web [Link]

Table 1.1 – Fiche technique de TEC Forge

I.3 Organigramme de l’entrprise

Directeur Général

Responsable Administratif
Directeur Technique
et Financier

Chef de Projet Chef de Projet Responsable Qualité Responsable

Électricité Informatique Méthodes Communication Digitale

Technicien Technicien
Électricité Informatique

I.4 Problématique
Actuellement, le système de production utilisé par l’entreprise fonctionne de manière entièrement
manuelle, ce qui entraı̂ne des pertes de temps, un risque d’erreurs humaines et un manque de traçabilité
des opérations. La question qui se pose est comment automatiser ce processus afin de garantir un
dosage précis, une communication fiable entre les équipements (automate, balance, interface), tout en
respectant les contraintes techniques et organisationnelles du site de production.

II Analyse de besoin
Introduction
L’objectif principale de ce chapitre est de fournir une vue détaillée de notre projet en utilisant des
diagrammes d’analyse fonctionnelle. Ensuite, nous allons procéder à la modélisation de notre système,

3
qui servira de guide pour la programmation.

II.1 Planification du projet

Il est essentiel d’avoir une gestion efficace pour assurer le succès d’un projet. Le diagramme de
Gantt est un outil très utilisé qui permet de visualiser le temps nécessaire pour accomplir différentes
tâches. La figure ci-dessous illustre le diagramme de Gantt de notre projet :

Figure 1.2 – Diagramme de Gantt.

II.2 Analyse fonctionnelle

L’analyse fonctionnelle est une méthode visant à identifier, organiser, définir, classer par ordre
d’importance et éventuellement évaluer les fonctions d’un système. En d’autres termes, elle offre une
description simple et claire des exigences attendues du système. Elle facilite également la modélisation
et la programmation en établissant une fondation solide pour orienter les décisions et planifier les
tâches.

On distingue deux grandes approches : l’analyse fonctionnelle externe, qui porte sur l’expression
des besoins, et l’analyse fonctionnelle interne, qui se concentre sur la représentation du système en
lui-même. Voici une synthèse des étapes clés de l’analyse fonctionnelle :
• Identification des besoins : L’analyste fonctionnel débute par l’analyse des besoins des utilisa-
teurs, ce qui nécessite d’écouter, d’observer et de consigner ces besoins de façon précise.
• Définition des fonctions : Après avoir identifié les besoins, l’analyste classe et priorise les fonc-
tions du système. Ces fonctions correspondent aux actions ou services que le produit doit fournir pour
répondre aux besoins identifiés.
• Conception technique : À ce stade, l’équipe examine les solutions techniques pour chaque fonc-
tion. Elle prend en compte les contraintes, les coûts et la faisabilité de chaque option.
• Représentations graphiques : Afin de clarifier les relations entre les fonctions, l’analyste recourt à
des outils graphiques tels que le diagramme bête à cornes, le diagramme pieuvre et le diagramme FAST.

4
II.2.1 Diagramme bête à cornes

Le diagramme bête à cornes est un outil d’analyse fonctionnelle externe qui permet d’identifier le
besoin auquel le système répond. Afin de créer un tel diagramme il convient de poser les questions
suivantes :
A qui rend-il service ?
Sur quoi agit-il ?
Dans quel but ?

Figure 1.3 – Diagramme bête à corne du fonctionnement du système.

II.2.2 Diagramme FAST

Le diagramme FAST (Functional Analysis System Technique) propose une décomposition struc-
turée et hiérarchisée des fonctions d’un système. Il part des fonctions de service, liées à l’interaction
avec l’environnement extérieur, passe par les fonctions techniques, propres au fonctionnement interne
du système, et aboutit à la description des solutions technologiques adoptées ou envisagées pour
répondre à ces fonctions techniques[9].

5
 Figure 1.4 – Diagramme FAST du fonctionnement du système.

II.2.3 Diagramme pieuvre

Le diagramme de pieuvre ou des Inter-acteurs représente les différentes interactions entre le pro-
duit et son environnement. Grâce à l’analyse fonctionnelle du besoin, il est possible de déterminer les
fonctions de service attendues et générées par l’utilisation du produit. Ainsi, en étudiant le produit
dans son contexte d’utilisation, en tenant compte de l’environnement dans lequel il évolue, on peut
s’assurer que le produit répond aux attentes exprimées par le client lors de son utilisation.

6
 Figure 1.5 – Diagramme pieuvre du fonctionnement du système.

— La fonction principale :
— FP : Dosage précis des composants d’encre.
— Les fonctions des contraintes :
— FC1 : ssurer la sécurité des opérateurs lors de l’utilisation et de la maintenance du système.
— FC2 : Communiquer avec le PC de gestion via Modbus TCP/IP.
— FC3 : : Fonctionner avec une alimentation électrique stable (interaction avec l’alimenta-
tion).
— FC4 : S’adapter aux conditions environnementales.

Conclusion
L’analyse fonctionnelle a constitué une étape clé dans la structuration de notre projet. Elle nous a
permis d’identifier avec précision les besoins réels, les attentes des utilisateurs, ainsi que les contraintes
techniques et environnementales liées au système. Grâce à cette démarche, nous avons pu définir
clairement les fonctions principales et contraintes de notre futur système, posant ainsi les bases solides
de sa conception. Cette analyse nous guidera tout au long du développement, en assurant cohérence,
efficacité et pertinence par rapport aux objectifs visés.

III Cahier de charge

Introduction
L’analyse du cahier des charges constitue une étape fondamentale pour garantir l’adéquation entre
les besoins du client et les solutions techniques proposées. Ce chapitre vise à détailler les exigences
fonctionnelles, techniques et organisationnelles du projet d’automatisme pour le contrôle-commande

7
d’une machine de production des encres. Il s’articule autour des objectifs, du périmètre, des contraintes
et des livrables définis en concertation avec les parties prenantes.

III.1 Objectifs du Projet

Le projet a pour finalité de concevoir et déployer un système automatisé répondant aux besoins
spécifiques de la production d’encres. Ses principales ambitions incluent :
• Développer un programme de contrôle-commande sur automate Siemens S7-1200 pour pilo-
ter les processus de production.
• Simuler l’intégration d’une balance Mettler Toledo via le protocole RS232 pour l’acquisition
précise des données de pesage.
• Assurer une communication fiable entre le PC de gestion et l’automate S7-1200.
• Développer une interface utilisateur conviviale pour offrir un suivi en temps réel, administrer
les recettes et faciliter le repérage des alarmes.

III.2 Périmètre du Projet

III.2.1 Fonctionnalités Attendues

Le système devra intégrer les fonctionnalités suivantes :

— Acquisition et traitement des données :

— Lecture des valeurs de pesage via la balance Mettler Toledo (simulée).
— Transformation des données brutes en informations utilisables.
— Gestion des recettes :
— Création, modification et sélection de recettes de production depuis le terminal.
— Communication entre l’automate et le terminal (ordinateur) :
— L’échange de données entre le PC de gestion et l’automate S7-1200 utilise un protocole de
communication standardisé.
— Gestion des alarmes et des événements :
— Le système détecte les anomalies (erreur de pesée, absence de seau).

III.2.2 Contraintes Techniques

Cet axe décrit les règles et limitations à respecter pour garantir le bon fonctionnement du projet.
• Langage de programmation : Utilisation de STEP 7 (TIA Portal) pour la programmation de
l’automate Siemens S7-1200.
• Protocoles de communication : Choix entre Modbus TCP/IP (interopérabilité), OPC UA
(sécurité) ou Profinet (intégration native Siemens).
• Respect des normes industrielles en matière de sécurité et de fiabilité.

III.2.3 Architecture Technique

III.2.3.1 Matériels
Cet axe liste les équipements physiques nécessaires pour l’implémentation du projet :
• Automate : Un automate industriel de Marque SIEMENS SIMATIC S7-1200, CPU 1214C, CPU

8
compacte, AC/DC/RLY, E/S intégrées : 14 DI 24V DC ; Relais 10 DO 2A ; 2 AI 0-10 V DC, alimen-
tation : AC 85-264V AC à 47-63Hz, mémoire programme/données 150 Ko.
• Balance : Mettler Toledo (simulation via RS232).
• Terminal : PC avec logiciel de gestion.

Figure 1.6 – Balance Mettler Toledo IND231.

III.2.3.2 Logiciels
Cet axe définit les outils logiciels nécessaires au développement et à l’exploitation du système :
• TIA Portal V15.1 pour le développement du programme automate (programmation LADDER).
• Simulateur pour la balance pour tester l’échange de données avec l’automate.

III.2.3.3 Protocole de Communication

Cet axe décrit les protocoles utilisés pour l’échange de données entre l’automate et le PC de gestion :
• Modbus TCP/IP : Simplicité et interopérabilité avec diverses plateformes.
• OPC UA : Normalisation et sécurité.
• Profinet : Intégration native avec les systèmes Siemens.

III.2.4 Livrables du Projet

• Spécifications fonctionnelles et techniques.

• Programme automate (S7-1200).
• Documentation du protocole de communication choisi.
• Interface utilisateur de supervision.
• Rapport de validation et tests.

Conclusion
L’analyse du cahier des charges a permis de formaliser les attentes techniques et fonctionnelles du
projet, tout en identifiant les contraintes à respecter. L’architecture retenue, centrée sur l’automate
Siemens S7-1200 et le protocole Modbus TCP/IP, assure une solution interopérable, économique et
facile à déployer.

9
Conclusion
En somme, ce chapitre nous a permis d’explorer les fondamentaux indispensables à tout projet,
notamment l’analyse fonctionnelle et le cahier des charges. L’analyse fonctionnelle nous a offert une
compréhension détaillée des besoins et des objectifs, tandis que le cahier des charges a constitué un
document de référence clair pour orienter nos efforts. Ces outils établissent les bases de notre futur
projet et de nos ambitions. Dans les chapitres suivants, nous appliquerons ces notions pour donner vie
à notre vision et atteindre nos buts avec succès.

10
Chapitre 2

Modélisation du système par GEMMA

et élaboration des GRAFCETS

Introduction
Pour garantir une gestion, une exploitation et une maintenance efficaces d’un système automa-
tisé tout au long de son cycle de vie, il est indispensable d’anticiper, dès sa conception, l’ensemble
des scénarios de fonctionnement et d’arrêt. Bien que l’objectif principal soit souvent de maintenir le
système en mode de production automatique, il est tout aussi important de bien comprendre tous
les autres états possibles de son comportement. Par exemple, il serait inapproprié de se retrouver à
découvrir les réactions du système dans une situation d’urgence simplement en actionnant le bouton
d’arrêt d’urgence. Il est impératif de maı̂triser les procédures permettant de sortir de cet état et de
redémarrer le système.
Dans cette perspective, nous commencerons par utiliser le GEMMA (Guide d’Étude des Modes
de Marche et d’Arrêt) pour identifier et définir les différents modes de fonctionnement et d’arrêt du
système. Puis, dans une seconde étape, nous détaillerons le comportement attendu du système en nous
appuyant sur l’outil GRAFCET (Graphe Fonctionnel de Commande des Étapes et Transitions).

I GRAFCET
I.1 Définition du GRAFCET
Le GRAFCET (Graphe Fonctionnel de Commande Étape/Transition) est un outil graphique
élaboré par l’AFCET (Association Française pour la Cybernétique Économique et Technique) en
1977. Il a été normalisé en 1982 (norme NFC 03-190), puis internationalement en 1988 sous la norme
IEC 848, et intégré à la norme IEC 1131-3 en 1993.
▶ Objectifs du GRAFCET
Le GRAFCET a pour but de :
— Représenter de manière graphique le comportement d’un automatisme.
— Décomposer le cycle de fonctionnement d’un système automatisé en étapes et transitions.
— Faciliter la compréhension du fonctionnement pour tous les intervenants (techniciens, développeurs,
etc.).
▶Avantages du GRAFCET
— Indépendant de la technologie utilisée.

11
 — Traduction cohérente du cahier des charges fonctionnel.
— Très adapté aux systèmes automatisés industriels.
— Favorise le passage à la programmation structurée (ex : LADDER, SCL, etc.).
▶Niveaux de représentation
— Niveau 1 : Fonctionnel : décrit le comportement global du système.
— Niveau 2 : Technologique : précise les composants techniques et leur rôle.
▶Composants du GRAFCET
— Étapes : Représentent les différents états stables du processus.
— Transitions : Déclenchent le passage d’une étape à l’autre en fonction de conditions logiques.
— Actions : : Définissent les tâches à exécuter à chaque étape.

Figure 2.1 – Composantes de GRAFCET.

I.2 Grafcet du projet

Les étapes et les transitions du Grafcet décrivent les différents états et les conditions de passage
entre ces états. Les étapes représentent les différents modes de fonctionnement du système, tandis
que les transitions définissent les critères à remplir pour passer d’un mode ou d’une étape à un autre.
Cette approche permet de visualiser clairement la séquence d’opérations et d’assurer la cohérence du
contrôle-commande du système.
▶ Mode automatique :
Ce mode représente le fonctionnement automatique du système. Lorsque toutes les conditions nécessaires
sont réunies, les équipements essentiels sont contrôlés automatiquement en fonction de données et de
paramètres prédéfinis. Par exemple, la commande automatique repose sur la vérification des niveaux
optimaux des matières premières dans les réservoirs pour démarrer le processus.
Macro-étape : Une macro-étape est l’unique représentation d’un ensemble unique d’étapes et de transi-
tions nommé macro-expansion. L’expansion de la macro-étape commence par une seule étape d’entrée
et se termine par une seule étape de sortie.

12
 Figure 2.2 – Exemple de Macro-étape .

Figure 2.3 – Grafcet automatique principal .

13
• Macro-étape C1 : Circuit de couleur rouge.

Figure 2.4 – Grafcet Circuit de couleur rouge .

• Macro-étape C2 : Circuit de couleur verte.

Figure 2.5 – Grafcet Circuit de couleur verte .

• Macro-étape C1 : Circuit de couleur blue.

14
 Figure 2.6 – Grafcet Circuit de couleur blue .

• Macro-étape CM : : Circuit de Mélange

Figure 2.7 – Grafcet Circuit de couleur blue .

Les variables dans ce mode sont :

15
 Type Symbole Signification
C1 Circuit de couleur rouge
C2 Circuit de couleur verte
Les étapes
C3 Circuit de couleur bleu
CM Circuit de mélange
Pompe Rouge 6bars Pompe de couleur rouge qui fonctionne à une pression
de 6 bars.
Pompe Rouge 4bars Pompe de couleur rouge qui fonctionne à une pression
de 4 bars.
Pompe Verte 6bars Pompe de couleur verte qui fonctionne à une pression
de 6 bars.
Les actions
Pompe Verte 4bars Pompe de couleur verte qui fonctionne à une pression
de 4 bars.
Pompe Bleu 6bars Pompe de couleur bleu qui fonctionne à une pression
de 6 bars.
Pompe Bleu 4bars Pompe de couleur bleu qui fonctionne à une pression
de 4 bars.
Vanne N1 Vanne de niveau 1 à grande ouverture.
Vanne N2 Vanne de niveau 2 à petite ouverture
Vanne N2 Vanne de niveau 3 à pulsation
PDR Poids demande de couleur rouge
PRR Calcule du poids restant pour couleur rouge
PDV Poids demande de couleur verte
Les conditions
PRV Calcule du poids restant pour couleur verte
PDB Poids demande de couleur bleu
PRB Calcule du poids restant pour couleur bleu
SPO Seuil de petite ouverture de la vanne
SPu Seuil de pulsation

Table 2.1 – Signification des symboles utilisés dans le système

▶ Mode sécurité :
Le mode sécurité est activé lorsqu’un arrêt d’urgence est déclenché à la suite d’une situation critique ou
d’une non-conformité détectée sur une ligne de production. Lorsqu’un opérateur appuie sur le bouton
d’arrêt d’urgence, toutes les opérations de production sur la ligne concernée sont immédiatement
interrompues afin de permettre une intervention rapide pour résoudre le problème. Pour rétablir le
service, l’exploitant peut choisir de reprendre le cycle à l’endroit précis où il avait été interrompu ou
de redémarrer le processus depuis le début, garantissant ainsi une reprise sécurisée et conforme aux
exigences de qualité et de sécurité industrielle.

16
 Figure 2.8 – Grafcet de mode sécurité.

Symbole Signification
ARU Bouton d’arrêt d’urgence
GPN Grafcet de production normale (Grafcet automa-
tique)
RESET Bouton d’initialisation de système

Table 2.2 – Signification des symboles

II GEMMA
II.1 Définition du GEMMA
Le GEMMA est un guide d’analyse graphique qui aide à définir, dès la phase de conception, les
différents modes de marche et d’arrêt d’un système automatisé. Il permet également d’organiser de
manière structurée la partie commande d’un système de production automatisé[7].

II.2 Procédures du GEMMA

Le GEMMA (Guide d’Étude des Modes de Marche et d’Arrêt) est un outil graphique complémentaire
au GRAFCET. Il permet de représenter de manière claire et complète les différents modes de marche
requis pour un système automatisé.
Les modes de marche peuvent être regroupés en trois grandes familles :
• Famille F : procédures de fonctionnement – elles définissent les différents états de fonctionnement
normal du système.
• Famille A : procédures d’arrêt – elles correspondent aux arrêts normaux ou aux séquences de
marche menant à ces arrêts.
• Famille D : procédures de défaillance – elles décrivent les états d’arrêt du système liés à des causes
internes, telles que des défaillances techniques.

17
Chaque famille regroupe plusieurs états spécifiques à la partie opérative du système :
• États de fonctionnement : F1, F2, F3, F4, F5, F6
• États d’arrêt : A1, A2, A3, A4, A5, A6, A7 • États de défaillance : D1, D2, D3

Figure 2.9 – La représentation GEMMA du système.

Dans le cadre de l’analyse GEMMA, les trois premières procédures de chaque famille permettent
d’illustrer les principaux modes d’exploitation d’un système automatisé :
— Famille F :
— F0 – Marche Automatique : Exécution de la séquence de production suivant la recette
définie.
— F1 – Marche Manuelle : Utilisé lors des phases de test ou pour des réglages fins.
— F2 – Mode de Réglage/Configuration : Permet d’ajuster les paramètres critiques
(calibrage, consignes, seuils).
— Famille A :
— A0 – Arrêt Normal : Arrêt contrôlé en fin de cycle ou de lot.
— A1 – Arrêt de Sécurité : Activation immédiate en cas d’anomalie ou de situation critique.
— A2 – Arrêt Planifié : Utilisé pour la maintenance préventive ou corrective.
— Famille D :
— D0 – Défaut de Communication : : Perte de liaison (par exemple RS232 avec la
balance).
— D1 – Défaut Interne de l’API : Erreur ou dépassement de temps de cycle sur l’automate.
— D2 – Défaut de Mesure : Incohérence entre la valeur attendue et celle obtenue par les
capteurs.

18
II.3 Description de gemma du système
•START : Démarrage du système. Ce signal permet de lancer le fonctionnement normal du
système à partir de l’état d’arrêt initial.
•AUTO : Passage au mode automatique. Le système passe en gestion autonome selon le cycle de
production préétabli.
• ARU : Déclenchement du mode sécurité suite à un arrêt d’urgence ou une détection de non-
conformité.
•RESET : Réinitialisation du système vers l’état initial après un arrêt ou un passage en mode sécurité.

Figure 2.10 – Mise en œuvre Gemma du système .

Conclusion
Le GEMMA s’est un outil essentiel dans la structuration des modes de fonctionnement et d’arrêt de
notre système. En facilitant la visualisation des interactions entre l’opérateur et la machine, il a permis
une meilleure compréhension des transitions entre les différents états du système. Cette approche a
non seulement simplifié la gestion opérationnelle, mais a également renforcé la maintenance préventive
et l’adaptabilité du système face aux évolutions futures. Ainsi, l’intégration du GEMMA dans notre
projet a contribué à une conception plus robuste et évolutive du système automatisé.

19
Chapitre 3

Protocole de communication

Introduction
Dans le cadre du projet de contrôle-commande de la machine de production des encres, la commu-
nication entre les différents équipements est un élément clé pour assurer l’interopérabilité, la fiabilité
et l’efficacité du système. Ce chapitre présente les protocoles de communication utilisés pour relier
l’automate Siemens S7-1200, la balance Mettler Toledo et le terminal de gestion.

I Modbus TCP/IP
Introduction
Modbus est un protocole de communication développé par Modicon (Schneider Electric) en 1979,
largement utilisé en automatisation industrielle. Modbus TCP/IP est une extension de Modbus RTU
fonctionnant sur un réseau Ethernet en utilisant le protocole TCP/IP. Il est basé sur une architecture
client-serveur où un client envoie des requêtes et un serveur répond [1]

I.1 Architecture et Fonctionnement

I.1.1 Modèle client-serveur

Modbus TCP/IP fonctionne selon un modèle client-serveur. C’est une difference par rapport au
modèle maı̂tre-esclave du Modbus RTU (liaison série). Ce modèle client/serveur est basé sur quatre
types de messages [3] :
,→ Requête MODBUS (MODBUS Request),
,→ Confirmation MODBUS (MODBUS Confirmation),
,→ Indication MODBUS (MODBUS Response),
,→ Réponse MODBUS (MODBUS Confirmation).

20
 Figure 3.1 – Cycle de communication Modbus TCP/IP[4].

Dans un réseau Modbus TCP/IP, plusieurs clients peuvent interroger un même serveur simul-
tanément. Cela permet une communication flexible et efficace entre divers équipements industriels.

I.1.2 Encapsulation des données

Modbus TCP/IP utilise une technique appelée encapsulation pour transporter les messages Mod-
bus sur les réseaux TCP/IP. Voici comment ça marche :
♣ Le message Modbus original est conservé intact.
♣ L’en-tête MBAP est ajouté devant le message Modbus.
♣ Le tout est placé dans la section de données d’un paquet TCP/IP standard.

I.1.3 La structure des trames Modbus TCP/IP

Le format de message se compose d’un en-tête d’application Modbus (MBAP) de sept octets, com-
prenant l’identifiant de transaction, l’identifiant de protocole, la longueur du message et l’identifiant
client. En Modbus TCP, l’identifiant de connexion et le numéro de port du serveur sont requis pour
établir la communication. Pour un client, l’adresse IP du serveur, l’identifiant client et le numéro de
port sont requis dans le format du message[1].

Figure 3.2 – Format de message de Modbus TCP[1].

Ce tableau présente les champs composant une trame Modbus TCP/IP, avec leur taille et leur rôle
dans la communication entre un maı̂tre et un esclave.

21
 Champ Taille Description
Identifiant de tran- Un identifiant unique pour suivre les transac-
2 octets
saction tions.
Identifiant Protocole 2 octets Toujours à 0 pour Modbus TCP.
Indique la longueur des données restantes dans
Longueur 2 octets
la trame.
Utilisé pour identifier l’esclave en cas de passe-
Identifiant de l’unité 1 octet
relle.
Spécifie l’action à effectuer (lecture, écriture,
Code de fonction 1 octet
etc.).
Contient les données ou le message Modbus à
Données Variable
transmettre.

Table 3.1 – Description de chaque champ du Modbus TCP/IP

I.1.4 Types de données échangés via Modbus TCP/IP

Modbus distingue quatre types principaux des registers, chacun ayant une fonction spécifique :

Type d’objet Description

Coils Interrupteurs binaires activés/désactivés, contrôlant des re-
lais ou des dispositifs d’E/S booléens.
Discrete Inputs Entrées binaires en lecture seule, provenant de capteurs ou
d’autres dispositifs d’entrée.
Input Registers Registres de 16 bits en lecture seule, souvent utilisés pour
lire des mesures de capteurs.
Holding Registers Registres de 16 bits en lecture/écriture, utilisés pour stocker
des valeurs numériques.

Table 3.2 – Types de register du Modbus et leur description

Ces types de données sont adressés et manipulés à l’aide de codes de fonction spécifiques dans le
protocole Modbus, Les codes de fonctions Modbus définissent les actions à réaliser, comme la lecture
ou l’écriture de données :

22
 Code de fonction Description
01 Read Coils : Lit l’état des variables binaires (0 ou 1) dans un dispositif
esclave (sorties).
02 Read Discrete Inputs : Lit l’état des entrées discrètes dans un dispositif
esclave. Généralement utilisé pour lire des entrées de capteurs (entrées).
03 Read Holding Registers : Lit la valeur de registres de maintien de 16 bits.
Utilisé pour lire des données numériques stockées ou des paramètres.
04 Read Input Registers : Lit la valeur des registres d’entrée, souvent utilisés
pour des données de capteurs ou de mesure (lecture seule).
05 Write Single Coil : Modifie l’état d’une bobine (0 ou 1). Utilisé pour
contrôler une sortie numérique telle qu’un relais ou un moteur.
06 Write Single Holding Register : Écrit une valeur dans un registre de
maintien de 16 bits.
15 Write Multiple Coils : Modifie l’état de plusieurs bobines en une seule
transaction. Utilisé pour changer simultanément plusieurs sorties.
16 Write Multiple Holding Registers : Écrit dans plusieurs registres de
maintien, pour mettre à jour plusieurs paramètres simultanément.

Table 3.3 – Codes de fonction Modbus et leur description

I.1.5 Échange de Données et Gestion des Exceptions

Le message MODBUS est construite par le client qui initie une transaction MODBUS. Le code de
fonction indique au serveur quelle action il doit effectuer. Le protocole d’application MODBUS définit
le format d’une requête initiée par un client.
Le champ du code de fonction dans une unité de données MODBUS est codé sur un octet. Les codes
valides sont compris entre 1 et 255 (en décimal), et la plage de 128 à 255 est réservée pour les réponses
d’exception. Lorsqu’un message est envoyé d’un client à un serveur, le champ du code de fonction
indique au serveur l’action à réaliser. Le code de fonction ”0” n’est pas valide. Des sous-codes de
fonction sont ajoutés à certains codes de fonction pour définir plusieurs actions possibles.
Le champ de données des messages envoyés d’un client à un serveur contient des informations supplémentaires
que le serveur utilise pour exécuter l’action définie par le code de fonction. Ces informations peuvent
inclure des éléments comme les adresses de sorties/discrètes et de registres, la quantité d’éléments à
traiter, et le nombre d’octets de données réels dans le champ.
Dans certains types de requêtes, le champ de données peut être inexistant (de longueur nulle), ce qui
signifie que le serveur n’a besoin d’aucune information supplémentaire. Dans ce cas, seul le code de
fonction spécifie l’action à réaliser.
Si aucune erreur n’est détectée lors de l’exécution de la fonction MODBUS demandée dans une unité
de données MODBUS correctement reçue, le champ de données de la réponse du serveur contient les
données demandées. Si une erreur survient lors de l’exécution de la fonction MODBUS demandée, le
champ contient un code d’exception que l’application serveur utilise pour déterminer l’action à entre-
prendre.
Lorsque le serveur répond au client, il utilise le champ du code de fonction pour indiquer soit une
réponse normale (sans erreur), soit qu’une erreur s’est produite (appelée réponse d’exception). Dans
le cas d’une réponse normale, le serveur renvoie simplement le code de fonction original de la requête.

23
 Figure 3.3 – Transaction sans erreur.

Pour une réponse d’exception, le serveur renvoie un code qui est équivalent au code de fonction
d’origine de la requête, mais avec son bit le plus significatif (le bit le plus à gauche) mis à 1 (logique
1).
Cela permet d’indiquer que la réponse n’est pas une réponse normale, mais une exception, signalant
ainsi un problème ou une erreur lors de l’exécution de la fonction demandée.

Figure 3.4 – Transaction avec erreur.

II Liaison RS232
II.1 Définition
La norme RS-232 (Recommended Standard 232) a été définie en 1969 par l’EIA (Electronic In-
dustries Alliance) pour le but de l’interfaçage d’équipements DTE (Data Terminal Equipment) et
d’équipements DCE (Data Circuit Equipment) en utilisant l’échange série de données binaires.
L’interface RS 232 spécifie la méthode de connexion de deux équipements DTE et DCE. Un équipement
DCE (Modem) reçoit les données provenant du DTE (PC ou imprimante) et les fait transmettre à un
autre DCE via un support de communication comme le téléphone.[5]
Les liaisons RS-232 sont fréquemment utilisées dans l’industrie pour connecter différents appareils
électroniques (automate, appareil de mesure, etc.)

24
 Figure 3.5 – Connecteur femelle DB-9 (gauche) et Connecteur mâle DB-9 (droite).[5]

II.2 Caractéristiques
La connexion RS232 est dite liaison série et de type asynchrone :
▼ Une liaison série fonctionne en envoyant des données un bit à la fois sur un seul canal, de manière
séquentielle. À l’inverse, une liaison parallèle transmet plusieurs bits simultanément sur plusieurs
canaux. Dans la liasion série limitant le nombre de fils de transmission par rapport à des liaisons
parallèles.
▼ La transmission asynchrone est une méthode de transfert de données dans laquelle les données sont
envoyées par l’expéditeur au récepteur à l’aide de la méthode de contrôle de flux. Elle est également
connue sous le nom de transmission start/stop.

Table 3.4 – Connecteur DB-9 et DB-25[6].

Les connecteurs DB-9 ont rapidement remplacé les DB-25, pour des raisons de taille de connecteur
et d’économie de câblage, tous les signaux n’étant pas indispensables à la communication.
Voici la signification des broches du connecteur DB9 :
• GND : (Ground) la masse. Référence nécessaire à toute mesure de tension.

25
• RxD : (Received Data) Données reçues.
• TxD : (Transmitted Data) Données émises.
• RTS : (Request to Send) Indique que le DTE est prêt à émettre.
• CTS : (Clear to Send) Indique que le DCE est prêt à recevoir.
• DSR : (Data Set Ready) Indique que le DCE écoute sa liaison RS-232.
• DTR : (Data Terminal Ready) Indique que le DTE (PC) écoute la liaison RS-232.
• DCD :(Data Carrier Detect, aussi nommée RLSD : Receive Line Signal Detect) Indique Détection
d’un signal sur la ligne.

II.2.1 Niveaux logiques

Les niveaux logiques sont les suivants :

niveau 0 = +12 V (3V < v < 25V )
niveau 1 = -12 V (−25V < v < −3V )

Figure 3.6 – les niveau logiques.

II.2.2 Protocole de transmission de la norme RS232

Les informations à transmettre sont envoyés bit par bit (poids faible en premier) par l’émetteur
sur la ligne TxD, vers le récepteur (ligne RxD) qui le reconstitue.

Figure 3.7 – La trame du RS232.

La signification des champs :

— Bit de start et bit de stop : Indiquent le début et la fin du mot transmis. Le bit de start
a un niveau logique ”0” tandis que le bit de stop est de niveau logique ”1” et ce dernière
généralement 1 ou 2 bits.
— Bit de parité : Ajouté pour détecter les erreurs de transmission.
— Parité paire : Le bit ajouté à la donnée est positionné de telle façon que le nombre des
états 1 soit pair sur l’ensemble {données + bit de parité}.
— Parité impaire : Le bit ajouté à la donnée est positionné de telle façon que le nombre des
états 1 soit impair sur l’ensemble {données + bit de parité}.

26
— Mot : mot transmis de 5,6 7 ou 8 bits.

Figure 3.8 – Exemple d’une trame du RS232 point de vue ordinateur.

Figure 3.9 – Exemple d’une trame du RS232 point de vue électrique.

27
Chapitre 4

Programmation et la supervision de la
plate-forme sous TIA PORTAL

Introduction
Quand un système est décrit comme automatisé, cela indique que le passage d’un état initial à un
état final s’effectue sans intervention humaine, et que ce processus se reproduit systématiquement dès
que les conditions spécifiques de l’état initial sont réunies.
Dans ce chapitre, nous présenterons de façon générale les automates programmables, en insistant plus
spécifiquement sur l’automate S7-1200 de Siemens, qui a servi de base à notre travail, aussi la mise en
place d’une supervision à l’aide de la plateforme Node-RED, permettant de surveiller et d’interagir en
temps réel avec le processus automatisé.

I Généralités sur les automates programmables industriels

I.1 Définition d’une automate programmable
Un automate programmable industriel (API) est un appareil électronique conçu pour être pro-
grammé par des utilisateurs sans compétences informatiques avancées, et spécifiquement destiné à
gérer des processus industriels en temps réel. Sa flexibilité permet de l’adapter à diverses applications,
qu’il s’agisse du traitement, des composants ou du langage utilisé. Cette adaptabilité repose sur sa
conception modulaire.

Figure 4.1 – Automate programmable industriel.

28
I.2 Présentation de l’automate
L’architecture des automates programmables industriels est structurée de la manière suivante :
• Un module d’unité centrale (CPU) qui assure le traitement de l’information et la gestion de toutes
les unités. Ce module comprend un microprocesseur, des circuits périphériques pour la gestion des
entrées/sorties, ainsi que des mémoires RAM et EEPROM pour le stockage des programmes, des
données et des paramètres de configuration du système.
• Un module d’alimentation fonctionnant avec une tension de 220V/50Hz.
• Des modules d’entrées et de sorties, ou des entrées sorties en même temps, qu’ils soient numériques
ou analogiques. Ils sont utilisés pour transmettre les signaux de commande à la partie opérative, ou
inversement.
• Des modules de communication.

I.3 Structure interne des automates programmables

Les automates programmables industriels (API) se composent de quatre principales parties :
• Une unité de traitement, qui comprend un processeur (CPU).
• Une mémoire.
• Des modules d’entrées-sorties.
• Des interfaces d’entrées-sorties.
Ils sont alimentés par une source électrique de 230 V, 50/60 Hz (courant alternatif) ou bien 24 V
(courant continu).
La structure interne d’un automate programmable industriel (API) est similaire à celle d’un système
informatique simple. L’unité centrale regroupe le processeur et la mémoire centrale. Elle est respon-
sable de la gestion de l’interprétation et de l’exécution des instructions du programme.

Figure 4.2 – Structure interne d’un API.

I.4 Critères de choix d’un automate

Lors du choix d’un type d’automate, il est important de prendre en compte certains critères es-
sentiels tels que :

29
• La capacité de traitement du processeur.
• Le nombre d’entrées/sorties.
• La nature des entrées/sorties, qu’elles soient numériques, analogiques ou booléennes.
• La fiabilité.
• La durée de garantie.

I.5 Automate utilisée

L’automate utilisé dans notre projet (appartenant à la gamme SIMATIC S7 de SIEMENS) est le
SIMATIC S7-1200 CPU 1214C AC/DC/Rly, créé sur TIA Portal, avec les caractéristiques suivantes :
• CPU compacte avec mémoire programme/données de 150 Ko.
• Alimentation AC 85-264V, fréquence 47-63 Hz.
• 14 entrées numériques 24VDC SINK/SOURCE.
• 10 sorties relais 2A
• 2 entrées analogiques 0-10V DC intégrées.
• Jusqu’à 3 modules de communication pour la communication série.
• Jusqu’à 8 modules de signalisation pour l’extension des E/S.
• 6 compteurs à haute vitesse et 4 sorties d’impulsion intégrés.
• Contrôleur PROFINET IO et périphérique I.
• Prise en charge des protocoles TCP/IP, communication S7, communication sécurisée Open User, et
serveur Web.
• Serveur OPC UA DA intégré pour les communications industrielles normalisées.

I.6 Langage de programmation pour API

Les automates programmables peuvent être programmés à l’aide de plusieurs langages, mais tous
les fabricants mettent à disposition un environnement de développement conforme à la norme CEI
61131-3. Cette norme définit cinq langages de programmation standardisés :
• Le langage IL (Instruction List) : un langage textuel de bas niveau où chaque ligne correspond
à une unique instruction.
• Le langage ST (Structured Text) : un langage textuel de haut niveau permettant de coder des
algorithmes de complexité diverse.
• Le langage LD (Ladder Diagram) : un langage graphique reposant sur des schémas de contacts,
particulièrement adapté à la programmation d’équations booléennes.
• Le langage FBD (Function Block Diagram) : un langage graphique utilisant des blocs pour
représenter des variables, des opérateurs ou des fonctions, capable de gérer tous les types de variables.
• Le langage SFC (Sequential Function Chart) : un diagramme séquentiel fonctionnel, également
appelé GRAFCET.

II Description logicielle

30
II.1 Description du logiciel TIA Portal V15.1
Le TIA Portal (Portal d’Automatisation Totalement Intégrée) est une plateforme de Siemens qui
repose sur un environnement de développement intégré (IDE) pour programmer et paramétrer ses
systèmes. Il englobe l’automatisation industrielle, incluant les automates programmables, les systèmes
d’entraı̂nement et divers autres équipements.

La version employée dans notre projet est TIA Portal V15.1. En plus des automates, cet outil
permet de programmer et de configurer d’autres dispositifs Siemens, tels que les interfaces homme-
machine (HMI), les systèmes de sécurité, ainsi que les capteurs et les actionneurs.

II.2 STEP7 sur TIA Portal

SIMATIC STEP 7 Basic (TIA Portal) est une version simplifiée et économique du logiciel STEP
7 (Professional Controller Software) intégré dans le TIA Portal. Il permet de réaliser l’ingénierie des
microcontrôleurs SIMATIC ainsi que la configuration des interfaces opérateurs SIMATIC HMI Basic
Panels. De plus, il intègre le logiciel WinCC Basic, inclus comme composant essentiel de la suite
logicielle.

II.3 Outils de communication

Dans notre installation, la communication entre le terminal de gestion (PC) et l’automate S7-1200
s’effectue via le protocole Modbus TCP/IP sur un réseau Ethernet industriel. Ce protocole est
particulièrement adapté pour l’échange rapide et structuré de données sur de longues distances. Par
ailleurs, la balance Mettler Toledo est connectée à l’automate au moyen d’une liaison série RS232,
idéale pour la transmission de données de pesée avec une grande fiabilité à courte distance.

II.3.1 Implémentation de la communication RS232 dans TIA Portal

La balance industrielle utilisée dans notre système transmet le poids en temps réel via une liaison
série RS232. Pour permettre cette communication avec le S7-1200, nous avons utilisé un module
d’extension CM 1241 (RS232), connecté à l’automate.

Figure 4.3 – Module CM 1242.

31
 Configuration des paramètres de communication pour ce module a travers le bloc PORT CFG :

Figure 4.4 – PORT CFG.

— Baudrate : 9600 bauds

— Parité : aucune
— Bits de données : 8
— Bit de stop : 1
on utilise le bloc de communication RCV PTP pour recevoir des trames.

Figure 4.5 – RCV PTP.

Les paramètres d’entrée sont :

— EN R : activé chaque 100 ms (Clock1 0Hz), ce qui déclenche périodiquement la lecture.
— PORT : le numéro du port utilisé. Ici, 270 correspond au module CM 1241 RS232.
— BUFFER : Adresse du tampon mémoire où seront stockées les données reçues.
Les paramètres de sortie permettent de surveiller l’état de la réception des données.
,→Pour analyser des trames reçues depuis la balance et extraction de la valeur de poids au format
ASCII ou binaire on utilise le bloc suivante :

32
 Figure 4.6 – Chars TO String.

Les paramètres d’entrées du bloc Chars TO Strg :

— Chars : Tableau source contenant les caractères à convertir.
— pChars : Il indique la position de départ dans le tableau source à partir de laquelle la copie
des caractères va commencer.
— Cnt : Il sert à spécifier combien de caractères doivent être copiés depuis le tableau source.
Le paramètre de sortie du bloc Chars TO Strg :
— Strg : Chaı̂ne de destination où seront copiés les caractères.
,→Pour convertire de la chaı̂ne de caractères en une valeur réelle utilisable dans le programme automate
on utilise le bloc suivante :

Figure 4.7 – Strg Val.

Les paramètres d’entrées du bloc Strg Val :

— IN : La chaı̂ne de caractères à convertir en valeur numérique.
— FORMAT : Définit le format d’entrée des caractères par exemple : 0000 : Point décimal (.)
ou bien 0001 : Virgule décimale (,).
— P : La position de départ dans la chaı̂ne à partir de laquelle la conversion doit commencer.
Le paramètre de sortie du bloc Strg Val :
— OUT : La valeur résultante après conversion.

II.3.2 Implémentation de la protocole Modbus TCP/IP dans TIA Portal

Pour permettre la supervision et le contrôle à distance via l’interface développée sous Node-RED,
nous avons mis en place une communication Modbus TCP/IP. L’automate Siemens S7-1200 agit ici
comme serveur Modbus, tandis que l’interface Node-RED agit comme client Modbus.

33
 Figure 4.8 – Le bloc MB SERVER.

Ce bloc permet de :
• Accepter une connexion d’un client Modbus TCP.
• Répondre aux requêtes Modbus telles que : lecture de registres ou bien écriture dans les registres.
Les paramètres d’entrées du bloc MB SERVER :
— DISCONNECT : contrôle la connexion, si 0 accepte les connexions entrantes sinon déconnecte
les clients actifs.
— MB HOLD REG : : zone mémoire utilisée pour stocker les valeurs échangées avec le client.
— CONNECT : structure contenant les paramètres de connexion.
Le type du structure de connect et de type TCON IP v4, ce type une donnée système qui décrit les
paramètres de connexion TCP de l’automate.

Paramètre Type de données Description

InterfaceID HW ANY ID de l’interface Profinet de la CPU
ID CONN OUC Identifiant unique de connexion (1 à 4095)
ConnectionType BYTE Type de connexion (11 = TCP)
ActiveEstablished BOOL Type d’établissement de la connexion (Actif/Passif )
RemoteAddress ARRAY [1..4] of BYTE Adresse IP du client autorisé à se connecter
RemotePort UINT Port du client (mettre 0 pour accepter tous)
LocalPort UINT Port du serveur Modbus TCP (habituellement 502)

Table 4.1 – Type TCON IP v4

dans notre cas on travaille avec les paramètres suivantes :

34
 Figure 4.9 – Le data bloc du modbus server.

III Simulateur de Balance RS232

Un simulateur de balance a été développé en [Link] afin de simuler l’envoi de données de poids
via une liaison série RS232. Ce simulateur permet de tester la réception des valeurs dans l’automate
[Link] facilite les essais sans avoir besoin d’une vraie balance physique.
[Link] (Visual Basic .NET) est un langage de programmation orienté objet développé par Micro-
soft. Il s’appuie sur la plateforme .NET Framework, ce qui lui permet de tirer parti de nombreuses
bibliothèques pour le développement d’applications robustes.

Figure 4.10 – Interface du simulateur de balance.

Interface :
L’interface graphique comprend :
— Une TrackBar permettant de simuler la variation du poids (de 0 à 100 kg).

35
 — Un Label affichant le poids sélectionné.
— Des ComboBox pour configurer les paramètres de communication (port COM, baud rate, parité,
bits de données, bits de stop).
— Des boutons pour :
— Ouvrir ou fermer la connexion série.
— Envoyer manuellement le poids courant.
— Activer un envoi automatique périodique.
— Une ComboBox pour sélectionner l’intervalle d’envoi automatique.
Fonctionnalités :
— Configuration RS232 complète avec choix dynamique des ports disponibles.
— Envoi manuel ou périodique du poids.

IV Programmation de la machine
IV.1 Tables de variables
Les tables suivantes contiennent les entrées et les sorties du système avec leurs types et adresses :

Figure 4.11 – Tableau des variables d’entrées.

36
 Figure 4.12 – Tableau des variables de sortie.

Figure 4.13 – Tableau des variables d’alarme.

IV.2 Blocs de programmation

Pour des raisons de faciliter la lecture, on va diviser notre programme en différents blocs.

Figure 4.14 – Blocs de programmation - TIA PORTAL.

IV.3 Programmes Ladder

Notre programme Ladder a été testé et validé sans erreur avec le logiciel Tia portal.

37
Figure 4.15 – Procédure du chargement du programme dans l’API 1.

Figure 4.16 – Procédure du chargement du programme dans l’API 2.

38
Figure 4.17 – Procédure du chargement du programme dans l’API 3.

Figure 4.18 – Procédure du chargement du programme dans l’API 4.

Figure 4.19 – Procédure de la simulation des réseaux - TIA PORTAL .

39
 Le ladder de notre plateforme est signalé dans les annexes.

V Supervision avec une Interface Node-RED

V.1 Présentation de Node-RED
V.1.1 Définition et principes

Node-RED est un environnement de développement visuel open-source conçu à l’origine par IBM.
Il est basé sur une approche orientée ≪ flux de données ≫ (flow-based programming), où l’utilisateur
conçoit des applications en assemblant des blocs fonctionnels appelés nœuds. Ces nœuds sont inter-
connectés pour former un flux de traitement, permettant ainsi la collecte, le traitement, et l’affichage
des données en temps réel.

Figure 4.20 – Logo Node-RED.

Figure 4.21 – Interface de développement de Node-RED.

V.1.2 Fonctionnalités clés

Node-RED se distingue par les fonctionnalités suivantes :

• Interface graphique intuitive : Développement sans code complexe, manipulation par glisser-
déposer
• Large bibliothèque de nœuds : Communication Modbus, OPC UA, MQTT, HTTP, WebSocket,
base de données, etc
• Dashboard intégré : Permet la création rapide d’interfaces utilisateurs (boutons, jauges, gra-
phiques. . .).

40
• Interopérabilité : Compatible avec de nombreux systèmes industriels (automates, capteurs, pla-
teformes cloud).

V.1.3 Architecture d’intégration dans le projet

Node-RED est utilisé comme interface de supervision entre l’automate Siemens S7-1200 et le
terminal utilisateur. L’automate envoie les données de processus (état machine, pesée, alarmes...) via
un protocole de communication Modbus TCP/IP, que Node-RED intercepte et affiche sous forme
graphique.
L’architecture générale est la suivante :

Figure 4.22 – Schéma d’architecture de communication avec Node-RED.

V.2 Création du flow sur Node-RED

L’interface de supervision a été réalisée à travers la construction de plusieurs flows fonctionnels
dans Node-RED. Chaque flow est dédié à une tâche spécifique (authentification, affichage des données,
commandes, etc.), facilitant ainsi la lisibilité, la maintenance et l’évolution du système.

V.2.1 Flow d’accueil

Cette interface est simple et contient un bouton unique permettant à l’utilisateur de se connecter.
L’objectif étant de diriger l’utilisateur vers la page de connexion où ses identifiants seront vérifiés
avant d’accéder aux fonctionnalités du système.

41
 Figure 4.23 – Flow d’accueil sur Node-RED.

Figure 4.24 – Vue d’accueil sur le dashboard.

V.2.2 Flow Login

Afin de sécuriser l’accès aux différentes interfaces du Dashboard, nous avons mis en place un flow
de connexion (login).
Le processus repose sur l’interface graphique du Dashboard, permettant à l’utilisateur de saisir ses
identifiants via un formulaire.

42
 Figure 4.25 – Flow de login sur Node-RED.

▶Fonctionnement du flow :
• form : permet de collecter les identifiants (username, password).
• function 5 et 6 : contiennent le code JavaScript de vérification. Ils comparent les identifiants saisis
avec une base pré-définie.
• set [Link] : formate la réponse selon le résultat (succès, échec, rôle).
• show dialog / notification : affiche un message à l’utilisateur .
• ui control : redirige vers la vue correcte du Dashboard en fonction du rôle de l’utilisateur.

Figure 4.26 – Vue Login sur le dashboard.

43
V.2.3 Flow de supervision

Le flow principal de supervision constitue l’élément central de la gestion de l’installation via l’envi-
ronnement Node-RED. Il permet d’assurer une interface homme-machine (IHM) interactive et réactive.
Le système repose sur le protocole industriel Modbus TCP et S7comm pour l’échange d’informations
avec les équipements.

Figure 4.27 – Flow de supervision sur Node-RED.

▶Fonctionnement du flow :
• modbus-write : Écrivant des valeurs de paramètres saisis par l’utilisateur(poids demandé de cha-
cune du couleur).
• s7comm : :read : Lire des bits depuis l’automate pour afficher l’état du chaque pompe et les vannes.
• s7comm : :write : Écrit un bit dans l’automate Siemens pour passer une commande et start du
processus et le mélange.
• ui led :Affiche l’état des pompes et les vannes.
• function 33, 34,35,36,37,38,39,40,41,42,43,44,45,46,47 : Convertit les valeurs qui arrivent
depuis s7comm : :read en booléen pour la LED

44
 Figure 4.28 – Vue supervision sur le dashboard.

V.2.4 Flow des alarmes

Le flow des alarmes a pour objectif de signaler en temps réel tout événement anormal comme stock
vide ou une absence du seau. Grâce à l’intégration de notifications visuelles.

Figure 4.29 – Flow des alarmes sur Node-RED.

▶Fonctionnement du flow :
• ui led :Une LED affiche l’état du stock de chaque couleur.
• ui gauge : Affiche une jauge pour visualiser le niveau du stock de chaque couleur (en kg).

45
• modbus-read : Lit la valeur du stock de chaque couleur depuis un registre Modbus (adresse xx).
• filtre : Filtre les données pour ne transmettre que les changements de valeur du stock de chaque
couleur (envoie un message uniquement si la valeur change).
• function 9,10 et 11 : Vérifie si le stock de chaque couleur est inférieur à 10. Si oui, envoie une
alerte.
• function 4,30 et 31 : Convertit la valeur du stock de chaque couleur en booléen pour la LED
• ui toast :Affiche une notification pop-up pour l’alerte de stock de chaque couleur.
• autre led qui affiche l’état de détection d’un seau (absent ou présent).
• s7comm : :read : Lit un bit depuis l’automate pour détecter la présence d’un seau.
• inject : Déclenche la lecture S7 toutes les 1 seconde.
• function 28 : Traite la valeur lue par S7 pour la LED ”Seau Absent”.
• autre ui toast qui affiche une notification pour pour l’absence du seau.

Figure 4.30 – Vue alarme sur le dashboard.

V.2.5 Flow des réglages

Le flow des réglages permet à l’utilisateur de modifier et de valider certains paramètres du système,
notamment les seuils d’ouverture des vannes et le poid de seau.

46
 Figure 4.31 – Flow de réglage sur Node-RED.

▶Fonctionnement du flow :
• modbus-write : Écrivant des valeurs de paramètres saisis par l’utilisateur (poids de la petite
ouverture, poids des petites pulsations, et poids du seau) dans des registres spécifiques (adresses 24,
25, et 26).
• ui text input :Champ de saisie dans l’interface utilisateur pour entrer les trois paramètres.
• s7comm : :write :Écrit un bit dans l’automate Siemens S7 pour valider les paramètres saisis.
• ui button : Bouton dans l’interface utilisateur pour valider les paramètres saisis.
• function 2 : Formate la valeur booléenne du bouton pour qu’elle soit compatible avec le nœud
S7Comm.
• modbus-client :Configuration du client Modbus pour communiquer avec le serveur S7-1200.

Figure 4.32 – Vue réglage sur le dashboard.

47
Conclusion
En résumé de ce chapitre, nous avons élaboré l’ensemble des programmes que nous avons implémentés
dans l’automate S7-1200 en utilisant le langage LADDER. Cette partie a été complétée par la création
des interfaces de supervision.

48
Conclusion générale

Le projet que nous avons réalisé au sein de l’entreprise Tec Forge, intitulé ≪ Contrôle et commande
d’une machine de production d’encre ≫ , est arrivé à son terme. Cette opportunité nous a permis de
nous pencher sur un sujet captivant et en parfaite adéquation avec notre formation d’élèves ingénieurs
en génie électrique.

Nous avons utilisé un ensemble d’outils d’analyse et de modélisation pour les systèmes industriels.

L’analyse fonctionnelle initiale a été essentielle pour définir précisément les besoins et contraintes du
projet. Grâce aux outils GEMMA et GRAFCET, nous avons structuré les comportements du système.

La maı̂trise des protocoles de communication industriels, comme Modbus TCP/IP, a assuré une
interconnexion fiable entre les différents équipements.

Parallèlement, l’interface web développée sous Node-RED a permis de proposer une solution mo-
derne pour le suivi en temps réel du processus.

Ce projet nous a offert une opportunité précieuse de mettre en pratique nos connaissances académiques
dans un contexte industriel concret, en renforçant notre autonomie, notre esprit d’analyse et nos
compétences en ingénierie des systèmes automatisés.

En conclusion, ce travail représente pour nous une expérience professionnelle enrichissante qui
constitue une base solide pour nos futures carrières d’ingénieurs en génie électrique et en automatisa-
tion industrielle

49
Bibliographie

[1] Antoine, Modbus TCP : Fonctionnement et mise en œuvre,

[Link]
[2] Instrumentys, Comment fonctionne le Modbus ? Que devez-vous savoir ?,
[Link]
[3] Teddy Caroni, Modbus : fonctionnement du protocole de communication,
[Link]
[4] Tamboli, Sadik, Rawale, Mallikarjun, Thoraiet, Rupesh, and Agashe, Sudhir, Implementation of
Modbus RTU and Modbus TCP communication using Siemens S7-1200 PLC for batch process,
2015 International Conference on Smart Technologies and Management for Computing, Commu-
nication, Controls, Energy and Materials (ICSTM), pages 258-263, 2015,
doi : 10.1109/ICSTM.2015.7225424.
[5] M106 & GI105, La liaison série RS232, document pédagogique, étude théorique et pratique incluant
la description de la norme RS-232, codage ASCII, et utilisation d’HyperTerminal
[6] Fenniche, Abd errazak, Étude et Réalisation d’une Connexion RS232 de la Fraiseuse EMCO F1
CNC et le Tour EMCO Compact 5 CNC avec le PC,
Mémoire de Master Professionnel, Université Kasdi Merbah Ouargla, 2013.
[7] ENISO, GEMMA : Guide d’Étude des Modes de Marches et d’Arrêts,
Cours de l’année universitaire 2011-2012, École Nationale d’Ingénieurs de Sousse, 2012.
[8] Siemens AG, Automate programmable S7-1200 – Manuel système,
Siemens AG, Nuremberg, Allemagne, mars 2014,
Numéro de référence : A5E02486682-AG,
[Link]
[Link].
[9] Technoboigne, Diagramme FAST,
[Link]
[10] Berger, Philippe, Le GEMMA,
[Link]

50
Annexes

Bloc main

51
52
53
54
Initialisation

55
Circuit de rouge

56
57
Circuit de verte

58
59
Circuit de bleu

60
61
Circuit de mélange

62
Circuit de paraméter

63
Circuit d’alarme

64