US20140180658A1

US20140180658A1 - Model-driven surveillance and diagnostics

Info

Publication number: US20140180658A1
Application number: US14/016,420
Authority: US
Inventors: David John Rossi; Richard Torrens; Zaki Ali
Original assignee: Schlumberger Technology Corp
Current assignee: Schlumberger Technology Corp
Priority date: 2012-09-04
Filing date: 2013-09-03
Publication date: 2014-06-26
Also published as: CA2883572A1; EP2893378A1; WO2014039463A1; EP2893378B1; EP2893378A4

Abstract

Performing diagnostic of hydrocarbon production in a field includes generating a thermal-hydraulic production system model of a wellsite and a surface facility in the field, and simulating, using the thermal-hydraulic production system model, and based on multiple root causes, a hydrocarbon production problem to generate a feature vectors corresponding to the root causes. Each of feature vectors includes parameter values corresponding to physical parameters associated with the hydrocarbon production. Performing diagnostic further includes configuring, using the feature vectors, a classifier of the hydrocarbon production problem, detecting the hydrocarbon production problem in the field, analyzing, using the classifier, and in response to detecting the hydrocarbon production problem, surveillance data from the wellsite and the surface facility to identify a root cause, and presenting the root cause to a user. The classifier is configured to classify the hydrocarbon production problem according to the root causes.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority under 35 U.S.C. §119 (e) from Provisional Patent Application No. 61/696,580, filed on Sep. 4, 2012, and entitled “MODEL-DRIVEN SURVEILLANCE AND DIAGNOSTICS” (with attorney docket number IS12.2921-US-PSP), which is hereby incorporated by reference.

BACKGROUND

Operations, such as geophysical surveying, drilling, logging, well completion, and production, may be performed to locate and gather valuable downhole fluids. The subterranean assets are not limited to hydrocarbons such as oil, throughout this document, the terms “oilfield” and “oilfield operation” may be used interchangeably with the terms “field” and “field operation” to refer to a site where any type of valuable fluids or minerals can be found and the activities required to extract them. The terms may also refer to sites where substances are deposited or stored by injecting the substances into the surface using boreholes and the operations associated with this process. Further, the term “field operation” refers to a field operation associated with a field, including activities related to field planning, wellbore drilling, wellbore completion, and/or production using the wellbore.
After oil and gas wells are drilled and hydrocarbon production begins, engineers are responsible for maintaining oil and gas production. One of the challenges faced by oil and gas engineers is to analyze the production system (reservoir, well, choke, flow line) using available measurement data to interpret the root cause for declining production system performance, such as a decline in hydrocarbon flow rate.

BRIEF DESCRIPTION OF DRAWINGS

The appended drawings illustrate several embodiments of model-driven surveillance and diagnostics and are not to be considered limiting of its scope, for model-driven surveillance and diagnostics may admit to other equally effective embodiments.

FIG. 1.1 is a schematic view, partially in cross-section, of a field in which one or more embodiments of model-driven surveillance and diagnostics may be implemented.

FIG. 1.2 shows a model-driven surveillance and diagnostics computer system in accordance with one or more embodiments.

FIG. 2 shows a flowchart of a method for model-driven surveillance and diagnostics in accordance with one or more embodiments.

FIGS. 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, and 3.7 show an example of model-driven surveillance and diagnostics in accordance with one or more embodiments.

FIG. 4 depicts a computer system using which one or more embodiments of model-driven surveillance and diagnostics may be implemented.

DETAILED DESCRIPTION

