Petrol 18 946: Downhole failures revealed through ontology engineering

1. Introduction

Despite huge technological improvements over the last decades, errors and failures still occur at a high rate (Prichard et al., 2012), especially during complex offshore drilling, where the number of wells is held low, and tend to be highly inclined and long. Most of the remaining oil and gas reserves are located on continental shelfs.

New technology for solving commonly known and new problems are always in demand. The method presented here is one that comes at a low investment and is easy to implement, once a rich and versatile knowledge model of the drilling process is in place.

The motivation behind our work is to advance a specific computerized method for helping the petroleum industry in reducing unwanted downtime. More up-time is needed. The goal of our research is to improve the quality and efficiency of the drilling process in two ways:

•
Predict failures before they occur, thus allowing for early counter-actions.
•
When failures do occur, point out cause(s), thus allowing for more efficient repair work.

The goal is achieved by developing a tool that predicts drilling failures. Our experimental system can read data from a drilling process and utilize on-line detected symptoms, including predefined static symptoms, to capture a probabilistic understanding of the downhole process.

2. Previous attempts

New attempts are continuously being developed to solve new challenges. We will here mention two existing technologies relevant for our work; Process Surveillance and Ontology Engineering.

Process surveillance: Recently, several competing process surveillance tools have emerged. Two tools from within the process of oil well drilling are DrillEdge (Gundersen at al. 2012) and e-drilling (Rommetveit et al., 2011).

DrillEdge is a software system that provides decision support based on case-based-reasoning applied on real-time drilling data (RTDD). DrillEdge was developed to reduce the cost and to decrease the probability of failures in oil well drilling. The system monitored commercially from 10 to 40 oil well drilling operations annually for several years.

e-drilling is also a decision-support system which performs automatic supervision. Dynamic models calculate well conditions, based on available data from the drilling process, and provide diagnostics in the form of warnings and advice. Forward-looking capability based on trends can give early warning of near-future error situations.

Ontology Engineering: Established results from the community of knowledge-acquisition and modeling have produced several methodologies and techniques for describing knowledge at a conceptual, implementation-independent level. Influential examples are the Components of Expertise Framework (Steels, 1990; Aamodt, 2001), and the Common KADS methodology (Breuker and Van de Velde, 1994). To promote the re-use of such models, the call for common generic models – more frequently referred to as ‘ontologies’ – has led to the development of generic knowledge models - i.e. ontologies - within different application areas (Klein and Smith, 2010). Correspondingly, the term ‘ontology engineering’ is now often used instead of ‘knowledge modeling’. A large ontology that became an international standard within the oil industry is the ISO 15926 ontology (Fiatech, 2011). This ontology has been an inspiration for our ontology as well, although its large cover and high complexity have led us to develop our own.

Ontology is a term used in philosophy, encompassing the study of “what is”. The application of Ontology within information technology and engineering is more recent, and has replaced or enhanced terms like data model, term-catalogue, etc. All ontologies make some assumptions about the world they represent. A resent application of ontology in this regard was suggested by Cayeux et al. (2019). Users share a common ontology (a semantic, topological network), which relates physical quantities, their logical position, their measurements and parameters (signals). A seamless data-integration of signals between users allows them to share a common understanding and application of drilling applications.

3. The method

The model of drilling-related knowledge developed as part of our research is based on the adaptation of established methods and best practice for knowledge model development (Gomez et al., 2005; Staab and Studer, 2005). The term ‘‘knowledge’’ – as used in this paper – refers to all types of explicitly represented data structures with accompanied inference methods from which a system can perform goal-driven reasoning (Aamodt, 1990).

In earlier work we have shown how to utilize specific cases supported by general domain knowledge through a process called knowledge-intensive case-based reasoning (Skalle et al., 2000; Aamodt, 2004). More recent work (Skalle et al., 2013), and like the work reported here, focus on reasoning within the ontology. Ontology engineering relies on formal representation of concepts within the selected domain and the semantics between those concepts. This requires an ontology at the conceptual level that is linked to knowledge representation and inference methods at the operational program level. Our ontology (examples are shown later in the paper) is a network of nodes and links between them, where the nodes are concepts and the links are relations between them. A concept is defined through its link to other concepts. This type of network is generally referred to as a semantic network (Sowa, 1992). A concept is typically a domain object, such as a physical object like a sensor or a part of the drilling equipment, a process like tripping out, or a state like an error state. To increase expressiveness in the model a concept may also be a relation type, such as a subclass relation or a causality relation.

We have built our ontology by working partly top-down, starting with the most generic concept, finding its more specific concepts, and so on. And partly bottom-up, by examining particular drilling situations, identifying the objects involved, and describing them by incorporating them as concepts and relations into the ontology, ensuring that the lower-level concepts correctly link up with the higher-level ones. This is explained in detail in Ch. 4 Step 3. A number of past experiences have been analyzed and generalized into concepts with their respective dependencies and other relationships to other concepts.

