Rechercher sur le site:
 
Web Memoire Online
Consulter les autres mémoires    Publier un mémoire    Une page au hasard

Etude de méthodes d'analyse des historiques de maintenance dans un environnement de forage pétrolier offshore


par Philippe JUNG
CNAM Paris
Traductions: Original: fr Source:

précédent sommaire suivant

Amélioration du retour d'expérience.

Méthodes de recueil de données de fiabilité:

Nous avons vu que l'un des outils nécessaires à la mise en place de la TPM reposait sur un recueil des informations de maintenances et leur analyse en vue d'effectuer des actions correctives (de type FRACAS). La version actuelle de Maximo telle que nous l'utilisons gère les historiques de maintenance, mais ne permet pas d'analyse facile ni de comparaison des données qui permettraient de cerner les problèmes qu'ils soient techniques ou économiques. L'un des moteurs de la TPM consiste à créer un système permettant en plus des commentaires libres de pouvoir catégoriser les sources de coûts, de pannes, les types de pannes et leurs conséquences. On veut aussi pouvoir comparer les niveaux de fiabilité entre équipements identiques fonctionnant sur des chantiers différents. Ce type d'information impose une standardisation de la saisie d'un certain nombre de données obligatoires qu'il faudra ajouter à Maximo. Nous pourrions créer notre propre standard, mais le mieux serait de s'inspirer de l'expérience déjà acquise par d'autres.

Il existe une norme internationale nommée:

ISO-14224:1999 "Industries du pétrole et du gaz naturel"

"Recueil et échange de données de fiabilité et de maintenance des équipements"

Cette norme offre des spécifications de recueil d'information, d'échange et de contrôle de la qualité des données de fiabilité dans le domaine des industries du forage, production, raffinage, et distribution de produits gaziers ou pétroliers.

Par contre, elle ne définit pas la façon dont seront utilisées les données par la suite ni les moyens de les analyser.

Elle est issue de l'expérience d'un projet nommé OREDA (Offshore REliability DAta) mené depuis les années 80 par le SINTEF et DNV Norway avec initialement huit des plus grandes compagnies pétrolières mondiales: BP, ENI, ExxonMobil, Hydro ASA, Conoco Phillips, Shell, Statoil, TOTAL. Chevron Texaco a rejoint ce groupe depuis 2001.

Ce recueil d'information avait pour objectif principal d'obtenir des données de fiabilité et de maintenabilité afin de définir des niveaux de risques pour les personnes, les équipements ou écologiques. Les données de OREDA ont été publiées dans les "OREDA Offshore Reliability Data Handbook" dont la dernière version est sortie en 2002. Une nouvelle révision du standard devrait sortir vers 2005 (Phase VII).

Certaines études prouvent qu'une maintenance efficace ne peut se faire sans une collecte et une analyse des données de défaillance, de modes de défaillances et des activités de maintenance [MOUB]. D'ou l'intérêt de disposer d'une normalisation de collecte, d'échange d'information de maintenance. L'analyse des données ne fait pas partie de la norme.

La spécification des données collectées permettra d'effectuer les analyses suivantes:

- Sécurité, fiabilité, disponibilité et maintenabilité des systèmes.

- Planification, optimisation et réalisation des tâches de maintenance.

- Lors de la conception d'équipements industriels nouveaux ou pour remplacer des équipements existants et les configurer.

- Analyse du coût de cycle de vie.

Le format normalisé des données permettra les échanges, les comparaisons entre différents interlocuteurs ainsi que le contrôle de la qualité des informations enregistrées.

Le texte suivant reprendra l'essentiel de la norme et donnera chaque fois les indications relatives à notre application. On tentera de faire ressortir ce qui est utilisable en tant que tel et de définir ce qui devrait être ajouté ou amélioré sans toutefois entrer dans l'étude complète de la migration qui demandera un travail plus approfondi.

Certains éléments de la norme seront notés en référence et ne seront pas reproduits dans ce document. Les annexes fournies dans la norme sont données à titre informatif et ne constituent pas un cadre rigide même si elles correspondent à des implantations existantes. Nous trouverons plus d'informations applicatives dans les documents publiés par le projet OREDA, mais la norme reste la référence pour la mise en oeuvre.

Guide pour l'obtention de données de qualité:

La mise en place de cette norme repose sur un certain nombre de mesures à prendre afin de garantir une saisie de données de qualité. Elle recommande de se poser un certain nombre de questions auxquelles nous allons répondre:

- Examen des sources de données:

Les sources de données de défaillances et de maintenance proviendront des rapports de maintenance et de "Downtime" du module "Work Order Tracking" de Maximo. Toutes ces informations sont saisies par les opérateurs des chantiers. Il n'existe aucune saisie automatique dans Maximo. Les écrans de Maximo devront être adaptés pour inclure les informations obligatoires préconisées par la norme.

Les informations d'équipement proviendront du module équipement après modification des écrans. Cela consistera principalement en l'addition de catégories d'équipement et des données spécifiques qui leur sont propres. Les données spécifiques d'équipement existent pour une grande partie, mais devront être transcrites de la "Long Description" vers le format imposé par la catégorie d'équipement.

- Objectif de la collecte:

Les données de fiabilité et de maintenance peuvent servir à cinq types d'applications décrites dans l'annexe D de la norme. Chacune d'elles nécessitera un certain nombre d'informations dont la saisie sera obligatoire ou non suivant les cas. Il nous faudra choisir le ou les types d'applications adaptés à nos besoins.

1) Augmenter les objectifs en terme de sécurité de fonctionnement et diminuer les risques (EQR).

2) Optimiser l'utilisation des équipements au travers d'une maintenance appropriée (FMD). Les coûts de maintenance plus élevés doivent être compensés par une meilleure performance de l'installation.

3) Maintenance basée sur la fiabilité (MBF): Il s'agit d'un type de maintenance ou les mesures sur les équipements permettent d'obtenir des informations de fiabilité qui font partie des historiques au même titre que les informations manuelles.

