OUTIL DE GESTION DE LA MAINTENANCE VIA

Transcription

1 INSA TOULOUSE MEMOIRE PRESENTE EN VUE D OBTENIR LE TITRE D INGENIEUR DIPLOME PAR L ETAT (IDPE) EN AUTOMATIQUE ET INFORMATIQUE INDUSTRIELLE PAR DENIS TUR OUTIL DE GESTION DE LA MAINTENANCE VIA L INTRANET DE FREESCALE LE TLS-TWIM Soutenu le 22 septembre 2009 Présidente du Jury : Madame Colette MERCE, Directrice DGEI INSA Toulouse Membres : Monsieur Michel CASTAN, Responsable de la Formation Continue, spécialité Informatique Monsieur Christian GANIBAL, Ingénieur CNRS, LAAS, Ingénieur de recherche en Electronique Monsieur Vincent MAHOUT, Enseignant DGEI, spécialité Automatique Informatique Industrielle Monsieur Pierre PINEL, Enseignant DGEI, spécialité Informatique Monsieur Jean-Louis VIDAL, Ingénieur DPE, Responsable du Service Informatique de la Mairie de Toulouse

2 Page 2 Denis TUR INSA TOULOUSE MEMOIRE PRESENTE EN VUE D OBTENIR LE TITRE D INGENIEUR DIPLOME PAR L ETAT (IDPE) EN AUTOMATIQUE ET INFORMATIQUE INDUSTRIELLE PAR DENIS TUR OUTIL DE GESTION DE LA MAINTENANCE VIA L INTRANET DE FREESCALE LE TLS-TWIM Soutenu le 22 septembre 2009 Présidente du Jury : Madame Colette MERCE, Directrice DGEI INSA Toulouse Membres : Monsieur Michel CASTAN, Responsable de la Formation Continue, spécialité Informatique Monsieur Christian GANIBAL, Ingénieur CNRS, LAAS, Ingénieur de recherche en Electronique Monsieur Vincent MAHOUT, Enseignant DGEI, spécialité Automatique Informatique Industrielle Monsieur Pierre PINEL, Enseignant DGEI, spécialité Informatique Monsieur Jean-Louis VIDAL, Ingénieur DPE, Responsable du Service Informatique de la Mairie de Toulouse

3 Page 3 Denis TUR Remerciements Avant de commencer la présentation du projet, je tiens à exprimer mes sincères remerciements à Monsieur Philippe MAZILIER, responsable du service de la maintenance à Freescale Toulouse, pour m avoir fait confiance et pour avoir su orienter mes travaux. Je souhaite aussi remercier Monsieur Vincent MAHOUT, Enseignant DGEI, spécialité Automatique Informatique Industrielle, pour ses relectures et corrections de ce mémoire. Je tiens aussi à exprimer ma reconnaissance et mes remerciements à Monsieur Philippe SIMOES, Ingénieur informaticien et responsable du groupe maintenance en weekend, pour son support, ses conseils et pour notre étroite collaboration tout au long du projet. Je tiens à remercier également Monsieur Simon TRESSIERES et Monsieur Fabrice JACQUEMIN, informaticiens au service support informatique, pour l aide qu ils m ont apportée pour la mise en production du site FSL-TWIM sur le serveur de Freescale. Je suis également très reconnaissant envers les responsables des groupes de maintenance, Messieurs Patrice LORENDEAUX, Michel CASON, Francis DUPRE, Philippe MANGEOLE, Bernard DOUILHAC, Pierre ANDRIEU, Philippe FLAMENT et Eric BRU, pour l aide au déploiement des outils dans leurs unités respectives. Je tiens de même à remercier Mademoiselle Frédérique GUILLON, Ingénieur procédé en implantation ionique à Freescale, pour ses relectures et corrections de ce mémoire. Enfin je veux également saluer la patience, la compréhension et le soutien dont a fait preuve mon épouse, Sandrine, lors de ces deux dernières années. Je tiens aussi à remercier mes enfants, Héléana et Florian, qui m ont souvent demandé pourquoi je travaillais au lieu de jouer avec eux.

4 Résumé Page 4 Denis TUR Ce mémoire décrit la mise en place d un système de gestion de la maintenance via l intranet de l usine Freescale à Toulouse : le TLS-TWIM. Après la constitution d une équipe projet, j ai élaboré un cahier des charges avec les futurs utilisateurs. Une fois les objectifs clairement définis j ai découpé les différents modules du système en diagrammes fonctionnels. Ce découpage m a permis d élaborer un planning prévisionnel pour ce projet. Les trois choix possibles pour le développement de cette interface étaient les suivants : la solution interne Freescale, l achat de logiciel externe ou le langage PHP. Ce dernier a été retenu sur des critères de coût, d évolution future et d entretien. En ce qui concerne le stockage des informations j ai utilisé la méthode Merise pour la conception des structures des bases de données. 52 tables ont été nécessaires pour le système TLS-TWIM. Pour le développement des codes source je me suis appuyé sur la culture du Lean Manufacturing présente dans l entreprise. Les notions de 5S, d amélioration continue et l outil Smed ont permis de structurer, de standardiser et d optimiser le codage. Le module, planification dynamique des préventives compteurs est détaillé en fin de mémoire. Cet outil permet de planifier dynamiquement les interventions de maintenance préventive en fonction des divers compteurs présents sur les équipements de production. L interface TLS-TWIM est en fonctionnement depuis juin 2009 et les utilisateurs en apprécient la convivialité, la rapidité et l accessibilité. Les temps de recherche d informations et d analyse de pannes ont diminués, soit 50% à 60% de gain. Ce système est le point d entrée unique de toutes les équipes de maintenance et centralise les informations nécessaires pour les équipes supports de la production de l usine de Toulouse. Mots clé : Standardisation, intranet, GMAO, PHP, convivialité, rapidité, accessibilité, LEAN MANUFACTURING. Summary This report describes the development and installation of maintenance software through the Toulouse Freescale network: the TLS-TWIM. After the constitution of team project, I elaborated the requirements with the future users. Once the objectives clearly defined, the various modules of the system were broken down into to build a functional diagram and estimated planning for this project. The three possible choices for the development of this interface were the following: the Freescale internal solution, external software or the PHP language. This last one was chosen on criteria of cost, evolution and maintenance. Concerning the data storage the Merise method was used to build the structural design of the databases. 52 tables were necessary for system TLS-TWIM. The development of source lines of code was based on Lean Manufacturing culture deployed in the company. Some tools like 5S continuous improvement or Smed were used to improve the structure, to standardize and to optimize the code. A specific module is described at the end of the report. This tool allows the planning of preventive maintenance according to the various meters retrieved from production equipments. TLS-TWIM interface is under operation since June People using the software particularly appreciate user-friendliness, speed and accessibility. The search and breakdowns analysis times have decreased, from 50% to 60% improvement. All data and inputs were now only gathered through this system. All sustaining teams were used this interface. Keywords: Standardization, Intranet, GMAO, PHP, friendly interface, response time, accessibility, LEAN MANUFACTURING.

5 Page 5 Denis TUR Je me suis souvent repenti d'avoir parlé, mais jamais de m'être tu. (Philippe de Commines)

6 Page 6 Denis TUR Sommaire Remerciements... 3 Résumé... Erreur! Signet non défini. Summary... Erreur! Signet non défini. Sommaire... 6 Introduction... 7 Abréviations... 8 Listes des Figures... 9 Listes des Tableaux... 9 Chapitre I : Présentation générale du projet FSL-TWIM I.1- Le cahier des charges La problématique Le plan de travail Les ressources nécessaires I.2- Déroulement du projet Etat des lieux La collecte des besoins clients Recherche des solutions de développement Architecture du système FLS-TWIM Etude du stockage des données Estimation des ressources nécessaires Le codage Cycle de vie d un projet Tests des programmes Validation des modules avec les clients Livraison finale Maintenance I.3- Conclusion chapitre I Chapitre II : Planification Dynamique des Préventives Compteurs (PDPC) 37 II.1- Introduction II.2- Présentation de Machine Manager II.3- Présentation de PROMIS II.4- Acquisition des relevés compteurs équipements Les compteurs TWIM II.5- La planification dynamique des interventions préventives II.6- Conclusion chapitre II Conclusion Les possibilités d évolution Bilan personnel Bibliographie/Web graphie Documents de référence Liens WEB Annexes Annexe I : Planning prévisionnel Annexe II : Les organigrammes de TLS-FAB Organigramme de Freescale Toulouse FAB Organigramme de la maintenance Toulouse FAB... 48

7 Page 7 Denis TUR Introduction La transparence, la réactivité et la communication sont les maîtres mots d une équipe, qu elle soit composée de techniciens de maintenance, d ingénieurs procédé ou d opérateurs de production. Les clients et les auditeurs externes sont très attentifs à ces différents termes, que l on peut définir d ailleurs comme mots-clés, tant l importance qu ils apportent à la qualité du produit final est primordiale. C est d autant plus vrai aujourd hui avec la situation économique mondiale sur le marché de l automobile. En effet Freescale, leader sur ce secteur, subit cette crise. Nous devons par notre savoir faire et notre expérience surmonter dans les meilleures conditions cette étape difficile. En tenant compte de cette situation, ce mémoire décrit le développement et la mise en place des outils informatiques pour répondre aux besoins des équipes supports de la production (maintenance et procédé). Cette évolution informatique permet de mettre sous chaque mot clé, présenté en début de cette introduction, une multitude de sujets et de références. C est une avancée notoire pour Freescale Toulouse. Ce mémoire est composé de deux parties. Le premier chapitre aborde le projet FSL-TWIM dans sa globalité. Ce chapitre reste général et ne s'attache pas à décrire, par souci de concision, les nombreux aspects techniques. Le deuxième chapitre traite d une sous-partie du projet : Planification Dynamique des Préventives Compteurs. En effet, ce module tient une place importante et nécessite des explications plus détaillées. En fin de mémoire, vous trouverez la conclusion et le bilan personnel de ce projet.