Our main objective of bringing ontology engineering into play is its ability to combine observed symptoms with potential failure states, and then producing explanations generated by a knowledge model (ontology). This manner of pointing out the most probable error and failure type, applying ontology for on-line surveillance has not been applied extensively in the oil-drilling domain before. However, more applications of ontology for the purpose of on-line surveillance in other domains do exist, for example the BioStorm surveillance technology program (Crubezy et al., 2005). In such applications the errors or failures occur at a high frequency, while the error-frequency within the drilling process is typically only a few failures pr. well. To compensate for low failure frequency, and few experiences to learn from, a rich knowledge model is needed.

Fig. 1 summarizes the practical approach to our method: starting with surveillance of drilling data, then activating the model through identified symptoms, and finally issuing of a warning, but only if the failure-probability increases beyond the threshold value. Fig. 1 serves also as a guide of how to develop the method.

4. Method development step by step

Step 1: Drilling Data and Static Symptoms.

Data are supplied by Equinor (Volve Database, 2018) and the Norwegian Petroleum Directorate (NPD) (Diskos Data base, 2019) in terms of real-time drilling data files (RTDD) and End of Well Reports (EoWR). Addresses to the two data sources are listed in the References. More than 100 drilled wells with corresponding RTDD and EoWR are stored here.

RTDD: A snapshot of selected RTDD is presented in Fig. 3 (see Step 2).

EoWR: Contains information like; geological goal; lithology to be drilled through; characteristics of equipment and material; and characteristics of all the challenges and how they were tackled.

Important data are the failures, since failures during drilling is the focus of our work. A Failure is a State, i.e. a subclass of state in the ontology, in which a significant unplanned stop in the process occurs; resulting in a repair operation, which represents a significant non-productive time (NPT). The related concept Error (subclass of State), defines a Process or a Facility which either is less functional or stops functioning temporarily, but does not necessarily cause any significant loss of time. Error is sometimes synonymous with Symptom. Failures in Table 1 (Prichard et al., 2012) were re-structured by us to specify the data more detailed to include all failure types in the latest version of our model. Pritchard et al. reported Stuck Pipe as one failure group. We split it into Stuck Pipe Differential and Stuck Pipe Mechanical (with different failure frequency, according to relevant experience). Likewise, for Wellbore Instability failures; they were split into Wellbore Instability Chemical and Wellbore Instability Mechanical.

Table 1. Failures during drilling. Left: Failure vs. occurrence-frequency of 427 offshore wells in the period between 2004 and 2010 (modified from Prichard et al., 2012). Right: Failure viewed (or classified) as Failure type.

Failure	%
Mud Loss	12.4
Kick	10.8
Shallow Gas	9.5
Stuck Pipe Differentially	8.2
Cement Failure	8.0
Stuck Pipe Mechanically	7.8
Wellbore Instability Mech Cause	7.5
Motor Stall	6.8
Rotary Stearable Failure	5.7
Mud Loss To Naturally Frac Fm	5.1
Wellbore Instability Chem Cause	5.0
Logging Tool Failure	3.4
Bit Malfunction	2.3
Drill String Washout	2.3
Technical Sid etrack	2.8
Drill String Twistoff	1.4
Casing Collapse	0.9
Failure	Type
Drill String Leakage Drill String Twist Off Logging Tool Failure Bit Failure Motor Stall	Tool Failure
Cement Failure Casing Failure	Csg Failure
Mud Loss Mud Loss To Weak Fm Shallow Gas Kick	LC/Kick
Unplanned Sidetrack Stuck Pipe Diff Stuck Pipe Mechanical Wellbore Instability Chem Wellbore Instability Mech	Wellbore Failure

Actual situation, i.e. drilling cases, are described by attributes/parameters which may be concept terms from the ontology, numerical values, or other data types (free text, graphs). Only concept terms from the ontology enables the system to perform semantic reasoning.

A total of 36 failure cases were found in the stated sources and defined as acceptable for our project. Two of them, located in well 15/9–19 A are presented below in the form of important headings:

Well section:	8.5
Failure:	Bit Malfunction
Time Lost:	One extra trip
Depth/Time of Occurrence:	2783 mMD/10.11.2005 at 12:11
Activity:	Drilling
Details:	Took 2.5 h to drill the very last meter. Grading of the last retrieved bit: Teeth: 3–4, Cone: cored out nose
Well section:	8.5
Failure:	Stuck Pipe Mechanically
Time Lost:	Only a few minutes, but will serve well as a training-failure
Depth/Time of Occurrence:	2708 mMD/11.11.2005 at 05:34
Activity:	Tripping Out
Details:	After several packing-off the string went stuck. Probably due to cavings-production