4) Permettre de comparer les performances de fiabilité de différents équipements (EVP).

5) Analyse du Coût de Cycle de Vie (CCV) et possibilité d'effectuer des comparaisons entre équipements.

L'objectif premier est d'obtenir des données de Fiabilité, de Maintenabilité et de Disponibilité (FMD) destinées aux services de maintenance du siège social et aux superviseurs de maintenance.

Il existe aussi un besoin concernant le calcul du Coût de Cycle de Vie (aussi nommé LCC), mais il s'agit d'une utilisation annexe qui ne fait pas directement partie du projet même si l'analyse des coûts ne peut être dissociée de la maintenance. Le produit Maximo ne dispose pas de toutes les informations pour fournir la totalité des coûts associés à un équipement (coûts de stock, du personnel, de la logistique, d'arrêts...). Les données de Maximo devront être associées à d'autres pour fournir ces informations.

Il n'existe pas de saisie automatique de données de maintenances dans Maximo (compteurs horaires ou donnés de Maintenance Basée sur la Fiabilité ou MBF). Ce n'est pas encore une pratique courante. Les données MBF actuelles sont issues des mesures d'huile, isolement et thermographie. Nous n'en tiendrons pas compte dans cette étude. Ces informations lorsqu'elles existent sont traitées dans le cadre des maintenances préventives. Il n'est pas encore envisagé de monter une maintenance de type MBF. Nous ne pensons pas en utilisant cette norme migrer vers une maintenance de type MBF (ou RCM) qui nécessiterait une trop grande rigueur pour notre type d'environnement.

La sécurité peut dans un premier temps être considérée comme une conséquence d'une bonne maintenance même si elle nécessitait un traitement à part pour certains équipements. En offshore, elle sera traitée au travers des indicateurs "ISM" qui servent à spécifier une certification couvrant tous les équipements de sécurité du navire. Les données FMD incluent l'ensemble des données de sécurité.

Le fait de choisir les données FMD donne une des contraintes de saisie les plus fortes. Cela veut dire que si toutes les données FMD sont disponibles, nous pourrons obtenir les données des autres applications hors MBF qui requièrent en plus la notion "Activité de maintenance" (Tableau Annexe B4).

La sélection des données obligatoire par type d'application décrite dans l'annexe D n'est qu'une recommandation et nous pourrons y ajouter toute donnée complémentaire.

- S'assurer de la qualité des données de défaillances:

La saisie des données de maintenance se fait dans le module "Work Order" où l'on peut mettre un équipement en arrêt (Downtime) et où sont saisis les rapports des maintenances préventives et correctives.

Lors de la saisie des "Work Order" correctifs, nous disposons des informations décrites dans le tableau suivant, certaines sont obligatoires (colonne OB) d'autres non. Nous allons détailler pour chaque champ, les valeurs qu'ils peuvent prendre et les commentaires subjectifs sur leur validité (Table 17). Notre jugement est issu de l'examen des données de deux chantiers offshore représentatifs. Ces chantiers sont ceux sur lesquels ont été testés les prototypes des autres chapitres. Il est volontairement sévère. Nous donnerons une note sur 5 pour chaque champ afin de juger de la qualité des informations entrées.

WORKORDER

Valeur saisie

OB

Commentaire

Note

N° d'équipement

O

L'équipement peut être choisi à plusieurs niveaux de l'arbre suivant l'utilisateur. Il n'existe pas de consigne particulière. Seul le bon sens prévaut.

4

Work Type

O

Les valeurs possibles sont:

ALT Alerte. SM Safety maintenance.

CM Maintenances correctives. PM Maintenances préventives.

RKS Remarques. RM Routine maintenance.

RPT RMS report (offshore only).

Les maintenances de type SM ont été abandonnées.

La sélection PM est indiquée automatiquement lors de la génération des PWO dans le module PM tous les 15 jours.

Les sélections autres que CM sont très peu utilisées. Autre que pour PM & CM, il n'existe pas de règle d'usage. Certains ajustements de stock ou remarques sont mis dans des CM sans différenciation utilisable. De nouvelles consignent indiquent d'utiliser RM à la place.

4

Sub Work Type

N

Il peut prendre les valeurs suivantes:

NDT Non destructive test. CAL Calibration.

INS Insulation. CMS Continuous Machinery Survey.

ANA Analysis. MPI Magnetic Particle Test.

DRN Drainage. SJ Survey jobs (Lloyds, ABS, BV, DNV).

OTHER

Ce champ n'est pratiquement pas utilisé en CM sauf parfois pour les valeurs CAL et INS.

3

Priority

N

Optionnel, valeurs "Normal" ou "High level". Très peu utilisé.

1

Failure code

N

Non utilisé.

0

Problem code

N

Non utilisé.

0

Start Date

N

Contiens la date de début des opérations de maintenance. Son remplissage n'est pas formalisé.

4

Finish date

N

Par défaut, il s'agit de la date ou le WO est passé en statut COMP. Il devrait contenir la date de finition des travaux. Elle doit être obligatoirement après la date de début. Son remplissage n'est pas très formalisé, mais il semble correct sur quelques chantiers.

4

Duration

N

Durée des travaux en heure-homme. Elle devrait inclure les temps de préparation, rangement et d'écriture des rapports ainsi que ceux liés à cette maintenance. Ce n'est pas souvent le cas. Il semble toutefois y avoir une certaine cohérence entre deux travaux identiques. De nouvelles consignes ont été données pour le remplissage de ce champ avec des données valides.

4

Meter reading

N

Ce champ texte optionnel devrait contenir la valeur du compteur de l'équipement lorsque la panne s'est produite. Il s'agit d'une simple information et ne peut être utilisé d'une façon sure. Il est très rarement utilisé.

1

%Completion

N

Ce champ optionnel contient le % de réalisations des travaux. Il n'est pas systématiquement mis à jour régulièrement. Le plus souvent, il n'est mis à jour que lors d'un changement de statut.

2

Reported by

N

Il s'agit d'un champ texte libre. Pas de contrôle de la saisie, car les personnes physiques ne sont pas répertoriées.