8 Page 8 Denis TUR Abréviations Acronyme 5S BIA CAB COCOMO Console VT220 DRP Equipment Engineering GMAO IT SUPPORT KARDEX LEAN MANUFACTURING MM PDPC PM PROMIS SERVEUR SMED TLS-FAB TWIM Désignation Méthode d origine japonaise qui permet de trier, mettre en ordre, nettoyer, standardiser, et de suivre tous lieux, travaux, etc. Business Impact Assement = Document interne pour connaître l importance d un système ou d un logiciel sur les clients. Change Access Board (système gérant les changements à Freescale) Méthode pour quantifier les ressources sur un projet informatique (acronyme de l'anglais COnstructive COst Model) Emulateur de terminal utilisé pour PROMIS Disaster Recovery Plan : document interne pour réparer un système ou un logiciel. Ingénieur équipement, responsable d une famille d équipement. Outil pour la gestion de la maintenance assistée par ordinateur Service support pour l informatique de l usine Freescale Endroit de stockage des pièces de rechanges pour la maintenance Philosophie qui propose d utiliser les outils comme le 5S, le SMED ou les groupes «KAIZENS» pour l amélioration continue des procédés. Machine Manager (software utilisé pour communiquer avec les équipements) Planification Dynamique des Préventives Compteurs Préventive Maintenance Système de gestion centralisé de la production Système informatique destiné à fournir des services à des utilisateurs connectés et, par extension, organisme qui exploite un tel système. Single Minute Exchange of Die permet le changement d un outil en moins de 10 minutes Abréviation interne de l usine de Toulouse Toulouse Web Interface Maintenance NB : Quelques abréviations font parties du langage interne à Freescale Toulouse

9 Page 9 Denis TUR Listes des Figures FIGURE 1 : EXTRAIT DU PLANNING PRÉVISIONNEL DU PROJET FSL-TWIM FIGURE 2 : DIAGRAMME FONCTIONNEL GLOBAL DU PROJET FSL-TWIM FIGURE 3 : DIAGRAMME FONCTIONNEL POUR LE CAHIER DE CONSIGNES FIGURE 4 : DIAGRAMME FONCTIONNEL POUR LA PLANIFICATION DES MAINTENANCES PRÉVENTIVES SUR LES ÉQUIPEMENTS FIGURE 5 : DIAGRAMME FONCTIONNEL POUR LE STOCK DES PIÈCES (KARDEX) FIGURE 6 : DIAGRAMME FONCTIONNEL DE LA DOCUMENTATION TECHNIQUE FIGURE 7 : DIAGRAMME FONCTIONNEL DE L OUTIL D ANALYSE DE LA DISPONIBILITÉ DES ÉQUIPEMENTS FIGURE 8 : DIAGRAMME FONCTIONNEL DES CONFIGURATIONS ÉQUIPEMENTS FIGURE 9 : DIAGRAMME DÉCISIONNEL DES SOLUTIONS TECHNIQUES FIGURE 10 : ARCHITECTURE DU SYSTÈME FSL-TWIM FIGURE 11 : EXEMPLE D ENTITÉS DANS LES BASES DE DONNÉES MYSQL FIGURE 12 : EXEMPLE D ATTRIBUTS DANS LES ENTITÉS DES BASES DE DONNÉES MYSQL FIGURE 13 : EXEMPLE DE RELATION OU D ASSOCIATION ENTRE ENTITÉS DANS LA BASE MYSQL FIGURE 14 : EXEMPLE DE CARDINALITÉ DANS DES RELATIONS D UNE BASE MYSQL FIGURE 15 : EXEMPLE DE CLEF DANS UNE ENTITÉ FIGURE 16 : EXEMPLE DE MCD, MODÈLE CONCEPTUEL DE DONNÉES, POUR L OUTIL DE GESTION DES MAINTENANCES PRÉVENTIVES FIGURE 17 : EXEMPLE DE STRUCTURE DE TABLE DANS LES BASES MYSQL FIGURE 18 : ARBORESCENCE DES CODES SOURCE SUR LE SERVEUR DE FSL-TWIM FIGURE 19 : EXEMPLE DE CODE SOURCE FIGURE 20 : EXTRAIT DE WIKIPÉDIA SUR LE FONCTIONNEMENT DU PHP FIGURE 21 : CYCLE DE VIE EN V FIGURE 22 : SYNOPTIQUE DU FONCTIONNEMENT DE MACHINE MANAGER FIGURE 23 : SYNOPTIQUE DU FONCTIONNEMENT DE PROMIS-MACHINE MANAGER-EQUIPEMENTS FIGURE 24 : SYNOPTIQUE DE L ACQUISITION DES RELEVÉS COMPTEURS FIGURE 25 : EXEMPLE DE CALCUL D UNE DATE D INTERVENTION DE MAINTENANCE PRÉVENTIVE AVEC DES COMPTEURS FIGURE 26 : EXTRAIT DU PLANNING DE FSL-TWIM Listes des Tableaux TABLEAU 1 : CRITÈRES DE SÉLECTION DES SOLUTIONS DE DÉVELOPPEMENT TABLEAU 2 : MÉTHODE COCOMO, EFFORT ET TEMPS DE DÉVELOPPEMENT TABLEAU 3 : BESOIN EN HOMMES ET DURÉE DES PHASES DANS LA MÉTHODE COCOMO TABLEAU 4 : MÉTHODE COCOMO, POURCENTAGE D EFFORT TABLEAU 5 : MÉTHODE COCOMO, POURCENTAGE DE TEMPS DU DÉVELOPPEMENT TABLEAU 6 : EXEMPLE DE TESTS POUR LE MODULE GESTION DES PRÉVENTIVES... 35

10 Page 10 Denis TUR Chapitre I : Présentation générale du projet FSL-TWIM Le FSL-TWIM (Freescale Toulouse Web Interface Maintenance) est l outil de GMAO incontournable sur le site de Toulouse. Son utilisation permet de centraliser les données pour la maintenance dans un environnement convivial et avec une grande accessibilité. Ce chapitre décrit la méthodologie et le déroulement de ce projet. I.1- Le cahier des charges La problématique Le sujet retenu Nous avons, depuis début 2007, un premier module fonctionnel «Cahier de Consignes Informatiques». La nécessité de cette partie, testée et validée par les différents clients du groupe maintenance, ne faisait plus aucun doute. Ce module fonctionnait sur un ordinateur transformé en serveur local. Dans le but d améliorer cet outil et de créer de nouvelles fonctionnalités, une réunion de travail a permis de mettre à jour deux besoins supplémentaires : La nécessité de mettre en place un serveur dédié et soutenu par le service IT (service informatique) L ajout d outils complémentaires répondant aux besoins des clients : - Gérer les interventions préventives - Afficher les pièces du stock - Centraliser les documentations techniques - Connaître la disponibilité des machines - Stocker les configurations des équipements La création du site FSL-TWIM prenait alors réellement forme. Enjeux Les enjeux de ce projet peuvent se décomposer selon quatre axes : technique, économique, humain et organisationnel. Les enjeux humains : Ce projet est avant tout un projet humain. En effet, avant d être un outil de gestion de la maintenance via l intranet de Freescale, c est une aventure humaine jalonnée de rencontres et d expériences. Tous les acteurs de la maintenance ont participé à cette réalisation. Cet apport inestimable donne à ce projet une dimension humaine, de plus il correspond à une véritable réalité industrielle. Les enjeux techniques : Comment faire pour réaliser un outil de gestion de la maintenance? Quel langage informatique choisir? Comment gérer le serveur? Quelles bases de données utiliser et comment les organiser? Ce mémoire présente tous ces aspects techniques.

11 Page 11 Denis TUR Les enjeux économiques : Ce projet doit permettre d améliorer le travail quotidien des techniciens et ingénieurs. Il doit réduire considérablement les temps de recherche dans le stock de l usine. Il doit faciliter les analyses de pannes machines et doit centraliser les documentations et les interventions de maintenance préventives. L amélioration de ces outils s inscrit donc dans une réduction des coûts. Les enjeux organisationnels : L utilisation de FSL-TWIM ne se limite pas à un service au profit de quelques personnes, il touche des secteurs très différents, de la maintenance, de la production, de l engineering ou du service «device». L aspect formation et management doit être challengé pour avoir une utilisation optimale des différents modules du programme. Objectifs visés Plusieurs objectifs se dégagent de ce projet. Le plus important est la centralisation de toutes les informations nécessaires aux équipes support, qu elles soient de maintenance, du «process engineering» ou du support «device». (Voir en annexe IV l organigramme des groupes supports) Le deuxième objectif est l amélioration de l efficacité et de la rapidité des interventions de maintenance. Le troisième objectif a pour but l analyse technique et la mise en place des interventions adéquates. Cet outil permet aux différents services de mieux déceler des problèmes et de mettre des actions en place. Enfin, le FSL-TWIM est la référence technique de la maintenance pour l ensemble des utilisateurs et permet une traçabilité et une transparence des interventions lors des audits qualité. Le plan de travail La démarche Chaque phase de collecte, des besoins initiaux puis spécifiques des clients, est articulée de la façon suivante : - Mise en place de réunion avec les clients - Formalisation des besoins (journal de bord) - Identification des différentes tâches - Réalisation du planning Une fois cette étape terminée, la phase de codification permet de réaliser un prototype. Les tests unitaires finis, une mise en situation avec les clients valide le projet. Au final, les clients valident les différents modules et la livraison de l outil complet peut avoir lieu.

12 Page 12 Denis TUR Les fonctionnalités envisagées pour les sous projets L outil FSL-TWIM comporte plusieurs sous-projets. Le premier qui est fonctionnel et utilisé depuis janvier 2007, s intitule «Cahier de Consignes Informatiques». Pour le module «Recherche de pièces dans le stock de l usine», les listings de pièces sont récupérés quotidiennement par transfert de fichiers sur un serveur. Ces informations permettent la mise en place d un support avec une recherche plus rapide et plus conviviale. Concernant le module «Documentation technique», une interface utilisateur est créée pour la mise en ligne des documents et la mise à jour si nécessaire. Avec l outil «Plans d actions», un système innovant et centralisé est proposé pour gérer et organiser le suivi des travaux des techniciens et ingénieurs. Le module de «Gestion des maintenances préventives» centralise les différentes interventions de maintenance. Il permet l affichage des plannings, gère les «compteurs équipements 1» et assure la traçabilité des interventions. La planification Le planning prévisionnel de ce projet est difficile à établir. En effet, ma fonction d Equipment Engineering m amène à gérer un parc équipement, aussi bien au niveau des budgets que des interventions de maintenance. Mon premier rôle est de maintenir les équipements de production en état de fonctionnement optimum. Le projet FSL-TWIM rentre à terme dans ce cadre-là. Ce planning est donc juste un indicateur et permet d estimer le délai de réalisation du projet. Voici ci-après un aperçu du planning prévisionnel. Figure 1 : Extrait du planning prévisionnel du projet FSL-TWIM 1 Valeurs disponibles sur les équipements pour connaître les heures de fonctionnement, la quantité de produit passé sur les équipements, les nombres de cycles, etc.

13 Page 13 Denis TUR Les ressources nécessaires Les ressources humaines Pour mener à bien ce projet, la communication avec plusieurs métiers est nécessaire. Que ce soit avec des managers de groupe, des opérateurs, des techniciens ou ingénieurs. Tous sont acteurs dans le projet. L équipe de pilotage du projet est la suivante : Sponsor : Support technique : Support technique IT : Support technique IT : Support technique : Maître d œuvre: Philippe Mazilier : Manager du groupe maintenance Toulouse FAB Philippe Simoés : Manager weekend maintenance et informaticien Simon Tressières : Informaticien Fabrice Jacquemin : Informaticien Catherine Saccoccini : Informaticienne Denis TUR : Equipment Engineering Implantation Les ressources budgétaires Les budgets maintenance sont soumis à beaucoup de contraintes. Dans une situation économique difficile, les sommes allouées à la maintenance sont sans cesse modifiées. Dans ces conditions, les ressources budgétaires pour un tel projet sont minimales. La mise en place d un serveur et le support technique à l année de celui-ci sont de l ordre de Le codage et la mise en production de ce projet sont effectués sur mon temps de travail et avec un investissement personnel important. I.2- Déroulement du projet La partie suivante montre la réalisation du projet. Etat des lieux L équipe de maintenance à Freescale est sectorisée en sept groupes. Au fil du temps, les méthodologies de chaque secteur ont divergé et il existe aujourd hui autant de façons de travailler qu il existe de groupes. Les passages de consignes entre les techniciens de maintenance sont soient orales, soient écrites, parfois les deux. L archivage des cahiers de consignes est inexistant. Bien que les évènements majeurs soient répertoriés dans PROMIS (logiciel de gestion de la production), la recherche de consignes importantes est difficile, voire impossible. Les interventions de maintenance préventives sont gérées par plusieurs systèmes. Pour le groupe implantation ionique, il existe un outil informatique depuis Cet outil développé sous Visual Basic atteint aujourd hui ses limites ; il exploite une base de données ACCESS et il n est plus maintenu. Les autres labos travaillent avec un système de planification sous LabView.

14 Page 14 Denis TUR Là encore, le logiciel utilisé n est plus adapté pour faire de la planification et surtout les performances sont en-dessous des besoins. L historique des détails des interventions de maintenance est présenté sous format papier, avec tous les inconvénients que cela comporte ; pertes de papier, check-lists mal remplies, etc. Les compteurs présents sur les machines sont relevés manuellement ou par système informatique. La planification des interventions se fait à l aide d un fichier Excel. On retrouve autant de fichiers qu il existe de type d équipements avec compteurs. La recherche de pièces de rechange se fait sur une console VT220 grâce à un logiciel, qui n est pas du tout intuitif et manque énormément de convivialité. Avec un affichage d une dizaine de pièces par écran, il faut faire défiler les différentes pages pour trouver la pièce souhaitée. Cela engendre une perte de temps conséquente pour les techniciens et ingénieurs, (de 5 à 10 minutes minimum par recherche). Concernant la gestion des documentations techniques, les avis et les méthodes divergent. Certains conservent leur classeur personnel qui fait office d aidemémoire. D autres partagent leur savoir et mettent en place des documentations communes. Aucun standard n existe pour la documentation dite «d aide au dépannage et documentation technique». Pour les projets des techniciens ou pour les suivis particuliers lors d événements sur les équipements, chaque groupe utilise sa méthode, son fichier de suivi, ses critères de priorités. Là encore rien de commun, impossible de s y retrouver. La collecte des besoins clients Le besoin exprimé par les futurs utilisateurs est très clair : ils demandent une STANDARDISATION des méthodes de travail. La norme ISOTS [B1] demande de plus en plus de standards pour garantir au client final un produit avec des caractéristiques techniques reproductibles. De ce fait, les services internes (maintenance/procédé/device) sont très attentifs au concept de standardisation. Lors des différentes réunions avec les futurs utilisateurs du système de gestion de la maintenance, les besoins se focalisent à chaque fois sur un système centralisé et commun. Les grandes lignes des besoins sont : Mettre en place un système informatisé. Disposer d un point d accès unifié. Standardiser des outils pour les groupes supports (maintenance/procédé) Communiquer avec les bases de données existantes Assurer la maintenance et permettre l évolution vers de nouvelles fonctions

15 Page 15 Denis TUR Diagramme fonctionnel du projet FSL-TWIM: Le diagramme fonctionnel du projet FSL-TWIM, présenté ci-après, permet de visualiser les différentes fonctionnalités du système. Trier Visualiser Organiser Rechercher Administrer Partager FSL-TWIM Données brutes Informations : Communication équipements Fonctionnalités : Consignes informatiques Gestion des préventives - CONVIVIALES - RAPIDES - COMMUNES - CENTRALISEES Données utilisateurs Affichage des pièces du stock Documentation technique Disponibilité des machines Configuration des équipements Figure 2 : Diagramme fonctionnel Global du projet FSL-TWIM Ce diagramme fonctionnel permet de mieux cerner l ampleur du projet. Les paragraphes suivants détaillent chaque module et permettent de mieux comprendre les différentes fonctionnalités.

16 Page 16 Denis TUR Les diagrammes fonctionnels du système FSL-TWIM : Cahier de consignes informatisé : - Ce module permet la saisie de consignes, dédiées par groupe de maintenance. L utilisateur doit indiquer son nom, choisir l équipement parmi une liste prédéterminée correspondant à son unité. - Il offre la possibilité de noter une remarque si l intervention doit être poursuivie lors du changement d équipe de maintenance. - Il permet de faire des recherches dans les historiques, soit par machine, par motsclés ou par période calendaire. - La page d accueil présente les consignes de la veille et de la journée, ainsi que l état actuel du parc machine. - Ce module offre la possibilité de modifier ou de supprimer des consignes (restriction aux consignes personnelles uniquement : accès par mot de passe) Trier Rechercher machine/jour Visualiser Consigne saisie Noter les consignes Information et analyse Cahier de consignes informatisé Figure 3 : Diagramme fonctionnel pour le cahier de consignes Maintenance préventive équipement (PM): - Ce module doit afficher le planning des interventions de maintenance préventive par unité. Chaque utilisateur peut choisir dans ce planning les équipements qui le concernent. Une vision générale des dates d intervention de maintenance est nécessaire afin de connaître les retards ou les oublis. Le planning de la période en cours doit être toujours affiché. Le choix d une période calendaire spécifique doit être possible par l intermédiaire d un menu. - Pour remplacer le bilan hebdomadaire manuel des interventions de maintenances préventives, un suivi (sous forme graphique) ainsi qu une alerte en cas de retard doivent être réalisés. - La centralisation des relevés présents sur les équipements, appelés «compteurs», doit permettre une vision rapide et globale de tous les systèmes compteur de l unité de fabrication (ex : compteurs Machine Manager, PROMIS ou compteurs manuels). Ce système permet d effectuer une planification dynamique en fonction des relevés récoltés. - La fonction «Compteur» doit également répondre aux besoins spécifiques de certaines unités, par exemple pour des calculs cumulatifs.

17 Page 17 Denis TUR - Une fonction de ce module doit permettre de connaître à l année la quantité de pièces nécessaires à l exécution des interventions de maintenance préventives. Cet outil prévisionnel sera une aide non négligeable pour la gestion des coûts de maintenance. - Pour répondre aux différents audits, un menu doit permettre la traçabilité des interventions au travers de l historique dans une base de données. - Une fois que le système préventif est en place, les préventives suivantes se génèreront automatiquement lors des saisies de fin d intervention précédentes par les utilisateurs. Le système sera auto-alimenté. - Enfin, le fonctionnement et l administration doivent être partagés par plusieurs utilisateurs. Les managers de services et Equipment Engineering doivent avoir les droits d accès pour créer, modifier, ou supprimer des interventions de maintenance préventives. Un menu convivial et complet permet, selon les niveaux d accès, l administration de cet outil. Fonction Rechercher Administrer Visualiser Trier historique COMPTEURS ou PM classique : Nécessite de saisir la 1 ère date de l intervention de maintenance et la fréquence. Planifier les préventives Maintenance préventive équipement Analyse et informations Planning complet, convivial et rapide. Régénération Figure 4 : Diagramme fonctionnel pour la planification des maintenances préventives sur les équipements Stock de pièces «KARDEX» : - Ce module doit permettre d optimiser la recherche des pièces de rechange pour les interventions de maintenance préventives ou curatives de l ensemble de l usine. - Un fichier «CSV (Comma Separated Value)» doit être récupéré tous les jours, pour alimenter une base de données. - Une page doit permettre, à l aide de requêtes, d effectuer un tri par référence fournisseur, par référence Freescale ou par famille d équipements.

18 Page 18 Denis TUR Trier par références Freescale, Fournisseur et famille d équipements Données brutes Stock pièces Afficher les pièces du stock Stock pièces KARDEX Tri convivial et rapide Figure 5 : Diagramme fonctionnel pour le stock des pièces (KARDEX) Documentation technique : - Il faut centraliser les documentations techniques et les aides aux dépannages sous un format unique. - Il faut créer un menu d administration pour la mise en ligne des documents. Les utilisateurs pourront ainsi partager leur savoir et leurs expériences de maintenance, après validation de ces informations auprès d un Equipment Engineering. Rechercher document Mettre en ligne les documents Données utilisateurs Partager le savoir Le savoir est partagé. Les documents sont accessibles Documentation technique Figure 6 : Diagramme fonctionnel de la documentation technique Outil d analyse de la disponibilité des équipements : - Ce module doit permettre de visualiser la disponibilité des équipements de production et de connaître les principales causes d arrêt. - La page d accueil doit guider l utilisateur, selon des choix multicritères. Il faut pouvoir sélectionner son unité, son équipement type, sa période d analyse, les différents groupes de pannes (appelés buckets) et les commentaires des intervenants par type de panne. - Il faut utiliser les bases de données (Oracles & TERADATA) pour déterminer la disponibilité des équipements.

19 Page 19 Denis TUR - Sélection Multicritères Deux bases de données Oracle et une base de données de type TERADATA Connaître la disponibilité Disponibilité équipements Affichage de la performance en temps réel Visualisation des détracteurs de panne Figure 7 : Diagramme fonctionnel de l outil d analyse de la disponibilité des équipements Configuration des équipements : - La centralisation des configurations machine doit permettre de garder la traçabilité des softwares, des paramètres, etc. Les données peuvent contenir par exemple, les versions de logiciels présents sur les équipements, les valeurs critiques de réglages ou les sous-ensembles mécaniques. Toutes les informations utiles et nécessaires sont stockées pour reconfigurer un équipement en cas de pannes importantes. - L utilité de cet outil sera sans aucun doute appréciée lors des audits de qualité. En effet, les auditeurs souhaitent connaître les configurations et les différences notables entre équipements du même type. Fonction Chercher par groupe d équipement type Données brutes des configurations Stocker les configurations Affichage rapide des configurations Configuration équipements Figure 8 : Diagramme fonctionnel des configurations équipements L ensemble de ces diagrammes fonctionnels permet de mieux cerner les besoins des clients et oriente les solutions de développement.

20 Page 20 Denis TUR Recherche des solutions de développement La validation du cahier des charges et des différentes fonctionnalités du système est réalisée. Nous pouvons aborder la phase de recherche de solutions, une des plus discutées et discutable au vue de la diversité des choix. La variété des sous-projets, la centralisation des informations, le besoin de rapidité et surtout l accessibilité du système sont des points très importants. Pour les satisfaire, deux phases sont nécessaires à l élaboration des solutions de développement : la phase de recherche et la phase de tri. La phase de recherche De prime abord, un logiciel de maintenance sous-entend GMAO (Gestion de Maintenance Assisté par Ordinateur). Aujourd hui sur le marché plusieurs outils existent : lequel choisir? Les principaux sont : CARL (software), CLARISSE, OPTIMAINT, COSWIN 7i, etc. Tous proposent des solutions innovantes dédiées par secteurs d activités. En effet, ces logiciels intègrent la gestion de stock, la planification d interventions préventives, la gestion des ressources humaines, le suivi d interventions, etc. Ils sont vraiment complets et répondent à certains besoins du projet avec précision. Autre axe de recherche : les solutions présentes en interne. Que possède Freescale pour la gestion de la maintenance? L outil PROMIS, déjà utilisé pour gérer la production du site de Toulouse, propose quelques solutions. Il intègre entre autres des fonctions de gestion d équipements (affichage des pannes curatives et des interventions préventive), des notifications de consignes après les différentes interventions (de maintenance bien sûr, mais aussi de production ou de d engineering) et des planifications de tâches. Enfin, la dernière solution possible est le développement d un système complet de A à Z en utilisant un langage, une plateforme ou un environnement dédié. La communication avec des bases de données internes à Freescale, l accessibilité sur toute l usine, la rapidité et l aspect convivial sont des critères décisifs. Autre point important, la mise en œuvre doit être simple. En prenant en compte toutes ces informations, une plateforme de type PHP [B2] peut correspondre à ces besoins. La phase de tri Ce «brainstorming» avec l équipe projet (présenté au paragraphe I.1) a permis de dégager plusieurs solutions potentiellement adaptables au projet. Pour faire un choix constructif, trois critères permettent de juger la faculté de chaque solution à répondre aux exigences des clients. Ces critères sont : le coût, la faisabilité et l évolution du système. Les notes varient de 0 à : pas de coût, réalisable et évolution interne possible : coût maximum, faisabilité nulle et pas d évolution interne possible. En utilisant un système à trois axes, le report de ces notes permet de connaître la meilleure solution : celle-là même qui occupe la surface la plus petite possible.

21 Page 21 Denis TUR La figure suivante montre ces trois critères et leurs notations. Faisabilité Solution GMAO du marché 4 3 Solution PROMIS Coût 8 5 Solution PHP Evolution Figure 9 : Diagramme décisionnel des solutions techniques Récapitulatif avec les avantages et les inconvénients. Choix Avantage Inconvénient Coût Faisabilité Evolution Classement Complet, dédié à un ème secteur d activité. Logiciel GMAO du marché PROMIS PHP Logiciel puissant pour la gestion de production. Bien adapté au développement WEB, simple à mettre en place. Maintenance facile. Economique à long terme. Communication avec les bases de données simplifiée. Coût à prévoir, pas d amélioration possible en interne. Pas forcement applicable aux différents besoins des clients. Pas du tout convivial, interface graphique inexistante. Pas de base de données. Formation personnelle nécessaire. Aucune connaissance de ce langage. Tableau 1 : Critères de sélection des solutions de développement ème er Avec tous ces critères, une proposition se dégage. La solution PHP est la mieux adaptée aux besoins exprimés. Reste un inconvénient à cette solution : la nouveauté d un tel système! L auto formation sera nécessaire. Sur le site de Freescale Toulouse je pourrai m appuyer sur le support technique de l équipe projet, et plus particulièrement sur Philippe Simoès, Ingénieur informaticien, et également sur la multitude d informations disponibles sur les forums et sites dédiés au PHP.

22 Architecture du système FLS-TWIM Page 22 Denis TUR Le cahier des charges impose une communication avec des bases de données multiples, une accessibilité via tous les ordinateurs de l usine. Il n y a pas de code résidant, pas d installation de logiciel ou de bibliothèque sur les postes clients. Tout est stocké et interprété par le serveur dans la partie applicative de l architecture. Concernant les bases de données MYSQL [B3], elles sont stockées sur le serveur, par contre d autres bases ORACLE et TERADATA/DIAMOND 2 sont stockées sur un serveur dédié. Ce dernier est complètement géré par le service informatique. Ces bases ne sont pas locales, elles sont communes à toutes les entités Freescale dans le monde. A l inverse des bases MYSQL, l applicatif communique avec celles-ci uniquement en lecture. Ces bases sont principalement utilisées pour créer des rapports et faire des analyses. Figure 10 : Architecture du système FSL-TWIM Etude du stockage des données Le projet FSL-TWIM est construit sur la manipulation de données. Les bases utilisées sont MYSQL, ORACLE et TERADATA/DIAMOND : sur ces deux dernières aucun changement n est possible. En effet, elles ont été définies par le groupe informatique principal (Freescale Etats-Unis), et les changements de structure sont impossibles. Par contre, pour les bases de données MYSQL, les structures sont à réaliser. Une recherche sur la construction des bases de données permet d identifier une méthode : la méthode MERISE 3 [B4]. 2 Nouvelle base de données dans l entreprise Freescale 3 Technique d origine française pour l analyse des bases de données

23 Page 23 Denis TUR Cette méthode est basée sur le modèle entité-association. C est une technique permettant de construire des schémas théoriques de raisonnement sur des applications utilisant des bases de données relationnelles. La connaissance des règles simples des schémas entités-associations (aussi appelé entitésrelations) permet d'affiner le projet, sans avoir besoin de programmer. Par conséquent, on réalise une économie de temps de conception tout en obtenant une plus grande souplesse au niveau de l'analyse. Le modèle entité-association est apparu dans les travaux des chercheurs, entre 1972 et 1975 lors des travaux de Messieurs MOULIN, TARDIEU et TEBOUL. Il est devenu célèbre dans le monde entier grâce à l américain Peter CHEN. Avec cette technique, la construction des différentes bases de données MYSQL du projet est la suivante. Définition des entités La méthode MERISE nécessite l existence d entités, en fait nous pourrions parler aussi de tables. C est le terme le plus souvent utilisé dans le secteur industriel ou privé, sur des bases comme ACCESS, par exemple. Le cahier des charges stipule que l outil final doit servir à plusieurs unités. Une centaine de techniciens et ingénieurs doivent s identifier. Il faut gérer plus de 1000 équipements de production. Le projet doit aussi intégrer un planning, des pièces de rechange, des interventions de maintenance préventives, des archives, des consignes, etc. Autant d entités à créer. Sur l ensemble du projet pas moins de 52 entités sont nécessaires au fonctionnement du système FSL-TWIM. Voici quelques exemples d entités utilisées dans le projet. Personnels Equipements Planning Figure 11 : Exemple d entités dans les bases de données MYSQL Définition des attributs Les attributs dans la méthode MERISE sont les caractéristiques décrivant les entités. Ils sont représentés par une liste de mots, la plus simple possible pour chacune d elle. Il faut également préciser le type des données attendues pour chaque attribut. Là aussi, nous pouvons utiliser le terme de champs à la place d attributs. En reprenant les exemples ci-dessus pour chaque entité, nous avons une liste d attributs. Dans le cas de l entité PERSONNELS il faut les attributs : NOM, PRENOM, CCID, USER_ID, ADMIN et LABO (unité d appartenance). Pour chacun d entre eux, les types de données ont des caractères d une longueur bien déterminée. Pour illustrer les attributs, la figure 12 reprend les exemples ci-dessus.

24 Page 24 Denis TUR Personnels Equipements Planning NOM PRENOM CCID USER_ID ADMIN LABO CHAR(20) CHAR(20) CHAR(8) CHAR(7) CHAR(2) CHAR(15) EQT_ID EQT_TYPE LABO DESCRIP CHAR(20) CHAR(20) CHAR(15) CHAR(255) LABO CHAR(15) EQT_ID CHAR(20) DATE DATETIME NOM_PM CHAR(50) FAITE CHAR(2) FAITE_HORS_D CHAR(2) PM_COMPTEUR CHAR(2) COMPTEUR_NAME CHAR(20) Figure 12 : Exemple d attributs dans les entités des bases de données MYSQL Définition des associations ou relations Ce sont les liaisons entre entités. Dans le projet FSL-TWIM, un utilisateur du logiciel appartient à une unité bien définie. Il travaille sur des équipements qui appartiennent à cette même unité. La visualisation du planning des interventions de maintenance préventives est aussi liée à cette unité. L illustration suivante montre ce type de liaisons. Personnels NOM PRENOM CCID USER_ID ADMIN LABO CHAR(20) CHAR(20) CHAR(8) CHAR(7) CHAR(2) CHAR(15) Maintien Equipements EQT_ID EQT_TYPE LABO DESCRIP CHAR(20) CHAR(20) CHAR(15) CHAR(255) Possède une PM Planning LABO EQT_ID DATE NOM_PM FAITE FAITE_HORS_D PM_COMPTEUR COMPTEUR_NAME CHAR(15) CHAR(20) DATETIME CHAR(50) CHAR(2) CHAR(2) CHAR(2) CHAR(20) Figure 13 : Exemple de relation ou d association entre entités dans la base MYSQL On peut aussi résumer cette illustration par cette phrase : «Un technicien à la charge de maintenir des équipements, et les équipements peuvent avoir ou non des interventions de maintenance préventives planifiées» Définition des cardinalités La notion de cardinalité permet de dénombrer les éléments de l'entité d'arrivée en relation avec les éléments de l'entité de départ, et vice versa. L exemple ci-dessus et surtout la phrase qui décrit l illustration sont des exemples de cardinalité. En effet, un technicien a la charge de plusieurs équipements et chaque équipement peut être maintenu par plusieurs techniciens. Autre exemple, un équipement peut avoir ou non une maintenance préventive planifiée, par contre chaque intervention de maintenance préventive a un et un seul équipement associé.

25 Page 25 Denis TUR Personnels NOM PRENOM CCID USER_ID ADMIN LABO CHAR(20) CHAR(20) CHAR(8) CHAR(7) CHAR(2) CHAR(15) Maintien Maintien Equipements EQT_ID EQT_TYPE LABO DESCRIP Possède une PM 1,n 1,n CHAR(20) CHAR(20) 0,n 1,1 CHAR(15) CHAR(255) Planning LABO EQT_ID DATE NOM_PM FAITE FAITE_HORS_D PM_COMPTEUR COMPTEUR_NAME CHAR(15) CHAR(20) DATETIME CHAR(50) CHAR(2) CHAR(2) CHAR(2) CHAR(20) Figure 14 : Exemple de cardinalité dans des relations d une base MYSQL Définition des clefs d une entité Une clef permet de distinguer sans ambigüité un élément dans une entité par rapport aux autres éléments de cette entité. Par souci de rapidité dans les recherches et pour éviter toute confusion, une clef purement informatique est créée dans chaque entité. Cette clef sert d index primaire et elle est dissociée des attributs de l entité. Prenons un exemple sur l entité PERSONNELS, un nouvel attribut est ajouté en tout début de l entité, il est complètement transparent pour l utilisateur. Cet attribut porte le nom «ID» quelles que soient les différentes entités dans les bases de données, le type de donnée est un «INT(10)», avec une clé primaire et une auto-incrémentation. Le fait qu il soit unique permet une manipulation des données sans aucune confusion possible. L attribut «ID» devient donc la clef des différentes entités. ID NOM PRENOM CCID USER_ID ADMIN LABO Personnels INT(10) CHAR(20) CHAR(20) CHAR(8) CHAR(7) CHAR(2) CHAR(15) Figure 15 : Exemple de clef dans une entité Le modèle conceptuel des données La méthode MERISE va plus loin dans la conception des structures des tables. Cependant, pour ce projet, seules les notions décrites précédemment sont nécessaires. Concernant le MCD (modèle conceptuel de données), voyons pour un cas bien précis la structure de celui-ci. La figure 13 montre l exemple de MCD pour l outil de gestion des maintenances préventives.

26 Page 26 Denis TUR Equipements Intervenir 1,n ID EQT_ID EQT_TYPE LABO DESCRIP INT(10) CHAR(20) CHAR(20) CHAR(15) CHAR(255) 0,n Planifier 1,n 1,n 1,n Planning PM Personnels ID NOM PRENOM CCID USER_ID ADMIN LABO INT(10) CHAR(20) CHAR(20) CHAR(8) CHAR(7) CHAR(2) CHAR(15) Associer 1,n Différentes PM ID INT(10) LABO CHAR(15) EQT_TYPE CHAR(20) NOM_PM CHAR(50) PERIODE CHAR(10) FREQUENCE CHAR(10) NB_JOURS FLOAT DESCRIP RETARD FLOAT SPEC CHAR(255) CHAR(100) 1,n ID INT(10) LABO CHAR(15) EQT_ID CHAR(20) DATE DATETIME NOM_PM CHAR(50) FAITE CHAR(2) FAITE_HORS_D CHAR(2) PM_COMPTEUR CHAR(2) COMPTEUR_NAME CHAR(20) 1,n Associer Spécifications 0,1 ID SPEC LIEN INT(10) CHAR(255) CHAR(255) 1,n Correspondre Figure 16 : Exemple de MCD (Modèle Conceptuel de Données), pour l outil de gestion des maintenances préventives Cet exemple montre la structure pour le module «gestion des maintenances préventives». Le projet dans sa globalité comporte 10 bases de données MYSQL avec 52 entités différentes. Les modèles conceptuels de données pour les 9 modules présents dans «FSL-TWIM» sont détaillés en annexes. A l issue des différents «MCD» de chaque module, les tables nécessaires au fonctionnement du système «FSL-TWIM» peuvent être construites.

27 Page 27 Denis TUR Exemple de construction de tables : Table PERSONNELS : Table DIFFERENTES_PM : Figure 17 : Exemple de structure de table dans les bases MYSQL La méthode MERISE m a permis de construire et structurer au mieux les tables nécessaires au système FSL-TWIM.

28 Page 28 Denis TUR Estimation des ressources nécessaires Le critère de coût dans la recherche des solutions techniques impose à ce projet un coût minimum voir nul. En fait, il faut prendre en compte la mise en place d un serveur avec un budget pour le maintien de celui-ci. Pour évaluer les ressources nécessaires, j ai utilisé la méthode COCOMO 4 [W1], qui estime à partir du nombre de lignes de code source le besoin en mois-homme et un temps de développement. En utilisant cette méthode, voici une estimation qui ne fait pas office de référence, mais permet de voir l ampleur du projet. Le développement du site est estimé environ à lignes de code source. Cette estimation détermine que c est un projet de complexité simple. De ce fait, en prenant la formule ci-dessous :... (suite ci-dessous) Complexité Effort (en mois homme) Temps de développement (en mois) S Effort = 2,4 * KLS 1,05 TDev = 2,5 * Effort 0,38 Effort = 2,4 * 25 1,05 = 70,5 TDev = 2,5 * 70,5 0,38 = 12.5 Tableau 2 : Méthode COCOMO, effort et temps de développement (suite) on aboutit à : - 70 mois-homme pour ce projet. - Temps de développement de 12.5 mois pour finaliser le projet (à pondérer). Le graphique ci-après montre la répartition du besoin en hommes sur les différentes phases du projet et la durée de chacune Besoin en hommes et durée des phases 8 Durée en mois Besoin en hommes Expression du besoin Conception générale Programmation Test et intégration Tableau 3 : Besoin en hommes et durée des phases dans la méthode COCOMO 4 Méthode statistique basée sur les résultats de 63 projets de développements informatiques.

29 Page 29 Denis TUR La méthode COCOMO permet également de distribuer la phase d effort selon les différentes phases du projet. En effet, pour un projet de complexité simple, des statistiques permettent de déterminer l effort nécessaire par phase. L expression du besoin est séparée de l effort total, la somme des trois autres phases faisant 100%. Phase du projet Expression des besoins et planification Pourcentage d effort 6 % (séparé de l effort total) Conception générale 16 % Programmation 62 % - Conception détaillée 4 % - Programmation et tests unitaires 38 % Tests et intégration 22 % Tableau 4 : Méthode COCOMO, pourcentage d effort Ainsi, on peut également par cette méthode calculer le temps de développement d un projet simple. Là aussi, le temps consacré à l expression du besoin et à la planification ne fait pas partie du temps total. Phase du projet Expression des besoins et planification Temps de développement 12% (séparé de temps total) Conception générale 19 % Programmation 55 % Tests et intégration 26 % Tableau 5 : Méthode COCOMO, pourcentage de temps du développement Pour conclure sur cette méthode statistique, il faut comprendre que c est juste un indicateur qui permet d évaluer la charge de travail d un projet et de connaître l ampleur de l effort et du temps de développement. Le codage Comme le montrent les tableaux 3, 4 et 5, le codage est l étape la plus importante de ce projet en temps et en effort. Dans ce paragraphe, la description des codes sources et des bibliothèques développées n est pas détaillée. Par contre, il décrit les règles de codage utilisées. Les feuilles de styles (mise en forme des pages web) de l entreprise sont réutilisées pour la présentation générale des pages du système FSL-TWIM. Elles définissent l aspect visuel des tableaux, des menus déroulants, des polices, etc. L arborescence des codes sources est séparée par module. La maintenance et l évolution future seront plus rapides et plus simples.

30 Page 30 Denis TUR Arborescence des codes sources Figure 18 : Arborescence des codes sources sur le serveur de FSL-TWIM Règles de codage et architecture du logiciel A Freescale, il n existe pas de normes ou de règles de codage clairement définies. Pour retrouver rapidement les différentes fonctions et simplifier l entretien du site, tous les codes sources sont commentés et indentés. Le développement du code se rapproche des missions transversales du métier d Equipment Engineering. En effet, étant leader du groupe 5S sur la zone implantation ionique, je participe à la mise en place de la philosophie Lean Manufacturing qui prône l utilisation du 5S, du SMED et prévoit l amélioration continue des procédés ou des interventions de maintenance au travers des KAIZEN. Le codage rentre complètement dans cette approche de structure, de notification, d indentation du code et d optimisation. Chaque code source se décompose de la façon suivante : - L en-tête, regroupant les liens des feuilles de styles, les liens javascripts, le menu déroulant de gauche, les variables d entrées en PHP avec les méthodes «GET 5» - La partie formulaire, regroupant les tableaux, les boutons, les affichages divers et les scripts PHP. - La partie de POST, avec toutes les actions demandées après une méthode POST 5 dans le formulaire. - La partie pied de page, regroupant les informations de fin de page, liens, etc. La figure 19 montre un exemple des différentes parties d un code source. 5 Les méthodes GET ou POST sont utilisées pour faire passer des variables d une page à l autre.

31 Page 31 Denis TUR En-tête d un code source Formulaire

32 Page 32 Denis TUR Partie POST Pied de page Figure 19 : Exemple de code source

33 Page 33 Denis TUR Notions sur la programmation en PHP Le langage PHP [W2] ou HYPERTEXT est un script qui est interprété sur le serveur (machine hébergeant les différentes pages WEB). Celui-ci va interpréter le code PHP et générer un autre code qui est envoyé sur le navigateur (Internet Explorer, Firefox, etc.). Le code généré est constitué généralement de langage XHTML ou HTML, de feuilles de style «CSS», de JavaScript et parfois de documents «PDF». Conçu pour permettre la création d'applications dynamiques, le plus souvent dédiées aux pages Web, le PHP est généralement installé sur un serveur Apache. Le point fort, c est la possibilité de communiquer très facilement avec des bases de données. Une fois l installation réalisée des modules correspondant aux bases de données sur le serveur, l accès est rapide et aisé. La figure ci-dessous, extraite de WIKIPEDIA, illustre parfaitement le fonctionnement du langage PHP. Le client ouvre une page WEB, lance une requête ou une demande d informations. Ces demandes sont envoyées au serveur via Internet ou pour ce projet via l intranet de Freescale. Le serveur prend en compte la page, exécute le script PHP, puis génère du code HTML qui est interprété par le navigateur du client. Figure 20 : Extrait de Wikipédia sur le fonctionnement du PHP Concrètement pour que le serveur exécute le script PHP, la page doit avoir une extension en «.php». Cette page peut bien sûr, comporter du code HTML, du JAVASCRIPT et du script PHP. Le script PHP est alors encadré par des tags : pour le PHP les tags sont : <? code script php placé ici?> La page WEB ainsi créée satisfait à la demande du client et en aucun cas il ne peut voir le code source d origine de sa page, seul le code HTML est visible. En effet, le retour est principalement composé de code HTML. C est un avantage important d un point de vue sécurité. Le risque pendant le développement du code est l effet tunnel. L effort et le temps consacré au code occultent un peu la réalité et le besoin final du client. Pour rester en ligne avec le cahier des charges, la recherche d une méthode de tests et de validation est indispensable. La question est : comment faire pour finaliser ce projet?

34 Page 34 Denis TUR Cycle de vie d un projet Après plusieurs recherches, la méthode la plus fréquemment utilisée est le «cycle de vie». Celle-ci permet de manière logique de suivre un projet dans sa totalité et surtout de n oublier aucune étape. Il existe des cycles en V ou en cascades, le plus courant est le cycle de vie en V. La figure ci-dessous décrit le cycle de vie en V d un projet informatique. Définition du projet Analyse des besoins et faisabilité Spécifications Conception architecturale Conception détaillée Vérification et validation Tests d intégration Tests unitaires Recette et maintenance Tests de validation Tests et intégration du projet Codage Temps Figure 21 : Cycle de vie en V Les premières étapes du début du projet FSL-TWIM suivent ce cycle de vie en V. Toutefois, ne connaissant pas cette méthode lors de l élaboration du projet, certaines étapes ou transitions n ont pas été présentées dans ce mémoire. En intégrant cette méthode à la suite (et fin) du projet, la deuxième partie du cycle : «Tests et intégration du projet» a permis de répondre à la question posée en fin page précédente : «Comment faire pour finaliser ce projet?»

35 Page 35 Denis TUR Tests des programmes Cette étape est étroitement liée au codage. En effet, les tests des modules et des fonctionnalités se font pendant le développement du code. La relation «codage tests» ou «tests codage» est très fréquente. Ces tests se déroulent en deux phases bien distinctes. Tests des sous programmes et des fonctionnalités particulières. Cette étape, appelée «Tests Unitaires», permet la vérification de chacun des codes sources. Le tableau ci-dessous montre un exemple de test unitaire sur un module. Numéro du test: A1 Type de test Unitaire Description Module de récupération des valeurs compteurs et traitement des données Description du test et Instructions Résultat attendu Test réussi Valeur compteur non disponible sur le serveur tlscim03 Notification erreur, pas de OK fichier disponible Commentaire du défaut RAS Description du test et Instructions Résultat attendu Test réussi Récupération des valeurs compteurs. Valeur compteur de chaque OK compteur affichée à l écran. Commentaire du défaut RAS Description du test et Instructions Résultat attendu Test réussi Calcul de la vitesse d avancement des valeurs des compteurs et Vitesse affichée à l écran, et OK archivage dans la base de données base de données compteur_pm mise à jour. Commentaire du défaut RAS.... Tableau 6 : Exemple de tests pour le module Gestion des préventives Tests imbriquant tous les sous programmes. Cette phase permet de tester les interactions des différents modules entre eux. Elle correspond à la phase de «Tests d intégration» du cycle de vie en V. Validation des modules avec les clients Les clients attendent des réponses aux besoins exprimés dans le cahier des charges. La livraison des modules au fur et à mesure de leur construction permet de satisfaire rapidement les besoins exprimés par les clients. L information aux différents managers de groupe et aux utilisateurs sur l'avancement du projet contribue au déploiement du système FSL-TWIM.

36 Page 36 Denis TUR Livraison finale En fin de validation des outils, j ai installé tous les codes sources sur le serveur de production, dans leur environnement réel. J ai mis en service le système FSL-TWIM. Ma mission consiste aussi à informer, préparer et encadrer les différents utilisateurs. La programmation de formation permet aussi une meilleure appropriation des différents menus et fonctionnalités du système FSL-TWIM. C est une nouvelle méthode de travail. J ai aussi documenté le fonctionnement de ce nouveau système dans un document de référence, (GUIDE UTILISATEUR). Là, je fais apparaître toutes les subtilités des différents menus et des différentes pages. Maintenance A Freescale, la mise en production d un logiciel et sa maintenance nécessite de documenter toutes les étapes du processus d installation et l architecture logicielle. Cette documentation technique détaillée est normalisée, son contenu doit permettre de comprendre le fonctionnement de l ensemble du système. Elle doit comporter les structures des codes sources, les structures des différentes bases de données et l architecture globale du logiciel. Concernant la maintenance curative d un tel système, un document de référence existe : le «DRP» (Disaster Recovery Plan). Il permet de remonter un serveur à l identique, avec la dernière sauvegarde des données utilisateurs. Ce document est très complet, il fait même apparaître le temps nécessaire pour revenir à une configuration standard après un crash complet du serveur. I.3- Conclusion chapitre I Ce premier chapitre décrit le système FSL-TWIM dans sa globalité, il expose la méthodologie appliquée à ce projet. Avec l aide des diagrammes fonctionnels, le cahier des charges est précis et permet une meilleure compréhension des différents modules du système. Le point commun de tous les modules est la communication avec des bases de données. La méthode MERISE permet la création des structures des tables et les MCD (Modèle Conceptuel de Données) permettent d identifier, à partir d une description exprimée en langage naturel ou parlé, les entités et les associations en appliquant des règles précises : les noms deviennent des entités et les verbes, des associations. Dès lors la construction physique peut voir lieu. Après une recherche des différentes solutions de développement, le PHP correspond aux critères coût et évolution. La programmation avec ce langage aborde la standardisation des codes sources avec les notions du LEAN MANUFACTURING. L utilisation de cette philosophie permet d avoir une architecture structurée, indentée et organisée en modules. Enfin pour finaliser ce projet, l explication du cycle de vie d un logiciel permet d utiliser en cours de route la deuxième partie du V. Les tests et validations sont appliqués pour la fin du projet.

37 Page 37 Denis TUR Chapitre II : Planification Dynamique des Préventives Compteurs (PDPC) II.1- Introduction Ce deuxième chapitre décrit le fonctionnement d un des sous-projets de FSL-TWIM. Il fait partie du système de gestion des maintenances préventives et il occupe une place importante. Pourquoi ce module a-t-il besoin d être approfondi? La situation économique impose une rigueur et une diminution des coûts de maintenance. La gestion des interventions de maintenance préventive, sans prendre en compte le rythme de la production, ne permet plus de satisfaire les exigences en termes de coût. Il faut généraliser la planification des maintenances préventives en fonction de l utilisation des équipements. Pour cela, il existe sur la majorité des équipements des compteurs. Ils permettent de connaître le nombre d heures de fonctionnement, de produits passés, d heures de radio fréquence sur les modules RF, etc. La nouveauté du système FSL-TWIM est la centralisation de ces relevés de compteurs et la planification dynamique des interventions de maintenance préventives en fonction de leur valeur. Pour centraliser et automatiser ces relevés compteurs deux outils existent dans l entreprise : - MACHINE MANAGER - PROMIS. II.2- Présentation de Machine Manager Machine Manager (ou MM) est un logiciel qui permet, grâce à un serveur, de communiquer avec certains équipements de l usine. La liaison est possible uniquement si l équipement en question possède un moyen de communication (liaison série, parallèle ou carte réseau) Le protocole de communication généralement utilisé est SECSII 6. Le dialogue entre MM et les équipements permet : - de lancer des recettes de production stockées dans une base de données (RMS) - de vérifier la conformité des recettes - de remonter les alarmes lors du fonctionnement - de verrouiller des états équipements sur PROMIS (logiciel de gestion de production) - de suivre des paramètres équipements - de remonter des relevés compteurs 6 Protocole de communication via une liaison série entre un équipement et un superviseur.

38 Page 38 Denis TUR Ci-dessous le synoptique des liaisons entre Machine Manager et les équipements sur le réseau intranet de l usine. Figure 22 : Synoptique du fonctionnement de Machine Manager II.3- Présentation de PROMIS Promis est un puissant logiciel de gestion de production. Il gère tous les produits de la première étape de fabrication jusqu au test final. Ce logiciel est utilisé par toutes les entités Freescale. Sur Toulouse, la version primaire est utilisée, l interface est peu conviviale, les utilisateurs exécutent des scripts ou des instructions sur des consoles VT220. Promis n est pas en relation directe avec les équipements de TLS-FAB 7. L interface est réalisée par Machine Manager. L illustration ci-dessous décrit le principe de communication entre PROMIS, MM et les équipements. Documents PROMIS Rgergergerghghghe ghergerhgkjvherere Rgergergerghghghe rjerbvenbenmbqetb ghergerhgkjvherere mnetmnetbmnetbm rjerbvenbenmbqetb Rgergergerghghghe tbtntntnbtrnblmtns mnetmnetbmnetbm ghergerhgkjvherere bstjbmsblnstlmbns tbtntntnbtrnblmtns rjerbvenbenmbqetb dtmbjqtmbgtqejgh bstjbmsblnstlmbns mnetmnetbmnetbm met ;hetjhemejmgh dtmbjqtmbgtqejgh tbtntntnbtrnblmtns et,jqhmej met ;bgejqtbje ;hetjhemejmgh bstjbmsblnstlmbns t ;mbgetj et,jqhmej ;qbvgjqet dtmbjqtmbgtqejgh ;bgejqtbje ; bje ;et t ;mbgetj met ;qbvgjqet ;hetjhemejmgh ; bje ;et et,jqhmej ;bgejqtbje t ;mbgetj ;qbvgjqet ; bje ;et Utilise PROMIS Download des données dans les différentes bases Bases de données ORACLE et TERADATA Communication (Commande/retour) Base de données RMS Contrôle et upload des versions actives de recettes de production Machine Manager (Upload/Download) des informations Equipements de production Figure 23 : Synoptique du fonctionnement de PROMIS-Machine Manager-Equipements. 7 TLS-FAB est l abréviation de l Unité de Fabrication de TOULOUSE

39 Page 39 Denis TUR Cet outil de gestion de la production n utilise pas les bases de données. Il travaille avec des documents (les documents PROMIS). En revanche, les données sont chargées sur des bases ORACLES ou TERADATA pour permettre les analyses et pour réaliser des suivis, soit en temps réel soit à fréquence déterminée. En m appuyant sur cette structure existante, la récupération des relevés des compteurs des équipements de production permet de planifier les interventions de maintenance préventives. II.4- Acquisition des relevés compteurs équipements Il existe trois possibilités pour relever les compteurs équipements et permettre ainsi de créer des plannings. La première est MM (Machine Manager). Ce principe permet de récupérer la valeur des compteurs sur les équipements grâce aux liaisons séries. Les données de ces compteurs sont alors stockées et utilisées pour prévoir les interventions de maintenance préventive. Le point faible à cette solution est que dans certains cas les équipements ne possèdent pas de moyen de communication. La deuxième possibilité est de compter le nombre de produits ou le nombre cycles de production. Dans ce cas, l outil PROMIS permet (via des tâches appelées TASK) de générer des compteurs. En effet, un document PROMIS répertorie tous les équipements physiques ou virtuels de l usine. Le système assure donc une traçabilité pour les produits et connaît exactement la quantité passée sur chaque machine. Cette solution ne dépend pas des outils de communication des équipements. Enfin, dans une minorité de cas, les valeurs recueillies sur les équipements sont enregistrées manuellement dans le système FSL-TWIM. Ces trois possibilités de relevé des compteurs sont utilisées dans le module PDPC (Planification Dynamique des Préventives Compteurs) Pour être réactif sur la planification des interventions de maintenance préventives, il faut une mise à jour des valeurs compteurs régulière et fréquente. Pour cela, MM envoie par l intermédiaire d un script sur le serveur de FSL-TWIM, deux fois par vingt quatre heures les données. Concernant l outil PROMIS, le système FSL-TWIM interroge par une requête SQL, la base de données et récupère les valeurs compteurs une fois par jour. Le schéma de la figure 25, présente le principe d acquisition des relevés compteurs.

40 Page 40 Denis TUR Documents PROMIS Rgergergerghghghe ghergerhgkjvherere Rgergergerghghghe rjerbvenbenmbqetb ghergerhgkjvherere mnetmnetbmnetbm rjerbvenbenmbqetb Rgergergerghghghe tbtntntnbtrnblmtns mnetmnetbmnetbm ghergerhgkjvherere bstjbmsblnstlmbns tbtntntnbtrnblmtns rjerbvenbenmbqetb dtmbjqtmbgtqejgh bstjbmsblnstlmbns mnetmnetbmnetbm met ;hetjhemejmgh dtmbjqtmbgtqejgh tbtntntnbtrnblmtns et,jqhmej met ;bgejqtbje ;hetjhemejmgh bstjbmsblnstlmbns t ;mbgetj et,jqhmej ;qbvgjqet dtmbjqtmbgtqejgh ;bgejqtbje ; bje ;et t ;mbgetj met ;qbvgjqet ;hetjhemejmgh ; bje ;et et,jqhmej ;bgejqtbje t ;mbgetj ;qbvgjqet ; bje ;et Travaille PROMIS Download des données dans les différentes bases Base de données ORACLE et TERADATA Communication (Commande/retour) Base de données RMS Contrôle et upload des versions actives de recettes de production Machine Manager (Upload/Download) des informations Equipements de production Envoi des relevés sur le serveur FSL-TWIM Système FSL-TWIM Récupération des valeurs PROMIS depuis les bases de données Enregistrement manuel des valeurs Figure 24 : Synoptique de l acquisition des relevés compteurs Les compteurs TWIM La souplesse du système FSL-TWIM permet de faire des accumulations de valeur compteur et répond à une demande utilisateur, qui aujourd hui est traitée manuellement. La mise en place de compteurs virtuels appelés «Compteur TWIM» complète cet outil. Le fonctionnement est le suivant : l utilisateur a la possibilité de choisir un compteur de référence dans une liste prédéterminée (compteurs stockés dans la base de données MYSQL du système FSL-TWIM). Un nouveau compteur est alors créé, sous le nom de «TWIM_(nouveau nom de compteur)» Ce nouveau compteur TWIM est mis à jour et la date d intervention de maintenance préventive est recalculée à chaque évolution du compteur de référence. Le tableau ci-après permet de visualiser le compteur de référence et le compteur TWIM :

41 Page 41 Denis TUR Exemple de compteur de référence : Exemple de compteur TWIM : II.5- La planification dynamique des interventions préventives La planification dynamique est l ajustement des interventions de maintenance préventives en fonction des relevés effectués sur les équipements. Cette prévision doit automatiquement être réévaluée à chaque relevé. C est l effet DYNAMIQUE du planning. Lors de l acquisition des valeurs, le système FSL-TWIM doit estimer une vitesse moyenne d avancement. Cette vitesse est calculée à partir des trois derniers relevés des compteurs et permet de déterminer une date théorique d intervention. Dans l exemple d un compteur sur le nombre de produits passés sur un équipement, le déclenchement d une intervention de maintenance préventive doit être réalisé avant la valeur maximale autorisée (exemple : 2500). Valeur maximale : 2500 Fréquence : Relevé 1 Relevé 2 Relevé 3 Relevé 4 Valeurs : Vitesse : Vitesse moyenne produits entre chaque relevé Calcul de la date d intervention : Figure 25 : Exemple de calcul d une date d intervention de maintenance préventive avec des compteurs. Cette date est recalculée à chaque relevé de compteurs et le planning est modifié dynamiquement. C est une avancée importante dans la planification des interventions de maintenance préventive. Il y a environ 1000 équipements de production à gérer et cette solution permet la simplification des plannings.

42 Page 42 Denis TUR Exemple de planning sur le système FSL-TWIM La figure 27 présente un extrait du planning tel qu il est sur FSL-TWIM. Les utilisateurs voient immédiatement les actions qui doivent être exécutées dans la journée. Figure 26 : Extrait du planning de FSL-TWIM II.6- Conclusion chapitre II Ce sous-projet est le cœur du système FSL-TWIM. La maintenance préventive occupe une part majeure dans le travail des techniciens et ingénieurs. Les coûts associés à ces interventions sont également importants. La planification dynamique des interventions de maintenance préventives rentre pleinement dans cette politique d optimisation des coûts engagée depuis plusieurs années à Freescale Toulouse. Cet outil améliore le travail quotidien des techniciens et ingénieurs, il permet des gains de temps et facilite les saisies. Il allie innovation et rapidité.

43 Page 43 Denis TUR Conclusion Pour conclure ce mémoire, je dirai tout d abord : le projet est réalisé et fonctionnel. En effet, les objectifs du cahier des charges de départ sont complètement remplis. Les clients utilisent les différents modules. Ils voient au quotidien les bienfaits du système de GMAO. Les aspects accessibilité, rapidité et convivialité sont au rendez-vous. La solution d utiliser le langage PHP satisfait pleinement les utilisateurs. Elle est de ce fait la meilleure pour ce projet. Concernant plus particulièrement le déroulement du projet, j ai, dans le chapitre I, parlé de «cycle de vie en V». J ai expliqué alors que je n avais pas utilisé cette méthode pour le début du projet. Je ne connaissais pas alors ce suivi. Par contre, la logique de construction du projet que j ai utilisée est quasiment identique au cycle de vie en V. N ayant pas utilisé cette technique dès le départ, je m en suis inspiré en cours de route pour finaliser ce projet. Il est certain que le processus de cycle de vie en V permet de travailler avec de la rigueur. Chaque étape doit être validée pour passer à la suivante. Il permet d éviter de faire du ré-engineering qui génère des surcoûts. La connaissance de ce processus me permettra, lors de futurs projets, de mettre en application toutes les étapes liées au cycle de vie. Ce sera sans aucun doute un apport supplémentaire pour mener à bien mes futurs projets.

44 Page 44 Denis TUR Les possibilités d évolution L outil «FSL-TWIM» est orienté vers les utilisateurs et il répond parfaitement à leurs besoins actuels. Cependant la partie administration du système reste un point sombre. En effet, il existe bien des menus : pour gérer les bases de données, pour modifier les comptes utilisateurs, pour vérifier certaines fonctionnalités, mais ces pages méritent d être remaniées avec plus de simplicité. Autre point, chaque module du système FSL-TWIM peut être modifié pour évoluer avec les besoins des utilisateurs. Effectivement, le métier de maintenance demande une remise en question permanente pour répondre aux exigences de coût, de performance et de qualité. Les menus disponibles permettent aujourd hui de satisfaire les exigences des techniciens et Ingénieurs, mais demain les besoins vont encore évolués. Enfin ce projet est dédié pour Freescale et le semi-conducteur, pourquoi ne pas rendre cet outil universel, quelque soit le corps de métier. (Un choix par domaine par exemple : Aéronautique, Semi-conducteur, Transport, Automobile, etc.).

45 Page 45 Denis TUR Bilan personnel La réalisation de ce projet m a permis de mettre en œuvre mes compétences techniques. J ai réalisé un outil de GMAO complet qui répond parfaitement aux besoins des utilisateurs. J ai appris à mettre en avant mes capacités de communication, d écoute et de diplomatie pour que ce projet soit une parfaite réussite. Il s avère également que mon esprit d initiative et ma créativité ont permis aux utilisateurs de travailler plus facilement. L aspect convivial était le leitmotiv de cette aventure. Etant moi-même utilisateur, je devais déployer toutes mes compétences pour atteindre cet objectif final. C est pour moi une formidable aventure technique. En effet, j ai amplement alimenté mon désir d apprendre, désir qui m anime sans cesse. L aspect auto formation n est pas nouveau pour moi. Effectivement, du contexte familial, pour construire une maison, en passant au domaine professionnel, pour connaître un équipement ou créer un logiciel, je recherche et j apprends tout seul. J ai aussi partagé et appris les techniques informatiques avec mon équipe projet, présentée en début de mémoire. La communication et le partage ont également occupé une place primordiale. L aboutissement de ce projet m a fait prendre conscience de l ampleur du métier d ingénieur. En effet, la structure d un tel projet, l utilisation des méthodes adéquates, le suivi, la prise de décision et les validations avec le client sont des actions très importantes et nécessaires. L évolution de toutes ces notions s est faite progressivement depuis 2002, date à laquelle j ai commencé dans le poste d Equipment Engineering. Je connais maintenant les outils nécessaires pour l exécution d un projet, aussi bien humainement que techniquement. Je sais proposer des solutions pour dynamiser la motivation de mes collaborateurs. Je sais générer un cadre de travail favorable pour une meilleure collaboration entre tous les intervenants. Enfin, je sais anticiper et je surveille toutes les dérives possibles. Le métier de technicien s est éloigné jour après jour pour faire place à celui de l Ingénieur. Enfin, plus personnellement, je suis très heureux et très fier d être arrivé à ce stade. Il n est pas si simple à trente huit ans de bouleverser sa vie familiale, ses week-ends et soirées pour se replonger dans la formation, la rédaction d un mémoire, le stress d un examen. Quoi qu il arrive pour la suite de ma vie professionnelle, j en sors grandi et je suis prêt à diriger et encadrer d autres projets.

46 Page 46 Denis TUR Bibliographie/Web graphie Documents de référence [B1] David Hoyle, «Automotive quality systems handbook: ISO/TS 16949: 2002 edition», Publié par Butterworth-Heinemann, [B2] - Rasmus Lerdorf, Kevin Tatroe, Peter MacIntyre, «Programming PHP», éditions O Reilly - Olivier Heurtel, «Développer un site WEB dynamique et interactif», édition ENI [B3] Cyril Thibaud, «MYSQL5 Installation, Mise en œuvre, Administration Programmation», éditions ENI [B4] - Jean-Patrick Matheron, «Comprendre merise», éditions EYROLLES - Di GALLO Frédéric, «Méthodologie des systèmes d information - MERISE», cours du cycle B du CNAM Liens WEB [W1] - Méthode COCOMO, juin 2009 [W2] - PHP, juin 2009

47 Page 47 Denis TUR Annexes Annexe I : Planning prévisionnel

48 Page 48 Denis TUR Annexe II : Les organigrammes de TLS-FAB Organigramme de Freescale Toulouse FAB Organigramme de la maintenance Toulouse FAB