i

Remerciements

En souvenir de notre profonde gratitude à la réalisation de nos études à l’École Supérieure Polytechnique d’Antananarivo, nous sommes très reconnaissant envers :

Monsieur ANDRIANARY Philippe, Directeur de l’École Supérieure Polytechnique d’Antananarivo, de nous avoir autorisé à soutenir cet ouvrage.

Monsieur RAKOTOMANANA Charles Rodin, Chef de département Génie Mécanique Productique et Président du Jury de ce mémoire, Monsieur RAKOTONIAINA Solofo Hery, Chef de département Génie Électrique , pour leurs formations et leurs compétences dans la direction et l’organisation de filière Génie Industriel.

Monsieur JOELIHARITAHAKA Rabeatoandro, de nous avoir fait l’honneur d’être parmi les membres de jury

Monsieur RAKOTONIRINA René, d’avoir accepté d’examiner et de donner ses remarques pour ce travail.

Monsieur RASOLDIER Olivier, de nous avoir apporté une contribution précieuse à ce mémoire

Monsieur ANDRIAMANOHISOA Hery-Zo qui a encadré avec patience et pertinence le long de ces travaux. Nos discussions ont toujours été très enrichissantes.

Enfin, nous remercions notre famille pour l’encouragement, le soutien moral et financier dont vous nous avez entouré ; que ce modeste travail soit l’exaucement de vos veux tant formulés et de vos prières quotidiennes. Tous les amis en souvenir de nos collaborations, des bons moments et de tout ce que nous avons vécu ensemble.

ii

Table des matières

PARTIE I : CONTEXTE GENERAL CHAPITRE 1 : GÉNÉRALITÉS SUR LE SYSTÈME D’INFORMATION………………..2

I. Définitions et rôles…………………………………………….………………….2 I.1. Système d’information……………………………………………………………2 I.2. Système informatique………………………………………………...…………..2

I.3. Système organisationnel…………………………………………………………3 I.4. Les rôles du système d’information……………………………………………...3

II. Composition d’un système d’information d’une entreprise………………………4 II.1. Composition classique………………………………………………...…………4 II.2. Composition évoluée…………………………………………………………….4 II.3. Les autres composantes possibles………………………………………………..5

III. Utilités de la méthodologie dynamique de développement de système……….…5 IV. Méthode d’analyse et de conception des systèmes d’information…………....…..6

IV.1. La méthode MERISE…………………………………………………..………6 IV.2. LE PROCESSUS UNIFIÉ et UML………………………………….…………7 IV.2.1. Définitions……………………………………………………………...…7

IV.2.2. Caractéristiques du processus unifié ……………………………………..7 IV.2.3. Méthodes du processus unifié………………………………………..…..8

IV.2.4. Utilités d’UML……………………………………………………...……9 IV.5. Caractéristiques d’UML……………………………………………………9

V. ANALYSE ET CONCEPTION ORIENTÉE OBJET……………………………9 V.1. Les paradigmes de la conception orientée objet………………………………....9 V.1.1. Classe…………………………………………………………………...….9

V.1.2. Objet……………………………………………………...……………….9 V.1.3. Encapsulation…………………………………………………………….10 V.1.4. Héritage…………………………………………...……………………..10 V.1.5. Polymorphisme…………………………..………………………………10 V.1.6. Agrégation………………………………………………………………..10 V.2. Définitions……………………………………………….………………..……10 V.2.1. L’analyse orientée objet……………………………………….…………10 V.2.2. La conception orientée objet………………………..……………………10

CHAPITRE 2: PRÉSENTATION DE LA MAINTENANCE INDUSTRIELLE....…….11

I. Définitions………………………………………………………………....…….11 II. Buts de la maintenance………………………………………............…………..11 III. Termes concernés dans la fonction maintenance…………………………..……11

III.1. La maintenabilité…………………………………………………….………..11 III.2. La durabilité…………………………………………………………………..11 III.3 La disponibilité……………………………………………………..…………..11

iii

III.4 La défaillance…………………………………………………………………..11 III.5 La fiabilité………………………………………………………………..……..12 III.6 La sécurité……………………………………………………...……………….12

IV. L’environnement de la maintenance……………………………………..………12 V. Types de maintenance………………………………………………...………….12

V.1. Maintenance préventive………………………………………………………..13 V.1.1. Maintenance préventive systématique………………………..………….13 V.1.2. Maintenance préventive conditionnelle………………………………….13

V.1.3. Maintenance préventive prévisionnelle……………………….…………..13 V.2 Maintenance corrective……………………………………………..……….….13 V.2.1 Maintenance palliative (dépannage)…………………………….………..13 V.2.2 Maintenance curative (réparation)……………………….……………….13

VI. Les 5 niveaux de maintenance………………………………...…………………13 VI.1. Niveau 1…………………………………………….………………………….13

VI.2. Niveau 2……………………………………………………………………….14 VI.3. Niveau 3……………………………...………………………………………..14

VI.4. Niveau 4……………………………………………………………………….14 VI.5. Niveau 5…………………………………..……………………………………..14

VII. La problématique du sujet………………….……………………………………14

PARTIE II : METHODOLOGIE

CHAPITRE 3 : LES ACTIVITÉS DE L’HOMME DE MAINTENANCE……………..15 I. Les métiers de la maintenance industrielle………………………………………15

I.1. Le responsable de maintenance……………………….………..……………….15 I.2. L’agent de maîtrise de maintenance……………….…………………………….15 I.3. Le technicien de maintenance……………………………………………………16 I.4. L’agent de maintenance…………………………………...…………………….16

II. Les différentes activités des maintenanciers……………………………………..16 II.1. Avant la défaillance……………………………………………………………16 II.2. Après la défaillance………………………………………..……………………17

II.3. Les différentes activités des agents de fabrication industrielle (agent de production)…………………………………………………………………………..17

CHAPITRE 4 : LES CALCULS THEORIQUES DE LA FIABILITÉ………….……..18 I. Les paramètres de la maintenance industrielle………………..………………18

I.1. Paramètre Fiabilité R(t)……………………………...…………………………18 I.2. Notion sur les redondances………………………….…………………………..18 I.2.1. Redondance active……………………………...…………………………18

I.2.2. Redondance passive ou « stand by »……………...…….…………………19 I.2.3. Redondance majoritaire……………………………………………………19 I.3. Le taux de défaillance…………………………………………………………..20 I.4.La courbe en baignoire (bathtub curve)…………………...……………………..20

iv

I.4.1.Période de jeunesse……………………………….………………………..21 I.4.2. Période de maturité……………………………….……………………….21 I.4.3.Période d’obsolescence, vieillesse ou usure………...……………………..21 I.5. Quelques termes caractéristiques utilisés en fiabilité……………….…………22 I.6. Méthodes d’analyse utilisées pour modéliser la courbe en fiabilité…..………..22 I.7. Les lois utilisées………………………………………………..…………….…22 I.7.1. Lois discrètes…………………………………………….………………..22 I.7.2. Lois continues……………………………………………………………..23

II. Étude des paramètres de la loi de Weibull………………………………………23 II.1. Expression de la fonction de fiabilité et la fonction de défaillance…………….23 II.2. Le papier graphique d’Allan Plait…………………………………….………..25 II.3. Étude du paramètre de position�……………………………….………………26

CHAPITRE 5 : ANALYSE ET CONCEPTION DU LOGICIEL……………………….29 I. Caractéristique du système………………………………………………...…….29 II. Étapes de modélisation UML………………………………………...………….30 III. Les différentes vues et types de diagrammes UML……………………………..30

II.1. Les diagrammes de cas d’utilisation (use case)……………………...…………30 II.1.1. La relation d’inclusion……………………………………..……………..31 II.1.2. La relation d’extension………………………………………...…………31 II.1.3. La relation de généralisation/spécialisation…………………..…………..31

II.2. Les diagrammes de classes………………………………………..…………….31 II.2.1. Visibilité des attributs et méthodes………………...……………………..32 II.2.2. Les associations…………………………………….……………………..32 II.2.3. L’agrégation et la composition……………………………………………32

II.3. Les diagrammes de composante…………………………....……………….33 II.4. Les diagrammes de déploiement……………………...…………………….33 II.5. Les diagrammes d’objets……………………………..…………………….33 II.6. Les diagrammes d’activités……………………………....…………………33 II.7. Les diagrammes d’états-transitions…………………………...……………34 II.8. Les diagrammes de séquences……………………………...……………….34 II.9. Les diagrammes de collaboration…………………………….……………..34

IV. Démarche du processus ICONIX……………………………………………….35 IV.1. GUI Prototype……………………………………………...………………….35 IV.2. Modèle de cas d’utilisation…………………………………...………………..35 IV.3. Diagramme de robustesse (robustness diagram)………………………………35

IV.3.1. Objet frontière ( boundary object)…………………………….…………36 IV.3.2. Objet entité (entity object)…………………………....………………….36 IV.3.3. Objet commande (control object)…………..……………………………36

IV.4. Le modèle de domaine (domain model)…………………...…………………36

v

PARTIE III : APPLICATIONS ET RESULTATS

CHAPITRE 6 : DEMARCHES DE CALCUL…………………………….…………….37 I. Présentation du cas…………………………………………………….……….37 II. Calculs paramétriques……………………………………………………………38

II.1. Détermination de la fonction de fiabilité R(t), le taux de défaillance �(t) et le traçage des courbes………………………………………..…………………………39

II.2. Détermination de la moyenne des temps de bon fonctionnement du matériel (MTBF) E(t)………………………………………………..……………………………40

II.3.Fiabilité pour t = MUT ou MTBF………………..……………………………40 III. Interprétation……………………………….……………………………………41

CHAPITRE 7 : RÉALISATION DU LOGICIEL……………………………………….42 I. Capture des besoins……………………………...………………………………42

I.1. Étude préliminaire…………………………………………..…………………42 I.2. GUI prototype……………………………………………….…………………..43 I.3. Modèle de cas d’utilisation……………………………………………………..43

I.3.1. Identification des cas d’utilisation du système fonctionnel……...………..43

I.3.2. Liste des cas d’utilisation………………………………………………….43

I.3.3. Diagrammes des cas d’utilisation…………………………………………44

I.3.4. Identification des cas d’utilisation du système non fonctionnel……...………47 I.4. Diagramme de robustesse……………………………………...………………..48 I.4.1. Diagramme de robustesse pour le cas « Insérer une information »…….....48 I.4.2. Diagramme de robustesse pour le cas « Insérer une interprétation »…..…49 I.5. Diagramme de séquences………………………………………….…………….49 I.5.1. Diagramme de séquence pour le cas « Insérer une information »………...49 I.5.2. Diagramme de séquence pour le cas « Insérer une interprétation »……....50 I.6. Modèle de domaine……………………………………………………………..50 I.7. Diagramme de classe…………………………………….………………………51

II. Conception du système (conception générale)……………..……………………51 II.1. Outil de développement………………………………………………………..52 II.1.1. Langage de programmation……………………………………………….52 II.1.2. Environnement de programmation…………………..……………………52 II.2. Système d’exploitation…………….…………………………………..……….52

III. Réalisation……………………………...……………………….……………….53 III.1. Présentation du prototype réalisé………….…………………………………..53 III.1.1. Interface d’accueil……………………………………………………….53 III.1.2. Interface d’authentification…………………………..………………….54 III.1.3. Interface de traitement des données…………….……………………….54 III.1.4. Interface des résultats et interprétations de l’utilisateur…………………55 III.1.5. Visualisation de l’interprétation à l’interface d’accueil…………………56

vi

LISTE DES FIGURES :

PARTIE I Figure I.1. Système informatique…………………………………………...…………………………2 Figure I.2. Système organisationnel………………………………………………………………….3 Figure I.3. Logo du processus unifié…………………………………………………………………7 Figure I.4. Logo d’UML……………………………………………………..…………………………7 Figure I.5. Schéma de l’environnement de la maintenance…………….………………………..12 Figure I.6. Types de maintenance……………………………..…………………………………….12

