Rapport PFE Data Science de La Maintenance Predictive CHAMI Soufiane

Elaboration d’un outil d’aide à la
décision à base du Machine

Learning pour l’amélioration de
la maintenance prédictive
UNIVERSITE MOHAMMED V AGDAL
ECOLE MOHAMMADIA D’INGENIEURS
Filière : Génie Industriel
Option : Ingénierie des systèmes de production
Mémoire de Projet de Fin d’Etudes
Elaboration d’un outil d’aide à la décision à base du Machine

Learning pour l’amélioration de la maintenance prédictive
Réalisé par :
CHAMI Soufiane
Membres du jury
M. BERRADO Abdelaziz Président
M. ARROUB Marouane Rapporteur
M. EL-HACHEMI Nizar Encadrant EMI
M. BADRI HAMZA Encadrant OCP
M. JBILI Abdenour Encadrant OCP
M. ESSAMSI Rachid Encadrant OCP
Année universitaire : 2016-2017
Figure 1: Distribution de la vitesse
Page i
Table des matières
Table des figures vi
Liste des tableaux viii
Dédicace 1
Remerciement 1
Abstract 1
Résumé 1
Introduction générale 1
0.1 Introduction générale . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1 Contexte général du projet de fin d’études 2

1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Présentation du groupe . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Près d’un siècle d’histoire dans l’industrie . . . . . . . . . . 3
1.1.3 Histoire de la maintenance au groupe OCP . . . . . . . . . . 5
1.1.4 Chiffres clés du groupe OCP de . . . . . . . . . . . . . . . . 5
1.2 Présentation de projet de fin d’études . . . . . . . . . . . . . . . . . 6
1.2.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Définition de la problématique . . . . . . . . . . . . . . . . . 6
1.2.3 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 Méthodologie et démarche de travail . . . . . . . . . . . . . 8
1.2.5 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . 9
1.2.6 Livrable du projet . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.7 Risques de projet . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.8 Facteurs de succès . . . . . . . . . . . . . . . . . . . . . . . 10
2 Business Understanding : Connaissance du métier 12

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Philosophies de la maintenance . . . . . . . . . . . . . . . . . . . . 13
2.3 Courbe P-F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Les techniques de la maintenance prédictive . . . . . . . . . . . . . 17
2.5 Analyse vibratoire . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
iii
TABLE DES MATIÈRES
2.5.1 Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.2 Définition theoriques . . . . . . . . . . . . . . . . . . . . . . 19
2.5.3 Un système d’analyse vibratoire . . . . . . . . . . . . . . . . 22
2.5.4 Les avantages de l’analyse vibratoire : . . . . . . . . . . . . . 22
2.6 Analyse de survie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3 Exploration et Préparation des données 27

3.1 Exploration des données . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.1 Identification des variables . . . . . . . . . . . . . . . . . . . 28
3.1.2 Analyses uni-variante . . . . . . . . . . . . . . . . . . . . . . 30
3.1.3 Analyse bivariante . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.4 Standardisation et recodage des données . . . . . . . . . . . 36
3.2 Introduction à la préparation Préparation des données . . . . . . . 38
3.3 Valeurs manquantes (Missing values) . . . . . . . . . . . . . . . . . 38
3.3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.2 Détection des valeurs manquantes . . . . . . . . . . . . . . . 39
3.3.3 Traitement des valeurs manquantes : . . . . . . . . . . . . . 40
3.4 Valeurs aberrants (Outliers) . . . . . . . . . . . . . . . . . . . . . . 41
3.4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.2 Détection et Traitement des points aberrants . . . . . . . . . 42
3.5 Transformation des variables (Features Engineering) . . . . . . . . . 46
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4 Phase de Modélisation 48
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2 Construction des modèles . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.1 Premier et deuxième itérations . . . . . . . . . . . . . . . . . 49
4.2.2 Troisième itération : Modèle de régression de Cox à risques
proportionnelles . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.3 La fonction coxph : Applications sur R . . . . . . . . . . . . 51
4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5 Restitution des résultats : Data Visualization 54

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2 Technologie utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3 Fonctionnement de l’application web . . . . . . . . . . . . . . . . . 55
5.4 Aperçu sur l’utilisation de l’application . . . . . . . . . . . . . . . . 55
5.4.1 Interface d’accueil . . . . . . . . . . . . . . . . . . . . . . . . 56
5.4.2 Page d’analyses personnalisées de chaque équipement : . . . 58
5.5 Page ”Equipement overvirew” . . . . . . . . . . . . . . . . . . . . . 60
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6 Déploiement et Conclusion 63
Appendices 64
Page iv
TABLE DES MATIÈRES
A Exploration des données 65

.1
Les variations des trois indicateurs vibratoires . . . . . . . . . . . . 65
.2
Fonctions de R (Phase de préparation) . . . . . . . . . . . . . . . . 67
.3
Fonctions exécutées pour la méthode de Tukey . . . . . . . . . . . 67
.4
Rapports de RStudios des des résultats des quartes modèles . . . . 67
.5
Code de l’application Shiny . . . . . . . . . . . . . . . . . . . . . . 69
Bibliographie 79
Page v
Table des figures
1 Distribution de la vitesse . . . . . . . . . . . . . . . . . . . . . . . . i
1.1 Présence industrielle et commerciale mondiale de l’OCP . . . . . . . 3

1.2 Histoire de l’OCP (source* : Rapport annuel du groupe OCP 2013) 4
1.3 Parts d’OCP dans les importations . . . . . . . . . . . . . . . . . . 5
1.4 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Les stratégies de la maintenance . . . . . . . . . . . . . . . . . . . . 14

2.2 Courbe P-F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Diagramme d’Ishikawa, Origines des défauts . . . . . . . . . . . . . 16
2.4 Coûts de récupération d’un composant . . . . . . . . . . . . . . . . 17
2.5 Mouvement de vibration . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Évolution des indicateurs d’état . . . . . . . . . . . . . . . . . . . . 21
2.7 Vibrations des machine tournantes . . . . . . . . . . . . . . . . . . 22
2.8 Illustration des Données censurées . . . . . . . . . . . . . . . . . . . 25
3.1 Charte d’identification des variables . . . . . . . . . . . . . . . . . . 29

3.2 Variation de la vitesse des vibrations au cours du temps . . . . . . . 30
3.3 Distribution de la vitesse . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Variation de l’accélération des vibrations au cours du temps . . . . 32
3.5 Distribution de l’accélération . . . . . . . . . . . . . . . . . . . . . . 32
3.6 Variation de température de la turbine au cours du temps . . . . . 33
3.7 Distribution de la température . . . . . . . . . . . . . . . . . . . . . 34
3.8 Interactions entre les trois variable . . . . . . . . . . . . . . . . . . 35
3.9 BoxPlot de la température . . . . . . . . . . . . . . . . . . . . . . . 42
3.10 Box Plot de la vitesse . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.11 Box Plot de l’accélération . . . . . . . . . . . . . . . . . . . . . . . 44
3.12 Avant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.13 Après . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.14 Avant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.15 Après . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.16 Avant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.17 Après . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1 Interface d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.2 ValueBox, Date la plus proche des pannes prédites . . . . . . . . . . 56
5.3 ValueBox, estimation du nombre des pannes prévues dans une semaine 57
vi
TABLE DES FIGURES
5.4 ValueBox, La certitude de l’occurence de la panne prédite . . . . . . 57

5.5 Vue globale sur la criticité des équipements . . . . . . . . . . . . . 57
5.6 Data STREAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.7 Time Frame Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.8 Choix des indicateurs vibratoires . . . . . . . . . . . . . . . . . . . 59
5.9 Tableau des données capteurs . . . . . . . . . . . . . . . . . . . . . 59
5.10 Page de ”Equipment Overview” . . . . . . . . . . . . . . . . . . . . 60
5.11 Le BOX dans la page qui indique la valeur du MTBF . . . . . . . . 60
5.12 Le temps moyen de réparation BOX . . . . . . . . . . . . . . . . . . 60
5.13 Le BOX qui affiche le compte à rebours pour la prochaine panne . . 61
5.14 Up Time BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.15 Up Time BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
1 Variation de la vitesse 2014-2017 . . . . . . . . . . . . . . . . . . . 65

2 Variation de l’accélération 2014-2017 . . . . . . . . . . . . . . . . . 66
3 Variation de l’accélération 2014-2017 . . . . . . . . . . . . . . . . . 66
Page vii
Liste des tableaux
3.1 Données des historiques des pannes . . . . . . . . . . . . . . . . . . 29

3.2 Données capteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Défaut de normalisation . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4 Exemple du résultat après la normalisation . . . . . . . . . . . . . 36
3.5 Tableau des valeurs manquantes . . . . . . . . . . . . . . . . . . . . 40
3.6 Tableau de la variable TTF . . . . . . . . . . . . . . . . . . . . . . 47
4.1 Résultats des modèles utilisés dans la 2ieme itération . . . . . . . . 50
viii
0.1. INTRODUCTION GÉNÉRALE
0.1 Introduction générale

Collecter des données sur le terrain pour anticiper et prédire les pannes, tel est
le principe de la maintenance prédictive et la problématique de ce projet de fin
d’études. En fait, en donnant aux industriels les moyens de prévoir les aléas plutôt
que de les subir, elle leur permet de programmer les interventions qui éviteront de
couteux arrêts de la production.
Pour des groupes comme l’OCP, la rentabilité d’une chaı̂ne de production est
souvent calculée à la minute près, pour optimiser au maximum les investissements
humains et technologiques.
C’est dans cette perspective que s’inscrit ce projet de fin d’études. Il s’agit
du développement et la mise en place d’une solution Data Science (la science des
données) de la maintenance prédictive dans une plateforme internet industriel des
objets (IIoT, Industrial Internet of Things).
Cette solution consiste à développer des modèles analytiques qui permettront
d’interpréter et de visualiser le fil des données sur l’état de fonctionnement des
machines tournantes afin de prévoir leurs prochaines pannes.
Une telle solution offrira un outil d’aide à la décision aux responsables de la
maintenance et leur permettra de ne faire des interventions que si nécessaire.
Par conséquence, la mise en place de cette solution mènera à une réduction
importante des arrêts non-planifiées des machines, à l’augmentation de leurs temps
de disponibilité, et donc une meilleure performance des lignes de production pour
satisfaire la demande.
Pour la réalisation de projet, on va adopter la démarche CRISP-DS (Cross
Industry Standard Process for Data Mining). C’est une démarche qui a été au
départ développé par IBM dans les années 60 pour réaliser les projets Data Mining.
Elle reste aujourd’hui la seule méthode utilisable efficacement pour tous les projets
Data Science.
Cette démarche est composée en six phases principales :
1. Connaissance du Métier (Business Understanding)
2. Connaissance des Données (Data Understanding)
3. Préparation des Données (Data Preparation)
4. Modélisation (Modeling)
5. Évaluation (Evaluation)
6. Déploiement (Deployment)
Dans un premier temps, le premier chapitre est consacré à la présentation du
cadre global du contexte du projet et à sa note de cadrage. Ensuite, les quatre
chapitres suivants vont couvrir les six phases de la démarche CRISP comme
suit : le second chapitre présente les éléments de métiers et la formulation des
problématiques que ce projet vise à résoudre. Le troisième chapitre, quant à lui,
concernera l’étape de la détermination des données à analyser et leur préparation.
Ensuite, le quatrième chapitre pour la modélisation et l’évaluation des modèles
analytiques. Le cinquième chapitre va entamer la partie de la visualisation des
résultats des modèles sous forme une application Shiny pour passer enfin au
sixième chapitre pour le déploiement de cette solution.
Page 1
Chapitre 1
Contexte général du projet de fin

d’études
L’objectif de ce chapitre est de placer ce projet de fin d’études dans son contexte
global. Tout d’abord, on va commencer par présenter l’organisme d’accueil.
Ensuite, la partie qui suit, quant à lui, sera consacré au cadrage du projet en
présentant son contexte, ses objectifs, ses phases de réalisation, ses livrables, les
facteurs de son succès et les risques auxquels il faut prêter attention.
2
1.1. ORGANISME D’ACCUEIL
1.1 Organisme d’accueil

1.1.1 Présentation du groupe
L’OCP occupe une place particulière dans l’histoire industrielle du Maroc ; le
groupe est le premier exportateur au monde de minerai, leader sur le marché
de l’acide phosphorique et un acteur de poids dans les engrais solides. Cette
performance, l’OCP en puise les racines dans son histoire et dans une expérience
accumulée de 90 ans.
Office Chérifien des Phosphates à sa création, le Groupe OCP depuis1975 a
évolué sur le plan juridique, pour devenir en 2008 une société anonyme dénommée
”OCP SA” dont le siège est à Casablanca. De quelques centaines de personnes à
sa création, pour un chiffre d’affaires de 3 millions de Dollars US, OCP a réalisé
un chiffre d’affaires de 4.9 milliards de Dollars US en 2014 et compte près de 23000
collaborateurs.
Le Groupe a connu une expansion considérable qui lui a permis de consolider
son leadership mondial, il gère aujourd’hui un portefeuille de 160 clients et se
distingue par une forte présence à travers le Maroc et à l’étranger.
Figure 1.1: Présence industrielle et commerciale mondiale de l’OCP
1.1.2 Près d’un siècle d’histoire dans l’industrie

L’Office Chérifien des Phosphates vit le jour lors du démarrage de sa première
activité d’extraction en 1921, avec l’ouverture de la première mine à Boujniba,
dans le gisement de Khouribga, le gisement de phosphate le plus riche du monde.
L’acheminement du phosphate jusqu’au port de Casablanca débuta la même
année, ce qui permit la première exportation de phosphate.
Page 3
Bien qu’ayant limité au départ ses activités à l’extraction et à la

commercialisation du minerai, l’OCP a élargi dès 1965 son domaine d’action
par la construction à Safi du complexe Maroc-Chimie pour la valorisation des
phosphates par la production de l’acide phosphorique et des engrais. L’OCP a
ensuite consolidé cette tendance au début des années 70 par l’élargissement du
complexe industriel en construisant les usines Maroc-Phosphore 1 et 2, ce qui
porta la capacité annuelle de production d’acide phosphorique à près de 1.5
millions de tonnes d’anhydre phosphorique, soit douze fois la capacité installée
à Maroc-Chimie en 1965. L’entreprise devient en 1975 le Groupe OCP.
Figure 1.2: Histoire de l’OCP (source* : Rapport annuel du groupe OCP 2013)
Le leadership du groupe OCP en matière de valorisation des phosphates se

renforçât en 1986 par l’édification d’un nouveau pôle industriel à Jorf Lasfar en y
créant Maroc Phosphore 4 et 5. Des partenariats ont par ailleurs permis au groupe
d’étendre ses activités au-delà des frontières nationales ainsi que de renforcer son
potentiel de valorisation par la production d’acide phosphorique purifié. Le Groupe
OCP devint en 2008 une société anonyme, pilier de l’économie marocaine avec un
chiffre d’affaires qui atteint en 2011 cinq milliards d’euros. [2]
Page 4
1.1.3 Histoire de la maintenance au groupe OCP

1.1.4 Chiffres clés du groupe OCP de
Échelle national
— 20,2% de contribution aux exportations nationales
— 4,3% de contribution au PIB national
Échelle international
— D’après le rapport annuel de l’OCP & IFA 2013, le groupe OCP est le 1er
exportateur mondial de phosphate sous toutes formes
— 28% 28% de part du marché mondial de phosphate sous toutes formes.
— 7,1 Milliards de Dirhams de résultats net
— 46 Milliards de Dirhams de chiffre d’affaires
— 145 Milliards de Dirhams investis dans le programme de transformation
industrielle 2008-2025
Figure 1.3: Parts d’OCP dans les importations
Les réserves de phosphate :