1

Lead Craft

O

Le "Lead Craft" contient la liste des différents départements du chantier. Il s'agit du département pour lequel on travaille et responsable de l'appareil ou se passe l'intervention. Il peut être différent du "Crew" pour lequel travaille l'intervenant.

4

Crew

N

L'équipe d'intervention. La différence avec "Lead Craft" n'est pas claire.

3

Supervisor

N

Optionnel, contient la liste des titres des superviseurs. La dénomination n'est pas claire par rapport aux "Lead Craft" et "Crew".

3

Modified by

N

Saisie automatique du nom de Login de l'utilisateur. Il s'agit d'un texte libre.

3

Modified date

N

Date à laquelle les modifications ont été faites sans lien avec le statut du WO.

3

Status Date

X

Ce champ contient la date de dernière modification du statut du WO. Elle correspond assez bien à la date à laquelle s'est passé l'événement qui a fait changer le statut.

3

Reported date

X

La date de création du "Work Order". Elle n'a pas de lien avec la date ou s'est produit le problème. Il s'agit de la date du premier état WAPPR pour les CM, celle de la génération des maintenances pour les PM.

5

Report downtime

X

Ce menu permet d'entrer des arrêts après coup alors que l'équipement est déjà retourné en service. On doit entrer les dates de début et de fin de l'arrêt ainsi que le "Downtime code". Les historiques enregistrent un état UP et un état DOWN aux dates entrées.

Ce menu est peut utilisé et les "Downtime code" ne sont pas toujours entrés. Lorsqu'il est utilisé, les dates sont justes. Les raisons qui font que ce menu est peu utilisé sont purement politiques, car certains arrêts ne sont pas comptabilisés ou l'objet de négociations et ne doivent pas apparaître en tant que tels.

4

Change Eqpt statut UP/Down

X

Permet de mettre un équipement dans un états opérationnel ou non en entrant une date et un "Downtime code". Même statut que le précédent.

4

Failure Report Date

N

N'est jamais utilisé (onglet "Failure report").

0

Failure Classe

N

N'est jamais utilisé (onglet "Failure report").

0

 
 
 
 

Table 18 Estimation de la qualité de saisie dans Maximo.

Le tableau qui précède (Table 17) nous permet de dire que la qualité de saisie des données de Maximo peut être grandement améliorée. La compétence des utilisateurs ne peut être remise en cause la plupart du temps. Il s'agit plutôt d'un manque de formaliste, il est vrai assez difficile à mettre au point dans notre type d'environnement. Nous travaillons dans un milieu dispersé ou l'information a parfois du mal à circuler.

Un certain nombre d'informations devront être rendues obligatoires et d'autres redéfinies pour en expliciter le contenu aux utilisateurs de façon plus formelle. La dernière partie du projet donnera des indications pour améliorer les saisies des données existantes. Les données de défaillances additionnelles nécessaires à l'implantation de la norme seront définies dans la suite du document.

- Identification des sources de données et des périodes:

La période d'exploitation des données démarre avec l'implantation de Maximo sur l'appareil. Certains appareils qui ont été rachetés d'autres sociétés possédaient des historiques de maintenances, mais peu d'entre eux ont été repris dans Maximo. Le plus souvent, l'ancien outil de gestion de la maintenance est gardé comme outil indépendant, mais uniquement pour la consultation des historiques. Il n'existe pas de liens immédiats entre les produits anciens et Maximo.

Il se posera toutefois le problème des données historiques des maintenances existantes qui ne possèdent pas de notions de défaillances.

Nous ne prendrons donc en compte les données présentes dans Maximo qu'à partir du moment ou seront implantés les codes de défaillances et les nouvelles spécifications d'équipements.

Il serait possible de reprendre les historiques et de leur attribuer des codes de défaillances. Mais l'étendue du travail pour chaque chantier ne permettra certainement pas d'effectuer cette opération. Tout au plus pourrions-nous le faire sur des sélections d'équipements principaux dont le suivi présente un fort intérêt économique.

- Vérification des méthodes de collecte de données:

Il n'existe pas de méthode automatique de saisie des données dans Maximo. L'ensemble est manuel et très dépendant de la formation de l'utilisateur. Ces derniers devront être formés aux standards de saisie que nous allons définir à l'aide de cette norme. Les saisies sont effectuées pour une part par les opérateurs de maintenance, contrôlées par les HOD et en final par les TC. Ce ne sont pas les utilisateurs finaux de ces données.

Les données de fiabilité des équipements seront principalement utilisées a posteriori par les personnels superviseurs ou par les responsables de la maintenance du siège de Houston. Toutefois, la qualité de saisie ne pourra être atteinte que si les utilisateurs n'appartenant pas à ce groupe voient les résultats de leurs saisies. De fortes contraintes de saisie sans résultats visibles par les opérateurs de maintenance pourraient entraîner des dérives. Si la norme est mise en place, il faudra tenir compte de ces contraintes et remonter certaines informations au niveau des chantiers. Garder l'information uniquement dans des sphères élevées serait une grave erreur.

- Plan du processus de collecte:

Il existe deux types principaux de rapports de maintenance: Les maintenances correctives et les maintenances correctives. Le processus de collecte des informations est déjà formalisé et ne nécessite pas de restructuration profonde. Il a déjà été décrit dans l'analyse de l'existant (voir Fig.11). Seules des données complémentaires devront être saisies lors des rapports de maintenance. Cela ne concernera pas nécessairement la totalité des équipements du chantier, mais les plus significatifs pour le fonctionnement opérationnel de l'unité. Cela inclura ceux de la norme plus une liste additionnelle à définir.

- Plan de formation du personnel à la saisie des données:

Les nouvelles normes de saisie seront intégrées aux formations Maximo et diffusées sous forme d'additifs à la partie PMS des manuels de référence normalisés de la société (Q-SMS).

Ils feront l'objet de documents de référence additionnels. Seuls ces additifs seront distribués localement aux différents départements jusqu'à mise à jour du Q-SMS.