PARTIE II Figure II.1. Schéma d’une redondance active des matériels en série……………..……………18 Figure II.2. Schéma d’une redondance active des matériels en parallèle………….………….18 Figure II.3. Schéma d’une redondance passive……………………………….…………………..19 Figure II.4. Schéma d’une redondance majoritaire…………………………..…………………..19 Figure II.5. Courbe en baignoire dans le domaine mécanique……………….…………………20 Figure II.6. Courbe en baignoire dans le domaine électronique…………..……………………21 Figure II.7. Termes caractéristiques utilisés en fiabilité………………...……………………….22 Figure II.8.Allure de la courbe de la fonction de fiabilité…………...………………………….24 Figure II.9.Allure de la courbe du taux de défaillance………………………..………………….24 Figure II.10. Papier fonctionnel d’Allan Plait…………………………………………………….25 Figure II.11.Graphe d’une loi de Weibull pour� =0…………………..………..………………26 Figure II.12.Graphe d’une loi de Weibull pour� >0…………………..………………………..26 Figure II.13. Redressement de la courbe pour� >0………………………….………………….27 Figure II.14. Redressement de la courbe pour� <0……………….…………………………….27 Figure II.15. Courbe d’estimation par calcul de �…………………...………………………….28 Figure II.16. Représentation du diagramme de classe……………………………..…………….31 Figure II.17. Représentation d’une agrégation et une composition…………………………….33 Figure II.18. Représentation du processus ICONIX…………………..………………………….35 Figure II.19. Les objets du diagramme de robustesse……………...……………………………..36

PARTIE III Figure III.1. Courbe des résultats de calcul des paramètres �, � et �……..………………39 Figure III.2. Courbe de la fonction de fiabilité obtenue…………………………….……………39 Figure III.3. Courbe de la fonction du taux de défaillance obtenue……………..……………..40 Figure III.4. Le GUI prototype………………………………………………………...…………….43 Figure III.5. Cas d’utilisation en paquetage « gestion des éléments »………….……………..45 Figure III.6. Cas d’utilisation en paquetage « gestion des informations »……...…………….45 Figure III.7. Cas d’utilisation en paquetage « gestion des données »…………..……………..46 Figure III.8. Diagramme de robustesse pour le cas « Insérer une information »…...……….48 Figure III.9. Diagramme de robustesse pour le cas « Insérer une interprétation……….……49 Figure III.10. Diagramme de séquence pour le cas « Insérer une information »……….……49 Figure III.11. Diagramme de séquence pour le cas « Insérer une interprétation »…….……50 Figure III.12. Modèle de domaine…………………………………………………………………..50

vii

Figure III.13. Diagramme des classes……………………………….……………………………..51 Figure III.14. Interface d’accueil………………………………………..……….…………………53 Figure III.15. Interface d’authentification………………………...……………………………….54 Figure III.16. Interface de traitement des données………………………………………………..54 Figure III.17. Interface graphique du papier de Weibull……………………...…………………55 Figure III.18. Interface des résultats………………………………..………………………………55 Figure III.19. Interface d’interprétation……………………………………………………………56 Figure III.20. Interface de visualisation de l’interprétation……………………..………………56

LISTE DES TABLEAUX : PARTIE II

Tableau II.1. Ordre de grandeur du taux de défaillance…………………………………………20 Tableau II.2. Cardinalité d’une relation…………………………………………………………..32

PARTIE III Tableau III.1. Données du temps de bon fonctionnement d’un roulement……..………………37 Tableau III.2. Valeurs des abscisses et ordonnées des points sur le papier de Weibull……..38

viii

NOTATIONS ET SYMBOLES :

AFNOR : Association Française de NORmalisation BEP : Brevet d’Étude Professionnel BTS : Brevet de Technicien Supérieur CRN :Customer Relationship Management DTS : Diplôme de Technicien Supérieur EDI : Environnement de Développement Intégré ERP : Enterprise Resource Planning GCL : Gestion de la Chaîne Logistique GMAO : Gestion de Maintenance Assistée par Ordinateur GRC : Gestion de la Relation Client GRH : Gestion des Ressources Humaines GUI : Graphic User Interface Interface Graphique Utilisateur HRM : Human Resource Management MDT : Mean Down Time MERISE : Méthode d' Étude et de Réalisation Informatique des Systèmes d' Entreprise MTBF : Mean Time Between Failure ou Moyenne des Temps de Bon Fonctionnement MTTR : Mean Time To Repair MUT : Mean Up Time OMT : Object Modeling Technique OOD : Object Oriented Design OOSE : Object Oriented Software Engineering PDM : Product Data Management PGI :Progiciel de Gestion Intégré RUP : Rational Unified Process SCM : Supply Chain Management SGDT : Système de Gestion de Données Techniques SI : Système d’Information UP : Unified Process UML : Unified Modeling Language XRM : eXtended Relationship Management � : taux de défaillance RRRR : fiabilité FFFF : fonction de défaillance � : Le paramètre de position. � : Le paramètre d’échelle

�: Le paramètre de forme

1

INTRODUCTION

Face à la mutation majeure et incessante des technologies, dans sa complexification et de l’automatisation de production, des concurrences et des courses à la compétitivité, la maintenance devient une des fonctions stratégiques pour l’optimisation industrielle et nécessite une amélioration continuelle.

La plupart des logiciels que nous avons eu l’occasion de connaître ne nous offre que la saisie et l’organisation du stockage des données. Or nous pensons que la manipulation de ces données réelles serait le principal avantage d’un traitement par ordinateur, du fait que celui-ci peut effectuer rapidement et facilement un grand nombre d’opération mathématique.

Ce problème nous amène à l’« ANALYSE, CONCEPTION ET RÉALISATION D’UN OUTIL DE MAINTENANCE AVANCÉE ».

L’objectif est non seulement d’insérer, d’organiser et de stocker l’information recueillie mais surtout d’effectuer tous les calculs de prévision fiabiliste qui sont traités dans nos cours de maintenance. Tout cela contribue à la prise de décision basée sur les éléments scientifiques et réels dans l’activité des personnels de maintenance.

Cet ouvrage présente 3 grandes parties :

� La première partie rappelle le contexte général sur le système d’information et la maintenance industrielle

� La deuxième partie illustre la méthodologie de calcul en fiabilité puis d’analyse et de conception du logiciel

� La dernière partie concerne les applications et résultats des calculs en fiabilité et du logiciel

PARTIE I

CONTEXTE GÉNÉRAL

2

CHAPITRE 1 : GÉNÉRALITÉS SUR LE SYSTÈME D’INFORMATI ON

VI. Définitions et rôles :

I.1. Système d’information :

On appelle système d’information (SI) l’organisation (organigramme, procédures, homme, règles de gestion, etc.) et les outils (applications informatiques, méthodes, règles de calcul, matériels, etc.) permettant aux acteurs d’une entreprise de communiquer, de traiter et de stocker des informations. Il décrit l’ensemble des éléments qui participent à la gestion, au stockage, au traitement, au transport et à la diffusion de l’information au sein d’une organisation ou entreprise.

I.2. Système informatique :

Le système informatique est la partie informatisée du système d’information automatisable (voir Figure I.1.). Autre que la communication entre composante d’une application (ex : fichier de mouvement), il communique directement avec son environnement (utilisateurs, fichiers d’autres systèmes à travers ou non d’un réseau informatique). Il effectue les demandes de traitements issues de l’échange entre lui et son environnement et met en œuvre le pilotage des traitements qu’il donne en gérant les appels aux processus permettant de les réaliser. Il effectue la mémorisation c'est-à-dire la gestion des données par différents modes d’accès et stockage aux niveaux logique et physique.

Figure I.1. Système informatique

3

I.3. Système organisationnel :

C’est un système qui englobe le système de décision, le système d’information, le système opérant et les flux liant ces 3 systèmes ; pour cela :

- Le système de décision décide des actions à conduire sur le système opérant selon les objectifs et les politiques de l’entreprise

- Le système opérant contient toutes les fonctions liées aux l’activités propres de l’entreprise telles que facturer les clients, régler les salariés, gérer les stocks, etc.

Figure I.2. Système organisationnel

I.4. Les rôles du système d’information :

- Fournir les informations légales demandées par l’environnement - Déclencher les décisions programmées - Donner les informations nécessaires aux décideurs dans le but de les aider à la prise de

décision non programmée - Assurer les communications au sein du système organisationnel pour coordonner les

tâches - Diminuer l’incertitude, libérer le choix, mettre en cohérence l’organisation et l’évoluer

par rapport à l’environnement

4

VII. Composition d’un système d’information d’une entreprise :

II.1. Composition classique :

- ERP (Enterprise Resource Planning) en français PGI (Progiciel de Gestion Intégré). Il intègre tous les systèmes informatisés permettant d’aider au travail. Le progiciel est un ensemble complet de programmes accompagné d’une documentation, conçu pour être fourni à différents acteurs du système afin de réaliser des traitements informatiques stables.

- Les systèmes qui sont appelés spécifiques (non standard, développés sur mesure, que l’on ne trouve pas sur le marché, etc.). Ils sont rencontrés davantage dans le domaine de la facturation, de l’aide à la production, ou de fonctions annexes.

Dans les cas les plus fréquents, une entreprise est équipée de plusieurs progiciels distincts en fonction des ses domaines d’activité. Dans cette situation, les progiciels ne sont pas totalement intégrés comme dans un PGI, mais interfacés entre eux et avec des applications spécifiques. En effet, les applications suivantes apparaissent:

- CRN (Customer Relationship Management) ou GRC (Gestion de la Relation Client). Elle englobe touts les activités permettant d’intégrer les clients dans le système d’information de l’entreprise

- XRM (eXtended Relationship Management) ou Gestion de la Relation Tiers, un système dont les processus relationnels constituent le socle le l’organisation de l’information

- SCM (Supply Chain Management) ou GCL (Gestion de la Chaîne Logistique), elle regroupe toutes les fonctions permettant d’intégrer la logistique et les fournisseurs au système d’information de l’entreprise

- HRM (Human Resource Management) ou GRH (Gestion des Ressources Humaines) - PDM (Product Data Management) ou SGDT (Système de Gestion de Données

Techniques). Ce sont les fonctions d’aide au stockage et à la gestion de données techniques, surtout utilisé par les bureaux d’études

II.2. Composition évoluée :

Le domaine du système d’information a certes une composante technologique et informatique. Mais c’est seulement un aspect de ce domaine qui est beaucoup plus vaste. Il s’agit de la conception et du stockage d’information de façon efficace et cohérente pour toutes les tâches d’une entreprise, d’un réseau d’entreprises, d’une administration publique, des relations entre entreprises, citoyens, gouvernements, etc.

5

En complément de système d’information classique, on a une ingénierie de connaissances (Knowledge Management) qui s’articule autour des deux composantes lesquelles pouvant être rencontrées dans chaque domaine d’activité de l’entreprise :

- La gestion de contenu (Content Management), destinée à gérer les données brutes à transformer en connaissances mieux structurées

- La gestion d’accès, autrement dit la gestion des flux et de protocoles d’échange dans le réseau de (télé-) communication internes ou partagés avec les partenaires

II.3. Les autres composantes possibles :

- Base de données de l’entreprise - Infrastructure réseau - Serveurs de données et systèmes de stockage - Serveurs d’application - Applications métiers - Poste de travail informatique - Dispositif de sécurité

VIII. Utilités de la méthodologie dynamique de développement de système :

Actuellement, les méthodes habituelles pour le développement d’applications informatiques ne correspondent plus à notre climat économique :

- La durée de développement est trop longue, en conséquence, l’environnement de l’entreprise subit une large évolution avant même la livraison. Si le système s’accorde aux besoins initiaux, il ne satisfait plus aux besoins actuels.

- Les applications livrées ne répondent pas aux besoins des clients, puisque ces derniers n’ont pas suffisamment participé à l’élaboration de leur outil

- Le développeur d’application informatique a trop peu d’influence sur l’architecture du produit, la consultation entre lui et les analystes et concepteurs est, dans la plupart des cas, rare.

- Lors d’une difficulté de fonctionnement d’un produit, diagnostiquer le problème est pratiquement impossible dans le cas où la personne ne possèderait pas une vue complète de l’outil depuis le système opératoire jusqu’à son application dans l’entreprise. Les contributions de chaque individu à la réalisation du système sont trop fragmentées et l’environnement de fonctionnement trop fragile

Afin de répondre au besoin des clients, la démarche EQUIPAGE est adoptée en respectant les étapes qui sont : la conception/prototypage, l’industrialisation, la généralisation, l’utilisation et le bilan.

