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

précédent sommaire suivant

Format final du prototype papier n°1:

Maintenance Management Report

Pride Drill Ship

Period from xxxx to yyyyy

Preventive Maintenance: MMR v0.1b

Note: Overdue is after 25% of the period of the PM.

Corrective Maintenance:

Top 10 list of the CM man hours consumption:

Equipment down:

Major PM prevision: Over 2 Years, or 10000h for the next month.

Etapes de construction du prototype quantitatif.

Les choix de réalisation des prototypes:

Afin de nous permettre de visualiser et d'extraire les données se trouvant dans les tables, nous avons choisi d'utiliser la base de donnée MS-Access comme une sorte d'AGL de départ. En effet, comme nous l'avons vu dans la présentation des ressources informatiques, les outils fournis avec Maximo ne présentent pas l'aspect pratique de MS-Access pour effectuer des requêtes ni pour représenter les données simplement sans programmation complexe.

MS-Access peut se lier à des tables ou importer les données de "SQL base" par l'intermédiaire d'ODBC. Nous importerons les données, car certaines requêtes MS-Access ne sont pas acceptées par ODBC.

Le premier prototype se fera dans un premier temps sous MS-Access avec les outils graphiques de base et des extensions "VB Access". Il permettra d'obtenir les premières informations utilisables pour donner du contenu au format proposé pour le "Prototype n°1" dans le chapitre précédent.

Le prototype MS-Access sera ensuite transcrit après validation du format dans le langage de programmation SQR utilisé pour la génération de rapport dans Maximo. Nous aurions pu utiliser Cristal Report, mais nous n'en disposons pas de licence et les développeurs du siège social ne l'utilisent pas.

Afin de pouvoir vérifier les chiffres plus facilement et pour faciliter la mise en page de tableaux sans avoir à tout construire, nous avons pris pour option d'utiliser les données de MS-Access, mais de faire le rapport dans Excel en utilisant les commandes de "VB-Access". Le format tabulaire d'Excel permet une mise en forme tabulaire plus pratique que MS-Access.

Installation de Maximo sur le poste de développement:

La machine de développement est un portable Dell Latitude C510, 40Go disque dur, 1Go ram.

L'installation se fera en locale et nous n'utiliserons pas les possibilités "Windows Terminal Server" des serveurs pour effectuer les développements. Cela permettra de rester indépendant des sites ou l'auteur se trouvera.

Les serveurs ne seront utilisés que lors de la finalisation du projet juste avant le déploiement de la première version jugée opérationnelle.

Etapes de l'installation:

- Installation standard de "Maximo SQLserver 4.0.3i". Nous ne disposons pas de la version "SQL base" sur la base LDA.

- Installation de Centura "SQL base 6.1.2" séparément.

- Installation des outils de développement "Visual Scribe".

- Installation des patches 1 & 2 de Maximo.

- Installation d'ODBC pour "SQL base", "Centura SQLbase 32-bits driver NT&95". La tentative de mise à jour vers la version "Gupta SQLbase 8.01" n'a pas donné de résultats probants avec MS-Access.

- Chargement des fichiers .DBS des bases de test en provenance de plusieurs chantiers:

Le nom des répertoires sera au format C:\Centura\<nom chantier>.

Le nom du fichier de la base de donnée doit avoir le même nom que celui du répertoire C:\Centura\<chantier1>\<chantier1>.DBS.

- Déclaration des bases de données dans ODBC:

Le DSN se nommera du nom de la base suivie du suffixe -O.

Par exemple: PANGOLA-O pour le "Database Name" PANGOLA.

Le nom du serveur est "server1".

Les bases devront être définies dans le fichier MAXIMO.INI. Voir dans les lignes suivantes.

Figure 16 "SQR4" configuration ODBC.

- Configuration des fichiers .INI des répertoires C:\max403 et C:\Centura et C:\WINNT. A noter que ces répertoires seront à un emplacement différent sur les futurs serveurs.

è MAXIMO.INI:

Vérifier les chemins des différents répertoires qui doivent pointer sur C:.

Les connexions ODBC doivent être déclarées dans ce fichier sous la forme

SQR4_SQLBASE_ODBC:{Database Name}={Data source name}

Exemple: SQR4_SQLBASE_ODBC:PANGOLA=PANGOLA-O pour la base PANGOLA.

è SQL.INI:

Il existe un fichier SQL.INI dans les répertoires C:\MAX403 et C:\CENTURA. Les deux doivent être modifié pour pointer sur les bases de données déclarées dans le répertoire C:\CENTURA.