Il existe déjà un plan de formation du personnel impliqué dans la maintenance et utilisant Maximo. Les supports de formation devront inclure ces nouvelles normes de saisie et faire l'objet d'une description spécifique durant le cours. On pourra prévoir des supports plus spécifiques pour les personnes chargées du contrôle de la qualité des données saisies (superviseurs, HOD, TC).

- Assurance qualité de la collecte de données: Annexe C de la norme.

La qualité des saisies des "Work Order" est déjà contrôlée à deux niveaux avant qu'ils soient fermés: Par le HOD lorsque le "% completion" est à 100%. Le HOD ne le passe dans l'état COMP que si la saisie est correcte et les champs renseignés. Il est ensuite vérifié par le TC avant sa fermeture (CLOSE).

L'assurance qualité des données se fera par l'intermédiaire des superviseurs des différents domaines et lors du passage de ceux du siège social de Houston. Ceux-ci ont déjà pour rôle de contrôler le contenu (cohérence, complétude, périodicité...) des champs et des commentaires libres inscrits dans les maintenances de Maximo. Leur rôle sera ainsi amplifié pour inclure la qualité des données faisant partie de la norme. Cela inclura les données spécifiques d'équipement et le contrôle du contenu des WO.

Il nous faudra créer des outils d'audit de la qualité des données sur des échantillons de données d'équipement et de WO préventifs et correctifs. Cela devra inclure des informations concernant les causes d'écarts et de mauvaise interprétation.

Formats des données d'équipements, de défaillances et de maintenance:

Les trois chapitres qui suivent donnent la liste des informations nécessaires faisant partie de la norme et les mettent en correspondance avec les informations disponibles dans Maximo.

La norme décrit trois formats de données nécessaires pour s'assurer que les données sont réutilisables. Il s'agit des données d'équipement, de défaillances et de maintenance.

Les équipements:

La normalisation des catégories d'équipements est essentielle pour pouvoir comparer les données entre elles d'un chantier à l'autre, mais aussi avec des données externes provenant d'autres sources ("OREDA handbook", constructeurs...). Elle sera construite sous forme d'arbre dont le niveau dépendra de la complexité de l'équipement et du niveau de détails requis. L'arbre dont le niveau le plus haut est la catégorie d'équipement doit indiquer les sous-équipements ainsi que les interfaces avec l'environnement. La norme définit quatre niveaux:

- La catégorie d'équipement,

- le type,

- le sous-ensemble,

- l'entité maintenable (EM).

Les données de fiabilité devront être rattachées à un niveau de l'arbre en fonction de leur usage.

La norme définit un certain nombre de données nécessaires et optionnelles à la description d'un équipement. Nous allons reprendre celles du module EQUIPMENT qui nous paraissent les plus réalistes par rapport à notre application.

Catégorie

Ss-Catégorie

Données

Données de Maximo

Identification

Emplacement

Numéro d'identification

EQNUM et DESCRIPTION. C'est l'arbre existant dans Maximo.

Classification

Catégorie d'unité d'équipement. (a)

Type d'équipement. (a)

Application. (a)

"Catégories" et "Type" peuvent être entrés dans l'onglet "Specifications" sous forme de "Classification" et "ss-classifications". (Specs)

N'est pas utilisé dans notre version.

"Application" n'a pas d'équivalent, mais peut être inclus dans les caractéristiques de conception.

Données d'installation

Nom de l'installation ou code. (a)

Type d'installation. (a)

Type d'opérations. (a)

Zone géographique.

Ce type d'information est enregistré dans la "Longue description" (LD) de l'équipement à la racine de l'arbre ou dans les "Specs" (à définir).

On y trouve les spécifications complètes de l'appareil.

Données d'unité d'équipement

Description de l'unité d'équipement.

Numéro unique (N°série ou autre).

Dans la LD ou "Linked documents" (format PDF préféré).

Champ SERNUM.

Conception

Données du fabricant

Désignation du fabricant.

Modèle.

Champ VENDOR.

Champ MANUFACTURER.

Champ ASSETNUM.

Caractéristiques de conception

Suivant la catégorie d'équipement: Puissance, vitesse, pression... (a)

Contenu dans la LD.

Maximo inclut ce type de renseignement dans un onglet "Specifications". Les spécifications entrées sont dépendantes des sous classifications sélectionnées.

N'est pas utilisé dans notre version.

Application

Exploitation en condition normale

Type de redondance.

Mode de fonctionnement.

Date d'installation.

Périodes de surveillance calendaire.

Durée de fonctionnement/période.

Nombre de sollicitations/période.

Paramètres de fonctionnement. (a)

Pas d'équivalent. Dans "Specs".

Pas d'équivalent. Dans "Specs".

Champ INSTALDATE.

Pas d'équivalent.

Compteurs horaires.

Pas d'équivalent.

Pas d'équivalent. Dans "Specs".

Facteurs d'environnement

Extérieur (b) et intérieur (c).

(extrême, modérée, favorable)

Pas d'équivalents.

Peut-être inclus dans "Specifications".

Commentaires

Compléments

Fiches techniques.

Peut être inclus en texte libre dans la LD ou encore comme document attaché pour les documents autres que du texte simple (format PDF de préférence).

 
 
 
 

Note: Les caractères en gras indiquent les éléments nécessaires à la norme pour une application FMD.

Note: Les caractères en italique indiquent le minimum requis pour la norme.

a) Voir l'annexe A de la norme pour consulter les listes proposées.

b) Paramètres à prendre en compte: Protection de l'enceinte, vibrations, humidité, corrosion...

c) L'environnement interne de l'équipement. Acidité, pressions chaleur...

 

Table 19 Données d'équipement ISO-14224.

L'annexe A définit (à titre indicatif) les caractéristiques des équipements à partir des informations suivantes:

Figure 39 Hiérarchie des équipements ISO-14224.

- Catégorie d'équipement: P.ex, "Moteur électrique".

