Intégration du standard d'échange WITSML dans les applications pétrolières

HAL Id: dumas-01298832

https://dumas.ccsd.cnrs.fr/dumas-01298832

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Intégration du standard d’échange WITSML dans les

applications pétrolières

Emmanuel Gonnot

To cite this version:

Emmanuel Gonnot. Intégration du standard d’échange WITSML dans les applications pétrolières. Ingénierie, finance et science [cs.CE]. 2015. �dumas-01298832�

CONSERVATOIRE NATIONAL DES ARTS ET METIERS Rhône-Alpes, centre de Lyon

___________________ MEMOIRE

présenté en vue d'obtenir le DIPLOME D'INGENIEUR CNAM

SPECIALITE : Informatique OPTION : Systèmes d'Information

par

Emmanuel GONNOT ___________________

Intégration du standard d'échange WITSML dans les applications pétrolières Soutenu le 10 juin 2015

_________________

JURY

PRESIDENT : Christophe PICOULEAU Enseignant au CNAM Paris Professeur des Universités

MEMBRES : Bertrand DAVID Enseignant au CNAM Lyon Enseignant responsable, Professeur des Universités ECL Lyon

Claude GENIER Enseignant au CNAM Lyon

Administrateur du CERN E.R.

Boris HERBINIÈRE-SÈVE Drillscan France

Responsable Développement IT

Ludovic MACRESY Drillscan Energy

Intégration du standard d'échange WITSML dans les applications pétrolières

R

EMERCIEMENTS

Je tiens, tout d'abord, à remercier Boris HERBINIÈRE-SÈVE pour m'avoir suivi durant la réalisation de ce projet. Il m'a fait partager son expérience grâce à ses conseils et ses recommandations.

Je voudrais également remercier la société Drillscan, et notamment le président de la holding Drillscan Energy, Ludovic MACRESY, grâce à qui ce projet a vu le jour et pour qui le standard WITSML nécessite de devenir une référence dans le monde du forage, mais également Régis STUDER, Directeur Général, et Christophe SIMON, Gérant et fondateur de Drillscan France, pour leur implication et leur soutien.

Je souhaite aussi remercier toute l'équipe de développement et d'ingénierie métier pour leur aide précieuse et les connaissances qu'ils m'ont apportées afin d'atteindre mes objectifs.

Enfin, je remercie Bertrand DAVID, enseignant référant au CNAM Lyon, pour ses conseils et sa disponibilité.

Intégration du standard d'échange WITSML dans les applications pétrolières

T

ABLE DES MATIERES

Remerciements ... i

Table des matières ... iii

Table des illustrations ... vii

Introduction ... 1

Chapitre 1 Cadre du projet ... 3

1.1. Contexte ... 3 1.1.1. Présentation ... 3 1.1.2. Drillscan ... 4 1.1.2.1. La société ... 4 1.1.2.2. Ses logiciels ... 5 1.1.2.3. Ses services ... 5

1.1.3. Principes généraux de forage ... 5

1.1.3.1. Architecture de puits ... 6

1.1.3.2. Garniture de forage ... 7

1.1.3.3. L'appareil de forage ... 9

1.2. Projet WITSML ... 11

1.2.1. Le standard d'échange de données WITSML ... 12

1.2.1.1. Principe ... 12

1.2.1.2. Les livrables ... 12

1.2.1.3. L’interface de programmation (API) ... 15

1.2.1.4. Le dictionnaire d’unités de mesure ... 17

1.2.2. Les imports / exports existant ... 18

1.2.2.1. Le module Database ... 18

1.2.2.2. Les objets principaux ... 19

1.3. Bilan du cadre du projet ... 24

Chapitre 2 Analyse et conception ... 27

2.1. Le besoin ... 27

2.1.1. Exigences & contraintes ... 27

2.1.1.1. Fonctionnalités ... 27

2.1.1.2. Contraintes techniques et fonctionnelles ... 28

2.1.2. Cas d'utilisations ... 28

2.1.2.1. La sélection d'éléments ... 29

Table des matières

2.1.2.3. L'export ... 30

2.1.2.1. La gestion des Wells et Wellbores ... 30

2.1.3. Maquettes ... 31

2.1.3.1. Import et export ... 31

2.1.3.2. Écran de sélection et de gestion des serveurs ... 31

2.1.3.3. Écran de sélection d'éléments ... 32

2.1.3.4. Écran de sélection et de gestion des Wells et Wellbores ... 32

2.2. Architecture ... 32

2.2.1. Les enjeux et objectifs ... 33

2.2.1.1. Généralité ... 33

2.2.1.2. L'architecture actuelle ... 33

2.2.1.3. Évolutions et solutions envisagées ... 35

2.2.2. Le patron de conception Model-View-Presenter ... 36

2.2.2.1. Présentation... 36 2.2.2.2. Les interfaces ... 37 2.2.2.3. View ... 38 2.2.2.4. Presenter ... 39 2.2.2.5. Model ... 39 2.2.3. La couche de données ... 39

2.2.3.1. Les modèles de données existants ... 40

2.2.3.2. Correspondances d'objets ... 41

2.2.3.3. Conversion Drillscan / WITSML ... 46

2.3. Bilan de l'analyse et de la conception ... 51

Chapitre 3 Réalisation et tests ... 53

3.1. Méthode agile ... 53

3.1.1. Itérations... 53

3.1.1.1. Développement dirigé par les tests (TDD) ... 53

3.1.1.2. Intégration continue ... 54

3.1.2. Gestion du projet ... 56

3.1.2.1. Backlog produit ... 56

3.1.2.2. Suivi de projet ... 58

3.1.2.3. Découpage des tâches ... 59

3.1.3. Release Wellscan 3.6 & Bitscan 1.2 ... 60

3.1.3.1. Plan de release ... 60 3.1.3.2. Stabilisation ... 60 3.2. Tests ... 61 3.2.1. Tests unitaires ... 61 3.2.1.1. DUnit ... 62 3.2.1.2. Doublures de tests ... 63

3.2.2. Tests techniques & fonctionnels ... 65

3.2.2.1. Tests d'intégration ... 65

3.2.2.2. Tests de performances et de stabilité ... 66

3.2.2.3. Tests de validation métier ... 67

Intégration du standard d'échange WITSML dans les applications pétrolières

3.3.1. Gestion des tickets ... 68

3.3.2. Problèmes majeurs rencontrés ... 69

3.3.2.1. Mauvaises performances ... 69

3.3.2.2. Défaut de l'algorithme de conversion des logs ... 70

3.3.2.3. Non correspondance des éléments des Drillstrings ... 70

3.3.2.4. Litige sur l’architecture logiciel ... 71

3.3.3. Solutions apportées ... 71

3.3.3.1. Ajout d’un système de mise en cache ... 71

3.3.3.2. Modification de l’algorithme de conversion des logs ... 73

3.3.3.3. Refonte des éléments des Drillstrings de Drillscan ... 73

3.4. Bilan de la réalisation ... 74

Conclusion ... 77 Glossaire ... I Table des abréviations ... VII Bibliographie ... IX Annexes ... XIII Annexe A. Organigramme hiérarchique ...XIV Annexe B. Nomenclature de dimension ... XV Annexe C. Correspondance d'unités ...XVI Annexe D. Modèle de données Drillscan ... XVIII Annexe E. Modèle de données WITSML ... XX Annexe F. Exemple de log WITSML v1.4.1.1 ... XXIII

Intégration du standard d'échange WITSML dans les applications pétrolières

T

ABLE DES ILLUSTRATIONS

Figure 1-1 : Exemple de programme de casing de Wellscan® ... 6

Figure 1-2 : Outil tricône (Society of Petroleum Engineers, 2013) ... 7

Figure 1-3 : Outil PDC (Varel International, Inc, 2014) ... 8

Figure 1-4 : Exemple de BHA de Build-Up issu de Wellscan® ... 9

Figure 1-5 : Nomenclature d'un chantier de forage (West & West, 2008) ... 10

Figure 1-6 : Ajout de tige de forage (Nguyen, 1993) ... 11

Figure 1-7 : Entrepôt des données d'un site de forage (Energistics, 2014) ... 12