Pour configurer ces fichiers, on utilise le programme SQLEDIT.EXE se trouvant dans chacun

des répertoires.

Figure 17 "SQLedit" Ecran principal.

On effectuera deux configurations: Une pour le "Serveur" et l'autre pour le "Client" sur le même poste.

Etant en local nous utiliserons une connexion par "Anonymous pipe" dans l'environnement "Windows NT single User".

Les installations des serveurs opérationnels sont aussi locales mais "Multi Users". En effet, la connexion par "Windows Terminal Server" n'implique aucune connexion client-serveur distante pour l'utilisation de Maximo. Certains sites sont encore installés avec une version client-serveur, mais ils devraient être migré dans le courant de l'année 2004.

Les figures suivantes décrivent les détails de chaque écran de configuration:

Figure 18 "SQLedit" détails de la configuration.

Le contenu du fichier SQL.INI doit ressembler à ce qui suit:

[dbnt1sv] ! Déclaration pour le serveur

! Déclaration de quatre bases de données.

dbname=PAFRICA,SQLAPIPE

dbname=PANGOLA,SQLAPIPE

dbname=PNA,SQLAPIPE

dbname=PSP,SQLAPIPE

servername=server1,sqlapipe ! Le nom du pipe

centurydefaultmode=0

! Les répertoires d'installation, ils seront sur D: dans les serveurs

dbdir=C:\Centura

logdir=C:\spl

tempdir=C:\temp

[win32client] ! Déclarations du nom client

clientname=PJUNG

[win32client.dll]

comdll=sqlapipe

è SQR.INI:

Il se trouve dans c:\winnt. Il contient les spécificités propres à SQR en particulier les configurations régionales.

Il nous permettra d'obtenir le cas échéant les chemins de certains éléments de SQR.

Analyse des données et des écrans:

Une partie de l'analyse des tables de Maximo ainsi que la correspondance avec les champs des écrans ont déjà été faits dans le chapitre d'analyse de l'existant. Toutefois, certaines tables ne sont pas visualisables facilement dans Maximo et le fonctionnement de certains écrans devra être analysé dans les détails. L'exploration des tables nous a aussi permis d'éliminer celles qui n'étaient pas utilisées.

Après examen d'une part des écrans, mais aussi par exploration des données des différentes tables, on peut donner la liste des tables qui nous concernent pour la création du prototype:

- EQUIPMENT: Qui est la table des équipements.

- EQSTATUS: Qui contient l'historique des statuts Up/Down des équipements (opérationnel ou pas).

- EQHISTORY: Contiens l'historique des compteurs ou "Meter-Readings" d'un équipement.

- PM: Contiens la liste des PM du chantier.

- WORKORDER: Est la table des "Work Order".

- WOSTATUS: Contiens l'historique du statut des "Work Order".

- MATUSETRANS: Contiens les transactions des pièces de rechange. Elle nous servira pour déterminer les coûts des pièces consommées dans un WO.

- VALUELIST: Contiens un certain nombre de valeurs prédéfinies. Les valeurs d'une liste sont obtenues en fonction du champ LISTNAME. Les listes sont configurables dans le menu "Application setup".

Nous avons rencontré certaines anomalies dans les tables. En voici la liste:

WOSTATUS:

- Les dates de chaque statut peuvent être identiques pour des statuts différents. Cela ne permet pas toujours de les remettre en ordre chronologique. C'est ce que représente l'exemple suivant. Il nous faudra trouver des artifices pour remettre les historiques dans un ordre cohérent.

EQSTATUS:

- Si l'on suit la chronologie des équipements Up/Down, certains équipements sont restés Down dans les historiques, mais sont marqués Up dans la table EQUIPEMENT. Il nous faudra toujours comparer l'état actuel de l'équipement avec celui des historiques.

WORKORDER:

- Les champs obligatoires WOJP1 qui contiennent le département contiennent d'anciennes valeurs non référencées dans la liste proposée par les utilisateurs. On considérera l'équivalence suivante pour les cas identifiés:

'ELE'=CE, 'MEC'=CM, 'STS'=STP, 'MEC/MOT'=CM, 'JRTP'=STP, 'RIGENG'=STP.

Tous les autres cas seront indiqués dans une colonne "Other" que nous rajouterons le cas échéant dans la liste des départements.

- Les statuts WAPPR, APPR et INPRG sont utilisés de façon peu orthodoxe. Il existe des allers et retours entre les différentes valeurs qui sont inexplicables par rapport aux procédures d'usage. Cela tend à démontrer que ces notions ne sont pas claires pour les utilisateurs.