Note: Descriptions are shown in the official language in which they were submitted.
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
MODEL-DRIVEN SURVEILLANCE AND DIAGNOSTICS
BACKGROUND
100011 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.
[0002] 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.
1
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
BRIEF DESCRIPTION OF DRAWINGS
[0003] 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.
[0004] 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.
[0005] FIG. 1.2 shows a model-driven surveillance and diagnostics computer
system in accordance with one or more embodiments.
[0006] FIG. 2 shows a flowchart of a method for model-driven surveillance
and
diagnostics in accordance with one or more embodiments.
[0007] 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.
[0008] FIG. 4 depicts a computer system using which one or more
embodiments of
model-driven surveillance and diagnostics may be implemented.
DETAILED DESCRIPTION
[0009] 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.
[0010] 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
2
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
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, TX) 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.
[0011] 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.
[0012] 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
3
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
(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.
[0013] 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.
[0014] 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.
[0015] 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
4
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
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.
[0016] 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
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
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.
[0017] 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.
[0018] 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.
[0019] 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
6
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
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.
[0020] 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
7
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
(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.
[0021] 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.
[0022] 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.
[0023] 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
8
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
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.
[0024] 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).
[0025] 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.
[0026] 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.
[0027] 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
9
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
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.
[0028] Examples of the thermal-hydraulic production system model are
described
in reference to FIGS. 3.1-3.7 below.
[0029] 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.
[0030] 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.
[0031] In one or more embodiments, physical parameters forming each
feature
vector includes one or more of electrical current to a downhole pump,
electrical
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] Examples of configuring the statistical classifier using the
feature vectors
and PDFs are described in reference to FIGS. 3.1-3.7 below.
[0036] 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.
11
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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
12
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
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.
[0043] 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 multi-
phase 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:
13
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
(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).
[0044] 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
[0045] Although the engineer may visit the well and flowline system and
conduct
14
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
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
[0046] 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.
[0047] All three root cause problem scenarios correspond to a liquid flow
rate
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
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
Case Liquid Wellhead Bottom
Flow Rate Pressure Hole
(STB/D) (psi) Pressure
(psi)
Base case 2744 601 2085
Flowline 2670 626 2110
block
Well 2670 594 2109
blockage
Inflow 2670 597 2081
[0048] 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.
[0049] 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:
16
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
= 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.
[0050] In particular, the probabilistic method is described in additional
details
below with a specific example computation to illustrate the method. For
example, let S = {S0, Si, S2, 53} denote the set of four scenarios shown in
the
four rows of TABLE 2. Consider a recursive process at times t = to, ti, t, tk,
tk+i,
... where the current time is denoted tk. After the computation of the
previous
time tk_i, the probability that the system is in scenario state Si is denoted
Pk¨ I(S d) jO12,3 (Eq 1)
[0051] 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 PIPESIMED.as shown in TABLE 2, where the jth row provides the
17
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
modeled data under scenario j which is referred to as di. PIPESIM is a
registered trademark of Schlumberger Technology Corporation, located in
Houston, Texas, United States of America. For example, under the second
scenario j=2 where the well blockage has occurred, the modeled data are:
- 2670 -
di = 594
_ 2109 _ (Eq 2)
[0052]
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 Si with noise-free 3-dimensional modeled data di, the noisy 3-
dimensional measurement mk at time k is represented as:
= di tPk trfr N(0, 17)
I (Eq 3)
[0053]
In (Eq 3) the 3-dimensional additive noise wk is modeled as a Gaussian or
Normal probability density function (PDF), having zero mean and 3x3
covariance matrix Z. The PDF for the measurement mk at time tk under scenario
Si may 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".
P(Tnk Si) = , 1 v '2 exp ¨ Yink ¨ di)1171 I eni ¨ di)
= 0, 1, 2, 3
(Eq 4)
[0054]
(Eq 4) corresponds to the so-called "forward problem" of computing the
PDF for the measurement mk, given the scenario state Si. The engineer,
however,
may address the "inverse problem", that is: given an observed measurement Mk
at time k, determine the most likely scenario state S by calculating the
posterior
probability that the system is in each scenario Si given the measurement Mk:
18
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
Pk(S1) = P(Sj Mk = Mk) J- O. 1, 2, 3 (Eq 5)
[0055] 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:
P(171 k= i)Pk_ I( S
Pk(S j) = P(S ,) k = = ____________________________ j = 0.1 2,3
m k=11, S S ?)
d 3¨u
(Eq 6)
[0056] 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 Si. 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 So, 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).
[0057] Note that (Eq 6) is recursive, that is, the output Pk(Si) at one
time is
considered to be the input Pk_i(Si) 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.
[0058] 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
19
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
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.
[0059] 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 Z in (Eq 3) may be a 3x3 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 Z
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.
[0060] CASE 1: Base case with noisy measurements is shown in FIG. 3.3
below.
[0061] 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
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
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.
[0062] 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).
[0063] CASE 2: Flow line block scenario with noisy measurements is shown
in
FIG. 3.4 below.
[0064] 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.
[0065] 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
21
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
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).
[0066] CASE 3: Well blockage scenario with noisy measurements is shown in
FIG. 3.5 below.
[0067] 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.
[0068] 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
22
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
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).
[0069] CASE 4: Inflow scenario with noisy measurements is shown in FIG.
3.6
below.
[0070] 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.
[0071] 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).
[0072] In summary, the example shown in FIGS. 3.1-3.6 above describes a
method
23
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
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.
[0073] 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.
[0074] 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:
24
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
= 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);
= Pi ¨ downhole pump intake pressure in psi;
= Pd- downhole pump discharge pressure in psi;
= Pd-Pi ¨ the difference between discharge and intake, i.e. the pressure
drop across the pump;
= Ti ¨ pump intake fluid temperature in degrees;
= Tm ¨ pump motor windings temperature in degrees;
= WHP-A ¨ well head annulus fluid pressure in psi.
[0075] 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
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
vector corresponding to a root-cause problem. In other words, the root-cause
problem feature vectors are specified at the outset, or pre-determined.
26
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
TABLE 3
SYMPTOM Most Probable
Cause
tm = a .. -tC
-c, , .._, E 4 Name Code
a' -8 4:: Pl= Pl= '-c E-1
Pl=
L)
Deadhead DH1
Deadhead DH2
40 40 <* <* 40 + + + +l +l + +l <*.
Deadhead DH3
40 <* <* 40 + + + + + + <*
Low LF1
40 +++ 40 + + 40 + + <*. Flow
Pump-off P01
40 T T 40 40 : ++ : + + T
The symptoms are the same as P01, but the rate of change is
Pump-off P02
slower.
[0076] 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
27
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
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.
[0077] 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.
[0078] 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
28
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
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.
[0079] 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
29
CA 02883572 2015-03-02
WO 2014/039463 PCT/US2013/057901
instructions may correspond to computer readable program code that when
executed by a processor(s), is configured to perform embodiments of the
invention.
[0080] 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.
[0081] 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.