Aspects of the present disclosure are shown in the above-identified drawings and described below. In the description, like or identical reference numerals are used to identify common or similar elements. The drawings are not necessarily to scale and certain features may be shown exaggerated in scale or in schematic in the interest of clarity and conciseness.
Embodiments of model-driven surveillance and diagnostics provide an algorithmic method that continuously monitors a large number of online measurement signals to detect and automatically classify or diagnose the root cause of an underlying oil and gas production problem. In one or more embodiments, a thermal-hydraulic production system model is created for each root cause problem; in this manner a catalog of scenarios of some production system root cause problems is pre-defined and stored. Each scenario in the catalog is continually re-simulated using the thermal-hydraulic production system model (e.g., PIPESIM®, a registered trademark of Schlumberger Technology Corporation, Houston, Tex.) that predicts the surface and subsurface measurements expected under each scenario. The measurements predicted for each scenario are compared to the actual measurements in order to identify scenarios that are consistent with the measurements, within the accuracies and uncertainties of the measurements and models. In one or more embodiments, the rate of model re-calculation is determined by several factors such as the sample rate of the incoming measurement data, the speed at which the underlying production system changes, the speed of the computing equipment, user specified speed requirements, etc.
FIG. 1.1 depicts a schematic view, partially in cross section, of a field (100) in which one or more embodiments of model-driven surveillance and diagnostics may be implemented. In one or more embodiments, one or more of the modules and elements shown in FIG. 1.1 may be omitted, repeated, and/or substituted. Accordingly, embodiments of model-driven surveillance and diagnostics should not be considered limited to the specific arrangements of modules shown in FIG. 1.1.
As shown in FIG. 1.1, oil and gas production in the field (100) is performed using a wellsite system (204), a flow line (106), and surface facilities (202), collectively referred to as a production system. In particular, the wellsite system (204) includes a wellbore (103) extending from a subsurface reservoir (104) to the surface wellhead (101), with hydrocarbon fluids flowing from the reservoir (104), through perforations (105) in the well casing and up to the wellhead (101). The wellbore operations may be controlled by a surface unit (201). The fluids proceed through a surface flow line (106) to the facilities equipment such as oil, gas and water fluid separators in the surface facilities (202), which may be situated miles to tens of miles away. Throughout this disclosure, the terms “wellbore” and “well” may be used interchangeably.
In a representative production system, measurements may be made using one or more data acquisition devices (102). From time to time (thus referred to as a “point” measurement), using the fluid separator equipment in the surface facilities (202), each individual well and flow line may be channeled into a dedicated fluid separator to perform a well test, where the individual flow rates of the oil, water and gas are measured and recorded. Additionally, instruments may measure pressure (P) and temperature (T) at the wellhead (101) and at the bottom of the well.
In one or more embodiments, the surface unit (201) and the surface facilities (202) may be located at the wellsite system (204) and/or remote locations. The surface unit (201) and the surface facilities (202) may be provided with computer facilities for receiving, storing, processing, and/or analyzing data from the data acquisition devices (102), or other part of the field (100). The surface unit (201) and the surface facilities (202) may also be provided with functionality for actuating mechanisms at the field (100). The surface unit (201) and the surface facilities (202) may then send command signals to the field (100) in response to data received, for example to control and/or optimize various field operations described above.
In one or more embodiments, when managing an oil or gas field, the engineer will monitor the well hydrocarbon flow rate. If it falls more quickly than expected, the engineer will evaluate the available pressure and temperature data, and combine this with additional knowledge and possibly analytical or mathematical models of the system to determine the cause for the decline. Thermal-hydraulic models for the well and flow line allow the engineer to relate measured pressures, temperature and flow rates. System performance can be analyzed to determine, for example, whether the root cause of an observed well performance problem lies with the reservoir (e.g., reservoir (104)), the perforation (inflow) sub-system (e.g., perforations (105)), or the well (tubing and/or annulus) subsystem (e.g., well bore (103)). An example of the thermal-hydraulic model for the well and flow line is described in reference to FIG. 3.1 below.
In one or more embodiments, the wellsite system (204) and the surface facilities (202) are operatively coupled to a model-driven surveillance and diagnostics computer system (208). In particular, the surface unit (201) and the surface facilities (202) are configured to communicate with the model-driven surveillance and diagnostics computer system (208) to send commands to the model-driven surveillance and diagnostics computer system (208) and to receive data therefrom. In one or more embodiments, the data received by the wellsite system (204) and the surface facilities (202) may be sent to the model-driven surveillance and diagnostics computer system (208) for further analysis. Generally, the model-driven surveillance and diagnostics computer system (208) is configured to analyze, model, control, optimize, or perform other management tasks of the aforementioned field operations based on the data provided from the wellsite system (204) and the surface facilities (202). In one or more embodiments, the model-driven surveillance and diagnostics computer system (208) is provided with functionality for manipulating and analyzing the data, such as pressure, temperature, and other well test data, or performing simulation, planning, and optimization of production operations of the wellsite system (204) and the surface facilities (202). In one or more embodiments, the result generated by the model-driven surveillance and diagnostics computer system (208) may be displayed for user viewing using a 2 dimensional (2D) display, 3 dimensional (3D) display, or other suitable display. Although the surface unit (201), the surface facilities (202), and the model-driven surveillance and diagnostics computer system (208) are shown as separate from each other in FIG. 1.1, in other examples, two or more of the surface unit (201), the surface facilities (202), and the model-driven surveillance and diagnostics computer system (208) may also be combined.
FIG. 1.2 shows more details of the model-driven surveillance and diagnostics computer system (208) in which one or more embodiments of model-driven surveillance and diagnostics may be implemented. In one or more embodiments, one or more of the modules and elements shown in FIG. 1.2 may be omitted, repeated, and/or substituted. Accordingly, embodiments of model-driven surveillance and diagnostics should not be considered limited to the specific arrangements of modules shown in FIG. 1.2.
As shown in FIG. 1.2, the model-driven surveillance and diagnostics computer system (208) includes model-driven surveillance and diagnostics tool (230) having model generator (231), analysis engine (232), and statistical classifier (233), data repository (234), and display (237). Each of these elements is described below.
In one or more embodiments, the model-driven surveillance and diagnostics computer system (208) includes the model-driven surveillance and diagnostics tool (230) having software instructions stored in a memory and executing on a processor to communicate with the surface facilities (202) and/or the wellsite system (204) for receiving surveillance data (235) therefrom and to manage (e.g., analyze, model, control, optimize, or perform other management tasks) the aforementioned field operations based on the received surveillance data (235). In one or more embodiments, the received surveillance data (235) is stored in the data repository (234) to be processed by the model-driven surveillance and diagnostics tool (230). One or more field operation management tasks (e.g., analysis task, modeling task, control task, optimization task, etc.) may be performed based on results of the model-driven surveillance and diagnostics tool (230). In one or more embodiments, the surveillance data (235) includes information that represents one or more of pressure data, temperature data, and/or flow rate data. In one or more embodiments, the wellbore (103) may be equipped with a downhole pump, and the surveillance data (235) may also include one or more of electrical current to a downhole pump, electrical voltage at the downhole pump, frequency of the electrical current, well head tubing fluid temperature, well head tubing fluid pressure, downhole pump intake pressure, downhole pump discharge pressure, downhole pump intake fluid temperature, downhole pump motor windings temperature, well head annulus fluid pressure, etc. In other embodiments, the wellbore (103) is not be equipped with a pump.
In one or more embodiments, the model-driven surveillance and diagnostics tool (230) includes the model generator (231) that is configured to generate a thermal-hydraulic production system model (236) that represents the hydrocarbon production of the surface facilities (202) and the wellsite system (204). In one or more embodiments, the thermal-hydraulic production system model (236) is a physics-based mathematical model that has been tuned or calibrated so that the computed signals associated with the surface facilities (202) and the wellsite system (204) match the corresponding measured signals. In one or more embodiments, these computed signals and measured signals correspond to at least a portion of the surveillance data (235). As shown in FIG. 1.2, the thermal-hydraulic production system model (236) may be stored in the repository (234). During the operation of the model-driven surveillance and diagnostics tool (230), the received surveillance data (235) is manipulated by the analysis engine (232) based on the thermal-hydraulic production system model (236) to generate, continuously or intermittently, preliminary results that are rendered and displayed to the user using the display (237). Examples of the thermal-hydraulic production system model (236) are described in reference to FIGS. 3.1-3.7 below.
In one or more embodiments, the model-driven surveillance and diagnostics tool (230) includes the analysis engine (232) that is configured to simulate, using the thermal-hydraulic production system model (236) and based on a number of pre-determined root causes, a hydrocarbon production problem to generate a set of feature vectors (238) corresponding to the root causes. In particular, each of feature vectors (238) includes multiple parameter values corresponding to physical parameters associated with the hydrocarbon production system. Using these feature vectors (238), the analysis engine (232) configures a statistical classifier (233) to classify the hydrocarbon production problem according to the root causes. Examples of the feature vectors (238) and corresponding root causes are described in reference to FIGS. 3.1-3.7 below.
In one or more embodiments, the model-driven surveillance and diagnostics tool (230) includes the statistical classifier (233) that is configured to detect the hydrocarbon production problem in the field and to analyze, in response to detecting the hydrocarbon production problem, the surveillance data (235) to identify one of the pre-determined root causes of the hydrocarbon production problem. In one or more embodiments, the statistical classifier (233) is a Bayesian classifier.
In one or more embodiments, the display (237) may be a two dimensional (2D) display, a three dimensional (3D) display, or other suitable display device. The processor and memory of the model-driven surveillance and diagnostics computer system (208) are not explicitly depicted in FIG. 1.2 so as not to obscure other elements of the model-driven surveillance and diagnostics computer system (208). An example of such processor and memory is described in reference to FIG. 3 below.
The data repository (234) (and/or any information stored therein) may be a data store such as a database, a file system, one or more data structures (e.g., arrays, link lists, tables, hierarchical data structures, etc.) configured in a memory, an extensible markup language (XML) file, any other suitable medium for storing data, or any suitable combination thereof. The data repository (234) may be a device internal to the model-driven surveillance and diagnostics computer system (208). In some embodiments, the data repository (234) may be an external storage device operatively connected to the model-driven surveillance and diagnostics computer system (208).
Additional features and functionalities of the model-driven surveillance and diagnostics tool (230), in particular the analysis engine (232) and the statistical classifier (233), are described in reference to FIG. 2 below.
FIG. 2 depicts an example method for model-driven surveillance and diagnostics in accordance with one or more embodiments. For example, the method depicted in FIG. 2 may be practiced using the model-driven surveillance and diagnostics computer system (208) described in reference to FIGS. 1.1 and 1.2 above. In one or more embodiments, one or more of the elements shown in FIG. 2 may be omitted, repeated, and/or performed in a different order. Accordingly, embodiments of the model-driven surveillance and diagnostics should not be considered limited to the specific arrangements of elements shown in FIG. 2.
Initially in Element 211, a thermal-hydraulic production system model of a wellsite and a surface facility in the field is generated. For example, the wellsite and surface facility may be those depicted in FIG. 1.1 above. In one or more embodiments, the thermal-hydraulic production system model is a physics-based mathematical model that has been tuned or calibrated so that the computed signals associated with the surface facilities and the wellsite system match the corresponding measured signals. In one or more embodiments, these computed signals and measured signals correspond to surveillance data, such as pressure data, temperature data, and/or flow rate data. In one or more embodiments, the wellbore may be equipped with a downhole pump, and the surveillance data may also includes downhole pump surveillance data, such as electrical current to a downhole pump, electrical voltage at the downhole pump, frequency of the electrical current, well head tubing fluid temperature, well head tubing fluid pressure, downhole pump intake pressure, downhole pump discharge pressure, downhole pump intake fluid temperature, downhole pump motor windings temperature, and well head annulus fluid pressure.
Examples of the thermal-hydraulic production system model are described in reference to FIGS. 3.1-3.7 below.
In Element 212, based on a list of pre-determined root causes, a hydrocarbon production problem is simulated using the thermal-hydraulic production system model to generate a set of feature vectors corresponding to the pre-determined root causes. In particular, each feature vector includes a number of parameter values corresponding to physical parameters associated with the hydrocarbon production.
In one or more embodiments, the list of pre-determined root causes includes zero flow through a downhole pump, low flow rate through the downhole pump, and operating the downhole pump that is not submerged in liquid.
In one or more embodiments, physical parameters forming each feature vector includes one or more of electrical current to a downhole pump, electrical voltage at the downhole pump, frequency of the electrical current, well head tubing fluid temperature, well head tubing fluid pressure, downhole pump intake pressure, downhole pump discharge pressure, downhole pump intake fluid temperature, downhole pump motor windings temperature, and well head annulus fluid pressure. In one or more embodiments, the feature vector further includes one or more derivative(s) (i.e., rate(s) of change, or higher order derivative(s)) of these physical parameters. In other words, the one or more derivative(s) are numerical derivatives of the signal.
Examples of simulating the hydrocarbon production problem using the thermal-hydraulic production system model to generate the feature vectors are described in reference to FIGS. 3.1-3.7 below.
In Element 213, probability density functions (PDFs) are obtained where each PDF represents a probability distribution of measurement noise associated with one of the parameter values forming the feature vector.
In Element 214, a statistical classifier of the hydrocarbon production problem is configured using the set of feature vectors, and optionally the PDFs. Specifically, the statistical classifier is configured to classify the hydrocarbon production problem according to the list of pre-determined root causes. In one or embodiments, the statistical classifier includes a Bayesian classifier.
Examples of configuring the statistical classifier using the feature vectors and PDFs are described in reference to FIGS. 3.1-3.7 below.
In Element 215, the hydrocarbon production problem in the field is detected. For example, the hydrocarbon production problem may be detected using conventional surveillance problem detecting technique. In one or more embodiments, the hydrocarbon production problem may be detected based on detecting pressure surveillance data, temperature surveillance data, and/or flow rate surveillance data exceeding one or more pre-defined threshold.
In Element 216, using the statistical classifier and in response to detecting the hydrocarbon production problem, surveillance data from the wellsite and the surface facility are analyzed to identify a root cause from the list of pre-determined root causes as causing the detected hydrocarbon production problem.
In one or more embodiments, analyzing the surveillance data includes using the statistical classifier to generate a classification probability associated with each of the pre-determined root causes based on the surveillance data. Accordingly, the root cause is identified based on the corresponding classification probability meeting a pre-determined criterion.
In one or more embodiments, the statistical classifier is a Bayesian classifier and classification probability is generated at least in part based on previous classification probabilities. For example, the Bayesian classifier obtains previous surveillance data at a previous time and analyzes the previous surveillance data to generate a previous classification probability associated with each of the pre-determined root causes. Subsequently, the Bayesian classifier obtains the surveillance data at a current time and updates the previous classification probabilities based on the surveillance data.
Examples of identifying the root cause using Bayesian updating are described in reference to FIGS. 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, and 3.7 below.
In Element 217, the identified root cause is presented to a user. In one or more embodiments, in response to presenting the root cause to the user, a user input is received from the user that specifies a particular corrective action with respect to the reported root cause. Accordingly, the corrective action is performed based on the user input to address the automatically detected hydrocarbon production problem.
FIGS. 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, and 3.7 depict an example of model-driven surveillance and diagnostics in accordance with one or more embodiments. In one of more embodiments, the example depicted in FIGS. 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, and 3.7 is practiced using the model-driven surveillance and diagnostics computer system (208) described above. Specifically, the example depicted in FIGS. 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, and 3.7 relates to the representative production system shown in FIG. 1.1, with the following example parameters:

- (i) The reservoir (104) produces a single phase liquid at 230 degF and a static reservoir pressure of 3000 psia (i.e., absolute pressure);
- (ii) The inflow model representing liquid flow from the reservoir (104) into the wellbore (103) (e.g., via the perforations (105)) is a productivity index PI=3 STB/D/psi (i.e., stock tank barrel per day per psi);
- (iii) The tubing in the wellbore (103) includes 2500 feet of 5″ tubing producing at a wellhead temperature of 120 degrees Fahrenheit;
- (iv) The flowline (106) includes 20 km of 4″ line; and
- (v) Under normal operations, the system operates at a flow rate of 2744 STB/D (i.e., stock tank barrel per day), with a surface well tubing head pressure of 601 pounds per square inch (psi), and a well bottom hole pressure of 2085 psi, including the hydrostatic pressure.

During normal management of this well and flow line system (referred to as the production system), the engineer monitors the liquid flow rate measurement that may arrive as frequently as several times per minute with modern multiphase flow meters. Suppose that the liquid flow rate drops unexpectedly from 2744 STB/D to 2670 STB/D, indicating a hydrocarbon production problem. In this case, the engineer is responsible for investigating and determining the cause for the decline. Several root cause problems may lead to such a decline, including:

- (i) A flow line blockage, for example a buildup of solids-like wax or asphaltenes in the flowline (106);
- (ii) A well blockage in the tubing connecting the perforated interval (105) at the bottom of the well with the wellhead (101), for example a buildup of solids in the tubing itself;
- (iii) An inflow problem in the perforations/reservoir region close to the well, for example the accumulation of fine material in the rock pore spaces that blocks the flow of fluids (referred to as a decrease in productivity index PI).