6

En plus, le principe fondamental de l’approche dynamique se base sur l’idée que rien n’est construit parfaitement du premier coup, mais en 20% du temps qu’il prendra pour une solution complète, 80% de la solution est réalisable.

D’un côté, le développement rapide d’application doit être considéré comme une approche légitime et sérieuse. La méthode dynamique inclut une description des activités du management de projet nécessaire pour maîtriser l’évolution accélérée d’un système, comme le principe de découpage en phase.

D’autre côté, l’apport efficace du temps et de la part des utilisateurs est un des éléments clés de la méthode dynamique. Les structures des équipes comprennent plusieurs rôles pour les utilisateurs. Les uns s’intègrent dans l’équipe de développement pour effectuer les décisions journalières de manière plus rapide et plus efficace ; les autres assument les rôles de clients externes plus traditionnels.

La méthodologie dynamique de développement montre aussi les conditions de développement idéal avec une « check-list » afin de fournir une assistance à une entreprise dans l’évaluation et la spécification d’un tel environnement. Parmi d’autres aspects traités en détails dans la méthode dynamique se trouvent :

- L’estimation des coûts et des durées - Des paramètres pour évaluer le succès des projets - Des recommandations pour la conduite de la sous-traitance - Enfin la méthodologie offre des conseils pour l’introduction de développement rapide

d’application au sein d’une organisation.

IX. Méthodes d’analyse et de conception des systèmes d’information :

IV.1. La méthode MERISE :

MERISE (Méthode d' Étude et de Réalisation Informatique des Systèmes d' Entreprise) est une des méthodes systémiques d' analyse et de conception de système d' information la plus connue en France. Elle est élaborée en 1978 sous la direction du ministère de l’Industrie français dans le but de choisir des sociétés de conseil en informatique afin de définir une méthode de conception de systèmes d'information.

La méthode MERISE est basée sur la séparation des données et des traitements à effectuer en plusieurs modèles conceptuels et physiques. Le processus est de type séquentiel (développement organisé en phases qui regroupent des étapes, elles mêmes fragmentées en tâches) et les niveaux de découpage coïncident (la fin d’une phase équivaut à la terminaison de ses étapes, qui elles mêmes se terminent avec l’accomplissement des tâches qui les composent).

7

IV.2. LE PROCESSUS UNIFIÉ et UML:

IV.2.1. Définitions :

Le processus unifié (de l’anglais UP ou Unified Process) est un processus de développement logiciel qui regroupe les activités à mener pour transformer les besoins d’un utilisateur en système logiciel. Il définit l’acteur et l’action, le moment et le moyen pour atteindre un objectif précis.

Figure I.3. Logo du processus unifié

UML ou Unified Modeling Language signifie langage de modélisation objet unifié, un outil utilisé pour la représentation du processus unifié et qui permet de modéliser de façon standard les activités de l’entreprise. Elle est basée principalement sur les méthodes objets OOD (Object Oriented Design) de Grady BOOCH, OMT (Object Modeling Technique) de James RUMBAUGH, et OOSE (Object Oriented Software Engineering) d’Ivar JACOBSON.

Figure I.4. Logo d’UML

IV.2.2. Caractéristiques du processus unifié:

- Le processus unifié est à base de composants - Le processus unifié utilise le langage UML - Les découpages ne coïncident pas : les activités (tâches, phases, étapes, …) ont lieu

dans plusieurs dimensions - Le processus est élaboré par des ingénieurs et spécialistes venant des quatre coins du

monde - Le processus unifié est guidé par les cas d’utilisation : le principal but d’un système

logiciel est de satisfaire les besoins des utilisateurs. Il faut alors bien comprendre les désirs et les besoins des futurs clients. Ces clients sont les utilisateurs humains ou les autres systèmes.

- Le processus unifié est centré sur l’architecture : à partir du démarrage du processus l’architecture à mettre en place apparaîtra. L’architecture d’un système logiciel sera décrite par les différentes vues du système obligatoirement à construire.

8

L’architecture logicielle équivaut aux aspects statiques et dynamiques du système. Il émerge des besoins de l’entreprise, tels qu’ils sont exprimés par les utilisateurs et autres intervenants et tels qu’ils sont reflétés par les cas d’utilisation.

- Le processus unifié est itératif et incrémental : une itération signifie la succession des étapes de l’enchaînement d’activités, alors qu’un incrément correspond à une avancée dans les différentes étapes de développement. Le développement d’un produit logiciel destiné à la commercialisation est une vaste entreprise pouvant s’étaler sur plusieurs mois. Il est impossible de tout développer d’un seul coup. On peut découper le travail en plusieurs parties qui sont autant de mini projets. Chacun d’entre eux représentant une itération qui donne lieu à un incrément.

IV.2.3. Méthodes du processus unifié:

La méthode de UP est une méthode générique de développement de logiciel c'est-à-dire qu’il est nécessaire de l’adapter au contexte du projet, de l’équipe, du domaine et/ou de l’organisation. Il existe donc un certain nombre de méthodes issues de UP :

- RUP (Rational Unified Process) : processus défini par Rational Software (principale actrice de UML) de la société américaine d’informatique IBM (International Business Machinnes). C’est l’une des plus célèbres implémentations de la méthode UP permettant de donner un cadre de développement du logiciel, répondant aux exigences fondamentales préconisées par les créateurs d’UML.

