IMA4 2018/2019 P7

Cahier des charges

Description

Le sujet étant la réalisation d'un système de supervision pour un équipement de production en version industrie 4.0. Il s'agit d'appliquer les principes prônés par l'industrie 4.0 sur l'interconnexion et la flexibilité des systèmes de production pour la réalisation d'un système de supervision d'un système de production.

Ainsi, appliqué à un des systèmes réels de Polytech (le système de traitement de surface de l'AIP), il s'agit de réaliser la chaîne complète permettant à un opérateur/client distance de faire une commande (= demander la production d'un produit) et d'être informé sur l'avancement de sa production (= en préparation, en production ou production achevée)

Concernant les gammes de production du traitement de surface, elle seront de la sorte :

- Gamme 1 : Pour cette première gamme, elle devra s'arrêter aux postes numéro 2 et 7. On dira que c'est la gamme de traitement rapide. Dans cette gamme il y aura une durée de 5s au poste 2 et 8s au poste 7.

- Gamme 2 : Concernant la deuxième gamme ce sera une gamme standard, on s'arrêtera alors aux postes 3, 5 et 7. La durée de plongée dans les bains pour cette gamme sera de 10s pour chaque poste desservie.

- Gamme 3 : Pour cette dernière gamme, elle sera plus longue. Celle-ci sera la plus complète car elle s'arrêtera à tous les postes de traitement. Cette fois-ci ce sera 12s pour les postes 2,4,6 et 13s pour les postes 3,5 et 7.

De plus, c'est le chariot A qui devra emmener le panier à tous les postes de traitement et une fois arrivé au poste 7 c'est alors au tour du chariot B d'aller chercher le panier pour l'emmener au dernier poste.

Objectifs

Réalisation d'un système de supervision pour un équipement de production (traitement de surface de l'AIP) selon les concepts industrie 4.0
Cibles : Ce projet serait utile pour les usines de production en général, les clients et les fournisseurs pourraient prendre place dans le processus de production.

Préparation du projet

Choix techniques : matériel et logiciel

Il y a différents systèmes disponibles à Polytech :

• Traitement de surface
• Pick and place
• Remplissage de bouteilles
• Cuves contenant liquide
• Bras robotisés effectuant une tâche précise

Mon choix se porterait sur le traitement de surface, pour pouvoir travailler sur un système réel.

Liste des tâches à effectuer

Voici les tâches qu'il faut réaliser pour la réalisation de ce projet :

• Programmation de l'API
• Effectuer la supervision du traitement de surface
• Réaliser une interface client
• Communication Modbus vers API
• Communication client
• Interface client

Calendrier prévisionnel

Il va falloir que je me fixe des objectifs par semaine pour pouvoir respecter le délai final. Ces objectifs doivent être validées pour chaque lundi 11h45.

S1 :

• Avoir un cahier des charges détaillé
• Prise en main du système
• Tester la communication avec l'API

S2 :

• Débuter la programmation de l'API
• Prise en main et effectuer quelques tutoriels pour la supervision
• Terminer la partie présentation dans le rapport

S3 :

• Commencer la Supervision
• Finir la Supervision
• Continuer le rapport

S4 :

• Récupération des données du PC Client
• Tests
• Finaliser le rapport
• Faire la présentation

Figure 1 : Planning Prévisionnel

Réalisation du Projet

Feuille d'heures

Tâche	Prélude	Heures S1	Heures S2	Heures S3	Heures S4	Heures S5	Heures S6	Heures S7	Heures S8	Heures S9	Heures S10	Total
Analyse du projet	0

Journal de bord

20/09/2018

Première rencontre avec M. Conrard:

• Explications plus approfondies sur l'objectif du projet
• Mise en place d'un prochain rendez-vous pour une explication des différents points compris et incompris

21/09/2018

• Recherches sur l'industrie 4.0 et ses concepts clés
• Je suis allé dans les différentes salles de Polytech ayant des automates pour les énumérer

22/09/2018

• Première description du travail à réaliser
• Premières recherches sur les différents outils nécessaires à la réalisation du projet

24/09/2018

• Rencontre avec M.Conrard où des objectifs pour le lendemain ont été fixé
• Première version du cahier des charges

25/09/2018

• Comprendre et décrire le processus avec ses fonctions principales
• Première description de l'architecture
• Effectuer une définition du système choisi (le traitement de surface)

26/09/2018

Lors de cette réunion nous nous sommes attardés sur les points suivants, et mes objectifs étaient donc les suivants :

• Avoir un badge d'accès pour la salle
• Réaliser un format de document quotidien
• Fiche sur la réalisation/faisabilité de la supervision (Quelques contraintes évoquées telles que la communication entre l'API et le Client)

27/09/2018

Pendant cette réunion nous nous sommes attardés sur les différentes méthode de travail et il a fallu réaliser les tâches suivantes pour le lendemain :

• Analyse fonctionnelle
• Description détaillée de l'architecture fonctionnelle
• Daily meeting
• Premier planning avec objectifs à réaliser

28/09/2018

Après cette réunion avec M. Conrard, les objectifs étaient :

• Vérifier si la chaine de production était fonctionnelle
• Vérifier si la communication avec l'API était possible

29/09/2018

Je suis venu travailler ce samedi j'ai pu voir quelques problèmes :

• Pression d'air qui ne fonctionnait ==> Tuyau craqué
• Conséquence ==> Impossible de travailler sur l'automate ce jour
• Étude de documentation technique

01/10/2018

Rendez-vous avec M. Conrard les points suivants on été évoqué :

• Problèmes liés au tuyau pour la pression d'air
• Version 2 du cahier des charges présentée
• J'ai énoncé le travail réalisé sur l'automate avant de voir le lendemain le problème pour la pression d'air

02/10/2018

Lors de cette rencontre, étant donné le problème du tuyau il a fallu trouver des alternatives :

• Bien spécifier les différentes gammes
• Services de l'automates à mieux décrire
• Trouver des tâches en parallèle à pouvoir réaliser

03/10/2018

Lors de cette réunion, des alternatives ont été trouvé :

• Étudier la communication Modbus
• Travailler sur un coupleur Ethernet Wago

04/10/2018

Cette fois-ci, après m'être concerté avec M. Conrard les décisions suivantes ont été prise:

• Utiliser un autre automate en attendant la réparation de la pression d'air
• Recherche et tests pour communiquer avec l'API

05/10/2018

Lors de cette rencontre, j'ai dû annoncer un nouveau problème qui était cette fois logicielle :

• Trouver comment régler ce problème
• Une fois trouvé celui-ci a persisté
• Recherches et lecture de datasheet sur le coupleur Ethernet

06/10/2018

Cette fois, le tuyau pour la pression d'air a été remplacé.

• Réalisation d'une application pour gérer un voyant
• Recherche sur la communication Modbus

08/10/2018

Après une réunion avec M. Conrard, le travail suivant a été réalisé

• Établir les différentes méthodes pour pouvoir communiquer
• Recherches et résolution des différents problèmes logiciels

09/10/2018

Lors de cette réunion il s'est dégagé quelques points importants

• Réalisation de la communication Modbus ==> Envoi de requêtes pour contrôler l'automate
• Choix de l'outil pour la réalisation d'un serveur web

10/10/2018

Pendant cette réunion, les points suivants ont été soulevé pour bien gérer le temps restant

• Recherche plus approfondies pour la réalisation du service web
• Rédaction du rapport

11/10/2018

Lors de cette journée et après la réunion avec M. Conrard, le travail suivant a été réalisé

• Restructuration de la programmation de la gamme 1
• Prise en main du modèle récent de LabView

12/10/2018

Lors de cette journée et après la réunion avec M. Conrard, il s'est dégagé quelques points à résoudre et j'ai réalisé cela

• Lecture de documentation technique
• Structure de la page HTML

13/10/2018

• Travail sur le banc composé de coupleurs Ethernet
• Programmation LabView pour le service web

15/10/2018

Lors de cette journée,

• Réussite de l'envoi de trames sur le coupleur wago 750
• Gestion de l'erreur de lecture de trames

16/10/2018

Lors de cette journée, le travail suivant a été réalisé :

• Envoi de trame depuis le service Web
• Restructuration du Grafcet

17/10/2018

Lors de cette journée je n'ai pas pu effectuer des tests sur le système de traitement de surface car il y avait des travaux à l'étage sur les arrivées d'air j'ai donc fait les tâches suivantes :

• Modification du LabView pour recevoir l'information de fin de production
• Rédaction du rapport

18/10/2018

Lors de cette journée, j'ai réalisé les tâches suivantes :

• Résolution du problème qui persistait dans mon Grafcet
• Planning des derniers jours à poster
• Travail sur la validation de l'opérateur après l'envoi de la requête du client

19/10/2018

Voici les tâches que j'ai réalisé cette journée,

• Travail sur la partie interface pour communiquer les informations client à l'opérateur
• Rédaction du rapport de projet

20/10/2018

Lors de cette journée, j'ai effectué les tâches suivantes :

• Travail sur la mise en place de tableau de commande pour la partie opérative
• Rédaction du rapport

22/10/2018

Lors de cette journée, j'ai réalisé les tâches suivantes :

• Finalisation du fichier LabView
• Rétablissement de la fonction d'état de la commande

Prologue

Qu'est-ce que le daily meeting ?

Nous avions décidé au début de mon projet de faire des réunions quotidiennes pour évoquer l'avancée de mon projet. L'objectif du daily meeting est de s'assurer que l'on va atteindre notre objectif. Il faut se poser 3 questions au quotidien :

• Qu'est-ce que j'ai terminé hier ?
• A quoi je m'engage et pour quand ?
• Qu'est-ce que j'ai comme problèmes ?

Description des concepts clés de l'industrie 4.0

L'industrie 4.0 qui est considéré comme la 4ème révolution industrielle se caractérise par l'intégration des technologies numériques dans les processus de fabrication. L'industrie 4.0 a pour objectifs d'optimiser les consommations par l'efficacité énergétique et à rendre plus les usines plus compétitives. Les concepts clés de l'industrie 4.0 sont les suivants :

• Numérisation de l'usine : En numérisant l'usine on cherche à avoir une communication continue et instantanée entre les différents outils et postes de travail intégrés dans les chaînes de production. En utilisant des capteurs communicants cela apporte à l'outil de production la capacité d'autodiagnostic

et permet un contrôle à distance.

• Flexibilité de l'usine et personnalisation de la production : Il y a une grande flexibilité qui peut être due aux systèmes de productions possédant des objets intelligents, pouvant communiquer et étant lié à un réseau étant lui-même relié à un réseau extérieur. Ainsi, le client/operateur peut

prendre une place dans le processus. Il sera donc possible de personnaliser des produits à grande échelle.

• Gestion de l'énergie et des matières premières : Grâce à l'industrie 4.0 et la communication des objets, il sera plus simple d'économiser de l'énergie et de mieux gérer les matières premières.

• Outils logistiques et outils de simulations : Il sera plus simple de communiquer avec les entreprises de logistiques étant extérieurs aux usines de productions. De plus, nous pouvant avoir des réplique virtuelle permettant de corriger plus facilement les problèmes de production.

Description du processus avec les fonctions principales

En ce qui concerne le traitement de surface, celui-ci permet la simulation d'un traitement de surface dans des bains différents. Je rappelle que l'objectif est de faire un démonstrateur Proof Of Concept (POC) d'un système de production type industrie 4.0. Les fonctions de ce système seraient les suivantes :

• Client/Opérateur passe une commande ( Choix du mode de production : possibilité de choisir entre plusieurs processus de traitement prédéfinis, possibilité de modifier les processus de production )

• Après le choix du type de panier, l'opérateur le place

• Lancement du processus choisi

• Suivi de l'état du processus (Sur le logiciel de supervision et sur l'interface client)

• Récupération du panier

Analyse et architecture fonctionnelle

Analyse fonctionnelle

Qu'est-ce qu'une analyse fonctionnelle : L'analyse fonctionnelle décrit le fonctionnement des équipements en listant l'ensemble des défauts, des modes de fonctionnement et des régulations nécessaires aux réalisations des fonctions souhaitées. Elle se présente sous la forme d'un texte clair permettant à un non automaticien de comprendre le fonctionnement de l'installation. Il faut dire quels sont les services attendus pour chaque éléments du système.

Traitement de surface :

• Réaliser les 3 ou 4 gammes de production
• Exécuter l'ordre reçu par le programme
• Acquisition des états du système (différents capteurs)
• Distribution de l'énergie (préactionneurs) ==> Opérationnel
• Convertir l'énergie en action (actionneur) ==> Opérationnel

API :

• Réaliser une production dite rapide
• Réaliser une production dite standard
• Réaliser une production dite lente/complète
• Gestion des déplacements des chariots A et B (Monter, descendre, aller à droite et à gauche)

Poste de supervision :

• Afficher l'avancée de la production
• Communiquer avec le Client (IHM)
• Piloter la production
• Surveiller l'activité (capteurs de fin de course)
• Gestion des commandes de pièces (Mémorise et transmet 1 à 1 à l'API)

PC Client :

• Permettre au client de choisir la gamme de production
• Être informé de l'avancée de la production

Architecture fonctionnelle

L'architecture est telle que le schéma suivant :

Figure 2 : Architecture fonctionnelle

Communication Modbus : Partie préliminaire

Modbus est un protocole de communication non-propriétaire, créé en 1979 par Modicon, utilisé pour des réseaux d'automates programmables, relevant du niveau applicatif, c'est-à-dire du niveau 7 du Modèle OSI.

Il y a différents types de fonctionnement, le mode maître-esclave et le mode client-serveur. Dans le premier cas seul le maître est actif, les esclaves sont complètement passifs. C'est le maître qui doit lire et écrire dans chaque esclave. La constitution de ses trames contiennent le numéro de l'esclave concerné, la fonction à traiter (écriture, lecture), la donnée et le code de vérification d'erreur appelé contrôle de redondance cyclique sur 16 bits ou CRC16 dans le cas de la liaison série.

Alors que en mode TCP : (Ethernet) Cela fonctionne sur le mode client-serveur. Seul le client est actif, les serveurs sont complètement passifs. C'est le client qui doit lire et écrire dans chaque serveur. Sa trame contient la fonction à traiter (écriture, lecture) et la donnée. Son adresse du serveur concerné est son adresse IP.

Pendant ces premiers tests avec un coupleur Wago 750 l'envoi de requêtes a permis une meilleure compréhension de ce mode de communication. Un envoi de requête pour favoriser le contrôle de différentes sorties.

Figure X : Banc pour la réalisation de tests avec les coupleurs Wago

Communication Modbus : Communiquer avec d'autres API

Dans un premier temps, j'ai réalisé une communication avec 2 automates. Il a fallu que j'utilise les mots mémoires pour enregistrer des valeurs dans la mémoire de l'automate esclave. Après avoir paramétré tout cela, l'utilisation du système de transmission de requêtes m'a permis d'utiliser SEND_REQ(@destination, code requête, table de transmission, table de réception, gestion).

@destination : adresse du coupleur Ethernet
code requête : Entrer le code pour la lecture ou l'écriture
table de transmission : Réserver 3 mots pour l'adresse du destinataire
table réception : L'endroit où l'on réceptionne les données
gestion : Permet de voir le compte rendu de l'opération et le compte rendu de la communication

Mon premier automate était alors le client, et j'envoyais alors une requête au second automate qui était lui serveur. J'ai donc envoyé une requête d'écriture pour écrire les chiffres 8, 9 et 10. Les codes de requêtes de lecture et d'écriture sont les suivantes : 16x0036 et 16x0037. Concernant la gestion, dans le compte rendu s'il est enregistré le code 00 alors la communication a été réussi. Nous pouvons aussi aller vérifier dans les variables du second automate pour voir si nous les avons bien écrit.

Fichier:Envoi code P7.jpg

Figure X : Capture de l'envoi des mots écrits par le maître

Communication Modbus : Envoie de requête pour contrôler l'API

J'ai utilisé le fichier labview pour pouvoir envoyer une requête à l'automate j'ai pris en compte ce type de trame :

Transaction ID	Protocole	longueur	Unit	Adresse Esclave	Code fonction	Données N octets
2 octets (ID choisi par l'utilisateur)	ID 2 octets (0x0000)	2 octets (0x0006	1 octet 1 octet (Je n'en ai pas mis, mais j'ai aussi testé avec)	1 octet (0x03)	1 octet(0x05)	(02 05 FF 00)

J'ai utilisé cette documentation et c'est à la page 48 où j'ai trouvé des informations pour les requêtes :

http://www2.schneiderelectric.com/resources/sites/SCHNEIDER_ELECTRIC/content/live/FAQS/1 7000/FA17465/fr_FR/TSX%20ETZ%20410%20et%20510%20-%20Manuel%20utilisateur.pdf

Ensuite, à cette page ils me conseillaient de lire la documentation suivante, et j'ai trouvé le plus d'information à la page 23 pour mon cas.

http://eshop.schneider-electric.com/Download.aspx?infos=H474055_1.pdf;3

Par la suite, j'ai décidé d'affecter un mot à une sortie de l'automate pour pouvoir la contrôler via la communication Modbus. Ainsi, dans ma trame, j'ai compris pourquoi j'avais une erreur qui était dans la réponse à ma requête. (Code x85) Cette erreur était due au fait que l'adresse Esclave et l'Unit correspondait à la même chose. Ensuite, l'adresse esclave était 0x03 car le traitement de surface est la station numéro 3 de ce réseau. Ensuite, j'ai utilisé le code fonction qui correspondait à l'écriture d'un bit. J'ai donc ensuite décidé de choisir le mot que j'allais changer. Ensuite, j'ai utilisé le fichier labview pour pouvoir envoyer une requête à l'automate j'ai pris en compte ce type de trame :

Transaction ID	Protocole	longueur	Adresse Esclave	Code fonction	Données N octets
2 octets (ID choisi par l'utilisateur)	ID 2 octets (0x0000)	2 octets (0x0006)	1 octet (0x03)	1 octet(0x05)	(00 01 FF 00)

Ensuite, concernant le départ cycle que je veux allumer, qui est la sortie %Q2.5 j'ai mis 0X0001. Et j'ai affecté cet mot à la sortie %Q2.5 pour pouvoir le modifier en envoyant la requête.

Programmation de l'API : Le traitement de surface

Pour programmer les différentes gammes de production il faut prendre en compte la communication ModBus. Il sera donc plus simple d'expérimenter différentes manières pour faciliter la communication. Le logiciel que j'utilise pour programmer mes gammes est le logiciel PL7 PRO, ce logiciel me permet de décomposer mon programme. Il y a une partie où la construction du grafcet est réalisée, dans cette même partie je mets les conditions de mon grafcet. Dans une autre partie, je mets les différentes actions et les différentes temporisations permettant le traitement à chaque poste pour chaque gamme.

Supervision : Gestion de commande des clients

Concernant la gestion des commandes des clients, la décision a été d'avoir les fonctionnalités suivantes :

• L'opérateur peut lancer les commandes envoyées par le client
• L'opérateur actualise les différentes commandes et choisit les commandes à lancer
• Lecture de l'état de la production (En attente de confirmation, En production, Terminé)

Pour cela il a fallu établir une ouverture de connexion TCP/IP, ensuite une fois que l'utilisateur choisit sa gamme la requête d'écriture ModBus est envoyée. De plus une seconde requête de lecture est envoyée pour connaître l'état de la production. Ensuite, la création d'un tableau permettant d'enregistrer les différentes commandes des clients. Pour cela, l'opérateur actualise le tableau de commande. Une fois que la gamme est choisi, nous avons celle-ci qui est enregistrée lorsque l'opérateur actualise puis choisit la commande à lancer en premier.

Figure X : Programmation LabView de la partie opérateur

Figure X : Aspect graphique de la partie opérateur

Pour connaître les différents états de production (en attente de confirmation, en production et terminé) la première décision a été de mettre directement les commandes en état d'attente de confirmation, ensuite une fois que l'opérateur à actualisé et a sélectionné la commande à lancer son état passe en production. Dans ce programme une requête de lecture est envoyée constamment ce qui permet de passer en mode « Terminé », pour cela je compare le 9ème bit de ma réponse de requête de lecture et s'il est à zéro cela signifie que la commande est terminée.

Interface Client

Pour gérer l'interface graphique, l'utilisation du JavaScript, du HTML et du CSS ont été nécessaire. Dans cette interface, le client entre les infos suivantes :

• Le choix de gamme
• Son Nom de commande

Et nous affichons l'état de production de sa gamme.

Le CSS est un langage permettant de gérer l'aspect graphique de fichier HTML et XML. Le langage HTML est un langage de balisage conçu pour présenter les pages Web. De plus, le langage JavaScript est un langage de programmation de scripts principalement employé dans les pages web interactives.

Dans le cas de l'interface graphique j'ai mis les éléments suivants dans le formulaire de la page d'accueil :

• Un champ « input » permettant de choisir le nom du client
• Un second champ « input » permettant cette fois-ci de choisir sa gamme
• Un champ permettant d'afficher l'état de la commande en cours
• Et enfin un bouton « valider », pour valider les différentes informations entrées par l'utilisateur.

Ainsi, les différentes requêtes HTTP de type GET et de type POST sont écrites dans ce fichier. L'état de la commande change sur cette même page. Pour réaliser ce service web, j'ai utilisé une des fonctionnalité sur LabView permettant de faire cela.

L’interface web a été mise en place par l’intermédiaire de différents langages de programmation dont le CSS. J'ai utilisé le code HTML pour la mise en page simple de l’application. Et j'ai utilisé le CSS pour un apport visuelle et esthétique de la page web.

Figure X : Aspect de l'interface client