Figure 1-8 : Relation entre les versions des différents composants (Energistics, 2014) . 14 Figure 1-9 : Exemple d'implémentation de Publish (Petrotechnical Open Standards Consortium, Inc (POSC), 2005) ... 16

Figure 1-10 : Module Database ... 18

Figure 1-11 : Saisie du format d'import ... 19

Figure 1-12 : Trajectoire de forage ... 20

Figure 1-13 : Well log (The University of Kansas, 1994) ... 21

Figure 1-14 : Panneau de saisie d'un assemblage de forage ... 22

Figure 1-15 : Formation géologique (Barrier & Montenat, 2002) ... 23

Figure 1-16 : Diagramme des relations entre objets d'un site de forage ... 24

Figure 2-2 : Cas d'utilisation "Gestion des serveurs" ... 29

Figure 2-1 : Cas d'utilisation "Sélection d'éléments" ... 29

Figure 2-5 : Cas d'utilisation "Gestion des Wells / Wellbores" ... 30

Figure 2-3 : Cas d'utilisation "Export" ... 30

Figure 2-4 : Cas d'utilisation "Import" ... 30

Figure 2-6 : Écran de sélection et de gestion des serveurs ... 31

Figure 2-7 : Écran de sélection d'objets ... 32

Figure 2-8 : Écran de sélection de Wellbore ... 32

Figure 2-9 : Patron de conception MVP ... 37

Figure 2-10 : Patron de conception MVC ... 37

Figure 2-11 : Interfaces de la View de l'écran de sélection de serveur WITSML ... 38

Figure 2-12 : Exemple d'interface du Presenter de sélection de server WITSML ... 39

Figure 2-13 : Log WITSML en version 1.4.1.1 ... 40

Figure 2-14 : Log WITSML en version 1.3.1.1 ... 40

Figure 2-15 : Assistant de génération XSD ... 47

Table des illustrations

Figure 2-18 : Traducteur & constructeur d'objets / chaine XML ... 51

Figure 3-1 : TortoiseHg® _{... 55}

Figure 3-2 : Vue d'ensemble du cadre d'exécution de Scrum (Scrum.org, 2015) ... 59

Figure 3-3 : Workflow de développement de Drillscan ... 61

Figure 3-4 : Application hôte de DUnit ... 62

Figure 3-5 : Graphe des appels issu d’AQtime ... 66

Figure 3-6 : Logiciel de gestion de tickets et de projets JIRA d'Atlassian ... 68

Figure 3-7 : Patron de conception Proxy ... 72

Figure Annexe 1 : Organigramme hiérarchique ...XIV Figure Annexe 2 : Diagramme de classe - Modèle de données Drillscan ... XVIII Figure Annexe 3 : Modèle de données WITSML ... XXII Tableau 1-1 : Hiérarchie des fichiers WITSML ... 15

Tableau 2-1 : Dimensions des composants graphiques de Drillscan... 28

Tableau 2-2 : Correspondance des wells et wellbores ... 41

Tableau 2-3 : Correspondance des trajectoires ... 42

Tableau 2-4 : Correspondance des logs ... 43

Tableau 2-5 : Correspondance des assemblages de forage ... 44

Tableau 2-6 : Correspondance des formations géologiques... 45

Tableau 2-7 : Correspondance des programmes de cuvelage ... 46

Tableau 2-8 : Arborescence du code source généré ... 47

Tableau 3-1 : Backlog produit ... 58

Tableau 3-2 : Serveurs de tests WITSML Kongsberg SiteCom® _{... 65}

Tableau Annexe 1 : Nomenclature de dimension pour l'UOM Dictionary (Energistics, 2014) ... XV Tableau Annexe 2 : Correspondances des unités Drillscan / Energistics UOM Dictionary ... XVII Tableau Annexe 3 : Description des classes du modèle données Drillscan ... XIX Code source 1-1 : Déclaration de type complexe XML (Petrotechnical Open Standards Consortium, Inc (POSC), 2005) ... 14

Code source 1-2 : Exemple de requête WITSML ... 15

Code source 1-3 : Exemple d'objet WITSML ... 16

Code source 2-1 : Exemple de déclaration d'interface en langage Delphi (Dardenne, 2007) ... 37

Code source 2-2 : Exemple d'instanciation et d'utilisation d'interface (Dardenne, 2007) ... 38

Code source 3-1 : Exemple de code de test avec Delphi.Mocks ... 63 Code source Annexe 1 : Exemple de log WITSML v1.4.1.1 ... XXIII

Intégration du standard d'échange WITSML dans les applications pétrolières

I

NTRODUCTION

L'ingénierie de forage contemporaine utilise des modèles mathématiques complexes, nécessitant un support informatique puissant, afin de réaliser des calculs scientifiques. La plupart des logiciels de forage utilisent des solutions propriétaires pour l'acquisition et l'échange de données, ce qui rend difficile leurs interactions (Energistics, 2014). Une volonté d'uniformisation de la part des acteurs majeurs du marché logiciel d'ingénierie E&P (Exploration & Production), opérateurs de forage, et fabricants de matériels de mesures, ont conduit à la création d'Energistics, un consortium dont le but est de spécifier et développer des standards ouverts et libres (Energistics, 2014).

La société Drillscan, dans laquelle je suis employé, développe des logiciels scientifiques pour le forage d'exploration et la conception d'outils diamantés. Actuellement, l'acquisition des données dans ces logiciels ne peut se faire que par l'intermédiaire de fichiers textes ou de saisies utilisateurs, ce qui constitue un inconvénient majeur, et une difficulté pour l'utilisateur, surtout sur de grands volumes. Le support du WITSML, un standard d'échange de données spécialisé dans le forage d'exploration et de développement proposé par Energistics, un consortium d’industriels, pourrait ainsi améliorer l'ergonomie lors des phases d'import et d'export des données, et constituer une valeur supplémentaire face aux produits concurrents.

Quelle est la solution optimale pour intégrer le standard d'échange WITSML dans l'architecture applicative et le rendre compatible avec la structure de données actuelle, et comment procéder à sa réalisation ?

La solution qui a été choisie se base sur le principe de séparation des préoccupations afin de faciliter la maintenance et l'évolutivité. Ce document décrit le processus de conception et de réalisation, ainsi que les connaissances et les techniques qui ont été nécessaires à sa mise en œuvre. Le chapitre 1 reprend les principes généraux du forage afin de définir les termes et les objets manipulés. Des

Introduction

notions de forage permettent une compréhension plus aisée des objets et des procédures métier. Le chapitre 2 porte sur l’analyse des solutions techniques et fonctionnelles, leurs avantages et inconvénients, et les choix qui ont été retenus. Le chapitre 3 détaille le processus d'implémentation et d'intégration des fonctionnalités d’import et d’export dans les logiciels de Drillscan, ainsi que les problèmes rencontrés et les solutions apportées. Le bilan de la réalisation du projet et les fonctionnalités restant à implémenter sont exposés dans la conclusion.

Intégration du standard d'échange WITSML dans les applications pétrolières

Chapitre 1

C

ADRE DU PROJET

Avant de débuter tout projet, il convient de comprendre les besoins qui le motivent et l'environnement dans lequel il s'exécute. Le forage, dans l'industrie pétrochimique et l'extraction des ressources fossiles, nécessite un minimum de connaissances métiers afin d'être appréhendé correctement.

1.1. C

ONTEXTE

L'utilisation des hydrocarbures est profondément ancrée dans la société contemporaine, et son exploitation relève d'un processus industriel complexe, comportant des risques environnementaux relativement importants. C'est pour réduire ces risques que des études sont menées grâce à des logiciels scientifiques, comme ceux produits par la société Drillscan.

1.1.1. P

Les hommes recherchent continuellement de nouvelles sources d'énergies afin de subvenir à leurs besoins, se chauffer, travailler ou encore se déplacer (TOTAL Sa, 2010). Après le charbon, largement utilisé au cours du XIXème _{siècle, c'est une autre} ressource fossile, le pétrole, qui domine l'économie mondiale. Il fut découvert à la fin du même siècle et a contribué à l'accélération des progrès technologiques, notamment dans les transports et l'industrie, et a été un élément déterminant de la révolution industrielle au début du siècle dernier. Il s'est même imposé, avec le gaz naturel auquel il est étroitement lié, comme une ressource primordiale, voire même indispensable au fonctionnement de la société contemporaine (La Documentation Française, 2011).