- AUP (Agile Unified Process) : c’est une version simplifiée de RUP. Il décrit une méthode simple, facile à comprendre pour des logiciels de gestion d’application en utilisant les concepts de RUP et la technique de développement agile (technique contenant le développement piloté par les tests, Agile Model Driven Development ou AMDD, la gestion du changement agile, et la factorisation de bases de données afin d'améliorer la productivité)

- EUP (Enterprise Unified Process) : une variante élargie de la RUP dans le but de surmonter ses pénuries comme le manque de soutien du système et de la rétraite éventuelle d’un système logiciel. Instanciation intégrant les phases de post-implantation et décrivant le cycle de vie du logiciel

- ICONIX Unified Process : par rapport aux autres, le processus ICONIX fournit la démarche du model de cas d’utilisation vers le code source dans un chemin direct et dans une courte durée.

9

IV.2.4. Utilités d’UML :

Une des compétences attendues de l’ingénieur est de posséder la capacité pour la spécification claire et précise du problème qu’il doit résoudre, indépendamment de sa connaissance approfondie en informatique. D’une part, dans le cas où il serait responsable d’une équipe de développement d’application informatique, il aura à assimiler les spécifications qu’il devra contribué à établir, puis il devra en mener l’analyse et la conception avant de confier le codage au sens exact à des développeurs, ensuite à communiquer avec les clients pour s’assurer que leur besoin soit réellement satisfait. D’autre part, s’il n’est pas informaticien, il aura sans doute à dialoguer avec des équipes de conception afin d’assurer que ses spécifications sont bien inclues.

Pour cela un langage ou une méthode de spécification et de modélisation pour être en relation avec ses fournisseurs, ses collaborateurs et ses clients seront nécessaire pour l’ingénieur. C’est pour cette raison qu’UML est utile, un langage standard que tous les ingénieurs pratiquent dans l’industrie informatique utilisant des langages orientés objets.

V.2.5. Caractéristiques d’UML:

- UML s’appuie sur un métamodèle qui est un modèle de plus haut niveau définissant les éléments (les concepts utilisables) et leur sémantique (leur signification et leur mode d’utilisation). Le métamodèle permet de se placer à un niveau d’abstraction supérieur puisqu’il est étudié pour être générique que le modèle qu’il permet de construire. Il en fait un langage formel possédant les caractéristiques telles qu’un langage sans ambiguïtés et universel, un langage qui peut se servir de support pour tout langage orienté objet, une représentation visuelle permettant aux acteurs d’un même projet de se communiquer.

- UML offre une manière élégante de représenter le système selon les vues complémentaires par ses diagrammes

X. ANALYSE ET CONCEPTION ORIENTÉE OBJET :

V.1. Les paradigmes de la conception orientée objet :

V.1.1. Classe :

Une classe est un type de donnée abstrait supportant l’héritage, l’encapsulation et le polymorphisme pour créer un objet possédant des propriétés qui le caractérisent. Les classes sont les structures de base de tous les langages à objets.

V.1.2. Objet :

Un objet est une instance d’une classe c'est-à-dire la matérialisation concrète d’une classe ; c’est un système intelligent, autonome et possédant des fonctionnements précis, une identité, une adresse, un espace occupé en mémoire de l’ordinateur. Son état est caractérisé par l’ensemble de ses attributs (données membres) et son comportement est définit par sa méthode (fonction membre).

10

V.1.3. Encapsulation :

C’est une façon de définir les services offerts ou accessibles aux utilisateurs de l’objet. Elle définit une interface (vue externe de l’objet) consistant à cacher les détails de l’implémentation de l’objet (utilisation de la notion d’accesseur qui bloque l’accès à ses attributs) dans le but de garantir l’intégrité des données et de faciliter l’évolution d’une application.

V.1.4. Héritage :

L’héritage est, par définition, un mécanisme de transmission des propriétés (attributs et méthodes) d’une classe de base, servie comme modèle, à des classes dérivées dans le but d’améliorer et de spécialiser les méthodes transmises par la classe parente. Il permet aussi d’éviter la duplication et de soutenir la réutilisation. Il peut être descendant (par spécialisation) ou ascendant (par généralisation).

V.1.5. Polymorphisme :

Le polymorphisme est une extension du concept de l’héritage. C’est un comportement d’une méthode qui peut être appliquée à des objets instanciés par des classes différentes. Il permet de généraliser un code.

V.1.6. Agrégation :

L’agrégation est une relation entre deux classes qui permet de posséder des objets par assemblage d’autres objets de base pour l’obtention d’objets plus complexe.

V.2. Définitions :

En général, la mise en œuvre d’un projet informatique suit les étapes suivantes :

- Analyse : c’est de comprendre clairement le problème posé, en étudiant les attentes des utilisateurs, afin d’identifier les objets de gestion ou « objets Métier » qu’il invoquent dans leur activité

- Conception (design) : elle sert à identifier les concepts fondamentaux impliqués dans une solution

- Programmation : il s’agit d’exprimer la solution dans un programme informatique

V.2.1. L’analyse orientée objet :

L’analyse orientée objet est une étape dans laquelle les objets, les structures sont identifiés, les attributs et les méthodes sont définis.

V.2.2. La conception orientée objet :

La conception est définie comme la méthode qui amène vers des architectures logicielles fondées sur les objets que tout système ou sous-système manipulent, plutôt que sur la fonction qu’il est censé réaliser.

11

CHAPITRE 2: PRÉSENTATION DE LA MAINTENANCE INDUSTRIELLE

VIII. Définitions :

La nouvelle norme européenne (NF EN 13306 X 60-319) définit que la maintenance est l’« ensemble de toutes les actions techniques, administratives et de management durant le cycle de vie d’un bien, destinées à le maintenir ou à le rétablir dans un état dans lequel il peut accomplir la fonction requise ». Elle sert d’outil d’aide à la décision au sein d’une entreprise.

La maintenance basée sur la fiabilité consiste à définir une stratégie basée sur les prédictions fiabilistes, permettant non seulement d’estimer l’espérance de vie d’un système mais également de simuler des scénarios possibles afin d’évaluer l’efficacité de son état.

IX. Buts de la maintenance :

- Mise en œuvre des objectifs requis par la direction de production, tels que l’accroissement de la connaissance des matériels, la diminution et la stabilisation des coûts

- Prolongement de la période d’exploitation des équipements - Diminution des temps d’arrêts programmés ou non - Respect de la qualité et délai,…, dont les diverses contraintes environnementales

(perturbations, anomalies, aléas, défaillances,…) sont à prendre en considération.

X. Termes concernés dans la fonction maintenance :

III.1. La maintenabilité :

Selon l’Association Française de NORmalisation (AFNOR), c’est l’aptitude d’un dispositif à être maintenu ou rétabli dans un état dans lequel il puisse accomplir une fonction requise lorsque la maintenance est accomplie dans des conditions d’utilisation données avec des moyens et procédures prescrits (norme AFNOR X-06-010).

III.2. La durabilité :

La durabilité est la durée de fonctionnement potentiel ou durée de vie d’un bien pour une tâche qui lui a été attribuée dans des conditions d’utilisation et de maintenance donnée.

III.3 La disponibilité :

C’est l’aptitude du matériel à être en fonctionnement ou en service. Un matériel disponible est un matériel dont on peut se servir.

12

III.4 La défaillance :

La défaillance est, par définition, l’altération ou cessation de l’aptitude d’un dispositif à accomplir une fonction requise. C’est un passage d’une entité d’un état de fonctionnement normal à un état de fonctionnement anormal ou de panne.

III.5 La fiabilité :

Selon la norme AFNOR X-06-501, c’est l’aptitude d’un dispositif à accomplir une fonction requise dans des conditions d’utilisation données à un instant donné

III.6 La sécurité :

Selon la norme AFNOR X-06-010, c’est l’aptitude d’un dispositif à éviter de faire apparaître des événements critiques ou catastrophiques.

XI. L’environnement de la maintenance :

La maintenance s’intègre dans le concept global de la sûreté de fonctionnement, qui lui-même s’intègre dans l’assurance produit. La fiabilité, la disponibilité, la maintenabilité et la sécurité se trouvent dans le terme de sûreté de fonctionnement.

Figure I.5. Schéma de l’environnement de la maintenance

XII. Types de maintenance:

Figure I.6. Types de maintenance

13

V.1. Maintenance préventive :

D’après la norme AFNOR X60-010, c’est « la maintenance effectuée selon des critères prédéterminés, dans l’intention de réduire la probabilité de défaillance d’un bien ou la dégradation d’un service rendu ». Autrement dit, l’action effectuée avant qu’un équipement soit défaillant avec ou non de la surveillance de l’évolution de ses paramètres critiques.

V.1.1. Maintenance préventive systématique:

D’après la norme NF EN 13306 X 60-319 de juin 2001, c’est la « maintenance préventive exécutée à des intervalles de temps préétablis ou selon un nombre défini d’unités d’usage mais sans contrôle préalable de l’état du bien ».

V.1.2. Maintenance préventive conditionnelle:

Définition extrait de la norme NF EN 13306 X 60-319 : « maintenance préventive basée sur une surveillance du fonctionnement du bien et/ou des paramètres significatifs de ce fonctionnement intégrant les actions qui en découlent ».

V.1.3. Maintenance préventive prévisionnelle :

La norme NF EN 13306 X 60-319 définit ce type comme la « maintenance conditionnelle exécutée en suivant les prévisions extrapolées de l'analyse et de l'évaluation de paramètres significatifs de la dégradation du bien »

V.2 Maintenance corrective :

La norme européenne NF EN 13306 X 60-319 donne la définition suivante : « maintenance exécutée après détection d’un panne et destinée à remettre un bien dans un état dans lequel il peut accomplir une fonction requise ».

V.2.1 Maintenance palliative (dépannage) :

Cette maintenance permet de remettre en bon état de fonctionnement un bien en attendant une action curative. La maintenance palliative est effectuée à court terme et provisoire.

V.2.2 Maintenance curative (réparation) :

La maintenance curative ne tient en compte que la défaillance catalectique c’est à dire ce qui est à la fois soudaine et complète. Elle est à long terme et définitive pour qu’un matériel ou une entité retrouve son état spécifié.

XIII. Les 5 niveaux de maintenance : VI.1. Niveau 1 :

Ce sont les simples réglages autrement dit sans démontage ni ouverture d’un équipement. L’intervention appartient au personnel exploitant du bien et est effectuée sur place.

14

VI.2. Niveau 2 :

La tâche qui est aussi effectuée sur place concerne le technicien possédant une aptitude légale sur les petites opérations de maintenance préventive et celui du dépannage par échange standard.

VI.3. Niveau 3 :

A ce niveau se trouve l’identification et/ou diagnostic de pannes, la maintenance préventive, réparation par échange standard et les réparations mécaniques mineures. La responsabilité appartient au technicien spécialisé et la maintenance de ce niveau s’effectue sur place ou dans un atelier de maintenance.

VI.4. Niveau 4 :

Le lieu de travail sera dans un atelier spécialisé avec outillage général, documentation et banc de mesure. À ce niveau s’effectuent les essentiels travaux de maintenance (corrective ou préventive) privée de la rénovation et de la reconstruction. La tâche concerne l’équipe avec encadrement technique bien spécialisé.

VI.5. Niveau 5 :

Les travaux sont la reconstruction, la rénovation et les réparations importantes. Ils sont confiés à un atelier de maintenance ou à des entreprises extérieures spécialisées dans un lieu de constructeur ou reconstructeur.

XIV. La problématique du sujet :

Les logiciels de maintenance qu’on a vu ne traitent pas les données en tant que telles pour avoir les caractéristiques décrites dans les manuels et livres traités de la maintenance industrielle. Les étudiants franchissent d’énormes difficultés avant d’acquérir les connaissances exhaustives sur la matière de maintenance. Ils se demandent la raison sur le temps consacré durant l’année scolaire à approfondir théoriquement ce domaine. Il est nécessaire d’affirmer que les industriels disposent de progiciels plus ou moins performants de type ERP ou GMAO (Gestion de Maintenance Assistée par Ordinateur) pour les accompagner dans l’organisation de leur plan de maintenance. L’avantage de ces progiciels est de pouvoir intégrer les informations propres à l’entreprise. Il faut toutefois noter que les résultats délivrés sont uniquement des informations statistiques. Ils ne donnent pas directement les actions à réaliser. Il est alors nécessaire à l’entreprise de disposer d’un outil qui puisse interpréter les résultats afin de prendre des décisions pertinentes.

PARTIE II

MÉTHODOLOGIE

15

CHAPITRE 3 : LES ACTIVITÉS DE L’HOMME DE MAINTENANC E

Il est important de donner une précision à propos des activités de l’homme de maintenance et de l’agent de production parce qu’ils sont parfois en confusion. Cette étape nous permet surtout de spécifier qui fait quoi pour l’application à concevoir.

III. Les métiers de la maintenance industrielle :

Dans le cas habituel, ces métiers sont classés sous forme hiérarchique :

I.1. Le responsable de maintenance :

Il garantit la rentabilité de l’activité par ce qu’il possède une supériorité hiérarchique par rapport aux autres et veille à son amélioration (ce qui peut conduire à externaliser quelques tâches) ; il gère le côté technique et financier sur la maintenance. Il est titulaire d’un diplôme d’ingénieur (principalement mécanique, électrique ou électronique) ou un diplôme DTS (Diplôme de Technicien Supérieur), BTS (Brevet de Technicien Supérieur), Licence professionnelle ou équivalent.

Le responsable de maintenance travaille dans les entreprises de production industrielle (mécanique, métallurgie, électronique, chimie, sidérurgie, chimie, pétrole, automobile) ou dans les sociétés prestataires de maintenance, dans les services après-vente et de maintenance des fabricants des outils de production. Il doit posséder une expérience importante des technologies manipulées dans la production de l’entreprise.

I.2. L’agent de maîtrise de maintenance :

L’agent dirige les agents de maintenance et une équipe de techniciens dans un cadre économique défini de coûts et de délais. Le lieu de travail est similaire à celui du responsable de maintenance. La tâche appartient à un agent de maintenance doté d’une grande expérience, promu agent de maîtrise ou un jeune de niveau DTS, BTS, Licence professionnel ou équivalent spécialisé dans le domaine de la maintenance ou plus spécialisé en électricité, électrotechnique ou électronique. Il est aussi inclus mais rarement titulaire des jeunes titulaires des Bac Technologie, Bac Technique ou Professionnel concernant ce domaine. Il est qualifié « chef d’équipe », « chef d’atelier », ou « chef de chantier ».

16

I.3. Le technicien de maintenance :

La tâche du technicien de maintenance est de mettre à la disposition par ses interventions de terrain des solutions techniques dans un cadre économique défini (coût et délais) ou de donner une suggestion pour les améliorations technico-économiques par un travail d’étude. Sa responsabilité diffère de l’agent de maintenance par un niveau de technicité reconnu plus élevé ou car il occupe une fonction d’étude. Le passage du technicien de maintenance à l’agent de maîtrise de maintenance est possible si le technicien possède une expérience suffisante. Le diplôme, expérience exigée et le lieu de travail sont sensiblement identiques à l’agent de maîtrise.

I.4. L’agent de maintenance :

Il a pour rôle d’accomplir des travaux techniques et apporte des résolutions techniques dans un délai défini. Il entretient les composantes ou les systèmes de production, exécute le dépannage rapide et réparation, évite les divers arrêts de fonctionnement. L’agent possède le diplôme de BEP (Brevet d’Étude Professionnel), Bac Technique ou Professionnel ou un opérateur de production ayant plus de dix ans d’expériences. Il travaille dans un même lieu que les précédents.

Notons ici que les diverses fonctions citées peuvent être occupées par un ou plusieurs personnels selon la taille de l’industrie ou de l’organisation.

IV. Les différentes activités des maintenanciers :

II.1. Avant la défaillance :

- Acquérir les données appropriées au procédé. L’acquisition varie selon l’événement, la période ou le lieu (ponctuelle).

- Vérifier et juger si les données préétablies correspondent aux exigences. - Déceler la différence entre le comportement réel du système et celle de la trajectoire

nominale c'est-à-dire le comportement nominal défini par la commande. - Détecter la panne pour la surveillance. Autrement dit, caractériser le fonctionnement

du système normal et anormal (nom prévue, rare, dangereux,…) par la comparaison entre la séquence d’évènements constatée et celle prévue.

- Vérifier ou mesurer si le matériel est apte à assurer ses fonctions, ou son niveau de performance, dans des conditions normales ou accidentelles.

- Exercer la surveillance dans le cadre d’une mission définie. Cette inspection ne se limite pas toujours sur la comparaison avec des données préétablies.

- Faire les divers types de la maintenance préventive, la mesure, la modification, la révision, la surveillance, le test et la visite.

- Prouver le caractère bénéficiaire de ses occupations (amélioration de la disponibilité des matériels de production, amélioration des performances de son service, meilleurs résultats que la concurrence potentielle)

17

II.2. Après la défaillance :

- Faire en sorte que la production continue en présence de défaillance (mode dégradé). C’est une fonction de compensation ou de recouvrement.

- Diagnostiquer la défaillance ou la panne. - Faire les différents types de la maintenance corrective et maintenance mixte ainsi que

la reconfiguration, le recouvrement, le rétablissement. - Vérifier si le composant ou le système est encore apte à accomplir la fonction requise.

D’une part, les maintenanciers contribuent à la modification des installations et mise en fonction d’un nouvel appareil. Ils gèrent aussi ses conflits de tâche avec les agents de fabrication industrielle. D’autre part, ils entretiennent aussi des espaces verts (jardin, parc d’une agglomération), des bâtiments et participent à la gestion des déchets, des fluides et des réseaux.

Grâce à l’évolution de la maintenance préventive, le premier ou même le second niveau de la maintenance sont transférées aux opérateurs de production.

II.3. Les différentes activités des agents de fabrication industrielle (agent de production) :

- Préparation et aménagement du poste de travail selon les instructions reçues. - Fixation des outils de production, réglages nécessaires et la surveillance au bon

approvisionnement des machines. - Fabrication des produits en série à l’aide ou non de machines simples. - Contrôle tout au long du processus la qualité de sa production selon le plan de

fabrication au moyen de calibres, d’instruments de mesure et de contrôle. - Tenir compte de la production et des aléas. - Obtention du renseignement sur la fiche de suivi de fabrication. - Propositions des améliorations techniques et organisationnelles dans son secteur. - Garantir la gestion complète de son poste de travail pour de multiples versions d’un

produit. - Traitement des flux dans le but d’atteindre les objectifs qualitatifs et quantitatifs de

production. - Transmission d’alertes auprès de l’animateur lorsqu’un dysfonctionnement apparaît. - Respect de la norme de sécurité.

18

CHAPITRE 4 : LES CALCULS THEORIQUES DE LA FIABILITÉ

I. Les paramètres de la maintenance industrielle :

I.1. Paramètre Fiabilité R(t) :

Mathématiquement, la fiabilité signifie la probabilité de bon fonctionnement d’un système entre l’instant initial (t =0) et l’instant t.

, avec �le taux de défaillance.

I.2. Notion sur les redondances :

Les redondances servent à améliorer la fiabilité et la maintenance d’un système. On distingue 3 grandes catégories :

I.2.1. Redondance active :

- Pour l’association des matériels en série :

On dit que le système est en série d’un point de vue de fiabilité, si la panne de l’un de ses éléments provoque l’arrêt du système.

Figure II.1. Schéma d’une redondance active des matériels en série

- Pour l’association des matériels en parallèles :

On dit qu’un système est en parallèle d’un point de vue fiabilité, si la panne de l’un de ses éléments ne provoque pas l’arrêt du système.

Figure II.2. Schéma d’une redondance active des matériels en parallèle

19

I.2.2. Redondance passive ou « stand by » :

Dans ce cas, seul un élément fonctionne, l’autre ou les autres sont en attente. Le calcul d’un système à redondance « stand by » fait appel à la variable de temps et les éléments à connaître sont :

- Le taux de défaillance �(t) - La loi de fiabilité R(t)

Figure II.3. Schéma d’une redondance passive

I.2.3. Redondance majoritaire :

Cette redondance concerne surtout des signaux de grande sécurité, et, en particulier, les systèmes électroniques.

Pour la redondance majoritaire, le système est opérationnel lorsque la majorité de ses éléments fonctionne.

Figure II.4. Schéma d’une redondance majoritaire

20

I.3. Le taux de défaillance :

Le taux de défaillance �(t) est un estimateur de fiabilité. Il montre une proportion d’éléments survivants à l’instant t, de forme générale (nombre de défaillance/durée d’usage). Son unité est le plus souvent en [pannes/heures] ou en [pannes/km]

On définit aussi le taux de défaillance afin d’avoir la probabilité, par unité de temps ou par unité d’usage (km, cycle, …), de voir le système tombée en panne dans les instants qui suivent. Plus, précisément, la probabilité d’avoir une défaillance du système ou de l’élément entre les instants t et (t+dt) à condition que le système est vécu jusqu’à l’instant t. Il est exprimé en générale en [��].

L’ordre de grandeur des taux de défaillance est :

Tableau II.1. Ordre de grandeur du taux de défaillance

Utilisé en fiabilité, le taux de défaillance devra exclure les défaillances extrinsèques à l’ensemble analysé, comme les pannes provoquées par une faute de conduite (accident, consigne non respectée) ou provoquées à une influence accidentelle du milieu extérieur (inondation, incendie, …).

I.4. La courbe en baignoire (bathtub curve):

La courbe en baignoire est une courbe qui donne l’évolution fréquemment vérifiée du taux de défaillance au cours du temps.

Figure II.5. Courbe en baignoire dans le domaine mécanique

21

Figure II.6. Courbe en baignoire dans le domaine électronique

Elle montre aussi les 3 périodes de vie d’un équipement qui sont :

I.4.1.Période de jeunesse :

Dans cette période de jeunesse (défaillance précoce, mortalité infantile), l’équipement est :

- En état de fonctionnement à l’origine (mise en service) - En période de rodage (pré usure, coup de râpe initiale) - En présélection des composants électroniques : déverminage.

I.4.2. Période de maturité :

Elle est aussi appelée période de vie utile ou période de défaillance aléatoire. Dans un telle période:

- La période de rendement du matériel est optimale - Le taux de défaillance est constant - Les défaillances apparaissent sans dégradations préalables visibles, par des causes

diverses, suivant un processus de poissonnien (défaillance aléatoire) ; poissonnien signifie ce qui suit la loi statistique de « «M.Poisson ».

I.4.3.Période d’obsolescence, vieillesse ou usure :

Un mode de défaillance entraîne une dégradation accélérée, à un taux de défaillance croissant pour un mécanisme. On trouve fréquemment une usure mécanique, de la fatigue, une érosion ou une corrosion.

22

I.5. Quelques termes caractéristiques utilisés en fiabilité :

Figure II.7. Termes caractéristiques utilisés en fiabilité

I.6. Méthodes d’analyse utilisées pour modéliser la courbe en fiabilité :

- Méthodes non paramétrées : méthode de Wayne-Nelson, méthode des rangs corrigés de Jonhson, méthode de Kaplan-Meyer

- Méthodes paramétriques : le maximum de vraisemblance, la méthode SGM (Stochastic Expectative Maximisation)

I.7. Les lois utilisées :

I.7.1. Lois discrètes : - loi binomiale : elle désigne le nombre d’apparition d’un événement dans une

suite de n-épreuves indépendantes dans lequel n est un entier ; la probabilité de la réalisation de cet événement est constante et égale à l’entier p. Un des cas de la variable qui suit la loi binomiale est le nombre de pièces défectueuses dans un lot de taille n extrait d’une production en série.

- loi de Poisson : cette loi, appelée aussi loi des événements rare, exprime la fréquence du nombre d’événements en un temps donné, lorsqu’à tout instant la probabilité d’un événement est la même. Elle décrit le nombre d’apparitions pendant une unité de temps d’un événement dont la réalisation ne dépend pas du nombre de réalisations passées.

23

I.7.2. Lois continues : - loi normale : elle est également appelée loi de Gauss ou loi Laplace-Gauss.

C’est la plus ancienne, la plus importante et la plus connue des lois de probabilité. Elle est employée dans le système électronique ou mécanique. Son point fort est de permettre l’application de nombreux tests statistiques ; des phénomènes d’usure en mécanique sont aussi distribués suivant cette loi.

- loi log-normal : elle nous permet d’estimer la durée de vie d’une pièce exploitée en régime d’usure et de vieillissement.

- loi exponentielle : elle est couramment employée en fiabilité, la plus importante loi de probabilité à densité après la loi normale. On peut utiliser cette loi à la période à taux de défaillance constant selon la courbe en baignoire. Le modèle est particulièrement employé en fiabilité électronique où les appareils convenablement « mis au point » ne sont pas susceptibles d’avoir de pannes infantiles et ne risquent pas encore de phénomène d’usure ou de détérioration.

- loi de Weibull : cette loi est largement utilisée par les fiabilistes et est bien applicable en fiabilité dans le domaine de la mécanique. Son point fort est d’être très souple de pouvoir s’ajuster à différents résultats d’expérimentations.

II. Étude des paramètres de la loi de Weibull :

Ici sera la démarche de conception fiabiliste qui consiste à proposer des modèles qui permettent de prévoir la probabilité de survie. Les modèles sont recalés par rapport à des valeurs expérimentales. Cela a pour objectif de connaître la traçabilité de panne et de recevoir une interprétation qui va aider un personnel à la prise de décision.

II.1. Expression de la fonction de fiabilité et la fonction de défaillance :

La fonction fiabilité et la fonction de défaillance (ou la fonction de répartition) qui lui est complémentaire sont fonction du temps, autrement dit R(t)+F(t) = 1.

On a alors :

Avec � : Le paramètre de position, en unité de temps.

� : Le paramètre d’échelle, en unité de temps.

�: Le paramètre de forme, sans unités.

24

La courbe de la figure II.8 donne l’allure de la fonction de fiabilité pour trois valeurs prises par le paramètre �:

Figure II.8.Allure de la courbe de la fonction de fiabilité

Le taux de défaillance a pour expression :

Si � 1, � (t) est une fonction décroissante du temps (correspond à la période de jeunesse de la courbe en baignoire)

Si � = 1, � (t) est une constante de valeur �

� (valeur correspondante à la période de maturité)

Si � �1, � (t) est une fonction croissante du temps (correspond à la période de vieillesse)

Figure II.9.Allure de la courbe du taux de défaillance

25

II.2. Le papier graphique d’Allan Plait :

On l’appelle aussi papier de Weibull, il sert à lire graphiquement les paramètres d’une loi de Weibull.

Notons qu’il y a quand même une méthode faisant intervenir des équations différentielles mais qui est désormais peu utilisée.

Le papier est gradué de la façon suivante :

abscisse haute : échelle naturelle en t abscisse intermédiaire : échelle logarithmique ( lecture du paramètre �) , c’es la ligne appelée ligne de 63.2 % qui est la valeur de F(t) pour ln [- ln (1 - F(t) )] = 0 abscisse basse : échelle logarithmique (on fait correspondre à chaque valeur de t son logarithme népérien ln t ) ordonnée gauche : on place les valeurs de F(t) en pourcentage en échelle ln [- ln (1 - F(t) )] ordonnée sur l'axe X = -1 ( lecture du paramètre �) : ce sont les valeurs ln [- ln (1 - F(t) )]

Figure II.10. Papier fonctionnel d’Allan Plait

Selon la figure, on tire :

- Le paramètre de position�. Sa valeur est déterminée selon le type et forme que la courbe tend à prendre. Il est nul si les données sont considérées comme linéaire.

- Le paramètre d’échelle �se lit directement à l’intersection de la droite obtenue avec l’axe des abscisses.

- Le paramètre de forme � est le coefficient directeur de la droite précédente, il suffit pour l’obtenir de tracer une droite parallèle à la précédente passant par �=1 et de lire directement le coefficient directeur de cette droite sur l’axe d’équation X = - 1.

26

II.3. Étude du paramètre de position �:

� Cas où �= 0 :

Figure II.11.Graphe d’une loi de Weibull pour� =0

� Cas où � �0 (estimation par itération) :

Ce qui veut dire que les données ne sont pas linéaire. On aura une courbe qui admet une asymptote verticale dont l’intersection avec l’abscisse nous permet d’obtenir une première estimation de �

Figure II.12.Graphe d’une loi de Weibull pour� >0

27

Après l’obtention de �, on redresse la courbe en transformant chaque t en un nouveau temps t’ = t - � jusqu’à ce qu’on atteint la linéarité ; cela signifie qu’on reporte les valeurs afin d’obtenir un objet qui se rapproche d’une droite. En cas d’échec, on recommence l’opération laquelle doit être répétée au plus trois fois. Lorsqu’on n’a toujours pas une droite, on peut conclure que les données ne suivent pas une loi de Weibull, ou que l’on peut avoir des lois de Weibull à origines différentes, ou mélangées.

Figure II.13. Redressement de la courbe pour� >0

� Cas où � 0 :

On obtient dans ce cas une courbe admettant une asymptote horizontale. Une façon d’estimer � est de procéder par essais successifs jusqu’à ce que la courbe soit redressée comme le montre la figure suivante :

Figure II.14. Redressement de la courbe pour� <0

28

� Estimation par calcul de �:

A partir des transformations fonctionnelles du papier graphique et après avoir considéré les points (����,����) ; (��,��) ; (����, ����), le paramètre � a pour expression :

Les points ����, �� et ���� sont déterminés de la manière suivante :

- ���� et ���� sont les valeurs maximum et minimum des données à qui on associe respectivement ���� et ����

- �� est le point milieu (mesuré avec une échelle linéaire) entre ���� et ���� tel que

- �� est la projection horizontale de l’intersection de �� avec la courbe.

La figure ci-après illustre ces étapes :

Figure II.15. Courbe d’estimation par calcul de �

29

CHAPITRE 5 : ANALYSE ET CONCEPTION DU LOGICIEL

V. Caractéristiques du système :

Le système permet :

- Aux agents de production d’enregistrer les évènements apparus lors du travail. - Aux agents de production de signaler le dysfonctionnement de l’outil de production - Aux gestionnaires de stock d’insérer la quantité des pièces de rechange disponible

dans le magasin - Aux gestionnaires de stock d’insérer les renseignements des fournisseurs à effectuer

les commandes en cas de besoin - Aux gestionnaires de stock d’insérer le délai de livraison après commande pour

chaque dispositif - Aux personnels de maintenance de connaître les renseignements sur chaque

responsable pour chaque machine dans le but de contribuer à la réalisation de sa mission et ses objectifs organisationnels

- Aux personnels de maintenance d’écouter les employés et leur besoin - Aux personnels de maintenance d’insérer les données historiques pour chaque

dispositif. - Aux personnels de maintenance de gérer chaque élément d’un système (critique ou

non) indépendamment de sa taille et allant de la partie extérieure jusqu’à la partie la plus profonde

- Aux personnels de maintenance d’insérer, pour chaque élément, les informations techniques venant du constructeur

- Aux personnels de maintenance de lancer la demande de travail - Aux personnels de maintenance de planifier ses interventions - Aux personnels de maintenance d’enregistrer le compte rendu d’intervention - Aux personnels de maintenance d’exprimer le travail à faire - Aux personnels de maintenance d’effectuer les traitements sur les données dans le cas

où celles-ci sont traitables - Aux personnels de maintenance de partager ses interprétations

30

VI. Étapes de modélisation UML: - Compréhension du système complexe à étudier - Représentation du système - Affinement de l’analyse étape par étape - Réalisation d’une démarche canalisée par les besoins des utilisateurs ou clients du

système - Définition de l’architecture de l’application, c’est l’approche « 4+1 » proposée par Ph.

Kruchten qui sont : � la vue des besoins des utilisateurs : elle correspond aux besoins définis par

chaque acteur, répondant à la question QUOI et le QUI . � La vue logique : elle précise le système vue de l’intérieur et montre les

moyens permettant à la satisfaction des besoins des acteurs en répondant à la question COMMENT .

� La vue des processus : vue technique et temporelle permettant la mise en ouvre des notions de tâches concurrentes, stimuli (facteurs agissant sur l’élément pour produire un résultat du système), contrôle, synchronisation,…

� La vue d’implémentation qui définit les dépendances entre les modules. � La vue de déploiement : elle décrit la position géographique et

l’architecture physique de chaque élément du système en répondant à la question OU.

A titre d’information, la question POURQUOI n’est pas définit dans UML.

VII. Les différentes vues et types de diagrammes UML :

UML propose des vues qui sont complémentaires les unes des autres et qui permettent de mettre en évidence différents aspects d’un logiciel à réaliser.

Selon les vues statiques ou structurelles qui représentent le système physiquement, on distingue :

III.1. Les diagrammes de cas d’utilisation (use case) :

Les diagrammes de cas d’utilisation décrivent les besoins des utilisateurs et les objectifs correspondants d’un système. Un cas d’utilisation décrit une séquence d’actions réalisées par le système qui produit un résultat visuel pour un utilisateur ou acteur interagissant avec le système. En général on distingue deux types de description des cas d’utilisation : l’un est une description textuelle de chaque cas et l’autre est le diagramme des cas qui constituent une synthèse de l’ensemble des cas.

31

UML définit trois types de relations standardisées entre cas d’utilisation qui sont :

III.1.1. La relation d’inclusion :

La relation d’inclusion est formalisée par la dépendance « include » ou utilisation des cas. Parfois, il existe des sous-ensembles communs à plusieurs cas d’utilisation pendant la description, il convient alors de factoriser ces fonctionnalités en générant de nouveaux cas d’utilisation qui seront utilisés par les cas d’utilisation qui les avaient en commun. Un cas d’utilisation A utilise un cas d’utilisation B signifie que : une instance de A va engendrer une instance de B et l’exécuter, A dépend de B, B n’existe pas tout seul et A n’existe pas sans B.

III.1.2. La relation d’extension :

La relation d’extension est formalisée par la dépendance « extend » (extension des cas). Elle est utilisée principalement pour séparer le comportement optionnel du comportement obligatoire. Lorsqu’un cas d’utilisation A étend le cas d’utilisation B, cela veut dire qu’une instance de A va engendrer une instance de B et l’exécuter sous certaines conditions, B sait où s’insérer dans A. B connaît A et non l’inverse, c’est à dire que B dépend de A ; B n’existe pas tout seul et A existe sans B.

On peut affirmer que la relation « extend » montre une possibilité d'exécution d'interactions qui augmentent les fonctionnalités du cas étendu, mais de façon optionnelle, non obligatoire ; quant à la relation « include », il suppose une obligation d’exécution des interactions.

III.1.3. La relation de généralisation/spécialisation :

La relation de généralisation, appelée également héritage, entre cas est plus subtile.

Cette relation est à prendre au sens classique de spécialisation, inhérent à l'héritage. Ici, la généralisation peut être vue aussi comme un "polymorphisme" de cas.

III.2. Les diagrammes de classes :

Le diagramme de classes est l’élément central d’UML, ils font chacun d’abstraction des aspects dynamiques et temporels. Ce diagramme est aussi une collection d’éléments de modélisation statiques montrant la structure d’un modèle. Il valorise la structuration des données en identifiant les objets/composants qui forment le programme, leurs attributs, opérations, méthodes et les liens (associations) qui les unissent.

Figure II.16. Représentation du diagramme de classe

32

III.2.1. Visibilité des attributs et méthodes :

Le niveau de visibilité des attributs et méthodes de la classe est représenté graphiquement en faisant précéder le nom de chacun d’eux par un caractère représentant ce niveau :

- le caractère «+ » signifie qu’un attribut ou une méthode est public - le caractère «# » défini un attribut ou méthode protégée - celui de «- » signifie qu’un attribut ou méthode est privée

III.2.2. Les associations :

On appelle une association une relation structurelle qu’on trouve entre les classes. Lorsque les relations sont dites binaires, elles connectent deux classes. On la représente par une ligne entre les classes associées. Les extrémités d’une association s’appellent les rôles. Ils décrivent comment une classe voit une autre classe au travers d’une association et peuvent porter un nom. Chaque rôle peut aussi porter une multiplicité qui indique combien d’objets de la classe considérée (celle qui joue ce rôle) peuvent être liés à une instance de l’autre classe par l’association. La multiplicité est représentée sous la forme d’un couple de cardinalités. La notation est décrite par le tableau suivant :

Tableau II.2. Cardinalité d’une relation

III.2.3. L’agrégation et la composition :

Une agrégation est un type particulier d’association. C’est une association non symétrique dans laquelle une des extrémités joue un rôle prédominant par rapport à l’autre. On effectue une agrégation si une classe fait partie d’une autre classe, si une action sur une classe implique une action sur une autre classe ou si les objets d’une classe sont subordonnés aux objets d’une autre classe. Notons que l’inverse n’est pas toujours vrai ; l’agrégation n’implique pas nécessairement ces critères.

La composition est une agrégation forte (agrégation par valeur) ; c’est un cas particulier d’agrégation dans laquelle la vie des composants est liée à celle de l’agrégat c'est-à-dire que si l’agrégat est détruit ou copié, ses composants le sont aussi. Dans la composition, l’agrégat ne peut être multiple.

33

Figure II.17. Représentation d’une agrégation et une composition

III.3. Les diagrammes de composante :

Les diagrammes de composante montrent l’implémentation physique des modèles de la vue logique avec l’environnement de développement et l’architecture physique et statique d’une application en termes de modules.

III.4. Les diagrammes de déploiement :

Les diagrammes de déploiement correspondent à la vue de déploiement d’une architecture logicielle (vue «4+1 ») et décrivent la répartition des composants sur les matériels et la disposition physique de celles-ci qui composent le système.

III.5. Les diagrammes d’objets :

Ce type de diagramme possède un niveau d’abstraction très haut, ce qui l’inclue dans la phase exploratoire. Les diagrammes sont utilisés pour montrer un contexte ainsi que les objets et ses liens.

La vue dynamique vise à montrer l’évolution ou la dynamique des objets complexes du programme tout au long de leur cycle de vie. Elle est plus algorithmique et orientés « traitement », elle comprend :

III.6. Les diagrammes d’activités :

Les diagrammes d’activités permettent de représenter le comportement d’une méthode ou le déroulement d’un cas d’utilisation. Un diagramme d’activité est une sorte d’organigramme qui correspond à une version simplifiée du diagramme d’états. Il permet de modéliser des activités se déroulant en parallèle les unes des autres, dans le cas où ce parallélisme pourrait poser du problème. En général, les diagrammes d’états à eux seuls ne permettent pas de visualiser les problèmes spécifiques posés par la synchronisation des processus en concurrence, pour assurer la cohérence du comportement et l’absence d’interblocage.

34

III.7. Les diagrammes d’états-transitions :

Les diagrammes d’états indiquent tous les changements d’états d’un seul objet à travers l’ensemble des cas d’utilisation dans lequel il est impliqué. Il existe deux types d’information sur un diagramme d’états : des états (état initial, état final ou les états courants) et des transitions qui est définit comme le passage d’un état à un autre. La syntaxe d’une transition est la suivante :

<NomÉvénement> [ <Contrainte (ou garde)> ]/<NomAction>

III.8. Les diagrammes de séquences :

Les diagrammes de séquences nous permettent de représenter les collaborations (déclenchant des événements) entre acteurs et objets (ou entre objets et objets) en fonction d’un point de vue temporel dans lequel on lit de haut en bas son évolution. Ils regroupent tous les objets impliqués dans un unique cas d’utilisation. L’objet montré dans le diagramme des classes ou un acteur présenté dans le diagramme des cas correspond à chaque colonne du diagramme. La ligne de vie de l’objet décrit la durée de son interaction avec les autres objets du diagramme.

III.9. Les diagrammes de collaboration :

Ils montrent les diverses interactions entre les objets et nous permettent de représenter le contexte d’une itération. Ils sont proches des scénarios ou diagramme de séquences et favorisent moins sur le séquencement chronologique des événements. En numérotant les messages pour conserver l’ordre, ils appuient sur les liens entre objets émetteurs et récepteurs de messages, ainsi que sur des informations supplémentaires comme des conditions d’envoi ou des comportements en boucle. Le diagramme de séquence n’arrive pas à effectuer ces idées à cause de sa linéarité.

35

VIII. Démarche du processus ICONIX :

Le processus ICONIX permet d’atteindre rapidement et efficacement le code en utilisant quelques diagrammes UML et quelques techniques selon la figure suivante :

Figure II.18. Représentation du processus ICONIX

IV.1. GUI Prototype :

Pour inciter l’utilisateur à nous fournir une information efficace, on adopte la démarche du prototypage. Le prototype GUI (Graphic User Interface ou Interface Graphique Utilisateur) montre quelques finalités du projet demandés par le client. Il est à noter que les interfaces prototypes peuvent ne rien avoir avec les interfaces du futur système.

IV.2. Modèle de cas d’utilisation :

Le modèle montre les cas d’utilisation et leurs relations avec les utilisateurs en utilisant le diagramme correspondant.

IV.3. Diagramme de robustesse (robustness diagram) :

Il permet de faciliter et clarifier le passage du diagramme de cas d’utilisation vers le diagramme de séquence. Comme le diagramme de collaboration, il montre les objets participants dans le scénario et les interactions entre eux. C’est un diagramme de classe qui n’est pas exactement le cœur d’UML mais fait partie de la méthode objet de Jacobson ; au lieu d’effectuer le diagramme de classe habituel, il utilise les objets tels que :

36

IV.3.1. Objet frontière ( boundary object) : utilisé par l’acteur pour communiquer avec le système. Les objets frontières ou les interfaces représentent les objets gérant la communication avec l’extérieur du logiciel.

IV.3.2. Objet entité (entity object) : qui contient les objets dans le modèle de domaine. Les objets entités représentent les informations possédant une certaine pérennité dans le système.

IV.3.3. Objet commande (control object) :

On l’appelle aussi contrôleur parce qu’il n’est pas souvent un réel objet mais une « colle » entre « boundary objects » et « entity objects ». Il est un support permettant d’assurer qu’aucune fonctionnalité et comportement du système demandé par le cas d’utilisation n’est oublié.

Figure II.19. Les objets du diagramme de robustesse

IV.4. Le modèle de domaine (domain model) :

Le modèle de domaine forme la fondation de la partie statique du modèle UML au sein du processus ICONIX. En le construisant, on commence à faire une abstraction de la réalité c'est-à-dire à identifier les principaux objets conceptuels qui vont participer dans le système. Il sert une représentation claire de la structure conceptuelle du domaine du problème et peut aussi servir comme un apport essentiel à la mise en œuvre de solution dans un cycle de développement du logiciel.

Vu les caractéristiques que possède le processus ICONIX, on réalise le logiciel selon sa conduite.

PARTIE III

APPLICATIONS ET

RÉSULTATS

37

CHAPITRE 6 : DEMARCHES DE CALCUL

IV. Présentation du cas :

Soit la durée de vie donnée par le constructeur pour un roulement à billes à contact radial 6308ZZ dans la boite de vitesse d’une fraiseuse est de 4300 heures. Ces roulements sont soumis à des charges cycliques et sont donc sollicités en fatigue. Lors du choix du roulement, la question qui se pose est: quelle est la durée de vie réel du roulement? Cependant dans le cas d'une utilisation industrielle, la durée de vie ne peut pas être le seul critère à prendre en compte. La probabilité que le roulement atteigne bien la durée de vie objective est aussi essentielle même si on ne va pas la traiter.

On doit aussi rendre compte que les données expérimentales disponibles pour l’estimation des durées des dispositifs consistent en la connaissance plus ou moins complète des instants de défaillance de chaque unité de l’échantillon servant de référence. Cela veut dire que la détermination de la durée de vie de ce roulement a une influence sur celle de la boîte de vitesse contenant ce roulement.

Les données saisies par les deux techniciens de méthode sur la durée de vie de chaque roulement employé au cours des quelques années sont les suivantes :

Tableau III.1. Données du temps de bon fonctionnement d’un roulement

38

V. Calculs paramétriques :

� Pour traiter la fiabilité dans le domaine mécanique, essayer et vérifier si on a un modèle de Weibull.

� Arranger les valeurs dans l’ordre de la durée de vie croissante et d’estimer la fonction de défaillance cumulée F(t) selon la méthode de Johnson. On choisira le rang médian dont l’expression est :

(6-1) , avec n le nombre de temps de bon fonctionnement et 0 ∑�� � �, ∀i ∈ �* .

� Passer aux calculs qui permettent de placer les valeurs dans le papier de Weibull :

Tableau III.2. Valeurs des abscisses et ordonnées des points sur le papier de Weibull

� Placer ces valeurs sur le papier fonctionnel d’Allan Plait

Figure III.1. Courbe

� On en déduit que la courbe est similaire à une droite, alors

II.1. Détermination de la fonction de fiabilité(t) et le traçage des courbes

Figure III.2.

ces valeurs sur le papier fonctionnel d’Allan Plait

. Courbe des résultats de calcul des paramètres

On en déduit que la courbe est similaire à une droite, alors on a :

II.1. Détermination de la fonction de fiabilité R(t) , le taux de défaillance (t) et le traçage des courbes:

Figure III.2. Courbe de la fonction de fiabilité obtenue

39

ces valeurs sur le papier fonctionnel d’Allan Plait :

R(t) , le taux de défaillance

40

Figure III.3. Courbe de la fonction du taux de défaillance obtenue

Selon la courbe, l’ordre de grandeur des valeurs du taux de défaillance varie de���

à ���!, ce qui correspond exactement au cas du domaine mécanique précédemment cité (voir Tableau II.1).

II.2. Détermination de la moyenne des temps de bon fonctionnement du matériel (MTBF) E(t) :

E(t)= �"(1+�

�) = 4100*"(1.37) (6-4)