The case we applied as base-case or demo-case in present paper, case # 12, is presented to some detail in Fig. 2.

Data can define both static and dynamic symptoms. Static symptoms were crucial as support for data agents and for determining relationship-strength. Static symptoms were retrieved mainly from EoWR. Some examples are:

•
Bit Type: Roller
•
Build Angle Located Inside Open Hole
•
Casing B Pressure Small
•
Cement Volume/Theoretical Volume Medium Low

Static and dynamic symptoms are often graded into several levels, typically expressed as Small, Medium and Very. The initial definition of threshold values for defining the levels will eventually be adjusted according to gained experience.

Step 2: Data Agents for extracting dynamic symptoms.

We have developed 35 dynamic agents so far; all for the purpose of extracting symptoms from RTDD during drilling operations. Symptoms are deviations from the expected values of either drilling parameter or of derived parameter. A derived parameter is one that has been inferred from the ontology, for example by following a causal relation, or in other ways computed by the system. Each agent's quality has been tested against historical drilling data. Here are four of the agents:

•
Activity Of Tripping-In
•
Cuttings Initial Concentration Very High
•
MW-Frac Density Very Low
•
Mechanical Friction Medium High

Automatically detected symptoms are exemplified and explained in Fig. 3.

Combinations of symptoms can give hints about the underlying problem. Rapid increases of pressure at constant pump rate can indicate several types of problems, e.g. accumulations of cuttings causing packoffs or pressure building up because of a motor stall. Poor hole cleaning combined with pressure spikes may indicate cuttings accumulation, while Hard Fm combined with pressure spikes may indicate a motor stall. These examples also serve as an introduction to the functionality of the knowledge model.

Agents are developed in three steps:

1.
Find symptoms manually in the historical RTDD and tag their temporal position (or time interval)
2.
Develop data agents in Matlab
3.
Evaluate performance of agents by counting the # of hits of tagged symptoms (True Positive) and # of misses (False Negative) and, if the agent wrongly fires (False Positive)

Both the percentages of False Positives and False Negatives should ideally approach zero, and are of interest both when optimizing the agents, and comparing the overall performance against older version of the agents. Agent quality was accepted when hit rate reached a detectability of more than 85%. The agent is run in two different ways (1. Comparing PP to expected PP, 2. Comparing PP with estimated PP (HyFr)), exemplified by pump pressure related symptom called HyFr:

Estimated pump pressure, Δpest, is identical with frictional pressure drop in the circulating system. In turbulent flow, pump pressure is approximately proportional to the 1.6–1.8 power of the pump flow rate (PFR). Fully turbulent flow is proportional to flow squared. Laminar flow in the annulus and lower flow rate in general reduces the exponent.(1)Δpest = Ktot . MD . PFR1.7

Ktot = Static Property. By dividing the observed pump pressure by the estimated pressure, we should get a constant, called the Hydraulic Friction Loss Factor (HyFr):(2)HyFr = PP /Δpest

At a substantial deviation from expected trend, the agent fires, as shown in Fig. 3 left, as HyFr. After obtaining some experience with this factor, we should be able to see “slowly filling up of cuttings” in highly inclined annuli. The script of this agent is shown below. It starts by removing invalid numbers such as the “not a number (NAN) code”, −999.25, or zero in the denominator. The script uses Matlab's “Logical Indexing” feature (Matlab Coding Style, 2019). It obtains an early and simplified version of Δpest.

2% Calculates Hydraulic Friction, HF = PP/PFR^1.75

4% If any of PP or MFI is −999.25, or PFR is 0.0,

5% then HF is set to −999.25

6 tic();

7 OIL_NAN = −999.25;

8 bad_spp_indices = (X.PP = = OIL_NAN);

9 bad_mfi_indices = (X.PFR = = OIL_NAN) | (X.PFR = = 0.0);

10 bad_indices = bad_spp_indices | bad_mfi_indices;

11 good_indices = 1 - bad_indices;

12 hfNanPart = bad_indices * OIL_NAN;

13 X.HF = X.PP./(X.PFR.^ 1.75).* (good_indices);

14 X.HF(bad_indices) = OIL_NAN;

15 toc();

Step 3: Knowledge model development.

The knowledge model is the heart of the system and was developed in two main steps:

Step A - Constructing the structure of concepts
Step B - Joining concepts in cause-effect relations

Knowledge in our model is retrieved from three type of sources;

•
Textbook
•
Failure case
•
Expert

A textbook published in 1986 (Bourgoyne et al., 1986) contains basic knowledge of the drilling process, still highly relevant. Retrieval of knowledge from second source type is explained through present paper.