C'est d'ailleurs cette dépendance qui a mené les grandes puissances mondiales aux chocs pétroliers de 1973 et 1979, puis d'une moindre envergure, en 2008. Le

Chapitre 1 Cadre du projet - Contexte

caractère non renouvelable de ces ressources nous conduit inévitablement vers un épuisement des réserves mondiales, mais les progrès réalisés dans les matériels et les techniques de forage repoussent sans cesse cette limite. Les rendements sont en nette augmentation et des réservoirs, jusqu'ici inaccessibles, peuvent désormais être exploités, comme par exemple les gaz de schistes qui, bien que soumis à controverse (Favari, et al., 2013), restent une alternative non négligeable pour les opérateurs de forage (Connaissance des Energies, 2013).

L'exemple typique de méthodes scientifiques novatrices est le forage directionnel qui permet d'atteindre une cible lorsque l'accès vertical est proscrit. Il est mis en œuvre grâce à des applications informatiques d'ingénierie qui permettent de calculer les différents paramètres de forage à appliquer sur l'assemblage de forage, afin de respecter la trajectoire à suivre. Les mesures, ou diagraphies instantanées, permettent de contrôler la progression, la corriger, et éviter certains incidents, mais sont également utilisées comme ressources pour les calculs ultérieurs. Elles constituent les données de base des logiciels scientifiques de forage. L'échange de ces données est une opération incontournable, et la quantité d'équipements de mesures disponibles sur le marché n'en facilite pas l'acquisition. Il en est de même pour les logiciels de forage qui utilisent, pour la plupart, des modèles de données propriétaires.

La normalisation d'un format de données s'est donc fait ressentir. Un consortium d'industriels, Energistics, a donc été créé en octobre 1990 dans le but de spécifier des standards d'échange de données liées au forage et à l'exploitation pétrolière et gazière. Parmi ces standards, WITSML (Wellsite Information Transfert Standard Markup Language), se fonde sur le langage de description à balise XML et décrit l'ensemble des structures de données spécifiques au forage d'exploration, ainsi que leur accès au travers de Web Services. L’utilisation des technologies web et de XML lui permette d’être indépendant de la plateforme et du langage de l’environnement dans lequel il est utilisé.

1.1.2. D

Drillscan est une société qui commercialise des logiciels pour l'industrie du forage, ainsi que des services et des études scientifiques d'aide à la gestion des puits et des assemblages de forage.

1.1.2.1. L

La société Drillscan fut fondée en 2001 par Christophe SIMON avec un capital de 8000 €, afin de développer un logiciel d'ingénierie pétrolière sous le nom BHA Management®. L'idée est née d'une collaboration entre le fondateur de Drillscan et la société Total. Cette dernière était à la recherche d'un produit capable de réaliser des calculs pour le forage directionnel, le marché étant très peu développé dans ce secteur.

Intégration du standard d'échange WITSML dans les applications pétrolières En 2011 Drillscan a étendu son activité à l'international avec la création d'une holding, Drillscan Energy, dirigée par Ludovic MACRESY, et d'une filiale basée à Houston (USA). Le groupe compte désormais plus de 20 collaborateurs, et génère un chiffre d'affaires de plus de 1,6 millions d'euro (en 2013).

Le groupe souhaite grandir davantage, avec la création de nouvelles filiales de par le monde, et devenir une référence dans le domaine de l'ingénierie pétrolière, en couvrant de nouveaux secteurs, tels que la géomécanique et la géophysique, et des consolidations de l'existant comme les calculs temps réel.

1.1.2.2. S

Drillscan produit actuellement deux logiciels liés au forage. Wellscan®, à l'origine de la création de la société sous le nom BHA Management®, est destiné à la gestion des assemblages de forage en proposant des fonctionnalités d'analyse scientifique sous la forme de modules indépendants. Certains de ces modules sont spécialisés dans le calcul directionnel, la correction de trajectoires, l'étude du comportement des assemblages, ou encore l'élaboration d'un assemblage optimal en fonction de l'action à réaliser.

Le second logiciel, Bitscan®, permet de concevoir des designs d'outils de forages diamantés (PDC bit). Il est conçu sur une architecture similaire à Wellscan®, et fonctionne sur le même modèle à base de modules. Certains permettent, entre autre, de simuler l'utilisation d'un outil, prévoir son usure, ou encore calculer ses caractéristiques de performances.

1.1.2.3. S

Drillscan propose des services d'ingénierie, comme par exemple la réalisation d'études. Pour des opérateurs qui ne souhaitent pas investir dans un logiciel de forage, les calculs sont réalisés en interne et les résultats lui sont ensuite transmis.

D'autres services sont également disponibles, comme la sous-traitance ou l'assistance lors d'opérations de forage, ou encore le sauvetage de puits lors d'incident. Des équipes sont alors déléguées sur les lieux du forage pour diriger les opérations. Wellscan® permet de réaliser les calculs scientifiques nécessaires pour atteindre leurs objectifs.

Des équipes dispensent également des formations, notamment sur les logiciels de Drillscan, et sur l'optimisation de leur utilisation.

1.1.3. P

Afin d'appréhender le projet de manière optimale, il convient de définir les principes de base, les termes et les objets relatifs au monde du forage, et d'en comprendre les différentes interactions.

Chapitre 1 Cadre du projet - Contexte

1.1.3.1. A

Le forage pétrolier et gazier nécessite une méthodologie et une rigueur toute particulière afin de réaliser la construction d'un puits d'exploitation en toute sécurité, et dans les meilleures conditions.

1.1.3.1.1. PROGRAMME DE FORAGE

Le programme de forage est une phase primordiale de la construction d'un puits. En fonction du type de réservoir, de son débit et de l'estimation des conditions de forage, on détermine le diamètre nominal de la dernière section à forer (Aadnoy, et al., 2009). On doit prévoir la pose de cuvelages (ou casing), de ciment, et d'équipements de production. De là, on établit le programme de forage en fonction des différents types de formations à traverser, en partant du fond et en remontant vers la surface (Nguyen, 1993), le diamètre intérieur de chaque section devant être plus large que le diamètre extérieur de la section inférieure (Bret-Rouzaut & Favennec, 2011). Les règles, pour le choix de ces

diamètres, sont dictées par le métier et ne sont pas détaillées ici (Nguyen, 1993).

La boue de forage qui circule dans l'assemblage de forage et remonte par l'annulaire du puits, répond elle aussi à des règles strictes en fonction des formations traversées (porosité, venue de fluide, etc.) (Aadnoy, et al., 2009). Elle permet d'évacuer les débris de roche arrachés par l'outil, de refroidir l'assemblage et l'ensemble du puits, mais également de maintenir une pression constante dans le puits afin d'éviter toute infiltration de fluide étranger (Nguyen, 1993).

Après avoir foré une section, on

procède à la pose d'un casing, conformément au programme établi, puis à sa cimentation. Une fois cette opération terminée et le délai de séchage respecté, on fore la section suivante de diamètre inférieur (Bret-Rouzaut & Favennec, 2011), et ainsi de suite jusqu'à atteinte de l'objectif (Nguyen, 1993).

1.1.3.1.2. TYPES DE COLONNES

Comme on peut le voir sur le schéma de la figure 1-1, les casings sont superposés, pour la plupart, à des profondeurs différentes. La première colonne est le tube guide (Conductor Pipe) qui permet de canaliser la boue et contenir les terrains meubles de la surface.

On trouve ensuite la colonne de surface qui constitue l'étanchéité du puits, et qui est donc entièrement cimentée. Elle sert de support aux obturateurs (BOP), qui

Figure 1-1 : Exemple de programme de casing de Wellscan®

Intégration du standard d'échange WITSML dans les applications pétrolières peuvent fermer le puits en cas de reflux ou de surpression importante afin d'éviter tout accident (Nguyen, 1993). Certains BOP sont même capables de sectionner la tige de forage si besoin. La solidité de cette section est donc primordiale (Aadnoy, et al., 2009).