D’après la table de la loi Gamma dans l’ANNEXE 1, "(1.3) = 0.897 et "(1.4) = 0.887 et on en déduit par interpolation linéaire que "(1.37) = 0.890

Par suite :

II.3.Fiabilité pour t = MUT ou MTBF :

On a MTTR<MTBF, alors MUT = MTBF

R(t = MTBF) = #�$%&!'

!���(). = 0.48

E(t) = 3649[h]

41

VI. Interprétation :

Comme on n’a pas recours au redressement de la courbe, ce qui signifie qu’on a déjà un modèle de Weibull.

Comme la fiabilité est faible à t = MTBF, le remplacement du matériel est conseillé avant que l’heure du MTBF arrive en cas d’adoption d’un remplacement systématique. Une bonne fiabilité entraîne plus de certitude et ce temps est ainsi prévue pour l’échange.

Si dans la plupart de cas le MTBF obtenu du dispositif s’écarte largement de celui venant du constructeur, il faut envisager un autre fournisseur du matériel.

Même si le constructeur suggère le temps 4300[h] les conditions réelles existantes au cours du travail nous permet d’avoir le résultat plus affiné et rélatif. Les décisions qui seront prises seront alors basées sur les temps de bon fonctionnement venant des deux personnels de maintenance.

Il est possible d’améliorer la fiabilité au bout de 3649 [h] par la mise en fonctionnement de 3 dispositifs en redondance active en parallèle si cela est réalisable, selon l’expression :