Step A - Structure: In our ontology, as in most ontologies, the top-level concept Thing stands for anything in the world worth naming or characterizing. In our problem-domain Thing should be interpreted as restricted to ‘Drilling Thing’, as illustrated in Fig. 4.

Only subclass relationships are shown in the figure, i.e. the relation “has subclass” is replaced by a directed arrow. A more general structure is illustrated in Fig. 5. Everything we want to talk about is a subclass or an instance of Drilling Thing, all the way down to the lowest-level concepts. The model can be viewed as a multi-level floor below the mentioned top-level concept. The upper floors consist of generic concepts, such as Physical Object, State and Facility. Lower floors contain more drilling-related concepts.

It is not a complete model, as several intermediate levels are incomplete or missing. The bottom level (the right-most in Fig. 5) will mostly be composed of detailed concepts defined through the study of cases. Specific examples of subclasses are shown to indicate the definition and the richness of concepts. The ontology is open access, available for anyone who wants to explore and expand it.

A concept may be a general definitional or prototypical concept. A network view to concept definition is taken, in which each concept is defined by its characteristics (see Table 2) and by its relations to other concepts, as earlier explained, thus defining the knowledge of the domain.

Table 2. Definition of four internal concepts (i). The definition concept and its link are not shown in Fig. 5.

Internal concepts	Definition
Accumulated Barite (i)	Barite segregates slowly out of suspension IF laminar flow AND IF well is inclined
Bit Aggressive (i)	Long bit body yields high contact area and high torque and tend to turn well path into a leftwards spiral
Bit Vibration (i)	High-frequency lateral movement. Occurs under high WOB AND High RPM
Bending Of DS (i)	Compressional stress in DC. Occurs at high WOB AND IF under-gauge stabilizers (freedom of DS to bend)

To ease the construction of the ontology and to make it more transparent, concepts are grouped vs. their role:

•Error concepts;	indicated as such by adding (err) to the concept name
•Failure concepts;	indicated by (f)
•Symptoms (s);	representing deviatoric behavior in RTDD, and are detected by data agents
•Static symptoms (ss);	they possess a constant value during a specific well sections, identified and known before drilling starts. Their value is read from drilling files or from EoWR
•Internal concepts (i);	non-observable concepts, existing purely as theoretical concepts inside the ontology, enhancing the ontology substantially

Concepts are classified into several relevant and logical classes. To further ease the construction process, failures and errors are classified in accordance to their three logical physical location of occurrence;

a)
inside the wall of the well (in the sedimentary formation)
b)
in the wellbore itself
c)
in the equipment

A flexible and effective ontology is realized by simultaneously viewing concept classes in more views, if expedient. Table 1 shows common failures also according to type of failure.

Step B - Cause-effect relations: An important property of the ontology model is the cause-effect relationship between concepts, and their resulting paths. The end-concept is a failure, making it possible to point out the cause of a failure through its path. Cause-effect relations may take many forms or names. Examples of such names are causes, implies and triggers. We have selected to let the “causes” relation represent all above-mentioned cause-effect relations:

Concept A causes Concept B
B is caused by A (inverse relation)

Every relationship is bi-directional, as each ‘causes’ relations automatically has an inverse relation. The strength of the relation is important. Strength varies between 1.0 and 0.1. The adverb expressing the relation-strength is:

always → 0.85–1.00
typically→0.55–0.85
sometimes → 0.25–0.55
seldom → 0.10–0.25

By including logical operators like AND, OR and IF THEN, we can develop creative and complex relationships, leading to a versatile ontology. New drilling experience realized for instance by an external user of the model, experience which is still not a part of the model, can be “translated” and entered the model.

Step 4: Probability Estimation.

After a failure case has occurred, the model estimates the most probable failures based on detected symptoms and the relation paths it generates. In order to estimate and compare failure-probabilities, path strengths of each single path to the target failure, and explanation strength of each failure, are needed:(3)•Path strength = П(i=1 to n) (Relation Strength)i [→ Involved Rel. Str. are multiplied](4)•Explanation strength = ∑(j=1 to m) (Path Strength)j [→ Involved Path Str. are summed up](5)•p failure k = Explanation Strength failure k / Explanation Strength all failures

After all paths are defined, the only data input to eqns. 3, 4 and 5 is the Relation Strength, defined in Step 3 and exemplified in Fig. 6. The two letters n and m are number of relations in a path and number of paths pr. failure, respectively. Calculated explanation strengths serve as a good measure for identifying probability, p, of failure number k. A path consisting of many concepts (relations) obtains a weak strength, since each factor are < 1.0. Weak paths, however, bring many concepts into play in the evaluation process. Still, if an observation is decisive of a failure, it suffices with a short part and a correspondingly high Path Strength.