les plus grandes réserves de phosphates su monde
1. Mines
(a) Roche phosphatée
i. Production de 24,4 Mt
ii. Capacité d’extraction 32,2 Mt
Page 5
1.2. PRÉSENTATION DE PROJET DE FIN D’ÉTUDES
2. Transformations
(a) Acide Phosphorique
ii. Capacité d’extraction de 4,7 Mt
(b) Engrais phosphatés :
ii. Capacité d’extraction de 7,4 Mt
3. Exportations
(a) Roche phosphatée = 8,6 Mt (part de marché de 33%)
(b) Acide Phosphorique = 2 Mt (équivalent de 47% de part de marché)
(c) Engrais phosphatés= 4,3 Mt (part de marché de 19
1.2 Présentation de projet de fin d’études

L’objectif de cette partie est de définir et expliquer clairement les différents
éléments de cadrage du projet.
1.2.1 Contexte
Étant donné qu’il y a plus de 1000 équipements qui sont répartis sur la
superficie du complexe industriel du MAROC CHIMIE qui vaut de plus 500 000
m2 , la mission de la gestion et le monitoring des équipements et l’assurance de
leur disponibilité tout en évitant des pannes imprévues devient plus en plus une
tache chalengeuse, parfois, difficile pour l’équipe de la maintenance dans l’usine.
Or, L’utilisation de la technologie Internet Of Things a facilité beaucoup le
travail des maintenanciers en leur permettant d’effectuer un contrôle à distance
des équipements critiques, grâce à des capteurs installés à bord. Grâce à une
plateforme online, , il est devenu possible aux responsables de la maintenance
de checker l’état actuel de tous ces équipements à tout moment, depuis leurs
smart-phones ou leurs ordinateurs.
L’impact de cette technologie était très positif sur l’efficience de travail des
maintenanciers dans l’usine. En effet, cela leur a permis de gagner en termes de
réactivité et de rapidité de leurs interventions et aussi en termes de réduction des
coûts qui sont réduites de façon drastiques grâce à cette technologie.
1.2.2 Définition de la problématique

Les fonctionnalités actuelles de la plateforme focalisent sur trois axes
principaux :
1. L’affichage de la variation des indicateurs des vibrations des machines en
temps réel
2. Dressage du spectre des vibrations des machines
Page 6
Alors, Le niveau d’étude et d’exploitation des données collectées dans la

plateforme ne va pas très loin en termes d’analyse et de valorisation, car il se
limite juste à un aspect préliminaire d’analyse (visualisation et affichage de ces
données). Cet aspect n’a pas une grande contribution pour prédire les pannes et
éviter les arrêts soudains des machines, alors que la base des données qu’on dispose
représente une vraie mine d’or qui n’est pas encore exploitée.
En outre, le niveau d’analyse des données est encore très préliminaire et a
besoin de développement pour pouvoir profiter au maximum des données collectées
sur les machines. Or, une autre fonctionnalité est offerte par le prestataire de
la plateforme. Elle consiste à envoyer un flash journalier qui rapporte une liste
des interventions à mener pour les équipements en état critique. En plus, le
département de la maintenance prédictive fait appel à des experts en analyse
vibratoire pour faire des diagnostics de l’état de santé des machines.
Cependant, vu la lenteur et les coûts élevés de ces options, les responsables
de la maintenance ont une ambition d’automatiser la fonctionnalité de l’analyse
des données, la rendre plus rapide et plus intelligente avec le moindre des coûts.
Ce niveau d’analyse constituera un levier de performance et un atout critique
pour la stratégie de développement de la maintenance prédictive au niveau du
département de la maintenance mécanique dans l’usine.
Ce projet de fin d’études a donc pour objectif, d’intégrer la fonctionnalité
d’analyse des données qui permettra non seulement de visualiser l’état actuel des
équipements connectées mais aussi de prédire le maximum des pannes au niveau
de ces machines.
Cette analyse prédictive repose sur des outils de l’intelligence artificielle qui
sont en principe des algorithmes de Machine Learning pour effectuer des études et
analyses normatives. Ces études seront plus capables de dresser un profil affiné du
mode de fonctionnement, de comportement et de dégradation de chacune de ces
machines. Par conséquence, Il sera possible de prédire le moment de la prochaine
panne.
Ce projet va s’intéresser principalement à deux couches d’analyse :
— Première Couche : Prédiction du moment de la prochaine panne.
— deuxième Couche : Prédiction du type de panne prévue (panne électrique,
mécanique, régulation, ...)
1.2.3 Objectifs du projet

L’objectif principal de Ce projet est donc la mise en place d’un outil de la
maintenance prédictive, à base d’intelligence artificielle, afin de prévoir les pannes
équipements avant qu’elles arrivent.
Pour ce faire, ce projet de fin d’études aura deux tâches principales à accomplir :
1. La construction d’un modèles de prédiction qui permet d’anticiper la date du
maximum des pannes des équipements connectés à la plateforme.
2. La construction d’un autre modèle de prédiction qui permet de prévoir les
types des pannes prévues.
Page 7
3. La restitution des résultats de ces analyses dans une application de

visualisation et qui sera intégrée dans la plateforme online IoT déjà existant.
1.2.4 Méthodologie et démarche de travail

Pour la realisation de ce projet, j’ai adopté La méthode CRISP (initialement
connue comme CRISP-DM). C’est une méthode qui a été au départ développé par
IBM dans les années 60 pour réaliser les projets Datamining. Elle reste aujourd’hui
la seule méthode utilisable efficacement pour tous les projets Data Science.
Cette démarche se décompose en 6 phases allant de la compréhension du
problème métier au déploiement et la mise en production.
Phase I : Compréhension du problème métier

Cette phase consiste à bien comprendre les éléments métiers et les
problématiques que ce projet vise à résoudre.
Phase II : Compréhension des données

Cette phase vise à déterminer précisément les données à analyser, à identifier
la qualité des données disponibles et à faire le lien entre les données et leur
signification d’un point de vue métier.
Phase III : Préparation des données

Cette phase regroupe les activités liées à la construction de l’ensemble précis
des données à analyser, faite à partir des données brutes. La préparation des
données inclut ainsi :
— Le classement des données en fonction de critères choisis,
— Le nettoyage des données,
— Leur standardisation et leur recodage pour les rendre compatibles avec les
algorithmes qui seront utilisés par la suite.
Phase IV : Modélisation
C’est la phase de Data Science proprement dite. En fait, la modélisation
comprend le choix, le paramétrage et le test de différents algorithmes ainsi que
leur enchaı̂nement, qui constitue un modèle. Ce processus est :
— Descriptif pour générer de la connaissance, en expliquant pourquoi les
choses se sont passées.
— Prédictif en expliquant ce qu’il va se passer,
— Prescriptif en permettant d’optimiser une situation future.
Page 8
Phase V : Évaluation
L’évaluation vise à vérifier le(s) modèle(s) ou les connaissances obtenues afin
de s’assurer qu’ils répondent aux objectifs formulés au début du processus. Elle
contribue aussi à la décision de déploiement du modèle ou, si besoin est, à son
amélioration. A ce stade, on teste notamment la robustesse et la précision des
modèles obtenus.
Phase VI : Déploiement
Il s’agit de l’étape finale du processus. Elle consiste en une mise en production
pour les utilisateurs finaux des modèles obtenus. Son objectif : mettre la
connaissance obtenue par la modélisation, dans une forme adaptée, et l’intégrer
au processus de prise de décision.
Le déploiement peut ainsi aller, selon les objectifs, de la simple génération
d’un rapport décrivant les connaissances obtenues jusqu’à la mise en place d’une
application, permettant l’utilisation du modèle obtenu, pour la prédiction de
valeurs inconnues d’un élément d’intérêt.
Enfin, il est important de souligner que cette démarche est

principalement itérative et agile. Ceci étant dit, que chaque itération
apporte de la connaissance métier supplémentaire qui permet de mieux
aborder l’itération suivante. C’est d’ailleurs pour cette raison que la
Data Science est plus une démarche globale qu’un simple projet.
1.2.5 Diagramme de Gantt

La Figure 1.4 présente le Diagramme de Gantt de Ce projet.
Figure 1.4: Diagramme de Gantt
1.2.6 Livrable du projet

A l’issu du projet, les livrables devant être mis en place sont :
— un ensemble des codes/scripts écrits avec le langage R qui ont pour fonction
de :
1. Nettoyage et la standardisation des données brutes à analyser.
Page 9
2. Préparation de ces données pour les injecter dans les algorithmes.

3. Paramétrage et l’entrainement des modèles prédictives pour l’ensemble
des équipements (le modèle va traiter chaque équipement un par un de
façon automatique)
— Une application web, dite Shiny Dashboard, qui va restituer les résultats des
analyses.
— un rapport comme feedback de la première itération
1.2.7 Risques de projet

Le grand challenge dans ce projet réside dans la qualité (et aussi la quantité)
des données qui seront exploitées et injectées dans les algorithmes. En d’autres
termes, des données fiables, suffisantes et de bonne qualité est tout ce que ce
projet a besoin pour réussir.
En effet, on dit qu’un ensemble des données est de bonne qualité, quand elles
sont :
— Des données complètes
— Des données disponibles
— Des données mises à jour
— Des données utilisables (erreurs de remplissage de champs, ...)
En plus, on dit que les données sont fiables, quand elles représentent réellement
le mode de fabrication auquel elles se réfèrent. Par conséquence, les risques de ce
projet sont :
1. Au niveau des données :
? Données de mauvaise qualité
? Données erronées
2. Au niveau des modèles :
? Défauts du paramétrage des algorithmes.
? Mauvaises analyses
? Interprétations fausses
1.2.8 Facteurs de succès

Les facteurs de succès de ce projet sont :
1. Bon choix des variables
2. Bon paramétrage des algorithmes
3. Bonne precision des modèles
4. Bonne interprétation des résultats
Page 10
Conclusion
Ce chapitre a été consacré à la présentation du projet dans sa globalité en
commençant par l’organisme d’accueil et sa strategie de la digitalisation, puis un
flash sur quelques nouvelles technologies de l’intelligence artificielle et de l’industrie
4.0 et en finissant par le cadrage du projet.
L’objectif de ce chapitre était d’expliciter l’importance de projet quant à
la vision stratégique de la digitalisation du Groupe OCP et de déclarer la
méthodologie de travail dans ce projet.
Après cette mise en situation, on va commencer la première phase de la
démarche CRISP qui concerne la connaissance du métier de la maintenance et
la structure et le fonctionnement de la plateforme IoT ainsi que ses fonctionnalités
actuelles.
Page 11
Chapitre 2
Business Understanding :
Connaissance du métier
Ce projet porte sur l’amélioration de la maintenance prédictive dans le site

du MAROC CHIMIE. Ainsi, pour pouvoir apporter des améliorations notables,
rien de plus efficient que de savoir des généralités sur les métiers qui sont mis en
jeu dans ce projet ainsi que d’analyser l’existant et de capitaliser sur les retours
d’expérience. Toutefois, et avant d’expliquer le processus du fonctionnement de la
plateforme, il est nécessaire de présenter en global des généralités sur les stratégies
de la maintenance en analysant la courbe de dégradation et ensuite passer à la
présentation de l’analyse vibratoire comme l’un des outils les plus puissants utilisés
en maintenance prédictive.
12
2.1. INTRODUCTION
2.1 Introduction
La connaissance du métier est une phase très importante pour réussir dans
ce projet. En effet, comprendre les détails du métier de la maintenance permet
de savoir quels paramètres et quelles variables à prendre en considération dans la
phase de la préparation des données et de la modélisation.
Encore plus, sans la connaissance de métier, il serait difficile d’interpréter les
résultats de l’analyse et en tirer le maximum des informations. Cela entraine le
risque de rester dans un niveau d’analyse très superficiel des données qu’on collecte.
En outre, cette incompréhension du métier limite la valeur ajoutée de l’outils
Data Analytics et amplifie la difficulté des problématiques qu’on peut rentrer. Or,
grâce au cours qu’on a reçu au génie Industriel,on est déjà familiarisé avec plusieurs
concepts qui sont en relation avec la maintenance prédictive et la problématique
de ce projet. Il s’agit principalement des cours de :
— La maintenance : les méthodes et les stratégies de la maintenance.
— La fiabilité qui traite principalement les modèles mathématiques statiques
qui permettent de modéliser l’évolution de la dégradation d’un équipement.
— Statistical Learning qui donne des outils révolutionnaires d’intelligence
artificielle. Ces outils permettent de générer des modèles mathématiques
dynamiques et plus flexibles pour décrire la courbe de dégradation d’un
équipement. Ces modèles ont la capacité de changer leur forme selon les
conditions de fonctionnement de chaque équipement. Ce dernier point sera
discuté en plus de détails dans le chapitre 4.
Alors, dans ce chapitre on va parler de trois points nécessaires pour la conduite
d’une bonne analyse. Le premier est une discussion des différentes stratégies de
la maintenance en comparant les caractéristiques techniques et financières de
chacune pour déduire enfin l’utilité de la stratégie de la maintenance prédictive.
Le deuxième point concerne une définition de la technique de l’analyse vibratoire
comme l’un des outils de la maintenance prédictive pour suivre la dégradation des
équipements. Ensuite, on finira par le troisième point qui est une présentation de
l’analyse de survie comme un type particulier des analyses qui permet de traiter la
problématique de ce projet. Finalement, La compréhension de ces trois éléments
constitue le nécessaire et le suffisant non seulement pour la compréhension de la
problématique de ce projet mais aussi pour sa réussite.
2.2 Philosophies de la maintenance

Selon la norme NF-X60-010 [11] la maintenance est définie comme étant un
ensemble d’activités destinées à maintenir ou rétablir un bien dans un état ou dans
des conditions données de sûreté de fonctionnement pour accomplir une fonction
requise [12]. Les activités de maintenance permettent une diminution des coûts
de production et l’amélioration de la qualité des produits. Les objectifs que vise la
maintenance consistent à augmenter la disponibilité des équipements, à améliorer
la qualité des produits, à optimiser les coûts de revient et à assurer la sécurité
Page 13
2.2. PHILOSOPHIES DE LA MAINTENANCE
des utilisateurs en évitant les imprévus dangereux. On distingue quatre types de

maintenance (figure 2.1) :
Figure 2.1: Les stratégies de la maintenance
La maintenance corrective : consiste à effectuer une action de maintenance

après la panne (Dépannage). Elle est caractérisée par son caractère aléatoire car on
ne peut pas la prévoir et requiert des ressources humaines et matérielles disponibles
sur place. La maintenance corrective débouche sur deux types d’intervention. Le
premier type est à caractère provisoire, ce qui caractérise la maintenance palliative.
Le deuxième type est définitif, et caractérise la maintenance curative.
maintenance pro-active : La maintenance proactive a pour objectif
d’étendre la durée de vie de la machine par la surveillance de l’état, du
comportement de celle-ci et par la correction de l’origine des causes de défaillance.
La maintenance préventive : est définie, quant à elle, comme une
maintenance effectuée dans l’intention de réduire la probabilité de défaillance
d’un bien ou d’un service rendu. Les activités correspondantes sont déclenchées
selon un échéancier établi à partir d’un nombre prédéterminé d’unités d’usage (
maintenance systématique) ou de critères prédéterminés significatifs de l’état
de dégradation du bien ou du service (maintenance conditionnelle).
1. La maintenance systématique est une maintenance dont la fréquence
est établie selon le temps ou le nombre d’unités d’usage.
2. La maintenance prédictiveest une maintenance préventive subordonnée
à l’analyse de l’évolution surveillée de paramètres significatifs de la
dégradation du bien, permettant de retarder et de planifier les interventions.
Divers outils comme l’analyse de la vibration et l’analyse d’huile, permettent
de détecter les signes d’usure ou de dégradation de l’équipement. L’action ne
se déclenche que lorsque le paramètre de contrôle dépasse un seuil déterminé
empiriquement, fixé par le constructeur ou par les normes de santé et de
sécurité au travail.
Page 14
2.3. COURBE P-F
2.3 Courbe P-F

La courbe P-F (figure 2.2) montre l’évolution de la performance d’un
composant d’un équipement dans le temps et les conséquences d’une dégradation
lorsqu’une ou plusieurs tâches de maintenance préventives ne sont pas exécutées au
bon moment. Les conséquences varient de la dégradation du composant jusqu’au
bris de ce dernier. Les coûts de réparations et de remplacement augmentent avec
la gravité du défaut.
Figure 2.2: Courbe P-F
Cette courbe est définie principalement par trois intervalles caractérisant

l’évolution de la dégradation d’un composant :
1. Intervalle [Début, Point P] : c’est l’intervalle du bon fonctionnement
du composant. Elle est définie par le point de début de la mise en service
de l’équipement jusqu’au point P qui définit l’apparition d’une défaillance
potentielle au niveau de l’équipement. Le fonctionnement de l’équipement
est normal et la mission de fonctionnement de la machine est accomplie
sans problème. Or, l’élément déclencheur qui définit la fin de cet intervalle
(Point P) est souvent une faute physique (interne ou externe) ou due
à l’utilisateur. Cette faute peut avoir plusieurs origines définies par le
digramme d’Ishikawa.(figure 2.3)
2. Intervalle P-F Au point P, la défaillance potentielle apparait au niveau
de la machine. Elle est latente au début car on ne s’en aperçoit pas tout de
suite soit par des appareils soit par l’œil nue.
Page 15
2.3. COURBE P-F
Figure 2.3: Diagramme d’Ishikawa, Origines des défauts
? On appelle le point P : Potential Failure Point , le point de début d’une

défaillance potentielle : plus on s’éloigne du point P, plus les symptômes
de la défaillance sont discernables et détectables plus facilement.
? Le point F s’appelle le point de défaillance fonctionnelle auquel
l’équipement n’est plus capable d’accomplir sa fonction dans les
conditions de fonctionnement donnés.
? Il y a trois niveaux de détection du défaut dans la machine :
— Le premier :(au voisinage du point P) Impossible du défaut
détecter directement ou même par des experts.
— Le deuxième (au milieu) : le défaut est difficilement détectable
de façon directe mais possible de le détecter à travers un diagnostic
fait par un expert avec des appareils de mesure.
— Le troisième (au voisinage du point F) : quand le défaut arrive à
des niveaux très avancés, l’anomalie devient facilement détectable
et l’arrêt de la machine peut arriver à tout moment.
Dans l’intervalle P-F, la machine est récupérable et une intervention
de la maintenance permettra d’éviter son arrêt. Or, les couts de la
récupération de la machine augmentent quand on s’approche du point
F depuis le point P.
3. Intervalle [F, Fin] Arrêt imprévu de la machine à cause d’un défaut
fonctionnel. La récupération de celle-ci nécessite des travaux de la
maintenance. En plus, si la machine est critique pour la production, alors
cela entrainera un arrêt de la production aussi. Par conséquence, les pertes
à cause de cette défaillance sont beaucoup plus importantes.
Il est nécessaire de considérer le temps qui s’écoule entre le point où une défaillance
potentielle se produit et le point où la dégradation se transforme en défaillance
fonctionnelle. Ceci étant dit qu’l est nécessaire de s’approcher du point P afin
Page 16
2.4. LES TECHNIQUES DE LA MAINTENANCE PRÉDICTIVE
de détecter les défaillances potentielles suffisamment en amont (stratégie de la

maintenance prédictive).
Figure 2.4: Coûts de récupération d’un composant
Sur le terrain au site du Maroc CHIMIE, on fait appel à des experts en

maintenance qui ont des appareils qui mesurent les vibrations des machines. Ces
experts font leur analyse pour décider si le machine est endommagée ou pas. Or,
malgré les avantages de cette solution mais elle a aussi des faiblesses.
La première, concernent les couts très élevés de cette solution car le prix à
payer un expert pour un diagnostic d’un équipement est cher sans mentionner le
nombre énorme des équipements à diagnostiquer dans le site. La deuxième, c’est
quand on a parlé des trois niveaux de détections du point de l’apparition d’une
défaillance potentielle, les diagnostics des experts sont encore incapables d’arriver
au premier niveau de détection, c’est à dire de s’approcher plus au voisinage de
point P. Ce qui constitue un manque à gagner qui peut affecter les bénéfices de
l’entreprise.
2.4 Les techniques de la maintenance prédictive

Les techniques de la maintenance prédictive sont nombreuses y compris :
— L’analyse vibratoire : C’est la technique la plus effective pour détecter
les défaillances mécaniques dans les machines tournantes.
Page 17
2.5. ANALYSE VIBRATOIRE
— La mesure acoustique : Cette technique consiste à utiliser les ultrasons

pour évaluer l’état des équipements. Elle permet de détecter rapidement la
présence de défauts mécaniques ou électriques ou encore des problèmes de
fuites.
— La thermographie : Elle consiste à utiliser des capteurs de températures-
généralement des caméras infrarouges- afin de déterminer le profil thermique
des équipements
— Autres techniques : connu en anglais comme : Performance monitoring
(analyse de la performance), Practicle Analysis et Corrosion monitoring.
Le choix de chaque technique dépend des défauts qu’on cherche à detecter. En
plus, ce choix depend aussi du type des activités industrielles de l’usine, le type
des machines et aussi du niveau de qualification de la main d’œuvre.
Il est aussi nécessaire de noter que ces techniques requièrent des instruments et
une expertise très sophistiqués pour être capable de les utiliser pour des diagnostics
et détecter les défaillances au niveau des machines. Généralement, ces instruments
coutent très chers et ont besoin des gens très compétents et de haut niveau afin
de pouvoir faire des analyses.
Les considérations des couts de ces instruments et leur complexité sont la
raison pour laquelle les responsables de la maintenance hésitent d’adopter la
stratégie de la maintenance prédictive. Cependant, si on arrive d’avoir un bon
support du management pour investir dans les équipements et les ressources
humaines nécessaires, la maintenance prédictive peut donner des résultats très
impressionnantes après une durée courte.
2.5 Analyse vibratoire

2.5.1 Généralités
L’analyse vibratoire est utilisée pour déterminer les conditions de
fonctionnement mécaniques et opérationnelles des équipements.
L’avantage de cette technique c’est qu’elle permet de détecter les problèmes
au niveau des équipements avant qu’ils arrivent à des niveaux très graves et qui
peuvent causer des arrêts imprévus. Cela peut être accompli en conduisant une
surveillance continue des équipements à travers des capteurs. Une plateforme
internet industriel des objets IIoT représente la meilleure solution pour
faire un suivi en temp réel.
La surveillance des équipements avec la technique de l’analyse vibratoire
permet détecter plusieurs types des défauts au niveau d’un équipement. Par
exemple :
? Balourd
? Défaut d’alignement
? Défaut de Desserrage et de jeu
? Défaut de Transmission par courroies
Page 18
? Défauts de denture d’engrenages

? Défauts électriques
? Défaut des circuits hydrauliques
L’analyse des données permet de détecter les anomalies au niveau de la machine
ainsi que d’autres modèles analytiques parvenant de la science de l’intelligence
artificielle ont prouvé leur capacité de détecter les défaillances au niveau des
machines suffisamment en amont.
2.5.2 Définition theoriques

Une vibration est un mouvement d’oscillation autour d’une position d’équilibre
stable ou d’une trajectoire moyenne. Un exemple classique d’un mouvement de
vibration est celui d’un corps solide de masse M attaché avec l’une des extrémités
d’un ressort. L’autre extrémité du ressort est fixée avec un bâtis fixe. La masse M
est en immobile dans sa position d’équilibre tant qu’il n’y a pas de force appliquée
sur lui et qui peut causer son mouvement. Dans ce cas il n’y a pas de vibration.
Selon la figure 2.5 En appliquant une force sur la masse M de telle sorte que
celle-ci se déplace à gauche en pressant le ressort. Une fois la masse M est lâchée,
son point d’inertie fait un mouvement d’oscillations (des vas et viens) autour de
sa position d’équilibre.
Figure 2.5: Mouvement de vibration
Page 19
Les indicateurs de l’état d’un équipement en analyse

vibratoire :
La vitesse Quand la masse se déplace, la vitesse de déplacement change. Elle
est nulle aux extrémités de l’intervalle de déplacement de la masse M et maximum
quand celle-ci passe sa position d’équilibre. Ce maximum est appelé le peak
(l’apogée).
La vitesse est mesurée en mm/s. Cette vitesse, on va l’appeler la vitesse-peak.

Or, dans le système international des standards (ISO). On a établi une unité de
mesure de la vitesse-peak des vibrations des machines : la moyenne quadratiques
(root mean square ou RMS).
La moyenne quadratique de la vitesse (vitesse RMS) donne une information
sur l’énergie contenue dans le signal vibratoire alors que la vitesse-peak donne une
idée sur l’intensité des vibrations. Une grande vitesse RMS est plus endommageant
en comparaison avec une même valeur de la vitesse-peak.
L’accélération : Étant définie comme la variation de la vitesse-peak,

l’accélération est en maximum aux extrémités de l’intervalle des vibrations de
la masse M où la vitesse est égale à zero. Quand la vitesse-peak s’approche de
sa valeur maximale à l’une des extrémités, l’accélération tend vers zero. Ensuite,
celle-ci augmente quand on passe à l’autre extrémité. L’unité de mesure est g (9.81
m/s2 ) au lieu de m/s2
Quels indicateurs à choisir ?

La vitesse-peak, la vitesse RMS et l’accélération sont des caractéristiques des
vibration de la machine. Elles sont généralement utilisées pour la mesure de la
gravité et la sévérité des vibrations au niveau de la machine. Ces trois variables
peuvent indiquer si les conditions de fonctionnement de la machine sont bonnes
ou mauvaises. En général, plus les vibrations sont grandes, plus la machine est
susceptibles de tomber en panne.
En pratique, on utilise souvent juste les deux indicateurs : vitesse-RMS et
accélération.
Les standards et limites de la vibration :

Un indicateur d’état est donc le résultat d’une mesure ou d’un calcul
représentant un ou plusieurs aspects de l’état ou de la performance d’un
équipement et dont l’évolution ou la transformation est significative de
l’aggravation ou de l’apparition d’un défaut.
L’indicateur d’état évolue dans le temps et peuvent être suivis selon la figure
2.7. Sur cette figure, on définit 2 seuils :
— Seuil d’alarme : Il nous prévient que l’état de la machine se dégrade et qu’il
va falloir prévenir une intervention de maintenance. On a donc le temps
de programmer l’arrêt de la machine afin de pénaliser le moins possible la
production.
Page 20
— Seuil de danger : il nous prévient de l’imminence d’une panne. Il nous faut

intervenir rapidement.
On peut aussi définir des seuils intermédiaires afin d’être plus précis dans notre
analyse.
Figure 2.6: Évolution des indicateurs d’état
Vibrations des machines tournantes

Les machines tournantes sont des systèmes dans lesquels peut se distinguer :
— Rotor
— Une structure
— Des liaisons
Le rotor tourne autour d’une ligne de rotation par l’intermédiaire de liaisons ayant
pour support la structure de la machine.
La rotation du rotor engendre des forces qui dépendent de l’état des machines.
Ces efforts vont se répercuter sur tous les éléments de la machine et des vibrations
vont être créées si ces efforts rencontrent une mobilité (un jeu ou un élément peu
rigide). Alors, les vibrations dépendent des conditions de fonctionnement.
Le signal vibratoire contient non seulement des informations sur les efforts
engendrés par le fonctionnement de la machine, mais aussi des informations sur
l’état mécaniques des structures.
Par conséquence, un signal vibratoire permet de donner un certain nombre
de défauts de fonctionnement. Cependant, en raison même de la richesse des
renseignements qu’un signal peut apporter, il n’est en général pas directement
exploitable. Il contient trop d’informations qu’l faut traiter et tirer.
Page 21
Figure 2.7: Vibrations des machine tournantes
2.5.3 Un système d’analyse vibratoire

La mesure des vibrations est une technique très utile et très effective pour la
gestion et le monitoring des machines tournantes depuis le moment de sa mise en
service, durant le temps de fonctionnement normal jusqu’à sa défaillance et son
arrêt. Un système d’analyse vibratoire se compose généralement de trois parties
basiques :
1. Un capteur pour la collecte du signal
2. Un logiciel d’analyse des signaux
3. Un serveur pour l’analyse et le stockage des données
Ces trois composantes basiques peuvent être configurée pour former un system
online continu, ou un système d’analyse periodique. Le choix de la configuration
la plus adéquate et la plus pratique dépend de la criticité des équipements et
l’importance.
2.5.4 Les avantages de l’analyse vibratoire :

La technique de l’analyse vibratoire permet d’identifier les mauvais pratiques
de la maintenance ou de la réparation. Cela inclus l’installation ou le remplacement
des paliers inappropriés, un balancement imprécis, ...etc.
L’environ de 80% des problèmes communs des machines tournantes sont les
problèmes de désalignement ou de balourd. L’analyse vibratoire est un outil très
important qui peut réduire ou annuler la fréquence d’occurrence de ces problèmes.
A l’aide des techniques d’analyse des données, on peut identifier aussi les
pratiques inappropriés de la production comme l’utilisation des équipements dans
des conditions qui peuvent endommager la santé des équipements (une haute
températures, cadence ou charge ...).
Enfin, l’analyse vibratoire peut être utilisée dans le cadre d’un programme
pour améliorera la fiabilité des machines d’une manière significative. Cela inclus,
Page 22
un alignement ou balancement plus précis, meilleure qualité d’installations et de

réparation et aussi la réduction de la moyenne des vibrations des équipements
dans l’usine.
Page 23
2.6. ANALYSE DE SURVIE
2.6 Analyse de survie

2.6.1 Introduction
Analyse de survie (Survival Analysis) est généralement définie comme
l’ensembles des méthodes qui analysent les données pour estimer la durée le temps
écoulé jusqu’à la survenue d’un événement précis.
Cet événement peut être un mort d’un patient par un arrêt cardiaque,
l’apparition d’une maladie, une guérison (temps entre le diagnostic et la guérison),
la panne d’une machine (durée de fonctionnement d’une machine, en fiabilité) ou
la survenue d’un sinistre (temps entre deux sinistres, en actuariat) ... etc. Le temp
écoulé est appelé la durée de survie. Elle peut être mesurée par jours, semaines,
minutes, .... etc. Les données qu’on traite dans ce cas sont appelées les données
censurées.
Les modèles classiques des données comme la régression linéaire ne peuvent
pas être utilisés pour ce type des problèmes qui requièrent l’estimation de la durée
de survie. La raison pour ça est, tout d’abord, parce que la durée de survie est
typiquement un nombre positive. Normalement, un modèle de régression linéaire
ne peut pas être le meilleur choix sauf si on arrive à trouver un moyen pour assurer
la positivité des valeurs prédites et éviter cette contrainte. Ensuite, ce modèle ne
peut pas traiter l’aspect censuré des données.
En effet, Les données censurées est un type particulier des données manquantes
dans lesquelles les informations concernant la durée de survie ne sont pas
complètes. La censure des données peut avoir lieu dans deux cas :
1. Avant la fin de l’étude, on n’observe plus l’individu sans qu’il y ait eu de
défaillance.
2. A la fin de l’étude, la défaillance n’a toujours pas été observée.
Sinon, si une défaillance est observée, on qualifie la donnée de complète. La
réponse à la fin de l’étude pour un individu i est notée :
Xiobs = min(Xi , Ci )
Dans la plupart des cas, on parle des données censurées à droite(voir figure 2.8).
Par exemple, supposons qu’on veut faire une étude médicale de l’occurrence
d’événement au niveau du corps de plusieurs personnes pendant 20 semaines. Si
le corps de l’un des patients n’a pas connu l’occurrence de cet évènement pendant
cette période, alors on dit l’information qu’on a collecté sur ce corps pendant
l’étude est censurée à droite, et La durée de survie pour ce patient est considérée
au moins supérieure à la durée totale de l’étude.
Page 24
Figure 2.8: Illustration des Données censurées
Au contraire des modèles de régression. L’analyse de survie a la capacité de

traiter les données parvenant des observations censurées et non-censurées. La
variable de réponse tenue en compte dans l’analyse de survie est composée de
deux parties :
1. - La durée entre deux occurrences successives de l’évènement en question.
(T)
2. - Une indicatrice indique si la donnée i est censurée. (Par exemple, pour
une observation des vibrations d’un équipement, l’indicatrice mentionne si
l’équipement était en marche ou en arrêt)
Voici la définition des fonctions principales utilisées dans l’analyse de survie :
? Fonction de survie

x > 0, S(x) = P(XR> x) (cas discrète)
x
x > 0, S(x) = 1 − 0 f (u)du (cas continue)
? Fonction de survie résiduelle :
S(t + x)
∀x ≥ 0, St (x) = P(X − t > x|x > t) =
S(t)
cette fonction correspond à la probabilité que l’équipement ne soit pas de
nouveau défaillant sachant qu’à l’instant t, il n’a pas encore tombé en panne.
? Taux de défaillance
P(x ≤ X < x + h|X ≥ x) −S 0 (x) f (x)
∀x > 0, α(x) = limh→0 = =
h S(x) S(x)
Appliqué à notre jeu de données, il s’agit de la probabilité que l’équipement soit
en panne entre les instants x et x +h étant donné qu’à l’instant x il soit bien en
marche.
Page 25
Conclusion
Une fois on devient familier avec les basiques du métier de la maintenance
prédictive et la technique de l’analyse vibratoire, on peut maintenance commencer
la première phase de traitement des données afin de pouvoir construire des modèles
prédictives par la suite.
Page 26
Chapitre 3
Exploration et Préparation des

données
Remarque Importante Par souci de simplification, dans ce rapport on va

traiter juste le cas d’un seul équipement pour appliquer les étapes qui restent de la
démarche CRISP. Cet équipement est appelées Ventilateur d’assainissement CD.
EN plus, il est bien de souligner que même si on connait bien que cet équipement
ne peut pas être représentative de plusieurs autres équipements, mais dans un
premier on va généraliser les modèles construites sur l’ensemble des équipements,
et ensuite on va les ajuster un par un si on n’a pas la performance
27
3.1. EXPLORATION DES DONNÉES
3.1 Exploration des données

La phase de l’exploration et la préparation des données et considérée comme
la phase la plus critique du projet, car la qualité des données utilisées détermine
la qualité des prédictions émanant de nos modèles.
Alors, il est raisonnable de consacrer suffisamment de temps et donner plus
d’effort afin de forger des données de qualité. En réalité, les professionnels en
sciences des données autour du monde ont estimé que cette phase prend entre
70% et 80% du temps total du projet, ce qui était le cas pour le notre !
Par la suite, on va commencer par l’exploration des données et en identifiant
tout d’abord les variables dans chaque tableau dans l’ensemble des données
colletées, en passant par les analyser un par un et puis après on va faire une
analyse de leurs interactions. Cela s’agira d’une :
1. Analyse mono-variante
2. Analyse bivariante
3.1.1 Identification des variables

Dans cette partie, on va identifier, d’après les données brutes qu’on a collectées,
quelles sont les variables prédicteurs et celles qui vont être utilisées comme une
variable réponse.
Il convient de souligner que lorsqu’on a dit qu’on veut prédire la prochaine
panne d’une machine en se basant sur les mesures de la télémétrie, cela ne veut
pas dire que ces données brutes soient injectées directement dans les modèles. En
effet, pour des raisons de qualité des données et selon la complexité de l’analyse,
on peut se trouver obligé de créer des variables prédicteurs et la variable réponse
à partir des champs des données dont on dispose. Celle-ci va nous permettre de
savoir le moment de la prochaine panne.
Alors, dans ce niveau, on va juste explorer les données brutes, et présenter un
résumé statistique sur chaque champ du tableau. Les données dont on dispose pour
faire des prédictions des pannes des machines émanent de deux sources principales :
1. Les historiques des pannes : on dispose d’un historique de l’ensemble des
équipements installés au complexe de Maroc chimie pour les cinq dernières
années (de 2012 jusqu’à présent). Voir figure 3.1
2. Les capteurs de vibrations installés sur les machines : ces capteurs
mesurent la variation de trois paramètres : La vitesse des vibrations,
l’accélération des vibrations et la température de la machine. Ces capteurs
comme j’ai dit auparavant prends des mesures plusieurs fois et font l’envoie
des données chaque deux heures au Gateway de la plateforme. Voir tableau
3.2
Donc les champs des données qui vont constituer les inputs de notre processus
d’analyse seront :
— Les trois variables mesurées par les capteurs : Température (Temp), la vitesse
de vibration (mm.s.RMS) et l’accélération des vibrations (G.pk)
Page 28
Table 3.1: Données des historiques des pannes

Équipement Ligne Maintenance Date Durée d’arrêt (h)
Ventilateur AP Régulation 13/08/2014 0,5
Trémies AP3/4 Mécanique 16/04/2014 1,5
Tour lavage AP3/4 Mécanique 15/08/2014 0,5
Séparateur B AP Électrique 06/12/2014 1
Redlers AP Électrique 25/12/2014 0,5
Table 3.2: Données capteurs

Date G.pk mm.s.RMS Temp
2014-02-10 18 :54 :13.077 0.7210234 19.5427055 22.031
2014-02-10 19 :22 :11.603 0.7628375 21.2503998 22.5
2014-02-10 19 :24 :21.434 0.6971685 19.5374467 22.441
2014-02-11 09 :01 :32.131 0.4503745 12.4655028 16.728
2014-02-11 09 :04 :41.619 0.7056432 19.5890269 16.669
— La date de pannes précédentes au niveau de la turbine.

Voici une charte (figure 3.1 ) qui identifie les variables des données à analyser :
Figure 3.1: Charte d’identification des variables
Taille des données

La taille des données mise en jeu :
— Données capteurs : 79721 observations depuis 2014-02-10 jusqu’à
2017-03-01 .
— Historiques des pannes : 18 événements de panne enregistrés
Alors, par la suite on va explorer les données brutes en décrivant la distribution
de chaque variable et en présentant des résumés statistiques de chaque champ des
données.
Page 29
3.1.2 Analyses uni-variante

Au début, on aimerait bien présenter un résumé statistique de l’ensemble des
données capteurs par laquelle on va travailler :
> summary(Data_Sensors)
Min. :2014-02-10 19:22:11 Min. : 0.0000 Min. : 0.03162 Min. : 0.00
1st Qu.:2015-01-02 20:44:48 1st Qu.: 0.2915 1st Qu.: 3.90937 1st Qu.: 32.99
Median :2016-05-23 20:02:53 Median : 0.5119 Median : 7.73622 Median : 43.80
Mean :2015-11-15 13:08:28 Mean : 1.0030 Mean : 10.48072 Mean : 42.27
3rd Qu.:2016-12-12 00:13:58 3rd Qu.: 1.0569 3rd Qu.: 11.78896 3rd Qu.: 50.98
Max. :2017-03-01 08:28:31 Max. :18.5858 Max. :249.78654 Max. :113.00
Vitesse des vibrations : mm.s.RMS

Dans le but d’avoir une première idée sur les variations de la vitesse. On a
tracé le graphique suivant en considérant toutes la période dont on va tenir en
compte pour nos analyses : entre 2014-02-10 20 :00 :00 et 2017-03-01 08 :00 :00.
La figure 3.2 montre que les valeurs que prend la vitesse ne sont pas régulières. On
30
20
5 10
0
nov. 23 15:28 déc. 26 00:13 janv. 23 00:13 févr. 20 02:14
Figure 3.2: Variation de la vitesse des vibrations au cours du temps
remarque, par exemple, qu’il y a des points extrêmes et très loins de la moyenne.
Ceci revient aux deux facteurs principaux :
1. Un défaut au niveau des capteurs : comme toute pièce fabriquée, un capteur
n’est pas parfait et donc il est susceptible qu’il commet des erreurs au
moment du prélèvement des mesures.
Page 30
2. Ruptures des mesures : revient au fait que le capteur ne fonctionne plus ou

bien il est enlevé de la machine.
Vu que la fréquence de ce type des défaillances est très rare au niveau des
capteurs, on peut pratiquement faire confiance aux mesures qu’il rapporte sans
doute.
Pour plus de details sur la vitesse de vibration, on donne la courbe de
distribution. Alors, les caractéristiques de la variable Vitesse sont :
0.00 0.02 0.04 0.06 0.08
Density
0 50 100 150 200 250
N = 6217 Bandwidth = 0.9224
Figure 3.3: Distribution de la vitesse
— La moyenne = 10.48072 mm/s

— Dispersion = 12.89096 mm/s
Accélération des vibrations : G.pk

On donne de même, les graphiques de la variable de l’accélération : G.pk
Pour accélération, on a les caractéristiques statistiques suivantes :
— La moyenne = 1.00 g
— Dispersion = 1.43 g
Donc avec une moyenne de 1.0 avec un écart-type 1.43. On conclut dans un premier
temps que la dispersion de l’accélération est très grande.
Page 31
7
6
5
4
3
2
1
0
nov. 23 15:28 déc. 26 00:13 janv. 23 00:13 févr. 20 02:14
Figure 3.4: Variation de l’accélération des vibrations au cours du temps

1.5
1.0
Density
0.5
0.0
0 5 10 15
N = 6217 Bandwidth = 0.08959
Figure 3.5: Distribution de l’accélération
On calcule le coefficient de l’asymétrie sur R et on trouve :
Page 32
> skewness(Data_Sensors$G.pk)
[1] 4.265274
on conclut que la distribution de l’accélération est aussi asymétrique à droite. On
peut aussi en tirer comme information que la médiane est inférieure de la moyenne.
On souligne aussi l’existence des valeurs aberrantes pour cette variable aussi.
Or, mathématiquement parlant, l’accélération est définie comme la dérivée de la
vitesse des vibrations, donc elles sont des variables dépendantes. C’est pour cette
raison qu’ils peuvent prendre des valeurs aberrantes en même moment.
Température
La figure 3.6 donne un échantillon de la variation de la température au cours
du temps. La variable de la température est caractérisée par une moyenne valant
de 47.27 et un écart-type de 13,1
> mean(Data_Sensors$Temp)
[1] 42.27007
> sd(Data_Sensors$Temp)
[1] 13.10095
70
50
30
10
nov. 23 15:28 déc. 26 00:13 janv. 23 00:13 févr. 20 02:14
Figure 3.6: Variation de température de la turbine au cours du temps
La distribution de la température semble d’être plus symétrique que les deux

variables précédentes. En calculant le coefficient d’asymétrie on trouve qu’il est
négatif mais proche de zéro.
Page 33
> skewness(Data_Sensors$Temp)
[1] -0.3632181
Cela veut dire que la distribution de la température est asymétrique à gauche et

confirme que la médiane est supérieure à la moyenne.
> mean(Data_Sensors$Temp)
[1] 42.27007
> median(Data_Sensors$Temp)
[1] 43.79883
0.030
0.020
Density
0.010
0.000
0 20 40 60 80 100 120
N = 6217 Bandwidth = 2.055
Figure 3.7: Distribution de la température
Page 34
3.1.3 Analyse bivariante

Pour faire une analyse bivariante pour voir d’une manière globale les interactions entre ces
trois variables en termes de dépendance et de corrélation. On trace la figure 3.8
0 50 100 150 200 250
G.pk
*** ***
15
0.78
Density
10
−0.14
5
0
●
mm.s.RMS
***
200
●
Density
x ● 0.043
100
●●
●
● ●●
●●●
●●● ●
● ●●
●
●
●●
●
●●
●
●●
●● ●●●
●●●
● ●
●
●
●●
●●
●●
●
●●
●●
●●
●
●●●● ●●
●
● ●
●
●
●●
●
●●
●
●●●
●●●
●
● ●●
●
●
●●
● ●
●
●
●●
●
●
●●
●
● ●●
●●
●●
●●● ●●
●●
●
●
● ●● ● ●●
●●●
●●
●● ●
●●
● ●●
● ● ●●
●
●
●
●●
●●
●● ●●
●●
●
●
●●
●
●●
●
●●●●
●●
●●●
●
●●
●
●●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●●
●
●
●
●
●
●●
●
●●
●
●
●
●●
●●
●
●
●
●●
●
●
●
●●
●●
●
●
●●
●
●● ●
●
●
●●
●
●
●●
●●
●
●
●
●
●
●
●●●
●
● ●
0
● ●
●●
●
●
● Temp
80
●
●●●
●● ●
●●
●
Density
●
●● ●●●
● ●●
●
●
●●
●
●
●
●● ●
●●
●
●●
●
●
●● ●●
●
●
●
●●
●
●●
●
●
●
●
●●
●
●
●
●
●●
●
●●
●
●●
●
●● ●●● ●
●
●
●●
●
●
●
●●
●
●
●
●
●
●● ●●
●
● ● ●
●
●
●
●●
●
●
●●
●
●
●●
●
●
●
●
●
●
●●
●
●
● ● ●
●
●
●
●●
●
●
●
●
●●
●
●
●
●
●
●●
●
●
●
●●●●
●
●●
●●
●
●● ●
●●●●
● x ●
●
●
●
●
●
●●
●
●
●
●
●●
●
●
●
●●
●
●
●
●
●
●
●●
●
●● ●
●
●
●
●
●●
●
●
●
●
●●
●
●
●
●
●
●
●●
●
●
●
●●●
●●●
●
●●
●●
●
●
●
●●●●
●
●●
●
●
●●
●
●
● ●
● ●
●
●●
●
●
●●
●
● ●●
●●●●
●●●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●●
●
●●● ● ●
● ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●●
●
●
●
●
●
●
●
●
●
●●
●
●
●
●
●
●
●
●
●
●
●
●●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●●●
●● ●
●
●●
● ● ●● ●●● ●
●●
●
●
●●
● ● ●●
40
●
●
●
●
●
●●
●
●
●
●
●●
●●
●
●
●
●
●
●●
●
●
●
●●
●
●
●
●●
●●
●
●●
●
● ●● ● ● ● ● ●●●●
●
● ●
●●
● ● ●
●
●
●
●
●
●●
●
●
●
●
●●
●
●
●
●
●
●●
●
●
●
●●
●●●
●
●●
●●●● ●
●
●●
● ●●●
● ●●
● ●
●
●
●
●
●
●●
●
●
●
●
●
●●
●
●●
●
●
●
●●
●
●●
●●
●
●
●
●
●
●●
●
●
●
●
●●
●
●
●●
●
●
●●
●
●●
● ●
●●
●● ●●
● ●
●●
●
● ● ●●
● ●
●
●● ●
●
●
●
●
●
●
●●
●
●
●
●
●
●●
●
●
●
●
●●
●
●
●
●
●●●
●
●●
●●●
● ●● ● ●●●
●
●●
●●
●
●
●●
●
●
●
●●
●●●
●
●●●
●
●
●
●
●●
●
●
●●
●
●
●
●
●●
●
●●
●
●
●●
●
●
●
●●
●●
●
●●
●
●
●●
●
●●
●●
●
●
●
●●● ●
●
● ●
●●
●●
●●
●●●
●●
●●●
● ● ●
●
● ●
●
●
●●
●
●
●
●●
●
●
●●
●
●
●●
●
●
●●
●● ●●
● ●
●●
●●●
●
●●
●●
●
●●●●
● ●
●●
●●
●
●●●●
●● ●
●
●
●
●
●
●●
●
●
● ●
●●●
●
●
●●
●
●
●
●●
●
●
●●
●
●●
●
●●
●
●
●
●●
●
●
●
●●
●
●
●
●●
●
●
●●
●
●
●
●●
●●
●
●
●
●●
●●
●
●●
●
●
●●
●●●
●
●●●● ●
●
●
●
●
●
●
●●
●
●
●
●
●●
●
●
●
●
●
●●
●
●
●
●●
●
●
●●
●
●●●
●●
●●●
●
●
●●
●
●●●
●
●●
●
●●●
●●
●●
●
●●
●
●●● ● ●
●
●
●
●
●
●
●
●●●●
●●
●●
● ●
●
●●
●
●●
●
●●
●
●
●●
●
●●
●●
●●
●
●
●●
●
●
●●
●
●
●
●
●
●
● ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●●
●
●
●
●
●
●
●
●
●
●
●●●●
●
●
●
●●
● ●
●●●●
●●
●
●●
●
●●
●
●●
●
●
●
●●
●
●● ● ●●
●●
●
●
●●
●
●
●
●
●
●
●
●
●
●
●● ● ●
●
●
●
●
●
●
●
●●
●
●●
●
●
●
●
●
●
●
●
●
●
●
●●
●
●
●
●● ●●
●
●
●
● ●
●
●
● ●
● ●
0
0 5 10 15 0 20 40 60 80 100
Figure 3.8: Interactions entre les trois variable
Cette figure permet de tirer deux informations principales concernant les relations liant les
trois variables :
1. Mesure de corrélation linéaire : la valeur du coefficient de corrélation reflète la force
de la relation de corrélation linéaire entre deux variables. Plus le coefficient est grand plus
la relation est forte.
2. Mesure de la dépendance : la p-valeur qui donne une information sur la force de
dépendance entre deux variables et au quel point cette dépendance est significatif.
3.
Commentaires/Remarques :
— D’une part, on remarque que le coefficient de corrélation est important entre les
deux variables (vitesse et accélération), alors qu’il est faible en valeur absolue pour la
température et vitesse et la température et accélération.
— Or, si le coefficient de corrélation est faible ou nul, cela ne signifie absolument pas que
les deux variables sont indépendantes car le coefficient de corrélation mesure en fait la
dépendance linéaire entre deux variables. Nous pouvons seulement tirer de conclusion de
sa nullité que nos deux variables ne sont pas dépendantes linéairement.
— D’autre part, on trouve, qu’il y a une interaction significative entre les trois variables en
question vu que la p-valeurs est très grande.
— Enfin, même si que le coefficient de corrélation est grand entre la vitesse et l’accélération,
on ne peut éliminer une d’eux grâce à la présence remarquable d’un effet d’interaction
entre ces deux variables.
Page 35
3.1.4 Standardisation et recodage des données
Au niveau du complexe MAROC CHIMIE, il n’y a pas une standardisation de la procédure

de la saisie des historiques des pannes. Cela entraine une possibilité de commettre des fautes
de frappe et par conséquence on va perdre en termes de normalisation de la base des données.
L’importance de la normalisation apparait quand on a besoin de manipuler de façon automatiques
une base des données de grande taille. Le problème se pose principalement lors de l’utilisation
des fonctions de sélections des attributs ou des lignes.
Quand la base des données n’est pas normalisée, on risque donc de rater un élément (une
ligne ou une case) lors de l’opération de la sélection ce qui va affecter négativement la qualité
des données et donc la qualité des analyses.
En plus, les données des historiques des pannes ont été considérablement marquées par ce
défaut. Cela a demandé un traitement spécial afin de standardiser les noms/attributs de chaque
équipement. Prenons par exemple le cas des ventilateurs d’assainissement, on a trouvé une
difficulté pour extraire les dates des pannes de chaque ventilateur car ces dates étaient liées par
des différents attributs du même équipement de telle sorte que parfois on confond entre deux
ventilateurs appartenant aux différentes lignes :
Table 3.3: Défaut de normalisation

Equipement Ligne Date Type Durée
Ventilateur Assainissement AP3/4 03/01/2014 Électrique 1
Ventilateur d’assainissement AP3/4 20/02/2014 Mécanique 1
Vntlr d’assainissment AP3/4 05/03/2014 Mécanique 12
Ventilateur AP3/4 24/03/2014 Mécanique 3
Ventilateur d’assainissement AP3/4 01/04/2014 Régulation 0,5
ventilateur d’assainissement AP3/4 20/05/2014 Génie civile 1
ventilateur d’assainissement AP3/4 31/05/2014 Régulation 1
Après avoir normalisé la base des données, chaque aura un seul attribut avec lequel on
peut relever toutes les informations d’un équipement. le tableau 3.4 montre le résultat après la
normalisation de la base des données des historiques des pannes.
Table 3.4: Exemple du résultat après la normalisation

Equipement Ligne Date Type Durée
Vtl Assainissement CD AP3/4 03/01/2014 Électrique 1
Vtl Assainissement CD AP3/4 20/02/2014 Mécanique 1
Vtl Assainissement CD AP3/4 01/04/2014 Régulation 0,5
Vtl Assainissement CD AP3/4 20/05/2014 Génie civile 1
Vtl Assainissement CD AP3/4 31/05/2014 Régulation 1
Le défaut de la normalisation n’est pas seulement limité aux attributs des équipements mais
aussi il peut se manifester dans autres colonnes du tableau, comme celle des références des lignes
de production auxquelles l’équipement appartient (ligne AP, ligne AP 1/2 ...etc). On a remarqué
que le nom de chaque ligne a changé avec le temps (par exemple : AP 1/2 devient AB et AP
3/4 devient CD). le défaut à ce niveau peut aussi créer des problèmes et des biais lors de la
manipulation des données .
Page 36
Cela peut apparaitre simple mais vu la variance au niveau de chaque colonne et la taille de la
base des données (plus de 200 équipements) de laquelle on prend les historiques correspondants
aux 40-50 équipements connectés à la plateforme.
Par conséquence, le travail de la normalisation seul peut prendre un temps considérable juste
pour le finir qui peut aller jusqu’à deux semaines comme c’était le cas dans ce projet.
Page 37
3.2. INTRODUCTION À LA PRÉPARATION PRÉPARATION DES
DONNÉES
3.2 Introduction à la préparation Préparation

des données
Lorsqu’on travaille sur des données réelles, on est très souvent amené à considérer des valeurs
manquantes ou aberrantes. Il existe un nombre important de méthodes pour faire face à ce
problème. Dans leur grande majorité, elles proviennent directement des statistiques classiques.
Dans cette partie, on va présenter une vue d’ensemble des principaux concepts du traitement des
valeurs aberrantes et manquantes, sans entrer dans les détails, et ensuite on va voir l’application
de quelques-unes de ces méthodes dans ce projet.
3.3 Valeurs manquantes (Missing values)

3.3.1 Définition
Pour parler des valeurs manquantes, j’aimerais bien faire appel à la définition de deux experts
en Data Analytics, Eric Biernat et Michiel Lutz. D’après eux, on peut distinguer deux grandes
catégories de données manquantes :
1. Lorsque l’on ne dispose d’aucune information c’est à dire une ligne complètement vide
dans une matrice : on parle de non-réponse totale
2. Lorsque l’on dispose d’une information incomplète c’est à dire une ligne partiellement
renseignée : on parle de non-réponse partielle.
Ces données peuvent manquer pour de nombreuses raisons : parce qu’elles n’ont pas été
enregistrées (défaillance d’un capteur, mesure impossible auprès d’un sujet, etc.), parce qu’elles
ont été perdues (mauvais encodage ou erreur de conversion des données, par exemple), etc. Pour
aller plus en détails, les données manquantes ne sont pas toutes de même nature. Elles sont
classifiées selon les formes de mécanismes qui génèrent ces données. Selon la typologie proposée
par Little et Rubin :
1. Les données manquantes complètement aléatoires MCAR(Missing Completely
At Random) : la probabilité qu’une valeur de la variable X1 soit manquante ne dépend
pas des valeurs prises par les autres variables Xj6=1 , qu’elles soient manquantes ou pas.
Il n’est donc pas possible de définir un profil des lignes individus ayant des valeurs
manquantes, la probabilité de ces données est uniforme. On peut formaliser ce concept
comme suit :
p(Xi1/manquant |Xij/observes , Xij/manquant ) = p(Xi1/manquant )
2. Les données manquantes aléatoires, MAR (Missing At Random) : dans ce cas, la

probabilité qu’une valeur de la variable X1 soit manquante ne dépend pas des valeurs prises
par les autres variables Xj6=1 manquantes, mais de leurs valeurs observées. Par exemple,
la probabilité d’avoir une valeur manquante pour les données capteurs des ventilateurs est
différente de celle des pompes. Autrement dit, la probabilité d’avoir une valeur manquante
change d’une catégorie d’équipement à une autre :
p(Xi1/manquant |Xij/observes , Xij/manquant ) = p(Xi1/manquant |Xij/observes )
3. Les données manquantes non aléatoires, MNAR (Missing not at random) :

la donnée est manquante pour une raison précise voulue. La probabilité qu’une valeur de
la variable xi soit manquante ne dépend pas des valeurs prises par les autres variables
Xj6=1 observées, mais de leurs valeurs manquantes. Par exemple, les valeurs manquantes
au niveau de l’accélération si on suppose son calcul se base sur la mesure de la vitesse.
Donc, quand la valeur de la vitesse est manquante en un moment, on pourra pas avoir la
valeur de l’accélération en ce point du temps. Mathématiquement parlant :
p(Xi1/manquant |Xij/observes , Xij/manquant ) = p(Xi1/manquant |Xij/observes )
Page 38
3.3. VALEURS MANQUANTES (MISSING VALUES)
3.3.2 Détection des valeurs manquantes

Au niveau des données capteurs, on fait un diagnostic des données pour détecter les valeurs
manquantes. En utilisant le logiciel R, on dresse un rapport détaillé sur les valeurs manquantes
dans le tableau des données.
> sapply(Data_Sensors, function(x) sum(is.na(x)))

Equipment Date G.pk mm.s.RMS Temp
0 0 0 0 115
Donc voilà, on détecte qu’il y a 115 valeurs manquantes au niveau de la colonne de la

température. Pour avoir plus de détails sur ces valeurs, par exemple pour savoir leur proportion
par rapport à la dimension du tableau des données, on crée la fonction suivante :
> propmiss <- function(dataframe){

lapply(dataframe,function(x)
data.frame(
nmiss=sum(is.na(x)),
n=length(x),
propmiss=sum(is.na(x))/length(x)
)
)
}
propmiss(Data_Sensors)
Cette fonction nous donne la proportion des valeurs manquantes au niveau de chaque
colonne. Les résultats obtenus sont :
> propmiss(Data_Sensors)
$Equipment
nmiss n propmiss
1 0 79721 0
$Date
nmiss n propmiss
1 0 79721 0
$G.pk
nmiss n propmiss
1 0 79721 0
$mm.s.RMS
nmiss n propmiss
1 0 79721 0
$Temp
nmiss n propmiss
1 115 79721 0.001442531
Alors, on conclut que les valeurs manquantes représente 0.14% de la totalité des données du
tableau. Or cela n’est pas encore suffisant pour prendre une décision sur la façon avec laquelle
on va traiter ces valeurs.
Alors, on va chercher l’emplacement de chacune de ces valeurs, le code suivant permet de
donner cette information.
Page 39
3.3. VALEURS MANQUANTES (MISSING VALUES)
> df <- data.frame(Equipement=character(),

Date=character(),
G.pk=numeric(),
mm.s.RMS=numeric(),
Temp=numeric(),
stringsAsFactors=FALSE)
j=0
for(i in 1: nrow(Data_Sensors)){
if(is.na(Data_Sensors$Temp[i])){
df[j,]=Data_Sensors[i,]
j=j+1
}
Les résultats sont affichés sous forme de tableau 3.5 :
Table 3.5: Tableau des valeurs manquantes

Equipment Date G.pk mm.s.RMS Temp
14392 Vtl Assainissement CD 2016-11-04 10 :42 :37 3.5260 14.7650 NA
... ... ... ... ... ...
On remarque qu’il s’agit d’une succession temporelle des valeurs manquantes. On peut
poser des hypothèses dans ce cas qui permet d’expliquer la situation. Puisqu’il s’agit des
valeurs manquantes détectées lors du fonctionnement des capteurs pendant 5 jours continus
de 2016-11-04 jusqu’à 2016-11-09.
Alors on pose l’hypothèse que c’est à cause d’une panne au niveau du capteur. Les
responsables qui surveillent ces capteurs confirment cette hypothèse quand on les a consulté !
3.3.3 Traitement des valeurs manquantes :

La méthode de l’analyse de données complètes est une méthode qui consiste à éliminer toutes
les valeurs manquantes. Elle est considérée comme la méthodes la plus simple et la plus courante.
Elle consiste à ne conserver que les observations qui ne contiennent aucune donnée manquante.
Cette méthode est admise comme acceptable pour les statisticiens tant que les individus
(les lignes) avec des valeurs manquantes représentent moins de 5% de la population. Sinon, elle
devient vite dangereuse car on risque d’avoir des analyses biaisées. Alors il faut adopter une
autre méthode pour remédier à ce problème.
Encore plus, il convient de mentionner que même si elle est acceptable, cette méthode est non
biaisée uniquement pour les données manquantes MCAR, mais elle aura malgré tout tendance
à diminuer la précision de la modélisation.
Page 40
3.4. VALEURS ABERRANTS (OUTLIERS)
Enfin, concernant les données qu’on a, on trouve que les valeurs manquantes de la
température étaient dues à une défaillance au niveau du capteur. En plus, on juge qu’il n’y
a pas de mal à éliminer les données des lignes ayant des valeurs manquantes pour les raisons
suivantes :
1. Il n’y a pas de panne au voisinage de la période pendant laquelle ces valeurs ont été
enregistrées (la dernière panne est en 07/09/2016 et la panne suivante est en 13/12/2016,
donc 63 jours avant et 34 jours après !).
2. La proportion des données manquantes ne dépasse même pas 0.2%
La décision d’élimination n’est définitive et peut être changée si on trouve qu’il avait un
impact sur les résultats des analyses.
Les autres méthodes utilisées pour limiter l’impact des valeurs manquantes (et les valeurs
aberrantes par la suite) sont :
1. Méthodes d’imputation par règle métier : c’est à dire que les gens de métier peuvent mettre
des règles pour remplacer les valeurs manquantes par d’autres données disponibles.
2. Méthodes d’imputation par régression : on remplace la valeur manquante par une autre
valeur prédite par un modèle de régression.
3. Méthodes d’imputation par la méthode du k-plus proches voisins : on définit une fonction
qui peut caractériser la proximité entre les individus ; après on remplace la valeur
manquante d’un individus par la moyenne des valeurs des k voisins les plus proches (
k est une entier)
4. ...etc
Conclusion Dans cette partie on a fini avec le problème des valeurs manquantes et on
va passer à un autre problème qui est celui des valeurs aberrantes. Souvent, on tend d’éviter de
travailler sur ce problème parce qu’il n’est pas facile à traiter. Cependant, les outliers peuvent
réduire la précision des analyses ou même les biaiser.
3.4 Valeurs aberrants (Outliers)

3.4.1 Définition
Avec le problème des valeurs manquantes, il existe aussi un autre problème qu’on rencontre
souvent dans la phase de la préparation des données. C’est le problème de la présence des valeurs
aberrantes. En général, une valeur est dite aberrante si elle est extrême de la distribution d’une
variable, c’est à dire qui diffère façon significative de l’ensemble des grandeurs d’une variable
donnée. On parle aussi d’outliers.
Le fait d’avoir une valeur extrême n’est pas forcément à cause d’une erreur mais elle peut
avoir une signification qui révèle une situation extraordinaire. Dans ce cas-là, les Outliers portent
réellement une information qu’il faut en tenir compte dans les analyses. En effet, vu le type de
notre problème, on attend d’avoir plusieurs valeurs aberrantes ou extrêmes.
Tout d’abord, il est utile de savoir qu’en réalité les deux derniers termes ne décrivent pas le
même type des valeurs, en effet :
— Une valeur extrême est logique et peut représenter un cas réel de fonctionnement de la
machine. Normalement, quand la date d’une panne au niveau d’une machine, celle-ci
commence à vibrer de façon anormale. Dans ce cas, les valeurs que prend la vitesse
des vibrations sont extrêmes de la distribution de cette variable (la même chose pour
l’accélération et la température), et pourtant, on ne peut pas dire que ce sont des valeurs
aberrantes.
— Une valeur aberrante est une valeur illogique. Cela peut être à cause d’une mesure erronée,
un calcul faux...etc. Les valeurs aberrantes ne sont pas forcements extrêmes mais plutôt
elles sont des valeurs incohérentes.
Page 41
Pour comprendre plus la différence entre les deux types valeurs, on donne l’exemple d’un
tableau qui contient des informations de l’âge des individus d’une population. Une valeur
aberrante est le cas d’un individu né en 2000 mais les données dans le tableau disent qu’il a
30 ans (illogique). Par contre, une valeur extrême est le cas d’un individu qui a 90 ans alors l’âge
moyen de cette population est 20 ans. Alors, pour le problème de la maintenance prédictive, le
fait d’avoir des valeurs extrêmes est quelque chose de tout à fait normal à cause des pannes que
subit la machine de temps en temps.
3.4.2 Détection et Traitement des points aberrants

Alors, pour le problème de la maintenance prédictive, le fait d’avoir des valeurs extrêmes est
quelque chose de tout à fait normal à cause des pannes que subit la machine de temps en temps.
Mais la détection des valeurs aberrantes est un peu difficile surtout quand ces valeurs ne sont
aberrantes et extrêmes en même temps.
Dans le cas, d’une valeur aberrante et extrême en même temps, on est peut capable de
discuter sa cohérence.Pour les autres cas des points aberrants, puisqu’il est plus difficile de les
détecter, on mettre des conditions de cohérence sur les champs du tableau des données.
Dans cette partie, on va entamer en premier temps les valeurs aberrantes extrêmes. Parmi
les moyens les plus simple qui permettent de détecter les outliers est les box plots (des boı̂tes à
moustaches).
La température
On dresse la box plot pour la variable de la température avec les logiciel R.
●
80 100
●
●
●
60
40
20
Figure 3.9: BoxPlot de la température
Alors, comme prévu, il y des valeurs extrêmes de la variable de la température. Quand on

demande à l’analyseur R de nous donner un rapport sur ces points extrême. On obtient le resulat
suivant :
Page 42
> boxplot(subset(Sensor_data$Temp)$out
[1] 78.66211 79.98047 78.98438 87.97852 88.97461 98.99414
[2] 98.99414 112.99805 98.99414
Alors, il s’agit de 9 valeurs extrêmes entre 78.66 et 113. Après consultation des responsables
de la maintenance, on nous a dit que c’est logique que la température prend des valeurs pareilles
quand il y a un problème au niveau de l’équipement en question (le ventilateur d’assainissement)
alors on va les tenir en compte dans nos analyses.
La vitesse
●
200
●
●
100
●
●
●
●
●
●
●
●
●
●
●
●
●
●
50
●
●
●
●
●
●
●
●
●
●
0
Figure 3.10: Box Plot de la vitesse
Au contraire de la température, on remarque qu’il y beaucoup des valeurs extrêmes pour

cette variable. Cependant, la remarque c’est que la plupart de ces points sont proches les uns
des autres sauf deux ou trois points qui sont très éloigné. Il s’agit de :
> subset(Sensor_data$mm.s.RMS, Sensor_data$mm.s.RM>120)

[1] 124.0757 180.9183 249.7865
D’après l’expérience des maintenanciers, la vitesse-RMS d’un ventilateur ne peut pas prendre
telles valeurs. Alors, ceux sont des valeurs aberrantes. On va parler de le méthode de leur
traitement dans la partie du traitement.
L’accélération
Pour l’accélération, on attend de trouver un cas pareil de la vitesse.
> selectMax(Sensors_Data)
Page 43
●
15
●
●
●
●
●
●
●
●
10
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
5
●
●
●
●
●
●
●
●
●
●
0
Figure 3.11: Box Plot de l’accélération
2014-02-14 19:50:52 13.41290 99.97399 34.07227

2014-02-15 09:20:34 15.42393 124.07567 40.04883
2014-02-15 11:22:52 11.69300 98.31532 49.65820
2014-02-17 08:09:59 11.43301 99.90825 32.60742
2014-02-17 04:36:14 18.58579 180.91825 32.84180
2016-07-29 13:02:11 12.79365 249.78654 58.97461
La remarque qu’on peut faire ici c’est les valeurs aberrantes de la vitesse sont aussi des
valeurs aberrantes de l’accélération.
Traitement des valeurs aberrantes par la méthode de tukey

Le traitement des valeurs aberrantes sera fait par la méthode de tukey qui permettra
d’éliminer les outliers des données.
Cette méthode du Tukey permet d’identifier les outliers en utilisant l’intervalle des
inter-quartiles pour éliminer les données ayant des valeurs très grandes ou très grandes. Les
limites de l’intervalles sont suit :

La limite basse = Q1 − 1, 5 ∗ IQR
La limite hausse = Q3 + 1, 5 ∗ IQR
Avec Q1= Quartile 1 , Q3= Quartile 3, et IQR= Inter-quartile.
Pour implémenter cette méthode dans R, on construit des fonctions bien définies, merci de
consulter les annexes pour voir leur code en R.
Après avoir appliqué cette méthode, on obtient les résultats suivants :
L’accélération
Page 44
●
10
4
●
●
●
●
●
●
●
●
●
●
8
3
● ●
● ●
●
●
●
6
●
●
●
●
●
● ●
2
● ●
●
●
4
●
●
●
●
●
1
●
●
●
●
●
●
2
0
0
Figure 3.13: Après

Figure 3.12: Avant
La vitesse
●
●
80
50
●
●
●
●
●
40
● ●
●
60
● ●
● ●
●
● ●
●
30
● ●
● ●
● ●
●
● ●
40
● ●
●
●
●
●
20
●
●
●
●
●
●
●
●
●
20
10
0
0

Figure 3.14: Avant
La Température
●
80
●
80
●
●
60
60
40
40
20
20
●
●
●
0
●
0

Figure 3.16: Avant
En final, on remarque qu’aucune valeur de la température n’a été enlevées au contraire des
deux autres variables. Dans la partie suivante, on va passer à la dernière partie de la phase de
la préparation des données qui concerne la création et la transformation des variables.
Page 45
3.5. TRANSFORMATION DES VARIABLES (FEATURES ENGINEERING)
3.5 Transformation des variables (Features

Engineering)
Après avoir fini les cinq étapes de la phase de l’exploration et préparation des données :
1. L’identification des variables
2. L’analyse Univariée
3. L’analyse bivariée
4. Traitement des données manquantes
5. Traitement des outliers
On passe à l’étape suivante qui est appelée le Features engineering. Cette étape est même
composée de deux catégories des actions :
— Features engineering ou Variables création
— Transformation des variables
Il convient de noter que la transformation des variables est un peu différée du Features
engineering. D’une part, le features engineering consiste à extraire des données implicites dans
les données ‘brutes’. Par exemple, supposons qu’on essaye de prédire la date des pannes des
machines, supposons qu’on a deux équipes qui travaillent sur la maintenance des machines.
L’équipe 1 travaille les trois premiers jours, et la deuxième équipe travaille le reste de la
semaine. Donc on peut extraire une variable qui peut indiquer l’équipe qui a assisté le plus
grand nombre des pannes. Pour ce type d’exercices, on parle du features engineering et non pas
de la transformation des variables car on a extrait des informations implicites dans la base des
données en jeu.
D’autre part, la transformation des variables consiste de remplacer une variable déjà existant
dans la base des données par une fonction. Par exemple, on remplace une variable X par log(X)
ou la racine de X. Autrement dit, la transformation des variables est un processus qui change la
distribution et la relation d’une variable avec les autres.
Pour notre problème, afin de prédire la date des pannes des machines, on a besoin de se
baser sur une variable qui peut nous donner accès à cette information. Puisqu’il n’y a pas encore
une variable dans la base des données mise en jeu qui indique cette information, on est donc
obligé de créer une colonne (variable) dans le tableau des données pour cet objectif. Le rôle de
cette variable est d’indiquer la date de la panne quand il va arriver, ou bien d’indiquer le nombre
de jours restant pour l’arrivée de la panne. (Ça revient au même !).
Alors, la variable de réponse qu’on va créer s’appelle la durée de vie résiduelle (Time To
Failure) qui calcule le nombre des jours restant pour qu’une machine tombe en panne. Dans
ce cas, il est clair qu’il s’agit plus d’un mode du feature engineering qu’une transformation de
variable.
La création de la variable TTF se fera à l’aide d’une autre variable intermédiaire qui s’appelle
TBF (Time Between failures). Cette variable calcule le temps, en jours, entre deux évènements
de pannes successifs. Mathématiquement parlant, pour tout événement de panne i on note ti la
date du jour de l’occurrence de cette panne. Alors,on a :
T BF (i) = ti+1 − ti
avec ti+1 est la date de la panne suivante de ti .

Alors, la variable TTF n’est qu’une incrémentation unitaire décroissante entre deux valeurs
T BFi et T BFj successifs (voir Tableau 3.6). Le tableau 3.6 illustre un exemple des valeurs de
la variables de réponse T T F .
3.6 Conclusion
Dans ce chapitre, on a fini la phase de la préparation des données dont l’objectif était
d’assurer une bonne qualité des données qui peut donner des analyses correctes et fiables. Cette
Page 46
3.6. CONCLUSION
phase a pris une portion considérable de temps du stage (presque 35%-40%). On a donc réussi
de définir les variables prédicteurs (La vitesse, l’accélération et la température) et la variable de
réponse TTF. Dans la partie suivante, on verra les différents modèles testés pour faire prédire
la date des pannes des équipements
Table 3.6: Tableau de la variable TTF

Equipment Date Record TTF days TBF days
Vntl Assainissement CD 24/03/2014 213 213
Vntl Assainissement CD 25/03/2014 212
.... .... .... ....
Vntl Assainissement CD 19/01/2015 151 151
.... .... .... ....
Page 47
Chapitre 4
Phase de Modélisation
Maintenant, on va commencer la phase de la construction des modèles qui est l’une des
parties les plus importantes dans toute la démarche CRISP et qui ajoute la valeur la plus grande
au le projet
48
4.1. INTRODUCTION
4.1 Introduction
Comme on a mentionné au début de la présentation de la démarche, on a dit qu’elle est
principalement une démarche itérative. Généralement, dans ce type des projets, on n’est pas
toujours chanceux de tomber dans le bon modèle au premier coup. Il faut plutôt essayer plusieurs
modèles et les réajuster plusieurs fois jusqu’à avoir des résultats satisfaisants. Ce projet n’est
pas une exception de cette règle.
En effet, on a itéré plus de deux fois avec plusieurs modèles, mais on n’a pas encore abouti.
Après plusieurs recherches, on s’est rendu compte que la nature du problème qu’on veut résoudre
ne peut pas être résolu pas des modèles classiques du machine Learning seuls (comme la régression
logistique, SVM, Random Forest, et même les réseaux de neurones). En fait, afin de pouvoir
prévoir la durée de vie résiduelle des machines, on a besoin de faire appel à un type particulier
d’analyse qui utilisent des modèles spécifiques. Il s’agit de l’analyse de survie qui est conçu
spécifiquement pour traiter les problèmes de survie. Ce type d’analyse vise de traiter un cas
particulier des données qui sont appelées des données censurées.
Dans les parties qui suivent, on va donner un bilan des deux itérations qu’on a fait. Ensuite,
on va passer à la troisième itération avec plus de détails.
4.2 Construction des modèles

4.2.1 Premier et deuxième itérations
Dans ce qui suit, on va présenter le bilan des deux itérations qu’on a réalisé mais elles
ne nous ont pas abouti au but visé du projet. Pourtant, chaque itération faite a apporté une
grande valeur ajoutée pour nous en termes de la compréhension des données avant d’arriver à la
troisième itération qui a donné des résultats plus exacts.
Itération 1
1. Les prédicteurs :
(a) Vitesse
(b) Accélération
(c) Température
2. Variable de réponse :

”Down”, quand la machine est en panne
Le statut de la machine
”U p” , sinon
3. Modèles utilisés :
(a) La régression logistique (Performance Test : 27
(b) Random forest (Performance Test : 80
(c) Decision Trees (Performance Test : 50
4. Conclusion :
(a) L’objectif de cette itération était pour comprendre plus les données et l’interaction
des variables entre eux.
(b) Selon la démarche de cette itération, On ne peut pas savoir quand la machine va
tomber en panne.
(c) Cette itération n’a pas tenu en compte le caractère censuré des données.
Page 49
4.2. CONSTRUCTION DES MODÈLES
Itération 2
1. Les prédicteurs :
(a) Vitesse
(b) Accélération
(c) Température
2. Variable de réponse : La durée de vie résiduelle de l’équipement.
3. Modèles utilisés : (Voir tableau 4.1)
Table 4.1: Résultats des modèles utilisés dans la 2ieme itération

Algorithms Mean Absolute Error Coefficient of Determination
Genralized Boosting Model 29.0108586260593 0.52831405253815
Poisson Regression Model 26.2617089322612 0.667362402339595
Extreme Gradient Boosting 26.006143450737 0.603349259146393
Random Forest 30.9802349807092 0.50123734171824
4. Conclusion :
(a) Dans cette iteration, on a pas tenu en compte
(b) Malgré que la performance des ces modeles peut etre bien dans un premier, mais
statistiquement parlant, leurs analyses sont erronées car on n’a pas tenu en compte
le fait qu’on des données censurées.
4.2.2 Troisième itération : Modèle de régression de Cox à

risques proportionnelles
Comme c’est expliqué auparavant, dans cette partie on va utiliser l’analyse de survie qui est
capable de donner des meilleures prédictions de la durée de survie des machines. En termes des
modèles, on a testé quatre modèles : la régression de Cox à risques proportionnelles, modèle de
Kaplan Meier, modèle Random Forest ajusté, et enfin le modèle du “Random forest for Survival
Classification and Regression ”.
Lors du test de ces modèles, on a trouvé qu’ils ont des performances égales. Par conséquence,
on décide de choisir le modèle le plus capable de vérifier les conditions suivantes : 1- Capacité
de prédictions forte 2- Possibilité d’interpréter la relation entre les prédicteurs et la variable de
réponse.
Finalement, le choix était sur le modèle de Cox à risques proportionnelles. Dans les parties
qui suivent on va donner une explication détaillée de ce modèle et puis après un bilan des résultats
des quatre modèles tous à la fois.
Notion basics Soit T le temps de survie,

on a T est une variable aléatoire avec la fonction de distribution cumulative P (t) = P r(T ≤ t)
et la fonction densité p(t) = dPdt(t) .
Alors la fonction de survie est la probabilité est définit comme suit :
S(t) = P r(T ≥ t) = 1 − P (t)
Comme ça on finit par la définition de la fonction de hasard (Hazard function) qui calcule
le risque de survie en un moment t :
P r(t ≤ T < t + ∆t|T ≥ t) −S 0 (t) f (t)
h(t) = lim = =
∆h→0 h S(t) S(t)
Alors les quatre modèles utilisés pour le traitement des données de survie ont pour but
d’estimer la fonction de hasard ou bien son logarithme décimal. Par exemple, pour une fonction
de hasard constant h(t) = ϑ implique que le temps de survie à une distribution exponentielle
avec un densité p(t) = ϑe−ϑt
Page 50
Modèle de régression de Cox à risques proportionnelles

Pour les modèles d’analyse de survie, on vise typiquement d’examiner la relation et
l’interaction entre la variable de réponse qui est le risque de survie et les variables prédicteurs.
L’examen de cette relation entraine de considérer une forme pseudo linaire de la fonction du log
du risque de survie :
log hi (t) = α + β1 xi1 + β2 xi2 + ... + βk xik
ou bien,
hi (t) = exp(α + β1 xi1 + β2 xi2 + ... + βk xik )

Où l’indice i réfère à chaque observation (chaque ligne ou bien chaque prélèvement de mesure
des trois variables) et les xk sont les valeurs des prédicteurs (les trois variables : la vitesse,
l’accélération et la température) et la fonction h0 (t) est appelée la fonction de risque de base
qui dépendent seulement du temps. Autrement dit, la fonction h0 (t) est le risque quand les
prédicteurs sont tous mis à zéro.
Les hypothèses de la régression de Cox :

1. La régression de cox suppose que la fonction de risque de base peut avoir n’importe quelle
forme α(t) = h0 (t) mais les prédicteurs (les covariantes) sont intégrés linéairement dans
le modèle comme indique la formule suivante :
hi (t) = h0 (t) exp(β1 xi1 + β2 xi2 + ... + βk xik )
2. Le ratio de risque entre deux observations ne dépend pas de temps.

Soient deux observations différentes i et i’, on a :
ηi = β1 xi1 + β2 xi2 + ... + βk xik
ηi0 = β1 xi0 1 + β2 xi0 2 + ... + βk xi0 k

Le ratio de risque entre les deux observations est donc donné comme suit :
hi (t) h0 (t)eηi
= = eηi −ηi0
hi0 (t) h0 (t)eηi0
Donc, on trouve bien que le ratio ne dépend pas de temps et par conclusion, on dit les
risques des observations sont proportionnels.
D’où vient le nom du Modèle : régression de Cox à risques proportionnels.
4.2.3 La fonction coxph : Applications sur R

La régression de Cox est connue sur R par une fonction coxph (Cox proportional-hazards
model) dans le package Survival.
> library(survival)
> args(coxph)
function (formula, data, weights, subset, na.action, init, control,
ties = c("efron", "breslow", "exact"), singular.ok = TRUE,
robust = FALSE, model = FALSE, x = FALSE, y = TRUE, tt, method = ties,
...)
NULL
Les arguments qui nous intéressent à ce niveau sont :
Page 51
— Formula : ici on spécifie la formule de prédiction du problème. Pour le cas de notre

projet on a la formule suivante : Surv(T T Fd ays, delta) T empm ean + G.pkm ean +
mm.s.RM Sm ean C’est à dire qu’on veut prédire le risque de survie sur la base des trois
prédicteurs (vitesse, accélération et température) étant donné l’historique de temps de
survie TTF.
— Data : les données mise en jeu.
On lance sur R la fonction coxph et on obtient le résultat suivant :
> fit_formula<-Surv(TTF_days,delta)~Temp_mean+G.pk_mean+mm.s.RMS_mean
> fit.cox <- coxph(formula = fit_formula, data = Model_data )
> fit.cox
Call:
coxph(formula = fit_formula, data = Model_data)
coef exp(coef) se(coef) z p

Temp_mean 0.000998 1.000998 0.036361 0.03 0.98
G.pk_mean 0.453948 1.574516 0.868087 0.52 0.60
mm.s.RMS_mean -0.079148 0.923903 0.091312 -0.87 0.39
Likelihood ratio test=1.19 on 3 df, p=0.756

n= 396, number of events= 5
Pour avoir plus details sur le modele, on execute la fonction summary :
> summary(fit.cox)
Call:
coef exp(coef) se(coef) z Pr(>|z|)

Temp_mean 0.0009977 1.0009982 0.0363614 0.027 0.978
G.pk_mean 0.4539476 1.5745155 0.8680872 0.523 0.601
mm.s.RMS_mean -0.0791484 0.9239028 0.0913119 -0.867 0.386
exp(coef) exp(-coef) lower .95 upper .95

Temp_mean 1.0010 0.9990 0.9321 1.075
G.pk_mean 1.5745 0.6351 0.2872 8.631
mm.s.RMS_mean 0.9239 1.0824 0.7725 1.105
Concordance= 0.585 (se = 0.151 )

Rsquare= 0.003 (max possible= 0.12 )
Likelihood ratio test= 1.19 on 3 df, p=0.7563
Wald test = 0.87 on 3 df, p=0.8328
Score (logrank) test = 0.91 on 3 df, p=0.8232
En premier temps, on va commenter juste les deux colonnes de coef et exp(coef) puis on va
revenir pour commenter sur la colonne de la p-valeur après avoir présenté les performances des
quatre modèles.
Vu la complexité des autres modèles et pour la contrainte de temps consacré pour le stage,
il n’est pas possible à ce niveau de traiter tous les détails des modèles. Ce qui nous intéresse le
plus, c’est les résultats finaux. Voir le rapport des résultats des modèles en Annexe.
Page 52
4.3. CONCLUSION
Remarques et commentaires
1. Dans un premier temps, on va discuter les résultats de la performance des quatre modèles.
Les indices d’évaluation de ces modèles sont un peu particuliers car ces modèles sont dits
des modèles probabilistes c’est à dire qu’ils prédisent des probabilités. Pour cette raison,
on utilise un score qui s’appelle Intergrated Brier Score (IBS). Ce score est similaire à
la fonction des couts pour les modèles linaires (Cost Function) et permet de mesurer la
capacité de prédiction d’un modèle probabiliste en calculant la moyenne quadratique de
la différence entre :
— La probabilité prédite de l’occurrence de l’évènement en question.
— La probabilité actuelle.
Par conséquences, plus se score est proche de zero plus le modèle est performant. En
effet, la formule qui relie le score IBS est la performance/capacité de prédiction d’un
modèle probabiliste est la suivante : IBS = (1 − perf ormance)2 D’où les performances
des modèles sont :
Integrated Brier score (crps):
Performance
Reference 1-racine(0.023)= 0.8483425
Cox 1-racine(0.023)= 0.8483425
RfSurv 1-racine(0.026)= 0.8387548
Cforest 1-racine(0.023)= 0.8483425
Alors, les quatres modeles ont une capacité de precition superieure de 80%.
2. Puisque les modèles ont presque la même performance, on a choisi en premier temps, le
modèle de Cox car il donne la possibilité d’interpréter la relation entre les prédicteurs (les
covariantes) et la variable de réponse alors que les autres modèles sont comme une boite
noire qui ne donne pas accès à une telle information. Par exemple, on dans les résultats
du modèle de cox :
coef exp(coef) se(coef) z Pr(>|z|)

Temp_mean 0.0009977 1.0009982 0.0363614 0.027 0.978
G.pk_mean 0.4539476 1.5745155 0.8680872 0.523 0.601
mm.s.RMS_mean -0.0791484 0.9239028 0.0913119 -0.867 0.386
Alors, dans la colonne coef, on a celui de l’accélération est égale à 0.4539476. Cela signifie
qu’une augmentation unitaire de la vitesse, augmente le risque de l’arrivée de la panne
par environ 0.45 (cad, Prob + 0.45%).
Ensuite, une augmentation unitaire de la vitesse diminue la probabilité par une valeur
de 0.0791484, ce qui peut apparaitre un peu bizarre, car l’augmentation de la vitesse
des vibrations de la machine est une symptôme d’une défaillance au niveau de la
machine. Enfin, le modèle indique qu’une augmentation unitaire de la température ajoute
0.0009977% au risque de panne de la machine.
4.3 Conclusion
Pour conclure, dans ce chapitre on a vu les résultats des trois itérations qui ont mener enfin
à la construction d’un modèle prédictive plus puissant et capable de prédire le risque de l’arrivée
de la panne au niveau de la machine. La troisième itération nous a permet de faire des bons
prédictions en tenant compte du nature censuré des données.
Page 53
Chapitre 5
Restitution des résultats : Data

Visualization
Maintenant, une fois les modèles sont prêts, on doit créer un outil d’interfaçage qui permet
l’exploitation des modèles et donner l’accès au gens de métier pour savoir l’état de santé des
équipements
54
5.1. INTRODUCTION
5.1 Introduction
Les utilisateurs de cette solution sont principalement des responsables de la maintenance
dans le site. Ces gens n’auront pas besoin d’entrer dans les détails des modèles analytiques
pour pouvoir exploiter cet outil de la maintenance prédictive. Ils doivent prendre rapideent
l’information nécessaire et suffisante qui leur permettre de savoir l’état de santé des équipements
surveillés dans le site, les pannes potentielles, leurs nature et le moment approximatif de chaque
panne.
Pour ce faire, on va créer un outil informatique d’aide à la décision qui permet de
synthétiser les informations nécessaires pour qu’un maintenancier prendre une décision envers
les interventions à mener chaque jour sur la base des résultats de prédictions. Dans ce chapitre,
nous allons présenter l’utilité de cet outil et sa valeur ajoutée ainsi que son processus de
fonctionnement.
5.2 Technologie utilisée

Le développement de cet outil est fait avec R, le même langage avec lequel on a développé
les modèles prédictifs. R possède des packages de visualisations des données très développées
et qui peuvent répondre à des besoins de toute sorte. Grace à ce langage, on va développer
une application web qui permet d’explorer les données d’inclure les analyses de R avec des
fonctionnalités interactives et entièrement personnalisables et extensibles. Aucune connaissance
en HTML, Javascript n’est utile.
Les packages principales de visualisation utilisées pour le développement de cette application
web sont :
1. shiny
2. shinydashboard
3. Bubbles
4. ggplot2
5. dygraphs
5.3 Fonctionnement de l’application web

Après plusieurs entrevues avec les utilisateurs de ce produit, on s’est arrivé à concevoir
l’application web, et l’améliorer continument, pour finalement sortir avec un produit qui satisfait
à leurs exigences ergonomiques et fonctionnelles du produit. La version finale de cet outil est
supposée d’être :
1. Rapide, efficace et facile d’utilisation : On a conçu cet outil pour qu’il soit accessible et
exploitable par tout type d’utilisateur. L’interface contient toute l’information dont le
maintenancier a besoin pour prendre une décision d’intervention et pour surveiller l’état
des équipements.
2. Capable de représenter une interface conviviale pour les utilisateurs. On a contacté en pas
mal de fois les utilisateurs du produit pour prendre leur avis et leur vision en considération.
5.4 Aperçu sur l’utilisation de l’application

Dans cette partie, on va donner un aperçu sur l’utilisation de l’application web en expliquant
son processus de fonctionnement.
Page 55
5.4. APERÇU SUR L’UTILISATION DE L’APPLICATION
5.4.1 Interface d’accueil

Au lancement de l’application, une page d’accueil qui est la première interface de
l’application.(Voir figure 5.2)
Figure 5.1: Interface d’accueil
Cette page contient des informations sous forme d’un rapport sur l’ensemble des équipements
connectés à la plateforme. La page du Dashboard permet l’utilisateur d’avoir accès :
1. Aux recommandations d’intervention en exposant :
— La date de la panne potentielle la plus proche
Figure 5.2: ValueBox, Date la plus proche des pannes prédites
— Le nombre des pannes prévues dans la semaine en cours

— La probabilité d’occurrence de cette panne
2. Visualisation graphique du degré de criticité de l’état de santé (Bubbles) :
Page 56
Figure 5.3: ValueBox, estimation du nombre des pannes prévues dans une
semaine
Figure 5.4: ValueBox, La certitude de l’occurence de la panne prédite
Figure 5.5: Vue globale sur la criticité des équipements
La taille des bubbles et leur couleur représentent la criticité de l’équipement comme suit :
(a) Taille des bulles : Plus la taille est grande plus la date de la panne de l’équipement
est proche
Page 57
(b) Couleurs des bulles :le degré de la criticité de la panne est défini par le tendance
vers la couleur rouge comme suit :
— Verts : quand il reste plus 25 jours pour la prochaine de l’équipement en
question
— Jaune : Quand moins de 15 jours restent pour l’arrivée de la panne
— Rouge : Quand moins d’une semaine pour la panne.
(c) Recommandations de la liste des équipements ayant besoin d’intervention le plus
urgent :
5.4.2 Page d’analyses personnalisées de chaque

équipement :
Après avoir eu une vision globale sur les équipements connectés à la plateforme, maintenant
à travers la page Analysis , l’utilisateur peut avoir accès aux informations relatives à chaque
équipement. La page Analysis contient quatre volets principaux :
Volet Data STREAM :

C’est une page qui visualise l’évolution des indicateurs vibratoires : Vitesse-RMS,
l’accélération, et la température de l’équipement avec un graphique interactif (Voir figure 5.6).
Figure 5.6: Data STREAM
Grâce au package dygraph, ce graphique donne l’option de zoomer vers un point ou un

intervalle précis. Cela peut être fait facilement soit par glissement du curseur ou par changeant
des paramètres du volet Time Frame.
Volet Time Frame

Ce volet permet à l’utilisateur de visualiser l’évolution des indicateurs vibratoire dans un
intervalle de temps précis (Voir figure 5.7)
Page 58
Figure 5.7: Time Frame Box
Volet choix de l’indicateur vibratoire

Il permet de choisir l’indicateur vibratoire à visualiser :
1. La vitesse (mm.s.RMS)
2. L’accélération (G.pk)
3. La température (Temp)
Figure 5.8: Choix des indicateurs vibratoires
Volet DATA RAW

Cette page donne accès au tableau des données capteurs de l’équipement.
Figure 5.9: Tableau des données capteurs
Page 59
5.5. PAGE ”EQUIPEMENT OVERVIREW”
5.5 Page ”Equipement overvirew”
Figure 5.10: Page de ”Equipment Overview”
A travers cette page, on a essayé de rassembler les informations essentielles sur la fiabilité
de l’équipement. Elle peut être indiquée par trois ou quatre indicateur principaux :
1. MTBF : le temps moyen entre le début de la réparation et la panne suivante. Il est défini
par la formule suivante :
X durée de f ocntionement − durée de panne
M T BF =
nombre des pannes + 1
Figure 5.11: Le BOX dans la page qui indique la valeur du MTBF
2. MTTR : C’est le temps moyen d’indisponibilité Le temps moyen entre la panne et la

remise en état de fonctionnement.
Figure 5.12: Le temps moyen de réparation BOX
Page 60
5.5. PAGE ”EQUIPEMENT OVERVIREW”
3. La date de la prochaine panne de l’équipement : cette date est la valeur qu’on obtient
grâce aux modèles prédictifs. Dans le box (figure 5.13), on affiche combien reste de jours
pour l’arrivée de la panne.
Figure 5.13: Le BOX qui affiche le compte à rebours pour la prochaine panne
4. Up time : le temps entre la dernière panne jusqu’à présent.
Figure 5.14: Up Time BOX
5. La classe de l’équipement En effet, la classification des équipements est définie comme

suit :
— Class AA : Des équipements en état très critique (score : 95%-100%)
— CLass A : Des équipements en état très critique dont l’occurrence des pannes est
fréquente (chaque 20 jours)
— Class B : Des équipements en état très critique dont l’occurrence des pannes est de
fréquence moyenne
— Class C : Des équipements en état très critique dont l’occurrence des pannes est de
fréquence faible
Figure 5.15: Up Time BOX
Page 61
5.6. CONCLUSION
5.6 Conclusion
Dans cette partie, on a expliqué la valeur ajoutée de la visualisation des données qui réside
dans la facilité de l’accès à l’information et la compréhension des résultats des modèles. Ensuite,
on da expliqué le fonctionnement de l’application web et les différents volets qu’elle contient.
Cette application est un outil d’aide à la décision qui va permettre aux gens de la maintenance
d’optimiser les coûts de la maintenance dans l’usine et de ne pas mener des interventions de la
maintenance que si nécessaire.
Page 62
Chapitre 6
Déploiement et Conclusion
63
Appendices
64
Annexe A
Exploration des données
.1
Les variations des trois indicateurs
vibratoires
Variation de la vitesse 2014−2017

200
100
50
0
févr. 10 19:22 déc. 01 00:44 oct. 29 18:59 nov. 23 15:28
Figure 1: Variation de la vitesse 2014-2017
65
.1.
LES VARIATIONS DES TROIS INDICATEURS VIBRATOIRES
Variation de l'acceleration 2014−2017

15
10
5
0
févr. 10 19:22 déc. 01 00:44 oct. 29 18:59 nov. 23 15:28
Figure 2: Variation de l’accélération 2014-2017
Variation de la temperature 2014−2017

80
60
40
20
0
févr. 10 19:22 déc. 01 00:44 oct. 29 18:59 nov. 23 15:28
Figure 3: Variation de l’accélération 2014-2017
Page 66
.2.
FONCTIONS DE R (PHASE DE PRÉPARATION)
.2
Fonctions de R (Phase de préparation)
1. Fonctions qui rend un rapport sur la proportion des des valeurs manquantes dans les
données capteurs
.3
Fonctions exécutées pour la méthode de
Tukey
> calcul.IQR <- function(x) {
iqrV <- IQR(x, na.rm=TRUE)
iqrV }
> uper.interval <- function(x,y) {

up.inter <- mean(x, na.rm=TRUE)+6*(y)
up.inter
}
> lower.interval <- function(x,y) {

low.inter <- mean(x, na.rm=TRUE)-6*(y)
low.inter
}
> functionData <- function(x,h,l) {

out <- ifelse(x > h, NA, ifelse(x < l, NA, x))
out
}
> outlier.fun <- function(column1) {

med_data <- median(column1, na.rm=TRUE)
cal_IQR <- calcul.IQR(column1)
up_data <- uper.interval(med_data, cal_IQR)
low_data <- lower.interval(med_data, cal_IQR)
column_without_outliers <- functionData(column1, up_data, low_data)
return(column_without_outliers)
}
.4
Rapports de RStudios des des résultats des
quartes modèles
> p <- function(df){
lapply(df,function(x)
data.frame(
nmiss=sum(is.na(x)),
Page 67
.4.
RAPPORTS DE RSTUDIOS DES DES RÉSULTATS DES QUARTES
MODÈLES
n=length(x),
p=sum(is.na(x))/length(x)
)
)
}
p(Data_Sensors)
> fitpec <- pec(list("Cox"=fit.cox,"RfSurv"=fit.rfsrc,"Cforest"=fit.cforest),

+ data=Model_data,
+ formula=Surv(TTF_days,delta)~Temp_mean+G.pk_mean+mm.s.RMS_mean,
+ cens.model="marginal",
+ splitMethod="Boot632plus",
+ B=10,
+ verbose = TRUE)
> fitpec
Prediction error curves
Prediction models:
Reference Cox RfSurv Cforest

Reference Cox RfSurv Cforest
Right-censored response of a survival model
No.Observations: 396
Pattern:
Freq
event 5
right.censored 391
IPCW: marginal model
Method for estimating the prediction error:
Bootstrap cross-validation
Type: resampling
Bootstrap sample size: 396
No. bootstrap samples: 10
Sample size: 396
Cumulative prediction error, aka Integrated Brier score (IBS)

aka Cumulative rank probability score
Range of integration: 0 and time=210 :
Integrated Brier score (crps):
IBS[0;time=210)
Reference 0.023
Cox 0.023
Page 68
.5.
CODE DE L’APPLICATION SHINY
RfSurv 0.026
Cforest 0.023
.5
Code de l’application Shiny
* Par un souci de confidentialité, on va donner ici juste une template de l’application.
Fichier Server :
##############################################################################################
################# R-shiny App for Predicive Maintenance ######################################
##############################################################################################
########################### Author Soufiane CHAMI ############################################
##############################################################################################
########################### Date : 06/April/2017 #############################################
##############################################################################################
######################################### Installing packages ################################

devtools::install_github("jcheng5/bubbles")
install.packages(c("ggplot2",
"dygraphs",
"DT",
"zoo",
"data.table",
"lubridate",
"dplyr",
"dtplyr",
"reshape2",
"dataQualityR",
"caret",
"compare",
"psych",
"randomForest",
"nnet",
"e1071",
"rpart",
"tree",
"xgboost",
"plyr",
"gbm", "party",
"neuralnet",
"survival",
"randomForestSRC",
"shinydashboard",
"shiny",
"xts"
))
Page 69
.5.
function(input, output) {
set.seed(122)
library(bubbles)
library(ggplot2)
library(xts)
library(dygraphs)
library(DT)
library(zoo)
library(data.table)
library(ggplot2)
library(lubridate)
library(dplyr)
library(dtplyr)
library(reshape2)
library(dataQualityR)
library(caret)
library(compare)
library(psych)
library(randomForest)
library(nnet)
library(e1071)
library(rpart)
library(tree)
library(xgboost)
library(plyr)
library(gbm)
library(party)
library(neuralnet)
library(survival)
library(rms)
library(randomForestSRC)
library(party)
library(prodlim)
library(xts)
library(dygraphs)
library(DT)
################################ Working directories#####################
path_parent="C:/Users/Curiosity/Desktop/OCP/Shiny Interface Beta 06_04_2017"

path_data=paste(path_parent,"/data/",sep="")
path_scripts=paste(path_parent,"/Scripts/",sep="")
path_results=paste(path_parent,"/Results/",sep="")
setwd("C:/Users/Curiosity/Desktop/OCP/Shiny Interface Beta 06_04_2017/data")
########## Importing the equipement failures history#####################

# Liste des equipements
TTAF=read.csv("TTF.csv",header = T, sep = ";")
TTF=TTAF$TTF
Equipment=read.csv("ID Equipement.csv",header = T, sep = ";")
PanneID=character(nrow(Equipment))
for(i in 1:nrow(Equipment)){
PanneID[i]=paste(Equipment$Equipment[i],"_Panne.csv", sep = "")
}
Page 70
.5.
TTF_date=TTF+Sys.Date()
Equipment=cbind(Equipment,PanneID, TTF, TTF_date)
Equipment$TTF_date=format(Equipment$TTF_date)
Equipment=Equipment[order(Equipment$TTF_date, decreasing = F),, drop=F]
S=rep(0, length(Equipment$TTF))
for(i in 1:length(Equipment$TTF)){
S[i]=1-(Equipment$TTF[i]/100)
}
Equipment=cbind(Equipment, S)
# colnames(Equipment)=c("Equipment", "ID", "PanneID", "TTF", "TTF_date","S")
Panne=read.csv(as.character(first(as.character(Equipment$PanneID[1]))),
header = T, sep = ",")
for (i in 2:nrow(Equipment)){
if (file.exists(first(as.character(Equipment$PanneID[i])))){
Tab=read.csv(first(as.character(Equipment$PanneID[i])),
header = T, sep = ",")
Panne=rbind(Panne,Tab)
}
}
Panne=Panne[,-1]
colnames(Panne)=c("Equipement", "Ligne", "Date", "Maintenance", "Duree" )
Panne$Date=as.POSIXct(as.character(Panne$Date), format = "%d/%m/%Y ")
levels(Panne$Maintenance)
levels(Panne$Maintenance)[1]="Electrical"
levels(Panne$Maintenance)[2]="Civil"
levels(Panne$Maintenance)[3]="Mechanical"
levels(Panne$Maintenance)[4]="Civil"
levels(Panne$Maintenance)[4]="Regulation"
Panne$Maintenance=as.character(Panne$Maintenance)
Panne$Equipement=as.character(Panne$Equipement)
######################################### Importing Data sensors############

Data_Sensors=read.csv("Data_sensors.csv", sep = ",")
Data_Sensors=Data_Sensors[,-1] # to remove the column X (it’s unused !)
Data_Sensors$Date=as.POSIXct(Data_Sensors$Date, format = "%Y-%m-%d %H:%M:%S")
############# The Preliminary outputs of the interface #####################
FromDate= reactive({
as.POSIXct(input$fromDatetime, format = "%Y-%m-%d %H:%M:%S")
})
ToDate= reactive({
as.POSIXct(input$ToDatetime, format = "%Y-%m-%d %H:%M:%S")
})
Xable=reactive({
Data_Sensors[Data_Sensors$Date>= FromDate()
& Data_Sensors$Date<=ToDate()
& Data_Sensors$Equipment==input$machine,]
})
Page 71
.5.
Yable=reactive({
Xable()[,input$Paramerter]
})
output$dt = DT::renderDataTable(DT::datatable({
data <- Xable()
data
}))
X1=reactive({
na.approx(xts(Yable(), as.POSIXct(Xable()$Date, format = "%Y-%m-%d %H:%M:%S")))
#I used appox in order to replace missing values
# by interpolation
})
output$ts= renderPrint({
summary(X1())
})
output$summ= renderPrint({
summary(Xable())
})
output$alarm =DT::renderDataTable(DT::datatable({
data1 <- X1()
data1
}))
shade_tab=reactive({
Panne[Panne$Date>= FromDate() & Panne$Date<=ToDate()
& Panne$Equipement==input$machine,]
})
output$Shadee = DT::renderDataTable(DT::datatable({
data_shade <- shade_tab()
data_shade
}))
output$str= renderPrint({
summary(shade_tab())
})
dg= reactive ({
ddgg=dygraph(X1(), main ="interactive graph",
xlab = "time frame",
ylab = "records" ) %>% dyRangeSelector()
for( i in 1:nrow(shade_tab()))
{
ddgg=dyShading(ddgg, from= shade_tab()$Date[i],
to = shade_tab()$Date[i] + 24*60*60 ,
color = ifelse(shade_tab()$Maintenance[i]== ’Mechanical’ ,
’gold’,
ifelse(shade_tab()$Maintenance[i]== ’Electrical’ ,
’springgreen’ ,
Page 72
.5.
ifelse(shade_tab()$Maintenance[i]== ’Civil’ ,
’royalblue’ , ’red’ ) ) ))
}
ddgg
})
output$dygraph <- renderDygraph({

dg()%>% dyLegend( show = "auto" ,
width = 250, showZeroValues = TRUE,
labelsDiv = NULL,
labelsSeparateLines = T,
hideOnMouseOut = TRUE) %>%
dyLimit( 0.04,
label = ’Lower Control Limit’,
labelLoc = "right",
color = "red",
strokePattern = "dashed") %>%
dyLimit( 0.5,
label = ’Upper Control Limit’,
labelLoc = "right",
color = "red",
strokePattern = "dashed")%>%
dyLimit( 0.27,
label = ’Normal’,
labelLoc = "right",
color = "black",
strokePattern = "dashed")
})
#################################### Dashboard ###########################
output$packagePlot <- renderBubbles({
bubbles(Equipment$S, Equipment$Equipment,
color =ifelse(Equipment$TTF>25,"#40E354",
ifelse(Equipment$TTF>15, "#FABC3C",
ifelse(Equipment$TTF>7, "#F55536", "#F55536"))),
width = "100%", height = 600)
})
output$packageTable<- renderTable({
Equipment[,c(1,5,4)]
})
output$nextFailure <- renderValueBox({

valueBox("Next failure:",
as.character(paste( min(Equipment[,5]),
Equipment$Equipment[Equipment$TTF_date==min(min(Equipment[,5]))],
sep = " : ")) ,
icon = icon("glyphicon glyphicon-warning-sign", lib = "glyphicon"),
color = "red"
)
})
Page 73
.5.
output$CriticalEquips <- renderValueBox({

valueBox( paste(length(Equipment$Equipment[Equipment$TTF<20]), "Failures", sep = " ")
,
"This week" ,
icon = icon("thumbs-down", lib = "glyphicon"),
color = "orange"
)
})
output$efficiency <- renderValueBox({

valueBox("80%", "Probabilty",
icon = icon("percent"),
color = "black"
)
})
output$MTBF=renderValueBox({
valueBox( "MTBF" ,paste("30", "jours", sep=" "),
icon = icon("glyphicon glyphicon-send", lib ="glyphicon" ),
color = "red"
)
})
output$TTF =renderValueBox({
valueBox( "Next failure date ",
paste(max(Equipment$TTF[Equipment$Equipment== input$machine], 0),
"jours", sep=" "),
icon = icon("glyphicon glyphicon-hourglass"),
color = "red"
)
})
output$TTR=renderValueBox({
valueBox("MTTR", paste(max(Equipment$TTF[Equipment$Equipment==input$machine]+2, 0),
"heures", sep=" "),
icon = icon("glyphicon glyphicon-wrench", lib="glyphicon"), color = "orange")
})
output$Temperature=renderValueBox({
valueBox("TEMPERATURE",
paste(signif(mean(Data_Sensors$Temp[(
length(Data_Sensors$Equipment[Equipment$Equipment== input$machine])-15)]),
digits = 3)
,"degree", sep = " " ),
icon = icon("glyphicon glyphicon-tint", lib="glyphicon"), color = "orange")
})
output$equipment=renderInfoBox({
infoBox("Equipment",input$machine, icon("glyphicon glyphicon-tags", lib="glyphicon"),
color = "orange" )
})
output$MachineClass=renderValueBox({
Page 74
.5.
valueBox("Equipement Class ","AA", icon("glyphicon glyphicon-oil", lib="glyphicon"),

color = "red" )
})
output$UpTime=renderValueBox({
valueBox("Up time ","100 jours 20 heures 30 min", icon("glyphicon glyphicon-oil",
lib="glyphicon"),
color = "green" )
})
randomVals <- eventReactive(input$go, {

runif(input$n)
})
plotInput <- function(){hist(randomVals())}
output$plot <- renderPlot({

hist(randomVals())
})
output$downloadPlot <- downloadHandler(

filename = "Shinyplot.png",
content = function(file) {
png(file)
plotInput()
dev.off()
})
Fichier Server :
setwd("C:/Users/Curiosity/Desktop/OCP/Shiny Interface Beta 06_04_2017/data")

library(ggplot2)
library(xts)
library(dygraphs)
library(DT)
library(shiny)
library(shinydashboard)
library(bubbles)
# devtools::install_github("jcheng5/bubbles")
# Liste des equipements

Equipment=read.csv("ID Equipement.csv",header = F, sep = ";")
# Tableau des donnees capteurs dpour ces equipements
Data_Sensors=read.csv("Data_sensors.csv", sep = ",")

Data_Sensors=Data_Sensors[,-1]
Data_Sensors$Date=as.POSIXct(Data_Sensors$Date, format = "%Y-%m-%d %H:%M:%S")
Page 75
.5.
TTAF=read.csv("TTF.csv",header = T, sep = ";")

anchor <- tags$a(href=’http://www.exemple.com’,
tags$img(src=’Logo.png’, height=’60’, width=’50’),
’project name’)
dashboardPage(skin = "blue",
####################### Header setting #########################################

dashboardHeader(title = "OCP Maitenance Solution", titleWidth = 350,
tags$li(a(href = ’www.ocpgroup.ma’,
img(src = ’Logo.png’,
title = "Company Home", height = "30px"),
style = "padding-top:10px; padding-bottom:10px;"),
class = "dropdown")
),
dashboardSidebar(
####################### Sidebar / Menu items #########################################
sidebarMenu(
sidebarSearchForm(textId = "searchText", buttonId = "searchButton", label = "Search..."),
h5("Main Navigation"),
menuItem("Dashboard", tabName = "dashboard", icon = icon("dashboard")),
h5("Rooms"),
menuItem("Analysis", icon = icon("pie-chart"), tabName = "stats",
selectInput("machine",
"Equipment name:",
c("",
unique(as.character(Data_Sensors$Equipment))), multiple = F),
menuSubItem(’Data Stream’,
tabName = ’a’,
icon = icon(’line-chart’)
),
menuSubItem("Data raw",
tabName = "DataRaw",
icon = icon("bars" )),
menuSubItem(’Equipment overview’,
tabName = ’overview’,
icon = icon(’folder-open-o’)
)),
br(),
menuItem("Maroc CHIMIE- General KPI", icon = icon("industry"), tabName = "Charts"),

br(),
br(),
h5("More information"),
menuItem("User Guide", icon = icon("info-circle"), tabName = "info",
badgeLabel = "new", badgeColor = "green"),
br(),
br(),
Page 76
.5.
br(),
br(),
actionButton("count", "Refresh Data")
)
),
####################### Dashb.Body#########################################
dashboardBody(
includeCSS("C:/Users/Desktop/Shiny Interface/www/custom.css"),
tags$head(
tags$link(rel = "stylesheet", type = "text/css", href = "custom.css")
),
tabItems(
tabItem("dashboard",
fluidRow(
valueBoxOutput("nextFailure"),
valueBoxOutput("efficiency"),
valueBoxOutput("CriticalEquips")
),
fluidRow(
box(
width = 8, status = "primary", solidHeader = TRUE,
title = "Equipment Criticality Overview",
value = tags$p(style = "font-size: 10px;", "Bubbles"),
bubblesOutput("packagePlot", width = "100%", height = 600),
collapsible = T
),
box(
width = 4, status = "info", collapsible = T , solidHeader = TRUE,
title = "Recommendations for maintenance actions ",
tableOutput("packageTable")
)
)
)
,
tabItem(tabName = "overview",
h2("Equipment overview"),
fluidRow(
valueBoxOutput("equipment"),
valueBoxOutput("MTBF"),
valueBoxOutput("TTR")),
fluidRow(
valueBoxOutput("VitesseRotation"),
valueBoxOutput("MachineClass"),
valueBoxOutput("Diametre")),
fluidRow(
valueBoxOutput("UpTime"),
Page 77
.5.
valueBoxOutput("TTF"),
infoBoxOutput("Temperature"))
tabItem(tabName = ’a’,
h2("DATA STREAM"),
fluidRow(
box(dygraphOutput("dygraph"), width = 9),
fluidRow(
h3("Equipement settings"),
box(selectInput("Paramerter", "Indicator", names(Data_Sensors)[-c(1,2)]),
width = 3, status = "success",solidHeader = TRUE,
collapsible = T, title = "Variable"),
box(
textInput("fromDatetime", "From:", value = "2014-12-01 00:00:00" ),

br(),
textInput("ToDatetime", "To:", value = "2014-12-30 00:00:00" ),
width = 3, status = "success",solidHeader = TRUE,
collapsible = T, title = "Time frame"),
br(), width = 3)
)),
tabItem(tabName = "DataRaw",
h2("Data raw from sensors"),
fluidRow(dataTableOutput("dt"))
),
tabItem(tabName ="info",
h2("How this App works ?"))
)
)
)
Page 78
Bibliographie
[1] Eric Biernat et Michel Lutz. OCTO Technologie. (France) [Data Science : Fondamentaux et
études de cas]. 195–201, 2004.
[2] Paresh Girdhar et C. Scheffer. [Practical Machinery Vibration Analysis and Predictive
Maintenance]. Oxford University. UK, pages 1–54, 2012.
[3] Thomas Rahlf. [Data Visualisation with R]. Deutsche Forschungsgemeinschaft Bonn,
Germany,390 pages, 2014.
[4] Morgan Kaufmann. [ Data Preparation for Data Mining]. San Francisco, CA 94104-3205
USA,1999.
[5] Claire Rowland, Elizabeth Goodman, Martin Charlier, Ann Light, and Alfred Lui. [
Designing Connected Products]. Printed in the United States of America.,2015.
[6] Data visualisation with R : Shiny app , Shiny Dashboard, HTML, CSS
https://stackoverflow.com
[7] Monde Diplomatique : L’Office chérifien des phosphates amorce une nouvelle phase
d’expansion,
https://www.monde-diplomatique.fr/1962/06/A/24781
79

Rapport PFE Data Science de La Maintenance Predictive CHAMI Soufiane

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport PFE Data Science de La Maintenance Predictive CHAMI Soufiane

Transféré par

Droits d'auteur :

Formats disponibles

Elaboration d’un outil d’aide à la

décision à base du Machine

ECOLE MOHAMMADIA D’INGENIEURS

Filière : Génie Industriel

Option : Ingénierie des systèmes de production

Mémoire de Projet de Fin d’Etudes

Elaboration d’un outil d’aide à la décision à base du Machine

M. BERRADO Abdelaziz Président

M. ARROUB Marouane Rapporteur

M. EL-HACHEMI Nizar Encadrant EMI

M. BADRI HAMZA Encadrant OCP

M. JBILI Abdenour Encadrant OCP

M. ESSAMSI Rachid Encadrant OCP

Année universitaire : 2016-2017

Figure 1: Distribution de la vitesse

Table des figures vi

Liste des tableaux viii

1 Contexte général du projet de fin d’études 2

2 Business Understanding : Connaissance du métier 12

3 Exploration et Préparation des données 27

5 Restitution des résultats : Data Visualization 54

A Exploration des données 65

1.1 Présence industrielle et commerciale mondiale de l’OCP . . . . . . . 3

2.1 Les stratégies de la maintenance . . . . . . . . . . . . . . . . . . . . 14

3.1 Charte d’identification des variables . . . . . . . . . . . . . . . . . . 29

5.1 Interface d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.4 ValueBox, La certitude de l’occurence de la panne prédite . . . . . . 57

1 Variation de la vitesse 2014-2017 . . . . . . . . . . . . . . . . . . . 65

3.1 Données des historiques des pannes . . . . . . . . . . . . . . . . . . 29

4.1 Résultats des modèles utilisés dans la 2ieme itération . . . . . . . . 50

0.1 Introduction générale

Contexte général du projet de fin

1.1 Organisme d’accueil

Figure 1.1: Présence industrielle et commerciale mondiale de l’OCP

1.1.2 Près d’un siècle d’histoire dans l’industrie

Bien qu’ayant limité au départ ses activités à l’extraction et à la

Le leadership du groupe OCP en matière de valorisation des phosphates se

1.1.3 Histoire de la maintenance au groupe OCP

Figure 1.3: Parts d’OCP dans les importations

Les réserves de phosphate :

1.2 Présentation de projet de fin d’études

1.2.2 Définition de la problématique

Alors, Le niveau d’étude et d’exploitation des données collectées dans la

1.2.3 Objectifs du projet

3. La restitution des résultats de ces analyses dans une application de

1.2.4 Méthodologie et démarche de travail

Phase I : Compréhension du problème métier

Phase II : Compréhension des données

Phase III : Préparation des données

Enfin, il est important de souligner que cette démarche est

1.2.5 Diagramme de Gantt

Figure 1.4: Diagramme de Gantt

1.2.6 Livrable du projet

2. Préparation de ces données pour les injecter dans les algorithmes.

1.2.7 Risques de projet

1.2.8 Facteurs de succès

Ce projet porte sur l’amélioration de la maintenance prédictive dans le site

2.2 Philosophies de la maintenance

des utilisateurs en évitant les imprévus dangereux. On distingue quatre types de

Figure 2.1: Les stratégies de la maintenance

La maintenance corrective : consiste à effectuer une action de maintenance

2.3 Courbe P-F

Figure 2.2: Courbe P-F

Cette courbe est définie principalement par trois intervalles caractérisant