R(t = MTBF) = 1- ∏ $� ,%�-� Ri) = 1- (1-0.48)(1-0.48)(1-0.48) = 0.86

42

CHAPITRE 7 : RÉALISATION DU LOGICIEL

IV. Capture des besoins :

Comme le système à introduire doit être opérationnel, évolutif, convivial et offrant les informations nécessaires en temps réel, il est alors crucial que ce système satisfait les exigences de la totalité des utilisateurs. En plus, la collecte d’informations est une tâche très importante au sein du processus unifié, puisque au fur et à mesure de la progression du projet, des nouveaux besoins apparaissent, chaque besoin doit être analysé, conçu, implémenté et enfin testé.

I.1. Étude préliminaire :

L’étude préliminaire sert à faire apparaître les acteurs principaux de notre système et les structures auxquelles ils sont rattachés. Les acteurs prenant part dans le système seront identifiés durant le cycle de vie d’un élément (de sa naissance -formulation- jusqu’au moment où la mort – reforme et/ou cession- a eu lieu).

� Identification des acteurs :

Un acteur est une entité externe qui agit sur le système (opérateur, autre système...).Il

peut consulter ou modifier l'état du système. En réponse à l'action des acteurs, le système

fournit un service qui correspond à son besoin.

Il est à classifier 3 types d’acteur :