Directement applicable en tant que "Classification" dans le module équipement. Chaque équipement ne peut appartenir qu'à une catégorie. Le lien entre catégorie et désignation de l'équipement dans Maximo doit être univoque. Dans le cas contraire, la classification n'est pas applicable. Il faudra soit la modifier ou descendre à un niveau inférieur de l'arbre.

P.ex: "053101001 Diesel Engine #1 (Eng+Alt)" contient deux catégories, "Engine" et "Alternator". La classification n'est pas applicable.

- Type d'équipement: P.ex, Continu ou Alternatif.

Directement applicable en tant que "SubClassification" dans le module équipement. Chaque équipement ne peut appartenir qu'à un type qui lui-même est lié à une seule catégorie. Dans le cas contraire, descendre dans l'arbre pour assigner les classifications.

P.ex: "053101002 Diesel Engine #1 Wartsila" appartient à la catégorie "Combustion engine". Le titre indique aussi le type de l'équipement qui est "Diesel".

- L'application: P.ex, Energie de secours, Energie principale, Secours incendie.

N'a pas d'équivalent dans les écrans Maximo. Elle pourra être incluse dans les spécifications.

- Les notions de sous-ensemble et d'entités maintenables (EM):

P.ex, pour les "Sous-ensemble": Moteur, Circuit de commande, Lubrification.

P.ex, pour les EM du système de lubrification: Réservoir, filtre.

Ces deux valeurs sont communes à tous les types d'une catégorie. Chaque sous-ensemble contient un certain nombre d'entités maintenables.

Cela nécessitera la création de deux niveaux de classification supplémentaires dans le module "Inventory", "Asset Catalog setup". Actuellement, l'application ne propose que deux niveaux, mais cinq sont possibles. Il faudra faire apparaître les champs dans le module équipement et "Asset Catalog setup" à l'aide du "Centura Object Nationalizer" qui permet de paramétrer les écrans de Maximo.

- Les données spécifiques à la catégorie: P.ex, Puissance, vitesse.

Directement applicable dans l'onglet "Specifications" du module équipement. Il faudra créer les listes dans le module "Inventory", "Asset Catalog setup".

Ces données ne seront rattachées qu'aux niveaux des "catégories" ou "catégorie+type" et non aux niveaux inférieurs. Le choix de l'un ou l'autre dépendra de la façon dont a été conçu l'arbre des équipements dans Maximo. Toutefois, rien n'empêche d'ajouter celles qui nous paraîtrait nécessaire à d'autres niveaux ou d'inclure des informations non présentes dans la norme.

- Lorsque c'est applicable, les données environnementales:

P.ex, Présence de gaz, pression, débit.

Elles pourront apparaître dans la liste des données spécifiques à la catégorie.

- A chaque catégorie d'équipement sont associées des listes de "Modes de défaillances". Il faudra faire apparaître le champ FAILURECODE dans le module équipement à l'aide du "Centura Object Nationalizer" et créer ces valeurs dans le module "Failure codes".

Note: Le "Failure Code" est aussi appelé "Failure Class" dans Maximo.

Les catégories d'équipements traités sont les suivants dans le domaine "Equipement de procédés":

- Moteurs à combustion.

- Compresseurs.

- Unités logiques de commande.

- Générateurs et moteurs électriques.

- Systèmes incendie et gaz.

- Turbine à gaz.

- Echangeurs thermiques.

- Capteurs et procédés.

- Pompes.

- Turbines de détente.

- Soupapes et robinets.

- Capacités et procédés de stockage.

Les parties "Equipement sous-marins" et de "Complétion de puits" ne sont pas applicables telles qu'elles. Elles sont très adaptées à la production et non à la partie forage.

La partie "Equipement de Forage" est réduite à sa plus simple expression, car elle ne concerne que les équipements "Tête d'injection motorisée" qui ne sont en général utilisés que lors des forages déviés.

La majorité des catégories équipements sont décrits dans les annexes, mais il nous faudra créer nos propres caractéristiques pour celles qu'il manque. On peut citer dans un premier temps, les plus importantes:

- "Equipement sous-marin": BOP, acoustique.

- "Equipement de forage": Tiges, risers.

- "Equipement marine ou positionnement": DGPS, gyroscopes, radio/navigation, télécoms.