Viennent après la colonne de surface, une ou plusieurs colonnes intermédiaires en fonction de la profondeur et de la résistance nécessaire pour garantir la sécurité du puits. Leur cimentation ne s'effectue en général que sur quelques centaines de mètres (Bret-Rouzaut & Favennec, 2011).

La colonne de production est un des derniers éléments du puits et elle reçoit les dispositifs d'exploitation du réservoir. Elle peut être suivie d'une colonne perdue (liner), comme c'est le cas dans le programme de cuvelage de la figure 1-1, plus légère et plus économique, mais, en contrepartie, également plus complexe à mettre en place et plus fragile (Nguyen, 1993).

1.1.3.2. G

La garniture de forage (Drill String) est l’assemblage d’éléments qui sont descendus dans le puits et mis en rotation depuis la surface. C'est elle qui va permettre de transmettre le couple à l’outil et lui appliquer le poids nécessaire.

1.1.3.2.1. OUTILS DE FORAGE

L'outil est l'élément principal et indispensable au forage car il est directement en contact avec la roche. C'est lui qui détruit la roche sous l'effet du poids qui lui est appliqué. On choisit le type d'outil en fonction du type de formation à traverser, et de l'action à réaliser, mais on ne détaille pas ici les techniques scientifiques qui permettent de déterminer ce choix.

OUTILS A MOLETTES

Les outils à molettes, aussi nommés Tricônes, se composent d’un corps circulaire, généralement surmonté de trois bras répartis sur sa circonférence. Chaque bras comprend un axe sur lequel s'articule un cône autour d'un roulement à bille. Ces cônes comprennent des dents, soit moulées, soit insérées, capables de cisailler ou de faire éclater la roche.

Comme nous l'avons vu à la section 1.1.3.1.1, l'hydraulique est un facteur clé de performance. Des duses sont réparties sur le corps afin d'irriguer l’outil et le fond de trou de la manière la plus homogène possible.

L’utilisation des outils à molettes reste relativement limitée du fait de leur faible durée de vie, due notamment à l’usure des roulements (Nguyen, 1993).