- Acteur humain : ce sont les utilisateurs de l’application via son interface graphique)

- Acteur logiciel : ce sont les logiciels disponibles connectant avec le système grâce à

une interface logicielle

- Acteur matériels : ce sont les robots et automates qui exploitent les données du

système qui sont pilotés par ce dernier.

Grâce à ces acteurs, il est possible de délimiter le système et d’obtenir une vue

orientée utilisateur. Pour cette raison, le système d’information proposée se basera sur une

nouvelle distribution des fonctions et sur la création de nouveaux acteurs dans l’intention de

prendre en charge l’ensemble des procédures engendrées par le système.

43

Les principaux acteurs sont : le personnel de maintenance, les agents de production, le

gestionnaire de stock

I.2. GUI prototype :

Figure III.4. Le GUI prototype

I.3. Modèle de cas d’utilisation :

I.3.1. Identification des cas d’utilisation du système fonctionnel :

Les cas d’utilisations sont déterminés par précision et observation, acteur par acteur,

les séquences d’interaction du point de vue de l’utilisateur. Ils se décrivent en termes

d’informations échangées et d’étapes dans la manière d’utiliser le système.

Les éléments de base des cas d’utilisations sont :

- Acteur

- Use case (cas d’utilisation) : c’est un ensemble d’actions effectuées par le système, en

réponse à une action d’un acteur. L’ensemble des uses cases décrit les objectifs du

système.

44

I.3.2. Liste des cas d’utilisation :

- Introduire le code d’accès

- Ajouter un élément

- Insérer une information

- Insérer une donnée

- Traiter les données stockées

- Consulter un élément

- Consulter une information

- Consulter une donnée

- Consulter les résultats du traitement

- Consulter l’interprétation du traitement

- Mettre à jour un élément

- Mettre à jour une information

- Mettre à jour une donnée

- Supprimer un élément

- Supprimer une information

- Supprimer une donnée

- Insérer une interprétation du traitement

Dans notre cas, un élément désigne un atelier, une machine outil ou ses composantes

critiques (moteur, boîte de vitesse, outil de coupe, …), pièce de rechange, etc. Une

information englobe les renseignements concernant un élément sélectionné comme le nom de

l’élément, la société fabricante, le personnel de maintenance responsable, pièce de rechange,

état du matériel, etc. Alors que les données représentent les renseignements historiques

stockés, les activités effectuées et l’état de chaque bien.

I.3.3. Diagrammes des cas d’utilisation :

Le diagramme est la solution pour UML de représenter un modèle conceptuel. Ils

identifient les utilisateurs du système (acteurs) et leur interaction avec le système.

45

Le modèle de cas d’utilisation que nous avons construit est assez complexe et sera

difficile à comprendre en une seule fois à cause de l’ampleur de sa taille. C’est pour cette

raison qu’il est nécessaire d’introduire les cas d’utilisation en paquetage (outil permettant de

regrouper les cas d’utilisations liées les uns des autres de manière à faciliter leur maintenance

ou leur évolution).

� Cas d’utilisation en paquetage « gestion des éléments » :

Figure III.5. Cas d’utilisation en paquetage « gestion des éléments »

� Cas d’utilisation en paquetage « gestion des informations » :

Figure III.6. Cas d’utilisation en paquetage « gestion des informations »

46

� Cas d’utilisation en paquetage « gestion des données » :

Figure III.7. Cas d’utilisation en paquetage « gestion des données »

� Description des cas d’utilisations :

La sécurisation n’est pas une chose à négliger si le système est Multi-Utilisateur. Pour cela, tous les acteurs sont invités à s’identifier avant d’effectuer n’importe quelle opération ; d’où l’utilisation du cas « Authentification » pour chaque paquetage.

Cas d’utilisation en paquetage « gestion des éléments » : seule l’opération « Consulter les éléments » qui étend le cas « Consulter les sous éléments » est accessible à tous les utilisateurs parce que les autres s’attachent directement aux données et informations concernant la maintenance. En détail, la façon de « Supprimer un élément » qui étend les cas « Supprimer le sous élément » rend inaccessible ou supprime directement les informations et les données qui concernent l’élément et ses composantes.

Cas d’utilisation en paquetage « gestion des informations » : les clients peuvent chacun « Consulter une information » ou « Insérer une information ». Cela vise à faire participer chacun pour favoriser le développement du service maintenance lequel est une des fonctions stratégiques de l’entreprise. Cela permet aussi aux autres de rendre plus de considération sur la fonction maintenance et d’encourager la communication interpersonnelle.

47

Cas d’utilisation « gestion des données » : puisque le maintenancier n’est pas toujours présent lors de l’apparition d’un événement sur les machines (panne spontané, état de chaque machine avant, au cours ou après la production,…) et quelques activités sont transférés aux agents de production industrielle (la maintenance niveau 1), on donne à ces agents la permission d’ « Insérer une donnée ». Les opérations telles que « Mettre à jour une donnée », « Traiter les données stockées », « Consulter les résultats du traitement » et « Insérer une interprétation des résultats » sont spécialement effectuées par le personnel de maintenance parce qu’elles exigent des niveaux de connaissances particulières et de savoir-faire dans le domaine de la maintenance.

I.3.4. Identification des cas d’utilisation du système non fonctionnel :

- Les besoins non fonctionnels :

Concernant l’interface utilisateur, le logiciel doit être cohérent du point de vue de l’ergonomie. La qualité de l’ergonomie est un facteur essentiel à cause de l’utilisation intensive qu’on attend de l’application.

En ce qui concerne le développement d’application, l’environnement d’exécution est un ordinateur des utilisateurs sous Windows XP-SP3 et l’environnement de développement est le langage C/C++ dont l’ EDI (Environnement de Développement Intégré) est le DevC++.

- Identification des cas d’utilisation non fonctionnels :

Pour élaborer un modèle de spécification logicielle, il est nécessaire de s’intéresser aux fonctionnalités particulières du système en procédant à une spécification logicielle.

Exploitant : c’est un acteur qui ne tire profit que pour des fonctionnalités techniques du système. Les exploitants du système sont :

� L’utilisateur du système. La plupart des acteurs de la branche fonctionnelle sont des utilisateurs dans la dimension technique.

� L’administrateur du système, qui a pour tâche de déployer, de perfectionner et de dépanner le système.

Cas d’utilisation technique (non fonctionnel) : c’est une suite d’actions produisant une valeur ajoutée opérationnelle ou purement technique. À part les besoins fonctionnels qui sont fondamentaux, notre application doit satisfaire les critères suivants :

� La rapidité de traitement : comme la transaction quotidienne des informations est abondante, il est alors nécessaire que la durée d’exécution et de traitement soit la plus rapide possible.

� La performance : un logiciel doit répondre aux exigences des usagers d’une manière optimale.

48

� La convivialité : les interfaces graphiques doivent être simples, ergonomiques et adaptées à l’utilisateur.

