CHAPITRE 5 : LES CONCEPTS RELATIFS A LA GESTION DE
6.1.1. Les besoins fonctionnels
Pour améliorer la gestion de la maintenance, notre application doit posséder certaines fonctionnalités, elle doit notamment :
fonctionner en mode client/serveur et dans un réseau d’ordinateurs ;
Permettre un accès par identifiant et un mot de passe ;
Gérer le planning des interventions :
L’application doit permettre au RP et au Chef du Service Maintenance d’éditer le planning des interventions. Elle devra rappeler systématiquement les échéances de maintenance (alertes échéances) ;
Gérer l’historique des interventions :
L’application doit permettre aux techniciens de signaler les pannes (une alerte panne devra être émise) ; puis lorsqu’une panne est résolue de donner les informations relatives à cette résolution. Ainsi, il pourra être mis à disposition de tous les techniciens un historique des interventions ;
Gérer le stock du magasin central :
L’application doit afficher la liste des pièces du magasin et permettre de retrouver rapidement les informations relatives à telle ou telle autre pièce (code, facture…). Aussi, le retrait (sortie de magasin) de pièces devra être gérer.
Ainsi, l’état du stock au magasin central sera mis à jour régulièrement. La figure 6.1 résume l’ensemble des besoins fonctionnels.
Figure 6.1: Aperçu général des besoins fonctionnels de l’application 6.1.2. Les besoins non fonctionnels
Les besoins non fonctionnels sont les suivants :
L’application doit permettre de gérer l’accès des utilisateurs selon le
Il faut garantir la sécurité d’accès à l’espace administrateur afin de protéger les données ;
L’interface de cette application doit aider les utilisateurs à mieux organiser leur espace de travail.
6.2. Modèle UML
L’objectif principal d’un développeur est de créer des applications optimisées, capables de satisfaire les besoins de leur utilisateur.
La modélisation d'une application permet de spécifier l’architecture et le comportement attendus d'un système, de comprendre son organisation, de déceler les possibilités de simplification et de réutilisation et de gérer les risques éventuels. Un modèle est une forme simplifiée de la réalité. Il permet de mieux appréhender le système à développer.
Un diagramme est la représentation graphique d'un ensemble d'éléments qui constituent un système.
L’UML est une approche orienté objet de modélisation qui permet d’appréhender un problème d’une manière standard et graphique. Pour visualiser un système sous différentes perspectives, le langage UML (Unified Modeling Language) propose neuf diagrammes, représentant chacun un état du système (statiques et dynamiques) [8] :
Diagrammes statiques :
- Diagramme de Cas d’utilisation ; - Diagramme de Classes ;
- Diagramme d’Objets ;
- Diagramme de Composants ; - Diagramme de Déploiement.
Diagrammes dynamiques : - Diagramme de Séquences ; - Diagramme d’Activités ;
- Diagramme d’Etats transitions ; - Diagramme de Collaboration.
Cette approche permet de modéliser à la fois, les aspects statiques et dynamiques du système. Dans la suite, nous présentons quelques diagrammes pour la compréhension du fonctionnement du système.
6.2.1. Le diagramme des cas d’utilisations
Un diagramme de cas d'utilisation permet de visualiser le comportement d'un système de telle sorte que [8] :
l'utilisateur puisse comprendre comment utiliser chaque élément ;
le développeur puisse implémenter ces éléments.
Ce diagramme répond à la question « Qui devrait pouvoir faire quoi ? ».
Pour cette application, les cas d’utilisation les plus pertinents sont présentés dans le tableau 6.1 et représentés dans la figure 6.2, avec les abréviations suivantes :
AQ : Agent de Quart ; CD : Chef Division ;
CSM : Chef du Service Maintenance ; Mag : Magasinier ;
RP : Responsable Planification ; TS : Technicien Supérieur.
Tableau 6.1 : Les cas d’utilisation
Cas d’utilisation Acteurs
Signaler Panne Tous les Acteurs sauf Magasinier
Signaler Résolution Panne TS, CD, AQ
Accéder à l’Historique Tous les acteurs sauf Magasinier
Emettre OT CD
Rédiger Rapport OT AQ
Accéder aux OT CD, CSM, AQ
Rédiger Rapport Quart AQ
Accéder Rapports Quart CSM, CD, AQ
Editer Planning RP, CSM
Accéder au Planning CSM, RP, CD, TS, AQ
Enregistrer Acquisition au Magasin Magasinier Enregistrer Retrait au Magasin Magasinier
Consulter Stock au Magasin Magasinier, CSM, RP, TS, CD, AQ Gérer les Utilisateurs Administrateur
Gérer le Parc d’Equipements Administrateur Gérer la Liste des Agents Administrateur
6.2.2. Le diagramme des classes
Un diagramme de classes permet de modéliser la structure d'un système grâce à des classes et à des relations entre ces classes. Les diagrammes de classes sont les diagrammes les plus courants dans la modélisation des systèmes orientés objet [8]. Le digramme des classes obtenu est présenté par la figure 6.3.
6.2.3. Diagramme de séquence
Un diagramme de séquence représente l'ordre chronologique des messages envoyés et reçus par un ensemble d'objets.
Un diagramme de séquence est composé des éléments suivants [8] :
Objet : représente les différents objets utilisés. Chaque objet est représenté par un carré surmontant une ligne en pointillé. Cette ligne représente la durée de vie de l'objet ;
Période d'activation d'un objet : Sur la ligne de vie d'un objet, il est possible d'insérer des périodes d'activation de l'objet. Ces périodes représentent les moments où l'objet est actif ;
Message : représente, grâce à des flèches horizontales, les messages échangés entre les différents objets. Ces flèches sont orientées de l'émetteur du message vers le destinataire. L'ordre d'envoi des messages est donné par la position des flèches sur l'axe vertical ;
Paquetage : divise et organise la représentation du diagramme (de la même manière que les répertoires organisent les fichiers).
Il est présenté ci-dessous les digrammes de séquence illustrant certains cas d’utilisations :
Ajout d’un Equipement dans la base
Avec Admi : Administrateur
Figure 6.4: Diagramme de séquence pour l’ajout d’un équipement Remarque :
Notons que les diagrammes de séquence pour l’enregistrement d’une panne, l’émission d’un OT, l’édition du planning, la rédaction du rapport de quart, entre autres, sont semblables à celui de la figure 6.4.
Accéder à l’historique
Avec UTIL : Utilisateur
Figure 6.5 : Diagramme de séquence pour accéder à l’historique des pannes
6.3. Réalisation
Pour la réalisation de l’application, le logiciel WinDev (version 17.00.142.0) a été utilisé. En effet, WinDev est un AGL (Atelier de Génie Logiciel) qui permet de développer des applications dans tous les domaines. A la différence d’autres langages traditionnels, il n’est pas nécessaire de chercher et de rajouter des modules pour concevoir, tester et installer une application.
De plus, le L5G (Langage de Cinquième Génération) de WinDev, le W-Langage, est très simple et très efficace. Ce langage est disponible en Français et en Anglais.
6.3.1. Préliminaires
Pour a réalisation, les préliminaires suivants ont été nécessaires.
Choix du type de base de données :
WinDev dispose de différents types de bases de données. Les plus pertinents dans notre cas sont HFSQL Classic et HFSQL Client/Serveur. Le tableau 6.2 compare ces deux (02) types.
Tableau 6.2 : Comparaison entre HFSQL Classic et HFSQL Client/Serveur [14]
Situation\Base de données HFSQL Classic HFSQL Client/Serveur
Mono-Utilisateur OUI (Conseillé) NON
Réseau Local Rapide OUI OUI
Installation simple/minimum OUI Nécessite une installation
mais facile à mettre en œuvre Accès depuis un mobile
- Plus de sécurité (utilisation d’un login, d’un mot de passe et définitions des droits associés aux utilisateurs) ;
- Pas de gestion de répertoire : tous les fichiers de la base de données sont regroupés au même endroit ;
- Les clients finaux ne voient pas les fichiers de données dans leur explorateur et ne peuvent pas y accéder directement ;
- Les bases de données en mode HFSQL Client/serveur peuvent être utilisées par une connexion internet.
Notre choix s’est donc porté sur HFSQL Client/Serveur compte tenu de ses nombreux avantages.
Installation du Serveur :
Pour permettre aux différents utilisateurs de pouvoir accéder aux fichiers de la base, un serveur doit être installé. Ce serveur sert d’interface pour accéder aux données, protégeant ainsi le dossier contenant les données. WinDev dispose du sien : le serveur Manta. Lors de son installation, il faut spécifier type de la base (HFSQL Client/Serveur).
Figure 6.6 : Principe d’accès au serveur 6.3.2. Analyse de l’application
Pour cette application, il faut disposer de fichiers de données. Par ailleurs, lorsqu’un projet WinDev utilise des fichiers de données, ce projet doit être
L’éditeur d’analyses de WinDev permet de créer très simplement une analyse. L’analyse d’un projet WinDev est donc l’ensemble des fichiers de données et leurs différentes liaisons (connexions). Chaque fichier de données de l’analyse est constitué de « rubriques ». Une rubrique est caractérisée par son Nom, son Libellé et son Type (date, heure, numérique…). Par exemple, pour enregistrer les Equipements, il a été créé un fichier de données « Equipements » ayant pour rubriques :
- « IDEquipements » de type « Numérique », créé par défaut ; il sert d’identifiant aux enregistrements du fichier ; il permet notamment le parcourt du fichier en question ;
- « NomEquip » de type « Texte » qui correspond au Nom d’un équipement ; - « CodeEquip » de type « Texte », qui correspond au code d’un équipement ;
- « GroupEquip » de type « Texte », qui correspond au groupe auquel appartient un équipement : tous les équipements sont répartis en neuf (09) groupes fonctionnels (Transport Ciment, Séparateur, Filtre Broyeur, Lubrification, Broyeur, Doseurs, Chargement, Déchargement Clinker, Conditionnement).
La figure 6.7 donne la vue d’un fichier de données de type HFSQL Client/Serveur.
Figure 6.7: Aperçu d’un Fichier de données
La figure 6.8 montre la structure de l’analyse obtenue.
Figure 6.8: Analyse de l’application
NB : Chaque fichier de l’analyse n’est qu’une projection de son équivalent
« physique » stocké dans le dossier du projet et sur le serveur.
6.3.3. Réalisations des fenêtres
Pour enregistrer les données dans la base et pour interroger la base, il faut créer des fenêtres. Pour cela, il a fallu entre autres :
- Créer des fenêtres vierges ;
- Ajouter les objets nécessaires (des boutons, des champs de saisie, des images, des champs tables…) ;
- Ecrire des requêtes pour trier ou afficher des données (dans un tableau par
l’affichage de l’historique des pannes entre deux dates. Le tableau 6.3 présente la liste des quinze (15) requêtes construites et leur utilisation ;
Figure 6.9: Vue de d’une requête
Tableau 6.3: Liste des requêtes et leur utilisation
- Créer des « Etats » pour imprimer le contenu d’une table, d’une requête, etc : un état est le nom donné à la représentation d’une édition [9]. Pour les différentes impressions, il a été créé au total douze (12) états. La figure 6.10
Requête Utilisation
AffichAgent Affichage de la liste des Agents affichEquip Affichage de la liste des équipements
AffichHisto Affichage de l’historique des pannes d’un équipement depuis sa mise en marche
AffichHisto1 Affichage de l’historique des pannes d’un équipement entre deux dates
AffichPièces Affichage du stock au magasin AffichQuart Affichage des rapports de quarts AffichRes Affichage de Réparations effectuées
AffichRetraits Affichage des opérations de retrait au magasin AlarmPlanning Tri des échéances de planning dont
l’exécution est dans au plus 3 jours
ChefOT Tri des agents selon leur Division
OT Tri des OT selon la division
RapportOT Tri des Rapports des OT selon la division
Planning Affichage du contenu du planning
TriAffichPan Affichage des Pannes enregistrées
TriOT Tri les OT suivant la division
Figure 6.10: Vue d’un état
- Ecrire les lignes de codes nécessaires au fonctionnement des différents objets graphiques, notamment des procédures locales et des « Threads » (procédure fonctionnant en tâches de fond).
Conclusion
La conception de l’application a été possible grâce à l’AGL WinDev et, a nécessité de faire une analyse des besoins à satisfaire pour en déduire les fonctionnalités, de construire un modèle UML de l’application, de choisir le type de base, de réaliser l’analyse et les interfaces de communication entre la base et les utilisateurs.
CHAPITRE 7 : PRESENTATION ET DEPLOIEMENT DE L’APPLICATION
Pour répondre aux besoins exprimés, l’application dispose de différentes fenêtres. Ce chapitre présente les différentes fenêtres de l’application et leur fonctionnement ; ainsi que la procédure de déploiement.
7.1. Présentation
7.1.1. Fenêtre principale
Cette fenêtre dispose de trois (04) volets : Accueil, Gestion des Equipements, Maintenance et Statistiques. Chaque volet dispose de plusieurs options (groupes). Sur cette fenêtre, en haut, à droite se trouve respectivement en partant de la gauche, les alarmes visuelles (clignotement) « Echéances Planning Proches », « Stocks Critiques au magasin » et « Pannes non Résolues ». Les figures 7.1, 7.2, 7.3 et 7.4 présentent différentes vues de la fenêtre principale.
Figure 7.2: Vue de la fenêtre principale avec le volet « Gestion des Equipements » actif
Figure 7.3: Vue de la fenêtre principale avec le volet « Maintenance » actif
Figure 7.4: Vue de la fenêtre principale avec le volet « Statistiques » actif
Un double clic sur l’icône blanc (alarme « Echéances Planning Proches»,) de la fenêtre principale fait apparaitre la fenêtre ci-dessous qui indique les interventions concernées par l’alarme.
Au niveau de cette même fenêtre principale, un double clic sur l’icône rouge en haut à droite (« Pannes non Résolues ») ouvre la fenêtre de la figure 7.6.Elle présente des différentes pannes non résolues (leur nombre) suivant trois (03) gammes : moins de 48h, entre 48h et 72h, supérieur à 72h.
Figure 7.6: Fenêtre des pannes non résolues
7.1.2. Volet « Accueil »
Ici, nous avons différentes fenêtres présentées par les figures 7.7 à 7.11.
Figure 7.7: Enregistrement d’une acquisition de pièce Figure 7.6 : Fenêtre des différentes catégories de pannes
non résolues
Figure 7.8: Enregistrement d’un retrait de pièce
Figure 7.10: Fenêtre d’aide
Un clic sur le bouton « Abréviation s» de la fenêtre d’aide ouvre la fenêtre des Abréviations présentée par la figure 7.11.
Figure 7.11: Fenêtre des abréviations
7.1.3. Volet « Gestion des Equipements » Ce volet dispose de trois fenêtres.
Figure 7.12: Enregistrement d’un équipement
Figure 7.14: Signaler la résolution d’une panne 7.1.4. Le volet « Maintenance »
Il possède quatre (04) fenêtres.
Avec CD : Chef Division
Figure 7.15: Ajout d’une intervention dans le planning
Chaque Chef Division doit compléter chaque ligne concernant sa division : il doit préciser le responsable qui doit exécuter la tâche et l’équipe avec laquelle celui-ci doit travailler.
Une autre fonctionnalité de ce volet est l’émission d’ordre de travail et la rédaction du rapport. Pour émettre un OT, après un clic sur le bouton correspondant, la fenêtre de la figure 7.16 apparait pour choisir la division de l’OT.
Figure 7.16: Choix de la division pour l’émission d’un OT
Pour rédiger le rapport d’un OT, après un clic sur le bouton adéquat, la fenêtre suivante apparait pour permettre de choisir la division correspondante.
Figure 7.18: Choix de la division pour le rapport d’un OT
Figure 7.19: Rédaction du rapport d’un ordre de travail
Figure 7.20 : Rédaction du rapport de quart 7.1.5. Volet « Statistiques »
Ce volet permet d’avoir rapidement accès à différents informations telles que : la liste des agents, l’état du stock au magasin, l’historique des retraits au magasin, l’histoire des pannes. La figure 7.21 présente la fenêtre permettant l’accès à ces fonctionnalités.
Figure 7.21 : Fenêtre des statistiques 7.2. Déploiement de l’application
Installation
Dans le cas présent, il s’agit d’une installation réseau. Un programme d'installation doit être créé pour être installé sur le poste serveur. Tous les postes utilisateurs voulant installer l'application lanceront directement l'installation de l'application par le réseau. La figure 7.22 résume les différentes étapes du déploiement.
Figure 7.22 : Déploiement de l’application [14]
Matériel et coût de déploiement
Pour déployer l’application, il est donc nécessaire d’avoir un ordinateur qui doit accueillir le serveur HFSQL Client/Serveur : il devra être en fonctionnement permanent. Le tableau 7.1 résume les besoins financiers du déploiement.
Tableau 7.1 : Besoins financiers pour déploiement de l’application Matériel Caractéristiques Prix TTC (FCFA) Un (01) ordinateur Marque : HP Compaq
LA1956X
Pour le déploiement nous avons donc besoin de 530,00 FCFA.
Suivi et adaptation des utilisateurs
Une fois l’application déployée, il faudra aider les agents du Service Maintenance à accepter progressivement le changement. Il conviendrait de dissiper les éventuels doutes en s’appuyant sur les avantages de la solution ; d’aider pendant un certain temps les utilisateurs dans la saisie des données. De plus l’administrateur devra être à même de répondre à toute inquiétude concernant la solution.
Une œuvre humaine n’étant pas parfaite, il convient de s’enquérir des suggestions des utilisateurs et des éventuelles failles qu’ils auraient décelées.
Cela contribuera à l’amélioration de l’application.
Conclusion
L’application réalisée répond au cahier des charges. Elle dispose de plusieurs interfaces offrant différentes fonctionnalités. Elle permet la gestion des Ordres de Travail, des échéances du planning de maintenance, du stock du magasin, des rapports de quart, du parc d’équipements.
CONCLUSION GENERALE ET SUGGESTIONS
Ce stage de fin d’étude au sein de CIMBENIN S.A., a permis la familiarisation avec l’usine. Il a nous a donné l’opportunité de comprendre le processus de fabrication du ciment et de participer aux différentes activités de maintenance. Aussi, nous avons eu un aperçu de l’organisation de la maintenance au sein de cette usine.
L’analyse du système de maintenance a révélé quelques insuffisances relatives à la révision du plan de maintenance et à l’accès aux informations.
Après l’inventaire des machines, le classement de celles-ci suivant la méthode PROMETHEE, qui est une méthode d’aide à décision issue de l’approche multicritère des indicateurs de performances, a été fait. Ce classement a permis d’identifier le système de distribution d’air comprimé comme le plus critique. Le classement ainsi obtenu est un outil pour donner une orientation sur les équipements dont le plan de maintenance peut être révisé.
Aussi, l’application de Gestion de la Maintenance Assistée par Ordinateur a été modélisée par la méthodologie orientée objet UML. Elle a été réalisée grâce à l’Atelier de Génie Logiciel WinDev. Cette application a été conçue en mode HFSQL Client/serveur.
Par rapport au classement des machines par la méthode PROMETHEE, il serait convenable que :
- le plan de maintenance soit révisé en combinant ce classement aux observations des techniciens sur le terrain ;
- une expérimentation du plan de maintenance révisé soit faite durant une période considérable ;
- une analyse soit faite pour comparer la période avant la révision du plan et
De même, des améliorations peuvent être apportées à l’application conçue. Ces améliorations s’expriment en partie, par les suggestions suivantes :
- remplacer les alarmes visuelles par des alarmes sonores pour attirer plus l’attention des agents ;
- ajouter des graphes pour donner un aperçu global de l’état de la maintenance ;
- améliorer continuellement l’aspect visuel de l’application pour la rendre de plus en plus attrayante ;
- intégrer l’évaluation des performances et le classement des machines dans l’application ;
- intégrer la gestion des périodicités dans l’application ; - Intégrer la gestion du magasin outillage dans l’application ;
- étendre progressivement l’utilisation de l’application à d’autres services de la direction technique de CIMBENIN S.A.
REFERENCES BIBLIOGRAPHIQUES ET WEBOGRAPHIE BIBLIOGRAPHIE
[1] AFNOR. Maintenance industrielle: fonction maintenance. FD X 60-000, 2002, 29p.
[2] Jérémy Llaurens, Mise en place d'un plan de maintenance préventive sur un site de production pharmaceutique. Thèse présentée pour l'obtention du titre de Docteur en pharmacie, Diplôme d'état, faculté de Pharmacie de Grenoble, 2014, 75p.
[3] Rosa ABBOU. Contribution a la mise en oeuvre d'une maintenance centralisee: Conception et Optimisation d'un Atelier de Maintenance.
Automatique-Productique. Grenoble. Thèse de doctorat de l'Universite Joseph-Fourier de , 2003, 142p.
[4] Hermann Paul Valère C. LOKO, Amélioration de la maintenance à ALPHA BENIN S.A, conception d’une application de gestion des interventions.
Mémoire d’ingénieur de conception, Génie Electrique, EPAC, 2015, 103p ; [5] Anthony VALDEZ. La Politique de Maintenance Biomédicale, l’assistance publique-hôpitaux de Marseille : Etat des lieux et éléments de réflexion.
Mémoire de l’Ecole Nationale de la Santé Publique, 2005, 103p.
[6] Francois Monchy et Jean-Pierre Vernier, Maintenance : Méthodes et Organisation. 3e édition, Paris : DUNOD, 2010, 519p.
[7] Renaud Caillet. Analyse multicritère : Etude et comparaison des méthodes existantes en vue d’une application en analyse de cycle de vie. Série Scientifique. Montréal : Centre Interuniversitaire de Recherche en Analyse des Organisation, 2003, 51p.
WEBOGRAPHIE
[10] https://books.google.co.uk/books , consulté le 30/11/2016 à 11h39min.
[11] https://en.wikipedia.org/wiki/Preference_ranking_organization_
Method_for_enrichment_evaluation, consulté le 09/11/2016 à 14h 00 min.
[12] www.ales.cci.fr/sites/default/files/cci/CTSP/FICHES-ENE/gmao, consulté le 11/08/2016 à 20h19min.
[13] http://www.siveco.com/fr/zoom-sur-la-societe-atmi-distributeur-des-solutions-coswin-base-en-tunisie, consulté le 28/09/2016 à 16h30min.
[14] http://blogs.pcsoft.fr/post.awp?title=hfsql-clientserveur-classic-reseau,7,227,consulté le 10/10/2016 à 07h57min.
[15] https://doc.pcsoft.fr/fr-FR/?2028008#NOTE2_2, consulté le 10/10/2016 à 07h57.
ANNEXE
ANNEXE 1 : PROGRAMME MATLAB POUR L’EVALUATION DES CRITERES ET LE CLASSEMENT DES MACHINES