Additional possible root causes are listed in TABLE 1 below.

TABLE 1

Examples of root causes for production system performance problems

Subsystem	Examples of root problems

Reservoir	Fast pressure decline due to small compartments; lack
pressure	of aquifer pressure drive or gas cap drive
decline
Wellbore	Fines migration into rock pore spaces; liquid gas
inflow (skin)	condensate formation in gas-filled pore spaces;
	changes in absolute or relative permeability due to
	mechanical or chemical changes
Well tubing	Liquid accumulation in the well (liquid loading); sand
	entry into the well; artificial lift problems;
	erosion/hole in tubing; packer leak; scale formation;
	debris in the well
Choke	Partial blockage of the choke (scale formation; sand
	loading); erosional deterioration of the choke
Flow line	Flow assurance formation of hydrate, wax, asphaltene;
	liquid drop out in flow lines; sanding; leaks; corrosion

Although the engineer may visit the well and flowline system and conduct additional hands-on tests or obtain additional measurements, the type of problem that has occurred may be inferred, as described in reference to FIGS. 3.1-3.4, based on the available remotely measured pressure and temperature data at the wellhead and at the bottom of the well. By way of another example, the root causes may include a change in a reservoir inflow performance, a change in a tubing characteristic, and a change in a surface characteristic. The root causes may also be related to a gas lift well. In such embodiments the root causes may include gas failing to flow into a bottom value in a gas lift well, a flowrate to a gas lift well being incorrect, a gas lift valve being stuck in an open position, and an injection through multiple gas lift values
FIG. 3.1 shows an example of the thermal-hydraulic production system model (236) depicted in FIG. 1.2 above. Specifically, the thermal-hydraulic production system model (236) includes a model A (311) for a base scenario, a model B (312) for a flowline block scenario, a model C (313) for a well blockage scenario, and a model D (314) for an inflow problem scenario. In one or more embodiments, the model A (311), model B (312), model C (313), and model D (314) are PIPESIM® models. As shown in FIG. 3.1, the model A (311) includes the model element A (315), model element B (316), model element C (317), model element D (318), and model element E (319), collectively representing the normal operations described above. Although not explicitly shown, each of the model B (312), model C (313), and model D (314) includes similar model elements with certain modification. In particular, the flowline block scenario introduces a reduction to 1″ in flowline diameter at one point along the flowline (106); the well blockage scenario introduces a reduction to 1″ in tubing diameter at one point along the well tubing in the wellbore (103); and the inflow problem scenario that reduces the PI to 2.908 in the inflow model.
All three root cause problem scenarios correspond to a liquid flow rate close to the observed declined rate of 2670 STB/D. By running the PIPESIM® model for these cases, the simulated liquid flow rates, wellhead pressure, and bottom hole pressure are listed in TABLE 2 below.

TABLE 2

Simulated flow rates and pressures for the base case and three root cause
scenarios

			Bottom
	Liquid	Wellhead	Hole
	Flow Rate	Pressure	Pressure
Case	(STB/D)	(psi)	(psi)

Base case	2744	601	2085
Flowline	2670	626	2110
block
Well
2670	594	2109
blockage
Inflow
2670	597	2081

FIG. 3.2 shows a cross-plot of predicted bottom hole pressure and wellhead pressure under the three root cause problem scenarios described above. The base case shown in TABLE 2 is omitted in FIG. 3.2 for clarity. The bottom hole pressure and wellhead pressure form the feature vector and the cross-plot correspond to a 2-dimensional (2D) feature vector space (320). As shown in FIG. 3.2, the feature vector A (321), feature vector B (322), and feature vector C (323) correspond to the well blockage scenario, inflow problem scenario, and flowline block scenario, respectively. In particular, these three feature vectors are within a range of approximately 30 psi in either the x-axis or y-axis of the cross-plot.
Based on the cross-plot shown in FIG. 3.2, various methods may be used to process the continuous field measurements of flow rate, pressure, and temperature to detect when conditions have moved away from the base case in TABLE 2, and when this happens, to determine which of the three root cause problems likely have occurred:

- Crisp logic method—hard-coded logic may be configured based on the proximity (or weighted proximity) of the measured values to the feature vectors in the 2D feature vector space (320);
- Fuzzy logic method—online measurements may be compared to the feature vectors in the 2D feature vector space (320) to compute fuzzy logic set membership (between zero and one) that is used as the basis for detection and diagnostics;
- Neural networks method—if enough historical data points are available of the measurement data and the associated state of the production system, a neural network may be created and calibrated that relates incoming pressure and flow rate data to a decision regarding which root cause problem scenario the system is in;
- Probabilistic method—because the measurements are not precise, and because new measurements are available at high frequency, a recursive procedure such as Baysian updating may be used to track the evolution of the production system from one time to the next.

In particular, the probabilistic method is described in additional details below with a specific example computation to illustrate the method. For example, let S={S₀, S₁, S₂, S₃} denote the set of four scenarios shown in the four rows of TABLE 2. Consider a recursive process at times t=t₀, t₁, t_k−1, t_k, t_k+1, . . . where the current time is denoted t_k. After the computation of the previous time t_k−1, the probability that the system is in scenario state S_jis denoted
P _k−1(S _j)j=0,1,2,3 (Eq 1)
The probabilities in (Eq 1) are between zero and one, and the four probabilities sum to one. The modeled data d under each scenario may be computed using PIPESIM®.as shown in TABLE 2, where the j^throw provides the modeled data under scenario j which is referred to as d_j. PIPESIM® is a registered trademark of Schlumberger Technology Corporation, located in Houston, Tex., United States of America. For example, under the second scenario j=2 where the well blockage has occurred, the modeled data are:
$\begin{matrix} d_{j} = [\begin{matrix} 2670 \\ 594 \\ 2109 \end{matrix}] & (Eq 2) \end{matrix}$
Because the actual sensor readings are not precise, the actual sensor readings are modeled as the modeled data plus some degree of uncertainty, represented as additive noise. Specifically, under the assumption that the true scenario is S_jwith noise-free 3-dimensional modeled data d_j, the noisy 3-dimensional measurement m_kat time k is represented as:
m _k =d _j +w _k w _k ˜N(0,Σ) (Eq 3)
In (Eq 3) the 3-dimensional additive noise w_kis modeled as a Gaussian or Normal probability density function (PDF), having zero mean and 3×3 covariance matrix Σ. The PDF for the measurement m_kat time t_kunder scenario S_jmay then be described probabilistically as a Bayses' rule shown in (Eq 4), where the number of measurements L=3, and the vertical bar notation on the left side of the equation denotes “given”.
$\begin{matrix} P (m_{k} | S_{j}) = \frac{1}{{(2 π)}^{L / 2} {\langle Σ \rangle}^{1 / 2}} \exp - \frac{1}{2} {(m_{k} - d_{j})}^{'} \sum^{- 1} (m_{k} - d_{j}) j = 0, 1, 2, 3 & (Eq 4) \end{matrix}$
(Eq 4) corresponds to the so-called “forward problem” of computing the PDF for the measurement m_k, given the scenario state S_j. The engineer, however, may address the “inverse problem”, that is: given an observed measurement M_kat time k, determine the most likely scenario state S by calculating the posterior probability that the system is in each scenario S_jgiven the measurement M_k:
P _k(S _j)=P(S _j |m _k =M _k)j=0,1,2,3 (Eq 5)
Bayesian inference or Bayesian updating is a method of inference in which Bayes' rule is used to update the probability estimate for a hypothesis as additional evidence is acquired. Bayesian updating provides a direct means of computing (Eq 5) in terms of quantities known from (Eq 1) and (Eq 4) as follows:
$\begin{matrix} P_{k} (S_{j}) = P (S_{j} | m_{k} = M_{k}) = \frac{P (m_{k} = M_{k} | S_{j}) P_{k - 1} (S_{j})}{\sum_{j = 0}^{3} P (m_{k} = M_{k} | S_{j}) P_{k - 1} (S_{j})} j = 0, 1, 2, 3 & (Eq 6) \end{matrix}$
In one or more embodiments, (Eq 6) is used to recursively compute, from one time to the next, the probability that the production system has moved into scenario state S_j. Alerts may be implemented based on the behavior of these probabilites, in order to (1) warn that the production system has moved away from the base case S₀, and (2) provide a pre-diagnostic that the production system appears to be approaching the root cause scenario having the largest posterior probability in (Eq 6).
Note that (Eq 6) is recursive, that is, the output P_k(S_j) at one time is considered to be the input P_k−1(S_j) at the next time. (Eq 6) provides a convenient computation that allows adaptation of the method over time. In particular, if additional types of measurements are introduced into the production system, such as multiphase flow rates at the wellhead, (Eq 6) still applies with the number of measurements L increased by one. The method developed in (Eq 1) through (Eq 6) is illustrated in the following example described in references to FIG. 3.3-3.6.
FIGS. 3.3-3.6 show a 3-dimensional (3D) feature vector space expanded from the 2D feature vector space (320) shown in FIG. 3.2 to include a set of three measurements: (1) well flow rate (e.g., from metering devices or well tests), (2) wellhead pressure (e.g., tubing head pressure or other pressure), and (3) bottom hole pressure. In one or more embodiments, the 3D feature vector space is presented in FIGS. 3.3-3.6 as a composite of two 2D cross-plots where each feature vector is represented as a node in each of the two 2D cross-plots. For example, the well blockage feature vector (331), inflow problem feature vector (333), and flowline block feature vector (334) are 3D feature vectors expanded from the 2-dimensional feature vector A (321) for the well blockage scenario, feature vector B (322) for the inflow problem scenario, and feature vector C (323) for the flowline block scenario, respectively as shown in FIG. 3.2 above. Further, each of the well blockage feature vector (331), inflow problem feature vector (333), and flowline block feature vector (334) may be the same throughout the four example cases described in reference to FIGS. 3.3, 3.4, 3.5, and 3.6 below.
In the description of FIGS. 3.3, 3.4, 3.5, and 3.6 below, the behavior of the Bayesian root cause diagnosed using (Eq 1)-(Eq 6) is evaluated using simulated noisy data to represent continuous field measurement data. For example, the measurement covariance Σ in (Eq 3) may be a 3×3 matrix with diagonal entries [400, 80, 80]. Note that the measurement covariance matrix is set to be diagonal, which means that the measurement noise is assumed to be uncorrelated. In other examples, the covariance matrix may also have nonzero off-diagonal terms corresponding to correlation of the noise sources. The diagonal entries of Σ correspond to the measurement variance (square of the standard deviation). Therefore, the assumed variance values of 400, 80 and 80 correspond to measurement standard deviations of ±20 STB/D for the well test measurement, and ±8.9 psi for the wellhead pressure and bottom hole pressure measurements.
CASE 1: Base case with noisy measurements is shown in FIG. 3.3 below.
Consider the case where the system root scenario is the base case, where the simulated base case values of the three measurements under normal operation are given by the first row of TABLE 2, namely 2744 STB/D. 601 psi, and 2085 psi. Under the assumed measurement standard deviations of ±20 STB/D on the well test and ±9 psi on the pressure measurements, a noisy measurement is simulated (Gaussian random number generator) of 2752 STB/D, 594 psi wellhead pressure, and 2097 psi bottom hole pressure.
FIG. 3.3 shows the 3D feature vector space A (330) where the simulated noisy measurement data (denoted as measurements (337)) is shown in the same cross-plots with the well blockage feature vector (331), inflow problem feature vector (333), and flowline block feature vector (334). In addition, FIG. 3.3 shows the prior probability histogram A (335) and the posterior probability histogram A (336). Specifically, the prior probability histogram A (335) shows the prior scenario root cause probability of 97% chance for the base case, and 1% chance for each other problem scenario. The posterior probability histogram A (336) shows the posterior scenario root cause probabilities computed using (Eq 4). Since there is no measurement evidence that any other scenario than the base scenario is true, the posterior probability is also near unity for the base case root cause in the posterior probability histogram A (336).
CASE 2: Flow line block scenario with noisy measurements is shown in FIG. 3.4 below.
Consider now the case where the system is experiencing a flow line block, where the simulated values of the three measurements are given by the second row of TABLE 2, namely 2670 STB/D, 626 psi, 2110 psi. Assuming a measurement standard deviation of ±20 STB/D on the well test and ±9 psi on the pressure measurements, a noisy measurement is simulated as 2692 STB/D, 636 psi wellhead pressure, and 2101 psi bottom hole pressure.
FIG. 3.4 shows the 3D feature vector space B (340) where the simulated noisy measurement data (denoted as measurements (347)) is shown in the same cross-plots with the well blockage feature vector (331), inflow problem feature vector (333), and flowline block feature vector (334). In addition, FIG. 3.4 shows the prior probability histogram B (345) and the posterior probability histogram B (346). Specifically, the prior probability histogram B (345) shows the prior scenario root cause probability of 97% chance for the base case, and 1% chance for each other scenario. The posterior probability histogram B (346) shows the posterior scenario root cause probabilities computed using (Eq 4). Even though the noisy measurements are not close to any of the feature vectors in the 3D feature vector space B (340), the posterior probability is computed to be nearly unity for the flow line block root cause in the posterior probability histogram B (346).
CASE 3: Well blockage scenario with noisy measurements is shown in FIG. 3.5 below.
Consider now the case where the system is experiencing a well blockage, where the simulated values of the three measurements are given by the third row of TABLE 2, namely 2670 STB/D, 594 psi, and 2109 psi. Assuming a measurement standard deviation of ±20 STB/D on the well test and ±9 psi on the pressure measurements, a noisy measurement is simulated as 2654 STB/D, 600 psi wellhead pressure, and 2122 psi bottom hole pressure.
FIG. 3.5 shows the 3D feature vector space C (350) where the simulated noisy measurement data (denoted as measurements (357)) is shown in the same cross-plots with the well blockage feature vector (331), inflow problem feature vector (333), and flowline block feature vector (334). In addition, FIG. 3.5 shows the prior probability histogram C (355) and the posterior probability histogram C (356). Specifically, the prior probability histogram C (355) shows the prior scenario root cause probability of 97% chance for the base case, and 1% chance for each other scenario. The posterior probability histogram C (356) shows the posterior scenario root cause probabilities computed using (Eq 4). Again, even though the noisy measurements are not close to any of the feature vectors in the 3D feature vector space C (350), the posterior probability is computed to be nearly unity for the well blockage root cause in the posterior probability histogram C (356).
CASE 4: Inflow scenario with noisy measurements is shown in FIG. 3.6 below.
Consider now the case where the system is experiencing an inflow problem, where the simulated values of the three measurements are given by the fourth row of TABLE 2, namely 2670 STB/D, 597 psi, and 2081 psi. Assuming a measurement standard deviation of ±20 STB/D on the well test and ±9 psi on the pressure measurements, a noisy measurement is simulated as 2672 STB/D, and 586 psi wellhead pressure, and 2072 psi bottom hole pressure.
FIG. 3.6 shows the 3D feature vector space D (360) where the simulated noisy measurement data (denoted as measurements (367)) is shown in the same cross-plots with the well blockage feature vector (331), inflow problem feature vector (333), and flowline block feature vector (334). In addition, FIG. 3.6 shows the prior probability histogram D (365) and the posterior probability histogram D (366). Specifically, the prior probability histogram D (365) shows the prior scenario root cause probability of 97% chance for the base case, and 1% chance for each other scenario. The posterior probability histogram D (366) shows the posterior scenario root cause probabilities computed using (Eq 4). Even though the noisy measurements are not very close to any of the feature vectors in the 3D feature vector space D (360), the posterior probability is computed to be nearly unity for the well inflow root cause in the posterior probability histogram D (366).
In summary, the example shown in FIGS. 3.1-3.6 above describes a method to solve the “inverse problem” of observing online measurements (i.e., continuous field measurements) such as pressures and flow rates in an oil and gas production system, and determining directly the likelihood of the root cause for the observations. The method is based on pre-defining a catalog of root cause scenarios, such as flow line blockage, well blockage, and inflow issues. The method continually re-calculates the probability that each competing scenario is the true explanation for the noisy measured data, using Bayesian updating to compute the scenario posterior probabilities.
This method has a number of advantage including:

- Speed of automated computation—each time new data arrive, the catalog of problem scenario models are run automatically to simulate measurements; equations (Eq 4) and (Eq 5) are closed-form computations that do not require human intervention;
- The ability to “learn” or capture oil and gas field knowledge through the definition of root cause scenarios. Knowledge about the system is captured in the state probabilities—with time, the posterior probabilities are recomputed recursively to represent the evolving state of the system.
- Flexibility, since the set of possible scenarios can expand with time as additional failure modes are incorporated into the scenario catalog. Also, if new measurement sensors are added to the system, the equations can be easily expanded to cover the added measurement data.

Although the example shown in FIGS. 3.1-3.6 above uses a limited number (i.e., two or three) of measurements to form the feature vector, additional measurements may also be included in the feature vector, such as one or more of the following:

- Current—the electrical current to the downhole pump motor, in amperes;
- Voltage—the electrical voltage at the downhole pump motor, in volts;
- Frequency—the frequency of the applied alternating electrical current in Hz;
- WHT—well head tubing fluid temperature in degrees;
- WHP—well head tubing fluid pressure in pounds per square inch (psi);
- P_i—downhole pump intake pressure in psi;
- P_d—downhole pump discharge pressure in psi;
- P_d-P_i—the difference between discharge and intake, i.e. the pressure drop across the pump;
- T_i—pump intake fluid temperature in degrees;
- T_m—pump motor windings temperature in degrees;
- WHP-A—well head annulus fluid pressure in psi.

TABLE 3 below also shows the behavior of these different measurements that may be expected in the event of several hypothetical root-cause problems that are listed in the two right hand columns. Three root-cause problems are listed here: deadhead (i.e., zero flow through the running pump), low flow rate through the pump, and pump-off (i.e., operating the pump while it is not submerged in liquid). Note that TABLE 3 indicates various levels of expected variations in the measurements, using single and double arrows up, down, and sideways corresponding to increasing, decreasing, and substantially unchanged. One row in this TABLE may be considered a set of features forming a feature vector corresponding to a root-cause problem. In other words, the root-cause problem feature vectors are specified at the outset, or pre-determined.

TABLE 3

	Most Probable
SYMPTOM	Cause

Current

Voltage

Freq.

WHT

WHP

Pi

Pd

Pd-Pi

Ti

Tm

WHP-A

Name

Code

⇓

⇑

Deadhead

DH1

⇓

⇑

⇓ ⇓

⇓

⇑ ⇑

⇑

⇑ ⇑

⇑

⇑ ⇑

Deadhead

DH2

⇓

⇑

Deadhead

DH3

⇓

⇑

⇓

⇑

Low

LF1

Flow

⇓

↑

⇓

⇓ ⇓

⇑

↑

Pump-off

PO1

⇓

The symptoms are the same as PO1, but the rate of change is	Pump-off	PO2
slower.

FIG. 3.7 shows an example flowchart of the method described above that is based on coupling a mathematical simulator (371) of a physical process to a Bayesian classifier (376) into a single integrated model-based system that is fully automated. In particular, this system autonomously computes the expected root-cause features (372), and automatically transfers those features into the Bayesian classifier (376). Specifically, the mathematical simulator (371) computes the expected signals (i.e., features (372)) under each of the assumed root causes (370), and automatically feeds those features (372) along with a description of the measurement noise statistics (374) to the Bayesian classifier (376). Measurement noise statistics (374) are used to define a catalog of measurement PDFs (373). In response, the Bayesian classifier (376) computes the updated probability (377) of each root-cause n=1, . . . , N, given the latest measurement data (375) at each time. These updated probabilities (377) are then used in subsequent root-cause diagnostics, where a problem is detected once at least one of the updated probabilities (377) exceeds a pre-determined threshold, and the root cause with the highest posterior probability is selected as the most likely root cause.
Note that as time advances, the updated posterior root-cause probabilities (377) from the previous time T become the prior probabilities (378) for the subsequent time T+1 (379). In this fashion, the Bayesian classifier (376) has an aspect of memory or an ability to take into account previous observations during the current Bayesian update computation. This particular aspect is advantageous because the root-cause features may vary with time, i.e., the feature vectors may be dependent on the current state of the production system. By using the current latest calibrated simulator to compute the root-cause features, this model-driven surveillance and diagnostic system out-perform traditional Bayesian classifiers that are pre-programmed with static nominal feature descriptions.
Embodiments of model-driven surveillance and diagnostics may be implemented on virtually any type of computing system regardless of the platform being used. For example, the computing system may be one or more mobile devices (e.g., laptop computer, smart phone, personal digital assistant, tablet computer, or other mobile device), desktop computers, servers, blades in a server chassis, or any other type of computing device or devices that includes at least the minimum processing power, memory, and input and output device(s) to perform one or more embodiments of the invention. For example, as shown in FIG. 4, the computing system (400) may include one or more computer processor(s) (402), associated memory (404) (e.g., random access memory (RAM), cache memory, flash memory, etc.), one or more storage device(s) (406) (e.g., a hard disk, an optical drive such as a compact disk (CD) drive or digital versatile disk (DVD) drive, a flash memory stick, etc.), and numerous other elements and functionalities. The computer processor(s) (402) may be an integrated circuit for processing instructions. For example, the computer processor(s) may be one or more cores, or micro-cores of a processor. The computing system (400) may also include one or more input device(s) (410), such as a touchscreen, keyboard, mouse, microphone, touchpad, electronic pen, or any other type of input device. Further, the computing system (400) may include one or more output device(s) (408), such as a screen (e.g., a liquid crystal display (LCD), a plasma display, touchscreen, cathode ray tube (CRT) monitor, projector, or other display device), a printer, external storage, or any other output device. One or more of the output device(s) may be the same or different from the input device. The computing system (400) may be connected to a network (412) (e.g., a local area network (LAN), a wide area network (WAN) such as the Internet, mobile network, or any other type of network) via a network interface connection (not shown). The input and output device(s) may be locally or remotely (e.g., via the network (412)) connected to the computer processor(s) (402), memory (404), and storage device(s) (406). Many different types of computing systems exist, and the aforementioned input and output device(s) may take other forms.
Software instructions in the form of computer readable program code to perform embodiments of the invention may be stored, in whole or in part, temporarily or permanently, on a non-transitory computer readable medium such as a CD, DVD, storage device, a diskette, a tape, flash memory, physical memory, or any other computer readable storage medium. Specifically, the software instructions may correspond to computer readable program code that when executed by a processor(s), is configured to perform embodiments of the invention.
Further, one or more elements of the aforementioned computing system (400) may be located at a remote location and connected to the other elements over a network (412). Further, embodiments of the invention may be implemented on a distributed system having a plurality of nodes, where each portion of the invention may be located on a different node within the distributed system. In one embodiment of the invention, the node corresponds to a distinct computing device. The node may correspond to a computer processor with associated physical memory. The node may correspond to a computer processor or micro-core of a computer processor with shared memory and/or resources.
While the invention has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of this disclosure, will appreciate that other embodiments can be devised which do not depart from the scope of the invention as disclosed herein. Accordingly, the scope of the invention should be limited only by the attached claims.

Claims

What is claimed is:

1. A method to perform diagnostic of hydrocarbon production in a field, comprising:

generating a thermal-hydraulic production system model of a wellsite and a surface facility in the field;

simulating, by a computer processor, using the thermal-hydraulic production system model, and based on a plurality of root causes, a hydrocarbon production problem to generate a plurality of feature vectors corresponding to the plurality of root causes,

wherein each of the plurality of feature vectors comprises a plurality of parameter values corresponding to a plurality of physical parameters associated with the hydrocarbon production;

configuring, using the plurality of feature vectors, a classifier of the hydrocarbon production problem,

wherein the classifier is configured to classify the hydrocarbon production problem according to the plurality of root causes;

detecting the hydrocarbon production problem in the field;

analyzing, by the computer processor, using the classifier, and in response to detecting the hydrocarbon production problem, surveillance data from the wellsite and the surface facility to identify a root cause of the plurality of root causes; and

presenting the root cause to a user.

2. The method of claim 1,

wherein the plurality of root causes comprises at least one selected from a group consisting of a change in a reservoir inflow performance, a change in a tubing characteristic, and a change in a surface characteristic.

3. The method of claim 1,

wherein the plurality of root causes comprises at least one selected from a group consisting of a zero flow through a downhole pump, low flow rate through the downhole pump, and operating the downhole pump that is not submerged in liquid, and

wherein the plurality of physical parameters comprises at least one selected from a group consisting of electrical current to the downhole pump, electrical voltage at the downhole pump, frequency of the electrical current, well head tubing fluid temperature, well head tubing fluid pressure, downhole pump intake pressure, downhole pump discharge pressure, downhole pump intake fluid temperature, downhole pump motor windings temperature, and well head annulus fluid pressure.

4. The method of claim 1, further comprising:

obtaining a plurality of probability density functions, wherein each of the plurality of probability density functions represents a probability distribution of measurement noise associated with one of the plurality of parameter values,

wherein the classifier is further configured using the plurality of probability density functions.

5. The method of claim 1, wherein analyzing the surveillance data comprises:

generating, using the classifier and based on the surveillance data, a classification probability associated with each of the plurality of root causes,

wherein identifying the root cause is based on the classification probability associated with the root cause meeting a pre-determined criterion.

6. The method of claim 5, further comprising:

obtaining previous surveillance data at a previous time;

analyzing, using the classifier, the previous surveillance data to generate a previous classification probability associated with each of the plurality of root causes, wherein the classifier is a Bayesian classifier; and

obtaining the surveillance data at a current time subsequent to the previous time,

wherein generating the classification probability associated with each of the plurality of root causes comprises updating, based on the surveillance data, the previous classification probability associated with each of the plurality of root causes.

7. The method of claim 1,

wherein the plurality of root causes comprise at least one selected from a group consisting of gas failing to flow into a bottom value in a gas lift well, a flowrate to a gas lift well being incorrect, a gas lift valve being stuck in an open position, and an injection through multiple gas lift values.

8. A system to perform diagnostic of hydrocarbon production in a field, comprising:

a wellsite and a surface facility in the field for performing the hydrocarbon production;

a surveillance and diagnostics computer system, comprising:

a model generator executing on a computer processor configured to:

generate a thermal-hydraulic production system model of the wellsite and the surface facility in the field, and

an analysis engine executing on a computer processor and configured to:

simulate, using the thermal-hydraulic production system model and based on a plurality of root causes, a hydrocarbon production problem to generate a plurality of feature vectors corresponding to the plurality of root causes,

wherein each of the plurality of feature vectors comprises a plurality of parameter values corresponding to a plurality of physical parameters associated with the hydrocarbon production, and

configure, using the plurality of feature vectors, a classifier of the hydrocarbon production problem,

wherein the classifier executes on a computer processor and is further configured to:

classify the hydrocarbon production problem according to the plurality of root causes,

detect the hydrocarbon production problem in the field,

analyze, in response to detecting the hydrocarbon production problem, surveillance data from the wellsite and the surface facility to identify a root cause of the plurality of root causes, and

present the root cause to a user; and

a repository configured to store the surveillance data and the thermal-hydraulic production system model.

9. The system of claim 8,

10. The system of claim 8,

11. The system of claim 8, wherein the analysis engine is further configured to:

obtain a plurality of probability density functions, wherein each of the plurality of probability density functions represents a probability distribution of measurement noise associated with one of the plurality of parameter values,

12. The system of claim 8, wherein analyzing the surveillance data comprises:

13. The system of claim 12,

wherein the analysis engine is further configured to:

obtain previous surveillance data at a previous time; and

obtain the surveillance data at a current time subsequent to the previous time,

wherein the classifier is further configured to:

analyze the previous surveillance data to generate a previous classification probability associated with each of the plurality of root causes, wherein the classifier is a Bayesian classifier, and

14. The system of claim 8,

15. A non-transitory computer readable medium comprising instructions to perform diagnostic of hydrocarbon production in a field, the instructions when executed by a computer processor comprising functionality for:

detecting the hydrocarbon production problem in the field;

presenting the root cause to a user.

16. The non-transitory computer readable medium of claim 15,

17. The non-transitory computer readable medium of claim 15,

18. The non-transitory computer readable medium of claim 15, further comprising:

19. The non-transitory computer readable medium of claim 15, wherein analyzing the surveillance data comprises:

20. The non-transitory computer readable medium of claim 19, further comprising:

obtaining previous surveillance data at a previous time;