� La souplesse : l’application doit être en mesure de permettre à l’utilisateur d’insérer des informations de taille variable, de type variable (mots, textes, images, vidéo, son, …)

� L’authentification : c’est un mécanisme qui empêche les intrusions externes au système. Les exploitants sont soumis à des règles de sécurité, ils doivent être reconnus par le système avant de se connecter.

� Le système doit être exploitable : pour cette raison, il faut que l’application soit en mesure de générer des traces et des alertes qui faciliteront la maintenance.

� L’intégrité : c’est un mécanisme qui bloque la mise à jour au même moment d’un même élément par deux exploitants différents. Ces utilisateurs peuvent alors travailler simultanément (en parallèle).

I.4. Diagramme de robustesse:

I.4.1. Diagramme de robustesse pour le cas « Insérer une information »:

Figure III.8. Diagramme de robustesse pour le cas « Insérer une information »

49

I.4.2. Diagramme de robustesse pour le cas « Insérer une interprétation »:

Figure III.9. Diagramme de robustesse pour le cas « Insérer une interprétation »

I.5. Diagramme de séquences:

I.5.1. Diagramme de séquence pour le cas « Insérer une information »:

Figure III.10. Diagramme de séquence pour le cas « Insérer une information »

50

I.5.2. Diagramme de séquence pour le cas « Insérer une interprétation »:

Figure III.11. Diagramme de séquence pour le cas « Insérer une interprétation »

I.6. Modèle de domaine:

Figure III.12. Modèle de domaine

51

I.7. Diagramme de classe:

Le diagramme des classes nous est utile car il nous permet de décrire le type des objets ou données du système ainsi que les formes de relation statiques distinctes qui les relient entre eux.

Figure III.13. Diagramme des classes

V. Conception du système (conception générale) :

C’est pendant cette étape de conception du système que doit être choisie une approche de base pour la résolution du problème. Pendant la conception du système, il faut décider de la structure générale et du style à adopter. L’architecture du système indique l’organisation du système en composants appelés sous-systèmes.

Pendant les phases de conception suivantes, l’architecture offre le contexte dans lequel seront prises des décisions plus détaillées. En prenant des décisions de haut niveau qui s’applique au système entier, le concepteur procède à la réalisation d’une partition du problème en sous-systèmes, pour que les travaux suivants puissent être assurés par des nombreux concepteurs qui travaillent séparément sur ces différents sous-systèmes.

52

II.1. Outil de développement :

II.1.1. Langage de programmation :

Le langage « C++ » est choisi pour des raisons suivantes :

- Il manipule les bits, bytes et l’adresse qui font fonctionner l’ordinateur - Il supporte la programmation structurale et orientée objet (notre projet est basée sur la

méthode objet) - Il supporte tous les composants nécessaires du langage structuré tels que les variables

locales et globales, passage par valeur et par référence, valeurs retournées par une fonction et/ou procédure.

- Il supporte le concept de la compilation séparée des modules du code source et le lien de module d’objet indépendant venant du fichier autonome ou du système ou les librairies locales. La compilation séparée permet au programmeur de recompiler seulement la partie de l’application qui a été modifiée et la connecte avec le module existant afin d’implémenter un nouveau programme exécutable.

- Il accorde une interface pour assembler le langage C et C++. Le compilateur accepte le bloc de code qu’on peut écrire en ensemble ou en liaison avec le bloc écrit en C et C++.

- Le langage C et C++ sont disponibles pour chaque système d’exploitation actuel. On écrit à ce langage la majorité du code employé dans UNIX et MS/PC- DOS

- Il est doté en standard d’une riche bibliothèque de classes, comportant la gestion des interfaces graphiques (fenêtre, boîte de dialogue, contrôles, menus, graphisme), la programmation multithreads (multitâches), la gestion des exceptions, les accès au fichiers et au réseau (notamment Internet).

II.1.2. Environnement de programmation :

Un langage de programmation nécessite obligatoirement un environnement dans lequel on désir de développer une application. Le « DevC++ » choisi est un EDI libre, universel, extensible et polyvalent, permettant potentiellement de créer des projets de développement qui met en œuvre le langage de programmation C/C++.

II.2. Système d’exploitation :

Windows est choisi comme système d’exploitation pour la raison suivante :

� Il est le plus connu à manipuler et pre-installé sur les machines vendues � Il possède les meilleurs programmeurs et développeurs d’application du monde � Il est facile de trouver ses logiciels (jeu 3D sont développés sous Windows). � L’interface est accueillante, personnalisable et évolue parallèlement avec les logiciels

commerciaux � Il est vraiment orienté multi-utilisateur � Le démarrage est rapide

53

VI. Réalisation :

L’étape de la réalisation se base sur les précédentes phases, elle donne un aspect réel aux suggestions présentées pendant l’étude de l’existant et une forme concrète à la conception. Afin de présenter le prototype effectué, on recourt à des prises d’écran pour figurer la tâche réalisée ainsi que d’illustrer les grandes et principales fonctionnalités du système. Cela est fait selon l’architecture logique du système (répartition en sous-systèmes et modules).

III.1. Présentation du prototype réalisé :

III.1.1. Interface d’accueil :

Figure III.14. Interface d’accueil

La fenêtre principale comprend 5 parties :

1- Contrôle contenant l’hiérarchisation des éléments 2- Contrôle sur la manipulation des éléments, des informations et des données 3- Espace réservée pour l’affichage des informations concernant l’élément sélectionné 4- Espace réservée pour l’affichage des données concernant l’élément sélectionné 5- Espace réservée pour l’affichage des images concernant l’élément sélectionné

54

III.1.2. Interface d’authentification :

Figure III.15. Interface d’authentification

L’utilisateur introduit son nom, son mot de passe puis sélectionne sa fonction. La fenêtre suivante apparaît si toutes les informations introduites sont correctes.

III.1.3. Interface de traitement des données :

On montre ici les traitements associés aux données numériques reçues. C’est ici qu’on effectue les calculs numériques et les traitements graphiques pour obtenir les résultats correspondants.

Figure III.16. Interface de traitement des données

55

Figure III.17. Interface graphique du papier de Weibull

III.1.4. Interface des résultats et interprétations de l’utilisateur:

Figure III.18. Interface des résultats

56

Figure III.19. Interface d’interprétation

En voyant les résultats, l’ingénieur en maintenance responsable insert son interprétation afin de transmettre l’information à un autre service.

III.1.5. Visualisation de l’interprétation à l’interface d’accueil :

Figure III.20. Interface de visualisation de l’interprétation

Les utilisateurs concernés peuvent maintenant recevoir l’information venant du responsable sur un élément pour les aider à prendre certaines décisions basées sur les données scientifiques et réelles.

Les autres opérations indiquées au contrôle sur la manipulation des éléments, des informations et des données se font de la même manière.

57

CONCLUSION

En guise de conclusion, les applications utilisées par l’entreprise ne donnent pas réellement la possibilité aux utilisateurs d’appliquer des théories importantes acquises durant le cours en fiabilité de la maintenance industrielle. Elles se focalisent sur l’insertion et l’organisation de stockage des données.

Notre étude montre l’organisation du système d’information consistant à cerner les activités des maintenanciers, à évaluer, à traiter informatiquement et à interpréter le résultat des données existantes. Elle permet aussi à fournir les moyens nécessaires pour gérer un dispositif, sans rien fixer ni la taille ni le type d’information auparavant, le plus bas du point de vue arborescente du système et de permettre à d’autre personnel que le maintenancier d’apporter leur part pour le développement de l’activité. Il est possible de réaliser le logiciel qui est basé sur le cours de maintenance grâce à la puissance du C++, un langage de programmation supportant la programmation orientée objet, disponible pour chaque système d’exploitation, portable, multiplateforme, multitâche et dynamique.

Ce mémoire permet aux ingénieurs en maintenance d’effectuer leurs activités en un minimum de temps et d’accéder rapidement aux grandes quantités d’informations enregistrées par divers employés.

Malgré les résultats attendus, l’équation obtenue dépend des valeurs qui restent toujours estimatives. La connaissance et l’obtention des renseignements fiables n’empêchent pas l’apparition imprévisible des défaillances des équipements.

Notre prochain objectif est de posséder un système d’information et de traitement qui peut répartir à une énorme distance.

58

BIBLIOGRAPHIE ET WEBOGRAPHIE

[1] D. Khaled Belmadhi, Technic of maintenance, second edition, 2006-212 p

[2] Doug Rosenberg et Kendall Scott, Applying Use Case Driven Object Modeling with UML : An Annotated e-Commerce Exemple, First Edition June14, 2001, 176 p

[3] John R. HUBBARD, Programmer en C++, EdiScience, 2002-174p

[4] Manel BOUZID et Mohamed Anis BACHTOBJI , conception et réalisation d’un logiciel de facturation pour une polyclinique privée

[5] Olivier Sigaud, Introduction à la modélisation orientée objets avec UML, Edition 2005

[6] RAZAFINIMANANA Heritiana Jean Beauquis , Contribution à la conception d’un logiciel gmao à l’intention du département ennoblissement de la société cotona, 2006-116p

[7] ZIANI Smail et CHEKOR Samir , conception et réalisation d’un système d’information pour la gestion des immobilisations de L’ESI

[8] http://www.revuesim.org/sim

[9] http://experts-univers.com/memoire-fin-etude-industriel.html

[10] http://www.info.univ-angers.fr/~gh/internet/cbd.

[11] http://www.sci.brooklyn.cuny.edu/~kopec/uml/uml-tutorial

[12] http://laurent-piechocki.developpez.com/uml/tutoriel/lp/cours

[13] http://www.agilmodeling.com/artifacts/ClassDiagram

[14] http://www.piloter.org/systeme-information/direction-systeme-information.htm

[15] http://www.revuesim.org/sim

[16] http://www.piloter.org/systeme-information/direction-systeme-information.htm

[17] http://www.afim.asso.fr/normalisation/normes.asp

[18] http://www.industrie.gouv.fr/capital-humain/documentation/metiers-maintenance.pdf

[19] www.afim.asso.fr/emploi/metiers/metiers.asp

[20] http://www.lernf.org/fichiers/041211_155508_Note_Info_RNF_13_09_Maintenance_ et_Normalisation.pdf

i

ANNEXE 1 :

LOI GAMMA ( "):

x "(x) 1.0 1.000 1.1 0.951 1.2 0.918 1.3 0.897 1.4 0.887 1.5 0.886 1.6 0.893 1.7 0.908 1.8 0.931 1.9 0.961 2.0 1.000 2.1 1.046 2.2 1.101 2.3 1.166 2.4 1.242 2.5 1.329 2.6 1.429 2.7 1.544 2.8 1.676 2.9 1.827 3.0 2.000

ii

ANNEXE II

EXEMPLE D’INSERTION D’UNE INFORMATION EN TEXTE D’ UN NOUVEAU ELEMENT :

Le but est d’insérer une information sur une nouvelle machine nommée « Tour parallèle » dans un « Atelier mécanique ».

Nous exprimons cet exemple étape par étape :

� Étape 1 : Sélection de l’ « Atelier mécanique » et un clic sur le bouton « Ajouter » dans le cadre de l’ « Elément »

� Étape 2 : Authentification

L’authentification a pour objectif de garantir si l’utilisateur est bien inclus parmi les personnels ciblés par le système et de connaître si celui-ci peut accéder à l’insertion d’un nouvel élément. Cela se fait par la saisie du nom, sélection de la fonction de l’utilisateur et l’insertion du code d’identification. Cliquer après le bouton « VALIDER »

iii

En cas d’erreur d’identification, la fenêtre suivante apparaît sur l’écran. Si ce n’est pas le cas, la prochaine étape apparaît.

� Étape 3 : Saisie du nom du nouvel élément inséré et sa visualisation du nouvel élément ajouté

� Étape 4 : insertion d’une information :

Il faut sélectionner l’élément qu’on vient de créer avant le clic sur le bouton «Insérer » dans le cadre « Information » et effectuer l’authentification correspondante. Sélectionner après le type du fichier et saisir les informations.

iv

Après saisie, Enregistrer la nouvelle information et fermer la fenêtre avec le menu.

v

� Dernière étape : visualisation de l’information saisie

Cette étape nous assure que l’information est bien insérer dans notre système.

vi