Figure 1-2 : Outil tricône (Society of Petroleum

Chapitre 1 Cadre du projet - Contexte OUTILS DIAMANTES

Il existe deux familles d’outils diamantés. Tout d’abord, les outils à diamants naturels se composent d’un corps monobloc recouvert d’une matrice dans laquelle sont moulés les diamants. Ce type d’outils abrase la roche. La taille et la quantité de diamants varient selon le type de formation et la vitesse de progression recherchée.

La seconde catégorie comprend les outils PDC. Comme les outils à diamants naturels, ils se composent d’un corps monobloc, possédant des lames réparties sur sa révolution. On vient usiner des logements cylindriques sur la surface de ces lames afin d’y insérer des pastilles de diamants polycristallins. Ces pastilles viennent cisailler la roche en prélevant des copeaux qui sont évacués grâce à des duses réparties sur le corps, de part et d’autre des lames.

Le caractère monobloc confère une certaine solidité aux outils diamantés, ce qui les rend plus intéressants économiquement que les outils à molettes dans certaines situations. On les trouve également sous forme de couronnes, qui permettent le prélèvement de carottes rocheuses pour l’analyse des formations traversées (Nguyen, 1993).

1.1.3.2.2. TIGES

Les tiges sont des éléments tubulaires, qui constituent les équipements de fond principaux. Ils transmettent l'énergie fournie en surface jusqu'à l'outil de forage, et permettent la circulation de la boue de forage. On trouve plusieurs types de tiges (Aadnoy, et al., 2009).

Les tiges essentielles à l'application du poids sur l'outil (WOB) sont les masses tiges (Drill Collar). Elles présentent un diamètre intérieur réduit au maximum afin d'avoir une masse la plus élevée possible et une grande rigidité, afin d'éviter le phénomène de flambage. Généralement, les masses tiges sont positionnées au plus près de l'outil, afin de garder l’assemblage de forage en tension constante (Nguyen, 1993).

Les tiges de forage (Drill Pipe) font la jonction entre l'assemblage de fond de trou (BHA) et la surface. Elles composent la plus grande partie de l'assemblage de forage et reçoivent la majorité des efforts, autant en traction, qu'en flexion (Aadnoy, et al., 2009). C'est pourquoi elles font l'objet d'une attention particulière, car la fatigue de ces tiges risque de conduire à une rupture, qui forcerait l'équipe de forage à procéder à un repêchage (Fishing) pour tenter de récupérer l'assemblage (Nguyen, 1993).

On peut trouver également, principalement en forage directionnel, des tiges de forage intermédiaire (Heavy Weight Drill Pipe) afin de créer du poids supplémentaire,

Figure 1-3 : Outil PDC (Varel International, Inc, 2014)

Intégration du standard d'échange WITSML dans les applications pétrolières juste avant le changement de direction (Kick Off Point). Elle présente également une meilleure résistance que les tiges de forage (Aadnoy, et al., 2009).

1.1.3.2.3. ÉQUIPEMENTS DIRECTIONNELS

Pour maîtriser la trajectoire de l'outil, l'assemblage est équipé de stabilisateurs (Stabilizer), qui procèdent au centrage de certaines parties de la BHA. L'effet levier permet de pouvoir agir sur l'inclinaison de la trajectoire, comme sur la figure 1-4. En les plaçant au plus près de l'outil, on peut au contraire maintenir la trajectoire.

Pour modifier l'azimut, on positionne généralement derrière l'outil un élément actif, comme un moteur ou encore un RSS (Rotary Steerable System). Le moteur est muni d'un coude fixe, orienté en surface avant la descente. Il met en rotation l'outil grâce à la circulation de la boue dans l'assemblage, qui lui, reste immobile. Le RSS, quant à lui, peut être piloté depuis la surface ou autonome, et il est préféré aux moteurs dans certains cas.

Figure 1-4 : Exemple de BHA de Build-Up issu de Wellscan®

Un équipement indispensable au forage directionnel est le module de mesure et de télémétrie. En effet, lorsque l'inclinaison du puits ne permet plus aux outils de mesure classique de descendre à l'intérieur de l'assemblage ou du puits, sous l'effet de la gravité, on doit les inclure sur la BHA, au plus près de l'outil de forage (Rigzone.com, 2014). Mais cette technique introduit une contrainte supplémentaire. Alors que les outils de mesure descendus dans le puits avec une liaison filaire peuvent transmettre les informations via le câble, les modules de mesure montés sur la BHA (MWD & LWD) ne le permettent pas. Une partie des informations est donc stockée pour être lue lorsque l'assemblage sera remonté. Les informations requises pour le pilotage et le contrôle de la BHA sont, elles, transmises via des impulsions dans la boue de forage, à l'intérieur de l'assemblage. Un transducteur en surface procède à la démodulation. Le débit de ce type de transmission ne dépasse rarement plus de 30bps.

1.1.3.3. L'

Les moyens nécessaires à la réalisation du puits de forage sont rassemblés en surface et forment l'appareil de forage (Rig). C'est depuis ce chantier qu'on pilote l'assemblage de forage, qu’on lui ajoute ou retire des éléments, qu’on le met en rotation et qu’on ajuste le poids appliqué sur l'outil (Bret-Rouzaut & Favennec, 2011).

Chapitre 1 Cadre du projet - Contexte 1.1.3.3.1. LEVAGE

L'élément principal de l'appareil est la tour de forage, car c'est elle qui conditionne la capacité du chantier. Selon sa hauteur et sa résistance, on peut entreprendre des forages plus ou moins profonds. La tour peut être, par exemple, un derrick (Figure 1-5), préféré en off-shore pour sa robustesse, ou encore un mât de levage.

La tour de forage doit supporter le poids de la garniture dans son intégralité au niveau du crochet de levage (Hook). Il est relié à un treuil par un câble métallique. La garniture est fixée au crochet par l’intermédiaire de la tête d'injection de boue, et la tige carrée d'entrainement (Kelly). En ajustant avec précision la hauteur du crochet, on réduit ou on augmente ainsi le poids de l'assemblage sur l'outil, en le "retenant". (Nguyen, 1993)

Le poids au crochet (WOH ou Hook Load) est la donnée la plus importante. Il fait l'objet d'une attention particulière de la part du chef de chantier. En le soustrayant au

Figure 1-5 : Nomenclature d'un chantier de forage (West & West, 2008)

Intégration du standard d'échange WITSML dans les applications pétrolières poids total de la garniture de forage, on connaît ainsi le poids appliqué sur l'outil (WOB) (Aadnoy, et al., 2009).

1.1.3.3.2. ROTATION

Afin de pouvoir attaquer la roche, un outil de forage a besoin d'être mis en rotation. La plupart des opérations de forage sont mises en rotation depuis le chantier de forage, sauf les assemblages munis d'un moteur, qui sont mis en action par simple circulation de boue. La puissance est transmise à la dernière tige de la garniture de forage (tige d'entrainement ou Kelly) par l'intermédiaire de la table de rotation.

Pour l'ajout de tiges, une partie de la table est désolidarisée et remontée avec la partie supérieure de la dernière tige de forage (Figure 1-6). Elle est alors bloquée par un outil de plancher, puis dévissée (A). On revisse alors une nouvelle tige de forage à la tige d'entrainement, puis à la dernière tige restée bloquée à la table de rotation (B). Le tout est ensuite redescendu dans le puits et le forage peut reprendre (C).

1.1.3.3.3. HYDRAULIQUE

Comme il a été vu précédemment, la boue est un élément indispensable au forage, pour évacuer les débris, lubrifier et refroidir l'ensemble des éléments, mais surtout, pour permettre de maintenir les parois du puits Open Hole, et éviter toute venue de fluide.

La pression de circulation est fournie grâce à des pompes en surface, et l'introduction de la boue dans le système s'effectue depuis la tête d'injection (Swivel). Cette dernière est suspendue au crochet de levage, et doit être conçue pour supporter, d'une part, le poids maximum de la garniture, et d’autre part, la vitesse de rotation maximum. L'étanchéité est faite par un joint rotatif à la base de la tête d'injection.

Le retour de boue par l'annulaire est capté au niveau de la table de rotation. La boue est ensuite filtrée, tamisée, puis remise en circulation. Elle fait l'objet de mesure constante de densité, et de viscosité afin d'être conforme au programme de forage (Section 1.1.3.1.1).

1.2. P

ROJET

WITSML

La plupart des applications d’ingénierie et d’analyse pétrolière puisent le plus souvent leurs données d’entrée dans des entrepôts ou des bases de données propriétaires. Leur chargement est un passage incontournable.

Chapitre 1 Cadre du projet - Projet WITSML

1.2.1. L

'

WITSML

WITSML (Wellsite Information Transfert Standard Markup Language) est un standard ouvert et non-propriétaire (Energistics, 2014), disponible gratuitement en téléchargement sur le site d'Energistics. Tout organisme projetant l'utilisation et l'implémentation d'un client ou d’un serveur WITSML peut donc y avoir accès.

1.2.1.1. P

WITSML ne spécifie pas la manière dont les données doivent être stockées. Il s’agit uniquement d’un format d’échange, véhiculé au travers d’un Web Service. Actuellement, WITSML utilise SOAP (Simple Object Access Protocol) comme protocole de transport. Il est indépendant de la plateforme et des systèmes d’exploitation des serveurs et des clients, ce qui lui confère une forte interopérabilité et une grande portabilité.

Figure 1-7 : Entrepôt des données d'un site de forage (Energistics, 2014)

On peut voir sur la figure 1-7, les interactions entre une implémentation de serveur WITSML et les différentes applications en collaboration. Le serveur reçoit les données agrégées et numérisées sur le site de forage, puis les stocke, la plupart du temps dans un format propriétaire, indépendant du XML ou non. Lorsqu'une application cliente initie une requête via le protocole SOAP, le serveur génère le résultat XML à la volée (Energistics, 2014).

1.2.1.2. L

WITSML n'est pas un standard figé, car le métier du forage évolue constamment grâce à de nouvelles technologies, ou de nouvelles techniques. Ces nouveaux éléments doivent donc être spécifiés afin de garantir la pérennité du standard.

Intégration du standard d'échange WITSML dans les applications pétrolières 1.2.1.2.1. VERSIONS

Energistics distribue et développe WITSML, parmi d'autres standards, depuis 2002. Les évolutions technologiques et les besoins émergeants des utilisateurs et des opérateurs de forage ont naturellement conduit au remaniement du standard. Plusieurs versions de WITSML ont ainsi été publiées, en dépréciant certaines devenues obsolètes. Une release du standard comporte plusieurs composants distincts, répartis sur deux archives.

Tout d’abord, la première archive comprend l'ensemble des schémas de données (Data Schema), qui décrivent les objets supportés pour cette release. Le numéro de version est codé sur 4 digits, représentant, dans l'ordre de lecture, la version majeure, la version mineure, la révision majeure, puis la révision mineure. Les changements de révision entraînent le remplacement des livrables de même version (mineure et majeure). Une nouvelle révision n’apporte pas de changement important et n’intégrera pas non plus de nouveaux objets. Une telle modification fera l’objet d’une nouvelle version.

La seconde archive correspond à l'interface de programmation (API) qui gère le transfert, via le protocole SOAP. Elle se compose de documents WSDL qui décrivent les fonctions présentées par le serveur (type de chaque argument et valeur de retour), et des schémas XML de l'API. Ces derniers détaillent les objets WITSML supportés par le serveur et le client, ainsi que les données relatives au logiciel (Version de l’exécutable, contact, nom du serveur/client…).

La version de l'API est codée sur 3 digits (version majeure, mineure et numéro de révision). Une release du Data Schema est liée à celle de l'API. Chaque changement de version du Data Schema, mineure ou majeure (1er _{& 2}e _{digit), est suivi d’un} changement de version de l'API. Le schéma XML de l'API suit également le même procédé.

Les versions antérieures au Data Schema 1.3.1.1 ayant été dépréciées, nous ne nous y intéressons pas dans ce dossier. La version 1.4.1.1 reste la version courante en développement, mais beaucoup de logiciels utilisent encore la version 1.3.1.1. Pour des raisons de rétro compatibilité, elle est toujours maintenue en production, mais ne bénéficie pas de nouvelle intégration. Les deux versions cohabitent donc dans la plupart des implémentations WITSML actuelles.

Chapitre 1 Cadre du projet - Projet WITSML

Figure 1-8 : Relation entre les versions des différents composants (Energistics, 2014) 1.2.1.2.2. SCHEMAS XML

XML Schema est un langage de description de format pour les documents XML qui définit les structures et les types d'objets utilisés dans le document. Les Data Schema de WITSML décrivent les objets principaux (préfixé obj_ et grp_), qui peuvent

être des trajectoires ou des logs par exemple, puis tous les types complexes et simples qu'ils utilisent. Ces derniers sont, soit des composants (préfixés cs_), qui sont

généralement des données relatives aux objets principaux (ex : points des trajectoires, courbes des logs, etc.), soit des types concernant les données numériques et leurs unités (préfixés typ_).

<xsd:complexType name="measuredDepthCoord" final="#all">

<xsd:simpleContent>

<xsd:extension base="witsml:abstractMeasure">

<xsd:attribute name="uom" type="witsml:MeasuredDepthUom" use="required"/>

<xsd:attribute name="datum" type="witsml:refWellDatum" use="optional"/>

</xsd:extension>

</xsd:simpleContent> </xsd:complexType>

Code source 1-1 : Déclaration de type complexe XML (Petrotechnical Open Standards Consortium, Inc (POSC), 2005)

Voici un exemple de code extrait du schéma typ_dataTypes.xsd, qui décrit le type measureDepthCoord correspondant à la profondeur mesurée (MD). On voit qu’il hérite

d’un type de base witsml:abstractMeasure, et comporte un attribut obligatoire nommé

« uom », qui correspond à l’unité dans laquelle la valeur de MD sera exprimée. 1.2.1.2.3. FICHIERS ANNEXES

Chaque release du standard WITSML est livrée avec des documents annexes. Pour l'archive du Data Schema, à chaque objet correspond un fichier XML exemple, avec des données réelles, ainsi qu'un fichier de documentation au format HTML. L'archive de l'API contient également des fichiers XML exemples pour les objets relatifs au serveur et au client, ainsi qu'une documentation détaillée au format Microsoft Word.

Intégration du standard d'échange WITSML dans les applications pétrolières WITSML v1.3.1.1 Data Schema

├ XML_Examples

│ └ *.xml Exemple d’objet XML avec données réelles

├ doc

│ └ *.html Documentation HTML de chaque objet

└ *.xsd Schémas XML de chaque objet

WITSML v1.3.1 API ├ XML_Examples │ └ *.xml ├ doc │ └ *.html

├ *.doc Documentation détaillée au format Ms Word

├ *.xsd Schémas XML de chaque objet de l’API

└ *.wsdl Document de description des Web Services

WITSML v1.4.1.1 Data Schema └ …

WITSML v1.4.1 API └ …

Tableau 1-1 : Hiérarchie des fichiers WITSML

1.2.1.3. L’

(API)

L’API WITSML propose deux Web Service distincts pour l’accès et le transfert de données, accessibles par l’intermédiaire des fichiers WSDL (wmls.wsdl & wmlp.wsdl)

fournis dans l’archive.

1.2.1.3.1. L’API CLIENT / SERVEUR

C’est l’interface principale pour l’accès aux données. Elle est définie dans le document wmls.wsdl de l’API, WMLS étant un acronyme utilisé par Energistics pour la

désigner (contraction de WitsML Store). Elle donne accès aux fonctions d’ajout, récupération, modification et suppression de données du serveur par l’intermédiaire du protocole de communication SOAP.

Le Store WITSML fonctionne de manière synchrone, sur le modèle requête / réponse. L’ensemble des requêtes initiées par le client doit être valide, conformément aux schémas de données correspondants, en suivant la syntaxe XML. Voici un exemple de requête permettant la récupération d’une liste de trajectoires d’un puits de forage donné :

<trajectorys xmlns="http://www.witsml.org/schemas/131"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.3.1.1">

<trajectory uidWell="well01" uidWellbore="" uid="">

<nameWell/> <nameWellbore/> <name/> <mdMn uom="m"/> <mdMx uom="m"/> </trajectory> </trajectorys>

Code source 1-2 : Exemple de requête WITSML

Le même schéma peut donc être utilisé à la fois pour l'écriture des requêtes, et pour formaliser la réponse du serveur. Un exemple de réponse pourrait être le suivant :

Chapitre 1 Cadre du projet - Projet WITSML

<trajectorys xmlns="http://www.witsml.org/schemas/131"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.3.1.1">

<trajectory uidWell="well01" uidWellbore="wellbore01" uid="id-001">

<nameWell>Well 01<nameWell/>

<nameWellbore>Wellbore 01<nameWellbore/>

<name>Trajectory 01<name/>

<mdMn uom="m">0<mdMn/>

<mdMx uom="m">6000<mdMx/>

</trajectory>

<trajectory uidWell="well01" uidWellbore="wellbore02" uid="id-052">

<nameWell>Well 01<nameWell/>

<nameWellbore>Another Wellbore<nameWellbore/>

<name>Trajectory 52<name/>

<mdMn uom="m">100<mdMn/>

<mdMx uom="m">4500<mdMx/>

</trajectory> </trajectorys>

Code source 1-3 : Exemple d'objet WITSML

1.2.1.3.2. L'API PUBLISH /SUBSCRIBE

La seconde API offre un mécanisme de publication / souscription de données. À la différence du Store, l'interface Publish fonctionne de manière asynchrone. On initie un "abonnement" à un objet ou un jeu d'objets au travers d'une requête sur le même modèle que pour le Store. Comme on le voit sur la figure 1-9, à la différence de ce dernier, la réponse n’est pas retournée instantanément, mais envoyée via une requête HTTP POST sur une URL renseignée lors de l'abonnement. Un serveur Web doit donc être installé et opérationnel sur la machine destinataire des données.

Figure 1-9 : Exemple d'implémentation de Publish (Petrotechnical Open Standards Consortium, Inc (POSC), 2005) Cette méthode permet d'optimiser les temps de chargement sur des données volumineuses en donnant la possibilité de les traiter en arrière-plan. Mais elle offre surtout l'opportunité de réaliser des traitements en temps réel, car un abonnement n'est pas ponctuel. Le serveur réitère le transfert périodiquement, et si des

Publisher Proprietary Data Store Subscriber sensor sensor sensor sensor aggregator application Web Server WMLI Implementation Subscriber Process HTTP/S POST PUBLISHING 1 2 3 4

Intégration du standard d'échange WITSML dans les applications pétrolières changements sont intervenus sur les données souscrites, seules les nouvelles données sont renvoyées.

Mais en contrepartie, en cas d'indisponibilité de serveur Web sur la machine de destination ou de rupture de connexion, les données en échec de transfert risquent d'être perdues. Dans les spécifications de WITSML, rien n'oblige le serveur Publish à retransmettre les données à la restauration de la connexion (Petrotechnical Open Standards Consortium, Inc (POSC), 2005).

1.2.1.4. L

’

Energistics a publié, en juin 2014, un standard fusionnant les spécifications des unités de mesures précédemment rédigées. Il a été réalisé en collaboration avec la Professional Petroleum Data Management (PPDM™) Association et la Society of Exploration Geophysicists (SEG).

1.2.1.4.1. PRINCIPE

La création de l’Energistics Unit Of Measure (UOM) Dictionary a permis de regrouper dans un seul standard, l’Epicentre Data Model v2.2, le RP66 v2.0 et le POSC, qui sont les plus utilisés dans le monde de l’ingénierie pétrolière.

Son but est d'être distribué aux équipes de développeurs et de concepteurs en vue d'être intégré dans leur environnement logiciel, et d'augmenter leur capacité d'interopérabilité et de compatibilité. Toute implémentation d'un standard d'échange de données d'Energistics doit d'ailleurs intégrer la gestion de l'UOM Dictionary Standard.

1.2.1.4.2. DIMENSION,CLASSE DE QUANTITE & CONVERSION

En plus de mettre à disposition un dictionnaire d’unités de mesure, l’UOM Dictionary introduit la notion de dimension. Elle fait intervenir une notation particulière qui n’est pas directement dépendante de l’unité de mesure. Elle permet de pouvoir définir la composition d’une grandeur, en vue d’établir des correspondances d’unités. Une dimension utilise la grammaire décrite dans le tableau annexe 1 en page XIII. Cette grammaire est largement inspirée des notations spécifiées par le Bureau International des Poids et Mesures dans le Système International d’unités (Bureau international des poids et mesures, 2006). Par exemple pour décrire un débit, on le décompose en longueur élevé au cube, divisé par un temps, soit L3/T.

Des classes de quantité sont également définies, regroupant toutes les unités de même dimension. Cette notion, déjà présente dans le RP66, permet la conversion sans perte d’une unité à une autre de la même classe. Par exemple, la classe de quantité

massPerLength permet de recenser toutes les unités utilisables pour exprimer une masse

linéaire (kg/m, g/cm, …, lbm/ft, …), ainsi que les formules de conversions (Energistics, 2014).

Chapitre 1 Cadre du projet - Projet WITSML

Une classe dispose d’une unité de base exprimée dans le Système International d’unités scientifiques (SI) qui constitue la référence de conversion. Energistics utilise 4 constantes, nommées A B C et D, pour chaque unité qui dérive d’une unité de base. La conversion d’une unité donnée dans l’unité de base est définie selon la formule :

𝑦 = 𝐴 + 𝐵𝑥 𝐶 + 𝐷𝑥 Où :

𝑥 représente la valeur dans l’unité source

𝑦 représente le résultat exprimé dans l’unité de base SI

On peut ainsi obtenir la valeur convertie dans l’unité de base SI puis la reconvertir dans l’unité désirée.

1.2.2. L

/

Dans les applications d'ingénierie pétrolière de la société Drillscan, toute session de calcul commence par le chargement des données d'entrées. Selon l'opération à réaliser, ces données peuvent être, par exemple, des trajectoires, des logs, ou encore des assemblages de forage.

1.2.2.1. L

D

Le module Database est un module applicatif qui permet de gérer les informations principales du logiciel. Il fait partie du tronc commun à tous les logiciels de Drillscan, nommé Foundation, qui gère notamment les accès aux bases de données relationnelles et les objets du modèle de données. Ce module permet l’ajout, la modification et la suppression de la plupart des données d’une base de données. C'est un des points d'entrée pour les imports et les exports de données.

Figure 1-10 : Module Database

Le module Database se présente sous la forme d’une fenêtre composée de différents onglets relatifs aux objets à manipuler (Figure 1-10). Dans les versions actuelles des logiciels de Drillscan, les entrées se font, soit par des saisies utilisateurs au travers de formulaires, point par point, soit par copier-coller depuis le presse-papier pour certains objets. Bien que rapide à réaliser, ce dernier mode d'import a le désavantage de ne pas tenir compte des unités dans lesquelles sont exprimées les

Intégration du standard d'échange WITSML dans les applications pétrolières données d'entrée. Il faut donc convertir les données a priori, ou modifier le système d'unités du logiciel pour le faire correspondre à celui des données d'entrée. Ce processus constitue donc une source d'erreur potentielle.

La saisie peut se faire par l'intermédiaire d'un formulaire mais cette méthode n'empêche pas les erreurs de conversion, et elle peut être longue et rébarbative. De plus, tout import doit déjà passer par une phase d'export depuis le logiciel exploitant les données sources. Il peut également y avoir des erreurs de saisie qui peuvent conduire à la corruption des données et donc à

l'obtention de résultats faux. C'est pourquoi un import automatisé peut accélérer le processus de chargement et diminuer le facteur de risque d'erreurs de saisie.

Pour les logs, on a également la possibilité de les importer depuis des fichiers textes, pour lesquels on saisit le format d'entrée, le type de données et l'unité dans laquelle elles sont exprimées (Figure 1-11). Ce processus prend en charge la conversion d'unités, à la condition que celle-ci soit connue. Elle nécessite tout de même la saisie d'une quantité d'informations non négligeable, qui sont également sujettes à erreur de saisie.

1.2.2.2. L

Les imports et exports concernés par le projet portent actuellement uniquement sur les types d'objets principaux, dont la saisie peut être longue et complexe.

1.2.2.2.1. LES TRAJECTOIRES

Une trajectoire décrit le chemin de l’assemblage de forage à travers la formation rocheuse. C’est le premier élément qui est défini lors de l’établissement d’un forage, juste après avoir déterminé la cible du puits (Figure 1-12). Elle est quasiment indispensable à la majorité des cas de calcul. C’est en se basant sur la trajectoire à suivre qu’on peut dimensionner la garniture en forage directionnel. On peut également déterminer le meilleur jeu de paramètres à lui appliquer afin d’optimiser l’opération de forage.

Une trajectoire se caractérise par des informations de localisation (le puits auquel elle se réfère), ainsi qu’une liste de points, dont les coordonnées sont exprimées selon un azimut et une inclinaison par rapport à la verticale. C’est la convention communément adoptée dans le domaine pétrolier. Les informations sur la profondeur sont données par la MD, qui est la profondeur mesurée le long de la trajectoire, ainsi que la True Vertical Depth (TVD), qui est, elle, la profondeur à la verticale, toutes deux ayant comme origine la table de rotation située en surface.

Chapitre 1 Cadre du projet - Projet WITSML

Figure 1-12 : Trajectoire de forage

D’autres informations, certaines optionnelles, donnent des indications sur la cohérence des données et la mise en œuvre de cette trajectoire, comme par exemple le Dog Leg Severity (DLS) qui fait apparaître les changements de direction ou d’inclinaison trop brutaux qui risquent d'occasionner des fatigues importantes sur les tiges de forage (Nguyen, 1993).

1.2.2.2.2. LES LOGS

Aussi connus sous le nom de diagraphies instantanées, (lorsqu’issues d'un module MWD), ou différées, (pour celles issues d'un module LWD), les logs permettent de contrôler, et de stocker, pour une analyse ultérieure, les paramètres de forage, comme le poids au crochet (WOB), ou la vitesse de pénétration dans la roche (ROP). Ils permettent également de piloter la BHA en forage directionnel.

La figure 1-13 montre un exemple de log que l’on peut communément trouver lors d'une opération de forage. Le sens de lecture est vertical, et s'effectue de haut en bas. Cette convention s'explique par le fait, qu'historiquement, les logs sont indexés en fonction de la profondeur (MD). Cette convention est conservée même pour les logs en base temps, car ils conservent toujours une relation entre le temps et la profondeur du trou ou de l’outil.

Les logiciels de Drillscan s’intéressent principalement aux logs concernant les paramètres de forage, car ce sont eux qui donnent des informations sur les données physiques appliquées à l’assemblage, ou sur des données environnementales qui impactent son comportement.

Intégration du standard d'échange WITSML dans les applications pétrolières

Beaucoup de logs concernent des relevés géophysiques, comme la résistivité, la radioactivité ou encore l’imagerie magnétique ou acoustique. Ces données servent principalement à reconstituer la formation géologique et à déterminer la composition des fluides qu’elles peuvent contenir. Ces traitements ne font pas partie des objectifs des logiciels de Drillscan. Ils sont donc réalisés antérieurement à l’import.

1.2.2.2.3. LES GARNITURES DE FORAGE

Les garnitures de forage ou drillstrings sont les éléments centraux de la plupart des modules de Wellscan, et sont à la base de leurs calculs. À la différence des autres objets, comme les trajectoires ou les logs, les garnitures ne sont pas accessibles depuis l'écran du module Database mais depuis les modules qui les utilisent comme objets centraux, comme, par exemple, la pré-analyse qui permet de simuler le comportement d'une garniture selon des paramètres d'entrée.

La saisie s'effectue élément par élément, par l'intermédiaire de formulaire ou par la sélection d'éléments déjà existants. Les éléments ainsi créés sont visualisés via une liste, qui récapitule les données principales. Ils sont également visualisés graphiquement, sous forme schématique. Les différents composants sont ainsi représentés à l’échelle, avec la cote correspondante à chacun d’eux.

Chapitre 1 Cadre du projet - Projet WITSML

Figure 1-14 : Panneau de saisie d'un assemblage de forage

On peut exporter un assemblage sous forme de fichier propriétaire (*.bha), qui est une sauvegarde partielle de la base de données au format FireBird Embedded. Ce fichier peut être réimporté dans le logiciel, ultérieurement, sur un autre poste ou dans une autre base de données. Le principal inconvénient de cette méthode d’import / export est sa portabilité relativement limitée. L'import n’est possible que dans une base de données de version supérieure ou égale à la base source, et, du fait du format de données propriétaires, le transfert vers d’autres environnements de travail est impossible.

1.2.2.2.4. LES FORMATIONS GEOLOGIQUES

Actuellement, les formations sont très peu utilisées dans Wellscan, mais elles le sont un peu plus dans Bitscan pour la simulation des outils (usure, stabilité, etc.). L'utilité principale d'un tel objet est de pouvoir connaître la dureté, ou encore la porosité des roches. Sur un forage qui peut atteindre plusieurs milliers de mètres de profondeur, les formations traversées ne se limitent pas à quelques couches. La saisie d'une formation, ainsi que sa lithologie, peut donc être une opération longue et fastidieuse, d'autant plus qu'aucune procédure d'import n'est actuellement disponible.

Comme sur la figure 1-15, les formations, dans Bitscan et Wellscan, sont divisées en couches, généralement en fonction de leur période géologique. Chaque couche comprend une succession de lithologies des roches qui la composent. Ces roches ont des propriétés qui leur sont propres (dureté, porosité, orientation spatiale, etc.) et qui peuvent être utilisées par certains modules pour des calculs scientifiques. Les textures et couleurs des types de roche sont normalisées et disponibles dans une bibliothèque intégrée à la base de données. Seules les informations physiques sont à saisir.

Intégration du standard d'échange WITSML dans les applications pétrolières

Le faible besoin envers cet objet n'en fait pas un élément prioritaire. Mais des évolutions futures du logiciel pourraient nécessiter une gestion beaucoup plus importante des formations, et par la même, du processus de chargement.

1.2.2.2.5. LES PROGRAMMES DE CASING

Les programmes de cuvelage (ou de casing) ne sont pas des objets très complexes. Ils se composent d'un conteneur principal et d'une liste de tubes spécifiés par leurs caractéristiques géométriques (diamètre intérieur & extérieur, longueur) et physiques (grade et matériau). Un aperçu des programmes de casing de Wellscan est disponible sur la figure 1-1 au paragraphe 1.1.3.1.1.

Les casings sont utilisés dans Wellscan afin de calculer les contacts de la garniture sur les parois et de redéfinir les contraintes de passage des Drillstrings. En effet, la mise en place d'un casing modifie le diamètre intérieur du puits. Il faut donc prendre en considération la nouvelle géométrie introduite par cet élément. Des calculs d'usure peuvent également être effectués afin de dimensionner les casings en fonction des opérations à réaliser ou de prévoir les ruptures éventuelles, car la rotation

Chapitre 1 Cadre du projet - Bilan du cadre du projet

et les passages successifs de la garniture engendrent des frictions et de l'usure sur les parois.

1.2.2.2.6. SITES DE FORAGE

Les sites de forage sont référencés dans les logiciels de Drillscan afin de pouvoir localiser les données géographiques, et hiérarchiser les autres données. Ainsi, les sites sont subdivisés en champs (Fields), représentant la zone géographique couverte par un réservoir. Chaque champ comprend un ou plusieurs puits (Wells) en vue de son exploitation. Les données et les objets vus précédemment sont référencés par rapport à un puits, car c’est lors de sa réalisation, ou pour une analyse le concernant, qu’ils ont été relevés ou calculés.

Figure 1-16 : Diagramme des relations entre objets d'un site de forage

Les champs font l’objet d’une concession attribuée à un opérateur de forage (Operator). Les opérateurs sont généralement subdivisés en filiales (Affiliate) qui se chargent de réaliser l’étude d’exploitation, du forage d'exploration et de développement.

La figure 1-16 montre les relations qui existent entre les différents objets intervenant dans la hiérarchisation des données. WITSML, à la différence des logiciels de Drillscan, introduit un niveau supplémentaire entre les données opérationnelles (logs, trajectoires, etc.) et le puits, à savoir le Wellbore. Il représente la partie de trou en cours de forage. Un puits comporte donc autant de wellbores que de phases de forage.

1.3. B

ILAN DU CADRE DU PROJET

Les notions de base du métier entrevues dans ce chapitre, permettent, d’une part, de se familiariser avec la terminologie liée au forage, et d’autre part, de mieux appréhender les objets manipulés en WITSML en vue de leurs identifications dans le Chapitre 2.

Les objets ont été volontairement limités aux cinq principaux types que sont les trajectoires, les logs, les assemblages de forage, les formations géologiques et les

Intégration du standard d'échange WITSML dans les applications pétrolières programmes de cuvelage du fait de l’activité ciblée des logiciels de Drillscan. D’autres objets portant sur la gestion du risque ou encore les rapports d’explorations ne sont pas traités. Mais il est impératif de prévoir une évolution possible du modèle de données. Cette contrainte est un critère fort dans les choix qui ont été effectués dans le projet.

Ces connaissances sont également très utiles dans la phase de réalisation et de test afin de pouvoir déterminer l’ordre de grandeur pour les valeurs de test, ainsi que pour vérifier la cohérence des données importées et la détection d’erreurs.

Intégration du standard d'échange WITSML dans les applications pétrolières

Chapitre 2

A

NALYSE ET CONCEPTION

Comme il a été évoqué dans le chapitre précédent, afin de faciliter le chargement et l’échange de données des logiciels Bitscan et Wellscan, une solution de transfert via un serveur (ou des fichiers WITSML) est une alternative extrêmement intéressante, autant d'un point de vue opérationnel que commercial.

2.1. L

E BESOIN

Les imports et exports actuels ne permettant pas une portabilité et une compatibilité suffisantes avec d'autres environnements de travail, il est nécessaire d'implémenter une méthode offrant des solutions répondants à ce problème.

2.1.1. E

&

Le projet d'intégration du WITSML doit également prendre en considération certaines contraintes et exigences afin de pouvoir être réalisé avec succès.

2.1.1.1. F

L'utilisateur doit pouvoir importer et exporter cinq types d'objets, à savoir les trajectoires, les logs de forage, les assemblages de forage, les formations géologiques et le programme de casing. Les imports et les exports doivent pouvoir se faire, soit depuis un serveur WITSML, soit depuis un fichier au format XML respectant le standard. Pour ce dernier cas, l'utilisateur doit choisir, lors de l'export, la version du schéma de données à utiliser.

La sélection d'éléments, lors d'une requête sur un serveur WITSML, commence toujours par le choix du Well, puis du Wellbore. Les interfaces utilisateurs doivent donc

Chapitre 2 Analyse et conception - Le besoin

posséder ces composants. L'utilisateur doit également pouvoir pré-visualiser les données qu'il souhaite importer.

Lors de la phase d'export d'objets vers un serveur, l'utilisateur doit également spécifier le Well et Wellbore. Dans le cas où les informations cibles n'existeraient pas, il doit pouvoir en ajouter de nouvelles, mais également les modifier, voire même les supprimer si besoin.

Pour la gestion des serveurs WITSML, une interface utilisateur doit permettre la saisie et la sauvegarde des informations. Un serveur se caractérise par un nom, une URL, un nom d'utilisateur et un mot de passe. L'interface doit permettre la sélection d'un serveur, dont les informations sont utilisées pour les opérations d'import et d'export.

2.1.1.2. C

Le projet est réalisé avec les mêmes outils que les logiciels Bitscan et Wellscan. Le langage de programmation Delphi et le logiciel Embarcadero® RAD Studio XE5 utilisés pour leur développement constituent la base de l'environnement de travail. RAD Studio permet de réaliser facilement des interfaces graphiques grâce à un éditeur visuel et une gestion des événements facilement extensible.

Les interfaces graphiques réalisées doivent respecter les codes visuels et les conventions de nommage et de dimensionnement des composants de l'application. Pour cela, l'utilisation des fonctionnalités issue du Framework Foundation doit être privilégiée. Voici les dimensions communément adoptées :

Type de composant Largeur Hauteur

Bouton 75px 22px

Liste déroulante 100px 22px

Zone de saisie 100px 22px

Tableau 2-1 : Dimensions des composants graphiques de Drillscan

Les unités de code source et classes créées, formant un ensemble cohérent et indépendant, doivent être rassemblées dans un Runtime Package unique. Il s'agit d'une bibliothèque dynamique propre à Delphi, à l'image des DLL de Microsoft. Ceci facilite la mise à jour du code source, et optimise les temps de compilation.

2.1.2. C

'

Les exigences décrites à la section 2.1.1.1 ont permis de regrouper les cas d'utilisations et de dégager cinq fonctionnalités principales (Import, Export, Gestion des serveurs, Gestion des Wells / Wellbores et Sélection d'éléments).

Intégration du standard d'échange WITSML dans les applications pétrolières

2.1.2.1. L

'

Lors de l'import depuis un serveur, l'utilisateur doit sélectionner le Well puis le Wellbore avant de pouvoir sélectionner un élément, et pouvoir le pré-visualiser.

2.1.2.1. L

La liste des serveurs doit être persistante et modifiable par l'utilisateur. Il peut ainsi ajouter de nouveaux serveurs et saisir ses données de connexion. Après la sélection d'un élément existant, il doit pouvoir les éditer, voire même supprimer le serveur sélectionné (Figure 2-2).

La sélection est un cas d'utilisation commun aux fonctionnalités d'import et d'export, et peut également être pris indépendamment de tout autre cas.

Figure 2-2 : Cas d'utilisation "Gestion des serveurs"

2.1.2.2. L'

L'import est la fonctionnalité la plus importante, le but principal du projet étant de faciliter la phase de chargement des données nécessaires aux calculs. Le projet prévoit cinq types d'objets à importer, donc cinq cas d'utilisations qui héritent tous d'un cas plus général "Import" (Figure 2-4). Celui-ci peut être un import depuis un fichier ou depuis un serveur.

L'import depuis un serveur nécessite, tout d'abord, la sélection du serveur en question, puis, pour le cas des logs, la sélection du type de données pour chaque log importé. En effet aucun champ du schéma ne permet de relier le type de log WITSML