La majorité de nos chantiers sont déjà équipés de Maximo et les arbres d'équipements existent déjà. Les trois premiers niveaux de l'arbre sont trop génériques pour correspondre à la classification de la norme. Ils correspondent respectivement au chantier (racine de l'arbre), aux grandes familles d'équipements et aux sous ensembles ou systèmes. Les équipements ne sont décrits qu'à partir du quatrième ou cinquième niveau. C'est à partir de ces niveaux que l'on pourra appliquer les classifications et/ou de "Failure code" à chaque branche des équipements.

Exemple d'arbre d'équipement:

Equipement

Catégorie

Type

Sous-ensemble

Entité maintenable (EM)

053 Drill Ship Pride Angola

Drill Ship (catégorie à créer pour chaque type de chantier)

0531 Power & Associated

Regroupement générique.

053101 Main Generators

Regroupement générique.

053101001 Diesel Engine #1 (Eng+Alt)

Pas de catégorie applicable, car cela regroupe moteur et générateur.

053101002 Diesel Engine #1 Wartsila

Moteur à Combustion (CE)

Moteur Diesel (DE)

Pas de Sous-ensemble ni EM.

Données spécifiques entrées à ce niveau.

...

 
 
 
 

053101011 Fuel feed pump

CE

DE

Unité du moteur à combustion

Pompe à carburant

053101015 Starting Equipement

CE

DE

Système de démarrage

Unité de démarrage

...

 
 
 
 

053101003 Alternator/Diesel Eng #1

Générateur Electrique (EG)

Entraîné par moteur (MD)

Pas de SS-Ensemble ni EM.

Données spécifiques entrées à ce niveau.

 
 
 
 
 

Il ne sera pas toujours facile de faire correspondre la hiérarchie de la norme avec celle des équipements, car les arbres ne sont pas superposables. Il conviendra de vérifier si la hiérarchie existante peut être changée ou re-découpée sans remettre en cause les historiques de maintenance ni les maintenances préventives qui leurs sont associées.

Les données spécifiques ne seront définies qu'aux niveaux des "catégories" ou "catégorie+type". Il est toutefois difficile de donner des règles précises, car tous les arbres ne sont pas identiques entre chantiers.

La norme spécifie d'indiquer les sous-ensembles et "Entités Maintenables" (EM) dans les saisies des données de défaillances. Dans notre cas, ils seront implicites et contenus dans le numéro de l'équipement, car ces champs n'existent pas dans Maximo. Le numéro d'équipement est entré dans le "Work Order" avec les autres informations de défaillance.

La majorité des informations requises par la norme existent déjà dans les saisies actuelles.

Les données spécifiques sont renseignées la majorité du temps dans la "Long Description" (LD). L'onglet "Specification" commence à être utilisé depuis peu et les données de la LD y sont transférées progressivement. Les données spécifiques à chaque catégorie d'équipement n'ont pas été créées à partir des données de cette norme.

La conversion des données spécifiques entre les LD et le nouveau format devront être faite manuellement et cela représentera un gros travail de saisie.

La conversion des spécifications existantes (hors LD) vers le nouveau format pourra être faite automatiquement. Cela nécessitera une comparaison entre ce qui est proposé par la norme et les 21 catégories existantes.

Il est prématuré de juger de la faisabilité. Il nous faudra examiner les possibilités d'adaptation et juger de l'intérêt de le faire. On notera que cela ne concernera que les équipements décrits dans la norme ainsi que ceux que l'on aura souhaité y ajouter et non l'ensemble.

Les données de défaillances:

Cette partie concerne principalement les données de maintenances correctives. L'ensemble des défaillances doit être consigné dans Maximo avec un minimum d'informations nécessaires à leur exploitation. Ce tableau résume les informations recommandées par la norme et celles qui sont le minimum nécessaire.

La majorité de ces informations sont déjà présentes dans notre version et sont contenues dans les "Work Order" correctifs. La différenciation entre une donnée de maintenance (préventive) et un rapport de défaillance (corrective) étant faite par le "Work Type".

Maximo dispose d'un module permettant de créer une hiérarchie de "Failure Class" et "Problems, Causes, Remedies". Ce module n'est pas utilisé dans notre configuration actuelle. Il devra être renseigné pour être utilisé dans les rapports de maintenance.

Catégorie

Donnée

Description

Données de Maximo

Identification

Enregistrement de la défaillance

Numéro unique

Numéro "Work order" corrective: WONUM.

Emplacement de l'équipement

Numéro d'identification de l'équipement

Numéro d'équipement: EQNUM.

Données de défaillances

Date de défaillance

Date de détection

Pas d'équivalent. Correspond à "Failure Date" (FAILDATE) onglet "Failure reporting" module WO.

Non utilisé dans notre version.

Mode de défaillance

Voir (a).

"Failure Class" (FAILURECODE) dans le module WO. Spécifique à un équipement.

Peut être lié à l'équipement.

Non utilisé dans notre version.

Conséquences sur la production ou la sécurité

Echelle d'impact.

Le "Downtime" de l'équipement dans le module "Work Order" contient aussi un "Downtime code" qui permet de caractériser le problème, mais pas forcement l'impact.

Classe de sévérité

Effet critique ou non sur l'unité.

Il existait une notion de "Downtime" opérationnel ou non dans les précédentes versions. Il faudrait la réactiver. Le champ "WO priority" pourrait aussi être utilisé.

Indicateur de la défaillance

Voir (b).

Champ PROBLEM du "Work Order" et compléments dans la "Long Description" (LD).

Non utilisé dans notre version.

Cause de défaillance

Voir (c).

Champ CAUSE du "Work Order" et compléments dans la LD.

Non utilisé dans notre version.

Sous-Ensemble défectueux

Sous-ensemble défaillant.

Voie (a)

Implicite dans le numéro d'équipement lorsque applicable.

Entités maintenables défaillantes

Détail des unités défaillantes. Voir (a).

Implicite dans le numéro d'équipement lorsque applicable.

Méthode d'observation

Méthode de détection de la défaillance. Voir (d)

Dans la "Long Description" du "Work Order". Peut faire l'objet de l'ajout de DETECTION dans les PROBLEM/CAUSES/REMEDIES.

Commentaires

Informations complémentaires

Informations complémentaires sur les conditions et cause de défaillances, diagnostic et méthodes de réparation.

Dans la "Long Description" du "Work Order".

 
 
 
 

Note: Les caractères en gras indiquent les éléments nécessaires à la norme pour une application FMD.

Note: Les caractères en italique indiquent le minimum requis pour la norme.

a) Voir l'annexe A de la norme pour consulter les listes proposées.

b) Tableau B1 de la norme "Indicateurs de défaillance".

c) Tableau B2 de la norme "Causes de défaillances.

d) Tableau B3 de la norme "Méthodes de détection".

 

Table 20 Données de défaillances ISO-14224.

L'annexe A donne une liste des "Modes de défaillances" par catégories d'équipements. Cette liste qui est assez similaire aux indicateurs de défaillances de la liste B1 doit correspondre à la description de la défaillance observée reportée au niveau du type d'équipement de la catégorie.

Le titre correspondrait aux "Failure Class" de Maximo. Le "Failure Class" d'un équipement peut être défini dans le module équipement ou par défaut dans le "Work Order", onglet "Failure Reporting". Il apparaîtra dans "Failure Class" lorsqu'un "Work Order" sera généré pour cet équipement. Ce champ n'est pas apparent dans la version actuelle du module équipement.

Les annexes B donnent à titre indicatif les listes générales des informations suivantes:

- B1: Les indicateurs généraux de défaillances (fuite, court circuit...) avec une répartition par catégorie (mécanique, électrique...). Il doit indiquer la cause de la défaillance au niveau le plus base de la hiérarchie de l'équipement (sous-ensemble ou entité maintenable). Cette distinction n'existe pas dans Maximo. Nous ferons correspondre les titres des "Modes de défaillances" avec "Failure Class". A chaque "Failure Class" correspondra une liste de PROBLEM correspondants à la liste des "Modes de défaillances" de l'annexe A.

- B2: Une liste commune de causes de défaillances: P.Ex, erreur humaine, mauvaise conception. On l'associera au champ CAUSE des "Failure Class" de Maximo.

- B3: Une liste commune de modes de détection: P.ex, observation, contrôle.

- B4: Une liste commune d'activités de maintenance: P.ex, PM, CM, réglage, remplacement.

Les listes B2, B3 et B4 seront communes à toutes les classes de défaillances.

Ces listes ne sont pas complètes et devront être revues avec le concours des personnels qualifiés de chaque discipline. Elles pourront servir de base solide pour de futures améliorations. Chaque élément de ces listes fera l'objet d'une codification adaptée à Maximo. On utilisera la codification de la norme si elle existe. Il faudra veiller à ne pas entrer dans une trop grande complexité afin de ne pas rebuter les personnes et de ne pas engendrer des temps de recherche trop longs de la bonne information dans des listes interminables.

Les données de maintenance:

Ce module est complémentaire du précédent. Dans Maximo, la différenciation entre rapports de défaillance et rapport de maintenance n'existe pas sous cette forme. Les rapports sont faits dans le module "Work Order" quel qu'en soit le type. La différentiation provient du champ "Work Type" qui définit si l'on a affaire à une maintenance préventive ou corrective. Les données de défaillances sont incluses dans les rapports dans le cas des maintenances correctives.

Catégorie

Donnée

Description

Données de Maximo

Identification

Enregistrement de maintenance.

Identifiant unique de la maintenance.

Numéro de "Work order" préventif: WONUM.

Emplacement de l'équipement.

Identification de l'équipement.

Numéro d'équipement: EQNUM.

Enregistrement de défaillance.

Pour les maintenances correctives uniquement.

N'est pas applicable.

Les maintenances préventives et correctives sont enregistrées dans le même module "Work Order".

Données de maintenance

Date de maintenance.

Date à laquelle s'est effectuée la maintenance.

ACTSTART & ACTFINISH module "Work Order".

Catégorie de maintenance.

Préventive ou corrective.

WORKTYPE du module "Work Order", inclut entre autres les PM et CM.

Opération de maintenance

Voir (b).

Pas d'équivalent. Pourrait correspondre à une liste modifiée des "Sub Work Type".

Conséquence sur la production.

Echelle d'impact.

Le "Downtime" de l'équipement dans le module "Work Order" contient aussi un "Downtime code" qui permet de caractériser le problème.

Sous ensemble soumis à la maintenance.

Sous ensemble concerné par la maintenance. Voir (a).

Pas d'équivalent. Implicite dans le numéro d'équipement.

Entité maintenable soumise à la maintenance.

Spécifier l'entité concernée. Voir (a).

Pas d'équivalent. Implicite dans le numéro d'équipement.

Moyens de maintenance

Maintenance en homme-heures par discipline.

Voir (c).

Les heures sont entrées dans le champ DURATION du module "Work Order". Chaque discipline devrait faire un "Work Order" différent. Ce n'est pas toujours le cas.

Durée totale de la maintenance en homme-heure.

 

Pas d'équivalent. Sauf à cumuler les heures des différentes disciplines. Toutefois, il ne sera pas possible de déterminer facilement s'il s'agit de la même intervention.

Temps de maintenance

Temps de maintenance active.

Temps de maintenance active par rapport au temps d'indisponibilité.

Peut être déduit à partir de ACTSTART, ACTFINISH et DURATION module "Work Order".

Temps d'indisponibilité.

Temps d'indisponibilité de l'équipement concerné.

FAILDATE, ACTSTART & ACTFINISH module "Work Order".

Commentaires

Informations complémentaires.

Indiquer toute information utile à cet emplacement.

Dans la "Long Description" du "Work Order".

 
 
 
 

Note: Les caractères en gras indiquent les éléments nécessaires à la norme pour une application FMD.

Note: Les caractères en italique indiquent le minimum requis pour la norme.

a) Voir l'annexe A de la norme pour consulter les listes proposées.

b) Tableau B4 de la norme "Méthodes de détection".

c) Pour les équipements sous-marins, préciser la logistique et les ressources externes.

 

Table 21 Données de maintenance ISO-14224.

Le développement en interne:

Nous avons vu que l'implantation de la norme était possible, mais qu'elle demandait un certain nombre de modifications de Maximo et de gros efforts de saisie si elle devait être implémentée complètement. Nous ne prétendons dans ce qui suit, donner une liste exhaustive, mais plutôt un ordre d'idée des opérations à effectuer. Le but étant principalement de faire une première évaluation des travaux afin de faciliter la prise de décision.

Avant de commencer l'étude, il conviendra de répondre aux questions suivantes:

- Quel effort de normalisation sommes-nous prêts à assumer et en voyons-nous les avantages?

Les plus gros travaux de normalisation concernent la classification des équipements dont il faudra évaluer la faisabilité.

La situation actuelle convient pour planifier les maintenances et pour une exploration manuelle des historiques uniquement.

- Voulons-nous une normalisation pour un usage interne uniquement et à quelle échelle?

Il est toujours possible de s'inspirer de la norme sans l'implémenter complètement. Dans ce cas, les données risquent de n'être utilisables qu'en interne et difficile à comparer aux données OREDA. Il est aussi possible de ne l'implanter que sur certains équipements sélectionnés. Nous pourrions limiter l'implantation à certains secteurs à forte valeur ajoutée comme le offshore qui seraient probablement plus demandeurs que d'autres.

- Quels sont les bénéfices espérés et comment présenter le projet aux directions?

Il s'agit d'un projet d'envergure et cela demandera l'implication des directions du groupe. Il ne s'agit pas d'un projet à court terme, car les données de maintenances et les résultats ne se feront sentir qu'au delà de deux ans dans le meilleur des cas. Nous comptons un an de mise en place et un an d'historiques minimum. La reprise des anciens historiques ne parait pas réalisable et n'est pas souhaitable car les règles utilisées n'auront pas été les mêmes.

- Vérifier que des solutions commerciales n'existent pas ou que nous ne pouvons pas bénéficier de l'expérience d'autres implémentations de la norme dans Maximo. MRO propose un élément de solution qu'il faudra explorer.

- Il serait aussi souhaitable d'entrer en contact avec les membres du projet OREDA pour en discuter les différents aspects et voir l'intérêt d'y participer. La normalisation et l'appartenance à ce projet sont dissociés.

On donnera dans ce qui suit, une liste préliminaire des opérations à effectuer pour mettre en place cette norme au sein de nos chantiers. Celle-ci peut servir de point de départ pour démarrer l'étude, mais devra être revue en détail pour s'assurer de la faisabilité de certains points. Il se peut que la situation soit différente sur d'autres installations, car nous n'avons exploré que les chantiers d'Angola et notre vision n'est pas celle de la situation du groupe.

Afin de compléter cette étude, nous devrons disposer du "OREDA Offshore Reliability Data Handbook" qui nous permettra d'avoir une idée d'implémentation de la norme.

En ce qui concerne le module équipement, la norme donne des indications qui pourraient nous permettre de créer une taxinomie ainsi que les listes de spécifications de chaque classification d'équipements. L'application de ces catégories à l'arbre des équipements existant pourra s'avérer difficile sur les chantiers ou il n'aura pas été conçu à partir de cette norme. Il conviendra de faire une étude de faisabilité avant d'entreprendre ces opérations. Les modifications ne devraient pas concerner tous les équipements, mais seulement ceux décrits par la norme et ceux que nous aurons voulus y ajouter.

- Afin de faciliter les futures saisies. Remettre en forme les formats proposés par la norme pour les faire correspondre à ceux de Maximo. Codifier les quatre niveaux de la hiérarchie des équipements. Les Catégories et Types ont déjà un code attribué dans la norme, nous pourrons le conserver (P.ex: CE pour la catégorie "Combustible Engine" et DE pour le type "Diesel Engine").

- Faire apparaître quatre niveaux de classifications dans le module "Asset Catalog Setup" du menu "Inventory" et dans l'onglet "Specification" du module équipement à l'aide du "Centura Object Nationalizer". Les nommer: Category, Type, Sub-assembly et Maintenable Entity.

- Faire apparaître le champ "Failure Code" dans l'onglet principal du module équipement. Associer les équipements sélectionnés avec une "Failure Code".

- Faire disparaître le champ "Classification" de l'onglet principal du module équipement. Il sera remplacé par les données de l'onglet "Specifications".

- Créer les "Classifications", "Sous Classifications", "sous-ensembles", "Entités maintenables" ainsi que les "Données spécifiques" décrites par la norme dans le module "Asset Catalogue Setup" du menu "Inventory".

- Etendre les classifications aux équipements manquants dans la norme. Cela demandera l'expérience des personnes expertes du domaine.

- Assigner une classification à chaque niveau de l'arbre des équipements ou c'est applicable. Cela revient à assigner dans l'ordre un ou plusieurs des niveaux suivant de la hiérarchie: Catégorie, Type, sous-ensemble et Entité maintenable. Pour les équipements qui poseraient des problèmes, vérifier s'il est possible de modifier l'arbre ou la dénomination.

- Pour les équipements où c'est applicable. Reporter toutes les données d'équipement se trouvant dans les "Long Descriptions" dans le format proposé dans l'onglet "Classifications". Vu l'étendue de ce travail, celui-ci ne pourra pas être réalisé par les personnes du bord, mais par les superviseurs de Maximo lors de leur passage.

Les données de défaillance ne peuvent être définies que si les équipements le sont aussi. A chaque type d'équipement correspondra une "Failure Class".

- Afin de faciliter les futures saisies. Remettre en forme les formats proposés par la norme dans les annexes A & B pour les faire correspondre à ceux de Maximo.

- Créer la hiérarchie des "Failure class", "Problems", "Causes" et "Remedies" dans le module "Failure codes" de Maximo.

- Ajouter le niveau de hiérarchie DETECTION dans le module "Failure codes". Il est nécessaire pour les rapports de défaillances

- Etendre cette hiérarchie aux cas non décrits par la norme. Cela demandera l'expérience des personnes expertes du domaine.

- Assigner une "Failure Class" aux équipements. On préférera les niveaux ou seuls "Catégory+Type" sont définis. A défaut on l'indiquera au niveau "Category". Il s'agit de la valeur qui apparaîtra dans le "Work Order" lors de sa génération. A défaut, l'utilisateur devra choir dans les listes.

- Explorer les solutions pour créer les champs obligatoires manquant dans les écrans et dans la base de données. On vérifiera que ces champs ne sont pas inclus dans une partie de Maximo non encore utilisée. Cela concerne les champs suivants: Classe de sévérité, Echelle d'impact, les temps de maintenance.

Tâches additionnelles:

- Ecrire les scripts SQL d'installation.

- Choisir un site pilote et définir la façon de mettre à jour les données d'équipements.

- Créer et diffuser la documentation additionnelle décrivant les normes de création de la hiérarchie d'équipements et de remplissage des rapports de maintenance.

- Définir des critères de qualité des données enregistrées et se donner les moyens pour les évaluer.

- Créer les outils d'analyse des données de maintenance à partir des nouvelles informations. Les tests que nous avons faits dans la partie qualitative devront pouvoir être réutilisés pour définir les meilleurs outils.

- Pour le siège social: Créer les outils de regroupement et d'analyse d'informations de maintenance à partir des données des différents chantiers. Il existe un projet nommé MIMOSA qui pourrait répondre à ce type de problème.

précédant sommaire suivant








® Memoire Online 2007 - Pour tout problème de consultation ou si vous voulez publier un mémoire: webmaster@memoireonline.com