U.S. patent application number 17/282586 was filed with the patent office on 2021-11-11 for oilfield system.
The applicant listed for this patent is Schlumberger Technology Corporation. Invention is credited to Jeffery Anderson, Alex Bird, Jonathan Wun Shiung Chong, Emmanuel Coste, John MacDonald, Nam Tuan Nguyen, Carlos Rocha, Christy Rubenstein, Yves-Marie Subervie, Ying Wang, Robb Wheatley, Matthew Worthington.
Application Number | 20210348490 17/282586 |
Document ID | / |
Family ID | 1000005780043 |
Filed Date | 2021-11-11 |
United States Patent
Application |
20210348490 |
Kind Code |
A1 |
Wheatley; Robb ; et
al. |
November 11, 2021 |
OILFIELD SYSTEM
Abstract
A method can include receiving time series data acquired during
equipment operations at a plurality of natural resource sites;
detecting operational events using the time series data; ranking
the operational events; associating each of the operational events
with a corresponding operational action; and outputting at least a
portion of the ranked operational events, each with its
corresponding operational action.
Inventors: |
Wheatley; Robb; (Houston,
TX) ; Coste; Emmanuel; (Katy, TX) ; Subervie;
Yves-Marie; (Houston, TX) ; Nguyen; Nam Tuan;
(Houston, TX) ; MacDonald; John; (Aberdeenshire,
GB) ; Chong; Jonathan Wun Shiung; (Houston, TX)
; Rocha; Carlos; (Icarai-Niteroi, BR) ;
Worthington; Matthew; (Houston, TX) ; Anderson;
Jeffery; (Nisku, CA) ; Bird; Alex; (Calgary,
CA) ; Rubenstein; Christy; (Houston, TX) ;
Wang; Ying; (Houston, TX) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Schlumberger Technology Corporation |
Sugar Land |
TX |
US |
|
|
Family ID: |
1000005780043 |
Appl. No.: |
17/282586 |
Filed: |
October 3, 2019 |
PCT Filed: |
October 3, 2019 |
PCT NO: |
PCT/US2019/054405 |
371 Date: |
April 2, 2021 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62740949 |
Oct 3, 2018 |
|
|
|
62873942 |
Jul 14, 2019 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
E21B 43/25 20130101;
E21B 47/02 20130101; E21B 43/30 20130101 |
International
Class: |
E21B 43/25 20060101
E21B043/25; E21B 43/30 20060101 E21B043/30; E21B 47/02 20060101
E21B047/02 |
Claims
1. A method comprising: receiving time series data acquired during
equipment operations at a plurality of natural resource sites;
detecting operational events using the time series data; ranking
the operational events; associating each of the operational events
with a corresponding operational action; and outputting at least a
portion of the ranked operational events, each with its
corresponding operational action.
2. The method of claim 1 wherein the outputting comprises rendering
graphics for the at least a portion of the ranked events to a
graphical user interface, wherein the graphical user interface
comprises graphical controls linked to the graphics that associate
each of the at least a portion of the ranked events with its
corresponding operational action.
3. The method of claim 1 wherein the time series data comprise one
or more of temperature time series data, pressure time series data,
fluid flow time series data and electrical time series data.
4. The method of claim 1 wherein the ranking of the operational
events comprises computing an operational event score for each of
the operational events.
5. The method of claim 4 wherein the time series data comprise time
series natural resource production data and wherein the computing
the operational event score comprises utilizing at least a portion
of the time series natural resource production data.
6. The method of claim 5 wherein the equipment operations comprise
pumping operations performed by pumps and wherein the time series
natural resource production data comprise fluid flow time series
data for a natural resource pumped from a reservoir by the
pumps.
7. The method of claim 4 wherein the equipment operations comprise
pumping operations performed by pumps and wherein the time series
natural resource production data comprise pressure time series data
for a natural resource pumped from a reservoir by the pumps.
8. The method of claim 4 comprising comparing at least a portion of
the time series natural resource production data to model data,
wherein the computing increases the operational event score for a
decrease in natural resource production at one of the natural
resource sites.
9. The method of claim 1 comprising classifying each of the
operational events as active or completed.
10. The method of claim 1 comprising, for each of the operational
events, determining one or more of a severity, a duration and a
type.
11. The method of claim 1 comprising, responsive to receipt of a
mode indicator, organizing the at least a portion of the ranked
operational events according to the mode indicator.
12. The method of claim 11 wherein the mode indicator comprises a
natural resource site mode or an equipment mode.
13. The method of claim 11 wherein the mode indicator comprises a
natural resource site mode wherein the natural resource sites
comprise wells in fluid communication with a common reservoir and
wherein the outputting the at least a portion of the ranked
operational events comprises outputting a ranked list of at least a
portion of the wells that correspond to the at least a portion of
the ranked operational events.
14. The method of claim 11 wherein the mode indicator comprises an
equipment mode wherein the equipment operations are performed by
pumps and wherein the outputting the at least a portion of the
ranked operational events comprises outputting a ranked list of at
least a portion of the pumps that correspond to the at least a
portion of the ranked operational events.
15. The method of claim 1 wherein the plurality of natural resource
sites comprise wells in fluid communication with a common reservoir
and wherein detecting operational events using the time series data
comprises detecting an operational event that decreases sandface
pressure in a wellbore of one of the wells in relationship to
reservoir pressure of the common reservoir.
16. The method of claim 1 wherein the time series data comprise
natural resource site identifiers, channel identifiers, timestamps
and values.
17. The method of claim 1 comprising, responsive to receipt of a
selection of one of the output ranked operational events, issuing a
control instruction that instructs equipment to perform its
corresponding operational action.
18. The method of claim 17 comprising rendering a graphic to a
graphical user interface for the selected one of the output ranked
operational events, determining a control status of the selected
one of the output ranked operational events, and dynamically
updating the graphic responsive to the determined control
status.
19. A system comprising: a processor; memory accessible to the
processor; processor-executable instructions stored in the memory
and executable by the process to instruct the system to: receive
time series data acquired during equipment operations at a
plurality of natural resource sites; detect operational events
using the time series data; rank the operational events; associate
each of the operational events with a corresponding operational
action; and output at least a portion of the ranked operational
events, each with its corresponding operational action.
20. One or more computer-readable storage media comprising
computer-executable instructions executable to instruct a computing
system to: receive time series data acquired during equipment
operations at a plurality of natural resource sites; detect
operational events using the time series data; rank the operational
events; associate each of the operational events with a
corresponding operational action; and output at least a portion of
the ranked operational events, each with its corresponding
operational action.
Description
RELATED APPLICATIONS
[0001] This application claims priority to and the benefit of a US
Provisional application having Ser. No. 62/740,949, filed 3 Oct.
2018, which is incorporated by reference herein, and this
application claims priority to and the benefit of a US Provisional
application having Ser. No. 62/873,942, filed 14 Jul. 2019, which
is incorporated by reference herein.
BACKGROUND
[0002] A resource field can be an accumulation of one or more
resources (e.g., oil, gas, oil and gas) in a subsurface
environment. A resource field can include at least one reservoir. A
bore can be drilled into an environment where the bore may be
utilized to form a well that can be utilized in producing
hydrocarbons from a reservoir.
[0003] A rig can be a system of components that can be operated to
form a bore in an environment, to transport equipment into and out
of a bore in an environment, etc. As an example, a rig can include
a system that can be used to drill a bore and to acquire
information about an environment, about drilling, etc. A resource
field may be an onshore field, an offshore field or an on- and
offshore field. A rig can include components for performing
operations onshore and/or offshore. A rig may be, for example,
vessel-based, offshore platform-based, onshore, etc.
[0004] Field planning and/or development can occur over one or more
phases, which can include an exploration phase that aims to
identify and assess an environment (e.g., a prospect, a play,
etc.), which may include drilling of one or more bores (e.g., one
or more exploratory wells, etc.). Various types of equipment may be
utilized to improve production of fluid from a reservoir. For
example, one or more of artificial lift technology, hydraulic
fracturing technology, injection technology, etc., may be
utilized.
SUMMARY
[0005] A method can include receiving time series data acquired
during equipment operations at a plurality of natural resource
sites; detecting operational events using the time series data;
ranking the operational events; associating each of the operational
events with a corresponding operational action; and outputting at
least a portion of the ranked operational events, each with its
corresponding operational action. A system can include a processor;
memory accessible to the processor; processor-executable
instructions stored in the memory and executable by the process to
instruct the system to: receive time series data acquired during
equipment operations at a plurality of natural resource sites;
detect operational events using the time series data; rank the
operational events; associate each of the operational events with a
corresponding operational action; and output at least a portion of
the ranked operational events, each with its corresponding
operational action. One or more computer-readable storage media can
include computer-executable instructions executable to instruct a
computing system to: receive time series data acquired during
equipment operations at a plurality of natural resource sites;
detect operational events using the time series data; rank the
operational events; associate each of the operational events with a
corresponding operational action; and output at least a portion of
the ranked operational events, each with its corresponding
operational action. Various other apparatuses, systems, methods,
etc., are also disclosed.
[0006] This summary is provided to introduce a selection of
concepts that are further described below in the detailed
description. This summary is not intended to identify key or
essential features of the claimed subject matter, nor is it
intended to be used as an aid in limiting the scope of the claimed
subject matter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] Features and advantages of the described implementations can
be more readily understood by reference to the following
description taken in conjunction with the accompanying
drawings.
[0008] FIG. 1 illustrates examples of equipment in a geologic
environment;
[0009] FIG. 2 illustrates examples of equipment and examples of
hole types;
[0010] FIG. 3 illustrates an example of a system;
[0011] FIG. 4 illustrates an example of a wellsite system and an
example of a computing system;
[0012] FIG. 5 illustrates an example of a graphical user
interface;
[0013] FIG. 6 illustrates an example of a graphical user
interface;
[0014] FIG. 7 illustrates examples of methods and an example of a
system;
[0015] FIG. 8 illustrates an example of a system and examples of
one or more data structures;
[0016] FIG. 9 illustrates an example of a graphical user
interface;
[0017] FIG. 10 illustrates an example of a graphical user
interface;
[0018] FIG. 11 illustrates an example of graphical user interfaces
that illustrates examples of a system and a method;
[0019] FIG. 12 illustrates an example of a method;
[0020] FIG. 13 illustrates an example of a system and examples of
workflows;
[0021] FIG. 14 illustrates an example of a method;
[0022] FIG. 15 illustrates examples of graphical user
interfaces;
[0023] FIG. 16 illustrates an example of a graphical user
interface;
[0024] FIG. 17 illustrates an example of a graphical user
interface;
[0025] FIG. 18 illustrates an example of a graphical user
interface;
[0026] FIG. 19 illustrates an example of a graphical user
interface;
[0027] FIG. 20 illustrates an example of a method;
[0028] FIG. 21 illustrates examples of graphical user interfaces
for computations of one or more triage scores that can be
ranked;
[0029] FIG. 22 illustrates an example of a method;
[0030] FIG. 23 illustrates an example of a method;
[0031] FIG. 24 illustrates an example of a method;
[0032] FIG. 25 illustrates an example of a graphical user
interface;
[0033] FIG. 26 illustrates an example of a system and example
components that include an automated event detection framework;
and
[0034] FIG. 27 illustrates an example of computing system.
DETAILED DESCRIPTION
[0035] The following description includes the best mode presently
contemplated for practicing the described implementations. This
description is not to be taken in a limiting sense, but rather is
made merely for the purpose of describing the general principles of
the implementations. The scope of the described implementations
should be ascertained with reference to the issued claims.
[0036] FIG. 1 shows an example of a geologic environment 120. In
FIG. 1, the geologic environment 120 may be a sedimentary basin
that includes layers (e.g., stratification) that include a
reservoir 121 and that may be, for example, intersected by a fault
123 (e.g., or faults). As an example, the geologic environment 120
may be outfitted with any of a variety of sensors, detectors,
actuators, etc. For example, equipment 122 may include
communication circuitry to receive and to transmit information with
respect to one or more networks 125. Such information may include
information associated with downhole equipment 124, which may be
equipment to acquire information, to assist with resource recovery,
etc. Other equipment 126 may be located remote from a well site and
include sensing, detecting, emitting or other circuitry. Such
equipment may include storage and communication circuitry to store
and to communicate data, instructions, etc. As an example, one or
more pieces of equipment may provide for measurement, collection,
communication, storage, analysis, etc. of data (e.g., for one or
more produced resources, etc.). As an example, one or more
satellites may be provided for purposes of communications, data
acquisition, etc. For example, FIG. 1 shows a satellite in
communication with the network 125 that may be configured for
communications, noting that the satellite may additionally or
alternatively include circuitry for imagery (e.g., spatial,
spectral, temporal, radiometric, etc.).
[0037] FIG. 1 also shows the geologic environment 120 as optionally
including equipment 127 and 128 associated with a well that
includes a substantially horizontal portion that may intersect with
one or more fractures 129. For example, consider a well in a shale
formation that may include natural fractures, artificial fractures
(e.g., hydraulic fractures) or a combination of natural and
artificial fractures. As an example, a well may be drilled for a
reservoir that is laterally extensive. In such an example, lateral
variations in properties, stresses, etc. may exist where an
assessment of such variations may assist with planning, operations,
etc. to develop the reservoir (e.g., via fracturing, injecting,
extracting, etc.). As an example, the equipment 127 and/or 128 may
include components, a system, systems, etc. for fracturing, seismic
sensing, analysis of seismic data, assessment of one or more
fractures, injection, production, etc. As an example, the equipment
127 and/or 128 may provide for measurement, collection,
communication, storage, analysis, etc. of data such as, for
example, production data (e.g., for one or more produced
resources). As an example, one or more satellites may be provided
for purposes of communications, data acquisition, etc.
[0038] FIG. 1 also shows an example of equipment 170 and an example
of equipment 180. Such equipment, which may be systems of
components, may be suitable for use in the geologic environment
120. While the equipment 170 and 180 are illustrated as land-based,
various components may be suitable for use in an offshore
system.
[0039] The equipment 170 includes a platform 171, a derrick 172, a
crown block 173, a line 174, a traveling block assembly 175,
drawworks 176 and a landing 177 (e.g., a monkeyboard). As an
example, the line 174 may be controlled at least in part via the
drawworks 176 such that the traveling block assembly 175 travels in
a vertical direction with respect to the platform 171. For example,
by drawing the line 174 in, the drawworks 176 may cause the line
174 to run through the crown block 173 and lift the traveling block
assembly 175 skyward away from the platform 171; whereas, by
allowing the line 174 out, the drawworks 176 may cause the line 174
to run through the crown block 173 and lower the traveling block
assembly 175 toward the platform 171. Where the traveling block
assembly 175 carries pipe (e.g., casing, etc.), tracking of
movement of the traveling block 175 may provide an indication as to
how much pipe has been deployed.
[0040] As an example, a trip may refer to the act of pulling
equipment from a bore and/or placing equipment in a bore. As an
example, equipment may include a drillstring that can be pulled out
of a hole and/or placed or replaced in a hole. As an example, a
pipe trip may be performed where a drill bit has dulled or has
otherwise ceased to drill efficiently and is to be replaced.
[0041] FIG. 2 shows an example of a wellsite system 200 (e.g., at a
wellsite that may be onshore or offshore). As shown, the wellsite
system 200 can include a mud tank 201 for holding mud and other
material (e.g., where mud can be a drilling fluid), a suction line
203 that serves as an inlet to a mud pump 204 for pumping mud from
the mud tank 201 such that mud flows to a vibrating hose 206, a
drawworks 207 for winching drill line or drill lines 212, a
standpipe 208 that receives mud from the vibrating hose 206, a
kelly hose 209 that receives mud from the standpipe 208, a
gooseneck or goosenecks 210, a traveling block 211, a crown block
213 for carrying the traveling block 211 via the drill line or
drill lines 212 (see, e.g., the crown block 173 of FIG. 1), a
derrick 214 (see, e.g., the derrick 172 of FIG. 1), a kelly 218 or
a top drive 240, a kelly drive bushing 219, a rotary table 220, a
drill floor 221, a bell nipple 222, one or more blowout preventors
(BOPs) 223, a drillstring 225, a drill bit 226, a casing head 227
and a flow pipe 228 that carries mud and other material to, for
example, the mud tank 201. In the example system of FIG. 2, a
borehole 232 is formed in subsurface formations 230 by drilling
(e.g., rotary, sliding, directional, etc.).
[0042] As shown in the example of FIG. 2, the drillstring 225 is
suspended within the borehole 232 and has a drillstring assembly
250 that includes the drill bit 226 at its lower end. As an
example, the drillstring assembly 250 may be a bottom hole assembly
(BHA).
[0043] The wellsite system 200 can provide for operation of the
drillstring 225 and other operations. As shown, the wellsite system
200 includes the platform 211 and the derrick 214 positioned over
the borehole 232. As mentioned, the wellsite system 200 can include
the rotary table 220 where the drillstring 225 pass through an
opening in the rotary table 220.
[0044] As shown in the example of FIG. 2, the wellsite system 200
can include the kelly 218 and associated components, etc., or a top
drive 240 and associated components. As to a kelly example, the
kelly 218 may be a square or hexagonal metal/alloy bar with a hole
drilled therein that serves as a mud flow path. The kelly 218 can
be used to transmit rotary motion from the rotary table 220 via the
kelly drive bushing 219 to the drillstring 225, while allowing the
drillstring 225 to be lowered or raised during rotation. The kelly
218 can pass through the kelly drive bushing 219, which can be
driven by the rotary table 220. As an example, the rotary table 220
can include a master bushing that operatively couples to the kelly
drive bushing 219 such that rotation of the rotary table 220 can
turn the kelly drive bushing 219 and hence the kelly 218. The kelly
drive bushing 219 can include an inside profile matching an outside
profile (e.g., square, hexagonal, etc.) of the kelly 218; however,
with slightly larger dimensions so that the kelly 218 can freely
move up and down inside the kelly drive bushing 219.
[0045] As to a top drive example, the top drive 240 can provide
functions performed by a kelly and a rotary table. The top drive
240 can turn the drillstring 225. As an example, the top drive 240
can include one or more motors (e.g., electric and/or hydraulic)
connected with appropriate gearing to a short section of pipe
called a quill, that in turn may be screwed into a saver sub or the
drillstring 225 itself. The top drive 240 can be suspended from the
traveling block 211, so the rotary mechanism is free to travel up
and down the derrick 214. As an example, a top drive 240 may allow
for drilling to be performed with more joint stands than a
kelly/rotary table approach.
[0046] In the example of FIG. 2, the mud tank 201 can hold mud,
which can be one or more types of drilling fluids. As an example, a
wellbore may be drilled to produce fluid, inject fluid or both
(e.g., hydrocarbons, minerals, water, etc.).
[0047] In the example of FIG. 2, the drillstring 225 (e.g.,
including one or more downhole tools) may be composed of a series
of pipes threadably connected together to form a long tube with the
drill bit 226 at the lower end thereof. As the drillstring 225 is
advanced into a wellbore for drilling, at some point in time prior
to or coincident with drilling, the mud may be pumped by the pump
204 from the mud tank 201 (e.g., or other source) via a the lines
206, 208 and 209 to a port of the kelly 218 or, for example, to a
port of the top drive 240. The mud can then flow via a passage
(e.g., or passages) in the drillstring 225 and out of ports located
on the drill bit 226 (see, e.g., a directional arrow). As the mud
exits the drillstring 225 via ports in the drill bit 226, it can
then circulate upwardly through an annular region between an outer
surface(s) of the drillstring 225 and surrounding wall(s) (e.g.,
open borehole, casing, etc.), as indicated by directional arrows.
In such a manner, the mud lubricates the drill bit 226 and carries
heat energy (e.g., frictional or other energy) and formation
cuttings to the surface where the mud (e.g., and cuttings) may be
returned to the mud tank 201, for example, for recirculation (e.g.,
with processing to remove cuttings, etc.).
[0048] As an example, mud-pulse telemetry equipment may include a
downhole device configured to effect changes in pressure in the mud
to create an acoustic wave or waves upon which information may
modulated. In such an example, information from downhole equipment
(e.g., one or more modules of the drillstring 225) may be
transmitted uphole to an uphole device, which may relay such
information to other equipment for processing, control, etc.
[0049] As an example, telemetry equipment may operate via
transmission of energy via the drillstring 225 itself. For example,
consider a signal generator that imparts coded energy signals to
the drillstring 225 and repeaters that may receive such energy and
repeat it to further transmit the coded energy signals (e.g.,
information, etc.).
[0050] In the example of FIG. 2, an uphole control and/or data
acquisition system 262 may include circuitry to sense pressure
pulses generated by telemetry equipment 252 and, for example,
communicate sensed pressure pulses or information derived therefrom
for process, control, etc.
[0051] The assembly 250 of the illustrated example includes a
logging-while-drilling (LWD) module 254, a measuring-while-drilling
(MWD) module 256, an optional module 258, a roto-steerable system
and motor 260, and the drill bit 226. Such components or modules
may be referred to as tools where a drillstring can include a
plurality of tools.
[0052] The LWD module 254 may be housed in a suitable type of drill
collar and can contain one or a plurality of selected types of
logging tools. It will also be understood that more than one LWD
and/or MWD module can be employed, for example, as represented at
by the module 256 of the drillstring assembly 250. Where the
position of an LWD module is mentioned, as an example, it may refer
to a module at the position of the LWD module 254, the module 256,
etc. An LWD module can include capabilities for measuring,
processing, and storing information, as well as for communicating
with the surface equipment. In the illustrated example, the LWD
module 254 may include a seismic measuring device.
[0053] The MWD module 256 may be housed in a suitable type of drill
collar and can contain one or more devices for measuring
characteristics of the drillstring 225 and the drill bit 226. As an
example, the MWD tool 254 may include equipment for generating
electrical power, for example, to power various components of the
drillstring 225. As an example, the MWD tool 254 may include the
telemetry equipment 252, for example, where the turbine impeller
can generate power by flow of the mud; it being understood that
other power and/or battery systems may be employed for purposes of
powering various components. As an example, the MWD module 256 may
include one or more of the following types of measuring devices: a
weight-on-bit measuring device, a torque measuring device, a
vibration measuring device, a shock measuring device, a stick slip
measuring device, a direction measuring device, and an inclination
measuring device.
[0054] FIG. 2 also shows some examples of types of holes that may
be drilled. For example, consider a slant hole 272, an S-shaped
hole 274, a deep inclined hole 276 and a horizontal hole 278.
[0055] As an example, a drilling operation can include directional
drilling where, for example, at least a portion of a well includes
a curved axis. For example, consider a radius that defines
curvature where an inclination with regard to the vertical may vary
until reaching an angle between about 30 degrees and about 60
degrees or, for example, an angle to about 90 degrees or possibly
greater than about 90 degrees.
[0056] As an example, a directional well can include several shapes
where each of the shapes may aim to meet particular operational
demands. As an example, a drilling process may be performed on the
basis of information as and when it is relayed to a drilling
engineer. As an example, inclination and/or direction may be
modified based on information received during a drilling
process.
[0057] As an example, deviation of a bore may be accomplished in
part by use of a downhole motor and/or a turbine. As to a motor,
for example, a drillstring can include a positive displacement
motor (PDM).
[0058] As an example, a system may be a steerable system and
include equipment to perform a method such as geosteering. As an
example, a steerable system can include a PDM or a turbine on a
lower part of a drillstring which, just above a drill bit, a bent
sub can be mounted. As an example, above a PDM, MWD equipment that
provides real-time or near real-time data of interest (e.g.,
inclination, direction, pressure, temperature, real weight on the
drill bit, torque stress, etc.) and/or LWD equipment may be
installed. As to the latter, LWD equipment can make it possible to
send to the surface various types of data of interest, including
for example, geological data (e.g., gamma ray log, resistivity,
density and sonic logs, etc.).
[0059] The coupling of sensors providing information on the course
of a well trajectory, in real-time or near real-time, with, for
example, one or more logs characterizing the formations from a
geological viewpoint, can allow for implementing a geosteering
method. Such a method can include navigating a subsurface
environment, for example, to follow a desired route to reach a
desired target or targets.
[0060] As an example, a drillstring can include an azimuthal
density neutron (ADN) tool for measuring density and porosity; a
MWD tool for measuring inclination, azimuth and shocks; a
compensated dual resistivity (CDR) tool for measuring resistivity
and gamma ray related phenomena; one or more variable gauge
stabilizers; one or more bend joints; and a geosteering tool, which
may include a motor and optionally equipment for measuring and/or
responding to one or more of inclination, resistivity and gamma ray
related phenomena.
[0061] Referring again to FIG. 2, the wellsite system 200 can
include one or more sensors 264 that are operatively coupled to the
control and/or data acquisition system 262. As an example, a sensor
or sensors may be at surface locations. As an example, a sensor or
sensors may be at downhole locations. As an example, a sensor or
sensors may be at one or more remote locations that are not within
a distance of the order of about one hundred meters from the
wellsite system 200. As an example, a sensor or sensor may be at an
offset wellsite where the wellsite system 200 and the offset
wellsite are in a common field (e.g., oil and/or gas field).
[0062] As an example, one or more portions of a drillstring may
become stuck. The term stuck can refer to one or more of varying
degrees of inability to move or remove a drillstring from a bore.
As an example, in a stuck condition, it might be possible to rotate
pipe or lower it back into a bore or, for example, in a stuck
condition, there may be an inability to move the drillstring
axially in the bore, though some amount of rotation may be
possible. As an example, in a stuck condition, there may be an
inability to move at least a portion of the drillstring axially and
rotationally. Differential sticking may occur when high-contact
forces caused by low reservoir pressures, high wellbore pressures,
or both, are exerted over a sufficiently large area of the
drillstring. A condition referred to as "mechanical sticking" can
be a condition where limiting or prevention of motion of the
drillstring by a mechanism other than differential pressure
sticking occurs. Mechanical sticking can be caused, for example, by
one or more of junk in the hole, wellbore geometry anomalies,
cement, keyseats or a buildup of cuttings in the annulus. Placing
equipment in a borehole, a completed well, etc., can possibly give
rise to one or more types of sticking, where, for example, one or
more actions may be taken to remedy stuck equipment.
[0063] As an example, artificial lift technology may be utilized to
assist production of fluid(s) from a well that is in fluid
communication with a reservoir. Various types of artificial lift
technology involve placing equipment in a borehole, a completed
well, etc. Artificial lift technology can add energy to fluid to
enhance production of the fluid. Artificial lift systems can
include rod pumping systems, gas lift systems and electric
submersible pump (ESP) systems. As an example, an artificial lift
pumping system can utilize a surface power source to drive a
downhole pump assembly. As an example, a beam and crank assembly
may be utilized to create reciprocating motion in a sucker-rod
string that connects to a downhole pump assembly. In such an
example, the pump can include a plunger and valve assembly that
converts the reciprocating motion to fluid movement (e.g., lifting
the fluid against gravity, etc.). As an example, an artificial lift
gas lift system can provide for injection of gas into production
tubing to reduce the hydrostatic pressure of a fluid column. In
such an example, a resulting reduction in pressure can allow
reservoir fluid to enter a wellbore at a higher flow rate. A gas
lift system can provide for conveying injection gas down a
tubing-casing annulus where it can enter a production train through
one or more gas-lift valves (e.g., a series of gas-lift valves,
etc.). As an example, an electric submersible pump (ESP) can
include a stack of impeller and diffuser stages where the impellers
are operatively coupled to a shaft driven by an electric motor. As
an example, an electric submersible pump (ESP) can include a piston
that is operatively coupled to a shaft driven by an electric motor,
for example, where at least a portion of the shaft may include one
or more magnets and form part of the electric motor.
[0064] Examples of artificial lift equipment can include a gas lift
(GL) system, a rod pumping (RP) system, and an ESP system. Such
equipment may be disposed at least in part in a downhole
environment to facilitate production of fluid; noting that a pump
system (e.g., RP and/or ESP) may be utilized to move fluid to a
location other than a surface location (e.g., consider injection to
inject fluid into a subterranean region, etc.). A gas lift system
operates at least in part on buoyancy as injected gas may be
expected to rise due to buoyancy in a direction that is opposite
gravity; whereas, a RP or an ESP may operate via mechanical
movement of physical components to drive fluid in a desired
direction, which may be with or against gravity.
[0065] FIG. 3 shows an example of an ESP system 300 that includes
an ESP 310 as an example of equipment that may be placed in a
geologic environment. As an example, an ESP may be expected to
function in an environment over an extended period of time (e.g.,
optionally of the order of years). As an example, consider ESPs
such as the REDA.TM. ESPs (Schlumberger Limited, Houston, Tex.),
which may find use in applications that call for, for example, pump
rates in excess of about 4,000 barrels per day and lift of about
12,000 feet or more.
[0066] In the example of FIG. 3, the ESP system 300 includes a
network 301, a well 303 disposed in a geologic environment (e.g.,
with surface equipment, etc.), a power supply 305, the ESP 310, a
controller 330, a motor controller 350 and a VSD unit 370. The
power supply 305 may receive power from a power grid, an onsite
generator (e.g., natural gas driven turbine), or other source. The
power supply 305 may supply a voltage, for example, of about 4.16
kV.
[0067] As shown, the well 303 includes a wellhead that can include
a choke (e.g., a choke valve). For example, the well 303 can
include a choke valve to control various operations such as to
reduce pressure of a fluid from high pressure in a closed wellbore
to atmospheric pressure. Adjustable choke valves can include valves
constructed to resist wear due to high-velocity, solids-laden fluid
flowing by restricting or sealing elements. A wellhead may include
one or more sensors such as a temperature sensor, a pressure
sensor, a solids sensor, etc.
[0068] As to the ESP 310, it is shown as including cables 311
(e.g., or a cable), a pump 312, gas handling features 313, a pump
intake 314, a motor 315, one or more sensors 316 (e.g.,
temperature, pressure, strain, current leakage, vibration, etc.)
and optionally a protector 317.
[0069] As an example, an ESP may include a REDA.TM. HOTLINE.TM.
high-temperature ESP motor. Such a motor may be suitable for
implementation in a thermal recovery heavy oil production system,
such as, for example, SAGD system or other steam-flooding
system.
[0070] As an example, an ESP motor can include a three-phase
squirrel cage with two-pole induction. As an example, an ESP motor
may include steel stator laminations that can help focus magnetic
forces on rotors, for example, to help reduce energy loss. As an
example, stator windings can include copper and insulation.
[0071] In the example of FIG. 3, the well 303 may include one or
more well sensors 320, for example, such as the OPTICLINE.TM.
sensors or WELLWATCHER BRITEBLUE.TM. sensors (Schlumberger Limited,
Houston, Tex.). Such sensors are fiber-optic based and can provide
for real-time sensing of temperature, for example, in SAGD or other
operations. As shown in the example of FIG. 1, a well can include a
relatively horizontal portion. Such a portion may collect heated
heavy oil responsive to steam injection. Measurements of
temperature along the length of the well can provide for feedback,
for example, to understand conditions downhole of an ESP. Well
sensors may extend thousands of feet into a well (e.g., 4,000 feet
or more) and beyond a position of an ESP.
[0072] In the example of FIG. 3, the controller 330 can include one
or more interfaces, for example, for receipt, transmission or
receipt and transmission of information with the motor controller
350, a VSD unit 370, the power supply 305 (e.g., a gas fueled
turbine generator, a power company, etc.), the network 301,
equipment in the well 303, equipment in another well, etc.
[0073] As shown in FIG. 3, the controller 330 may include or
provide access to one or more modules or frameworks. Further, the
controller 330 may include features of an ESP motor controller and
optionally supplant the ESP motor controller 350. For example, the
controller 330 may include the INSTRUCT.TM. motor controller and/or
the UNICONN.TM. motor controller 382 (Schlumberger Limited,
Houston, Tex.). In the example of FIG. 3, the controller 330 may
access one or more of the PIPESIM.TM. framework 384, the
ECLIPSE.TM. framework 386 (Schlumberger Limited, Houston, Tex.) and
the PETREL.TM. framework 388 (Schlumberger Limited, Houston, Tex.)
(e.g., and optionally the OCEAN.TM. framework and/or the DELFI.TM.
framework (Schlumberger Limited, Houston, Tex.)).
[0074] In the example of FIG. 3, the motor controller 350 may be a
motor controller such as the UNICONN.TM. motor controller or the
INSTRUCT.TM. motor controller. A motor controller can connect to a
SCADA system, the ESPWATCHER.TM. surveillance system, the
LIFTWATCHER.TM. system (Schlumberger Limited, Houston, Tex.),
LIFTIQ.TM. system (Schlumberger Limited, Houston, Tex.), etc. A
motor controller can perform various control and data acquisition
tasks for ESPs, surface pumps or other monitored wells. A motor
controller can interface with a monitoring system (e.g., the
PHOENIX.TM. monitoring system), for example, to access pressure,
temperature and vibration data and various protection parameters as
well as to provide direct current power to downhole sensors (e.g.,
sensors of a gauge, etc.).
[0075] The PHOENIX.TM. monitoring system includes a "gauge", which
can be available in various configurations. As an example, a
configuration of the gauge may provide for measurement of intake
pressure and temperature, motor oil or motor winding temperature,
vibration, and current leakage. As another example, a configuration
of the gauge can provide for measurement of pump discharge
pressure, which can be used in evaluating pump performance.
[0076] The PHOENIX.TM. monitoring system includes high-temperature
microelectronics and digital telemetry circuitry that can
communicates with surface equipment through an ESP motor cable. The
electrical system of the PHOENIX.TM. monitoring system has a
tolerance for high phase imbalance and a capacity to handle voltage
spikes.
[0077] As an example, a controller can be operatively coupled to
the PHOENIX.TM. monitoring system, for example, to provide remote
access and control. Data can be integrated with a real-time
surveillance service that may provide for robust surveillance of
monitored parameters (e.g., via satellite and/or other network
technologies). The PHOENIX.TM. monitoring system is SCADA ready and
has a MODBUS protocol terminal with RS232 and RS485 ports for data
output.
[0078] As to some examples of gauge parameters, consider Table 1
below.
TABLE-US-00001 TABLE 1 Some examples of gauge parameters for
sensors. Measurement Range Accuracy Resolution Drift Rate P Intake
0-40 MPa +/-34 0.7 34/ 4 s year P Discharge 0-40 MPa +/-34 0.7 34/
4 s year T Intake 0-150 C. 1.3% FS 0.1 NA 4 s/8 s T Winding/Oil
0-409 C. 1% FS 0.1 NA 36 s Vibration 0-30 G 3.3% FS 0.1 NA Variable
Current Leak 0-25 mA 0.2% FS 0.001 NA Variable
[0079] As to dimensions of a gauge, consider a gauge that is
approximately 60 centimeters in length and approximately 11 cm in
diameter. Such a gauge may be rated to withstand pressures of
approximately 45 MPa and survive for 24 hours at a temperature of
approximately 175 degrees C. A surface choke unit may provide for
reading sensed information from a three-phase ESP power cable.
[0080] The UNICONN.TM. motor controller and/or the INSTRUCT.TM.
motor controller can interface with fixed speed drive (FSD)
controllers or a VSD unit, for example, such as the VSD unit 370.
For FSD controllers, the UNICONN.TM. motor controller and/or the
INSTRUCT.TM. motor controller can monitor ESP system three-phase
currents, three-phase surface voltage, supply voltage and
frequency, ESP spinning frequency and leg ground, power factor and
motor load.
[0081] For VSD units, the UNICONN.TM. motor controller and/or the
INSTRUCT.TM. motor controller can monitor VSD output current, ESP
running current, VSD output voltage, supply voltage, VSD input and
VSD output power, VSD output frequency, drive loading, motor load,
three-phase ESP running current, three-phase VSD input or output
voltage, ESP spinning frequency, and leg-ground.
[0082] In the example of FIG. 3, the ESP motor controller 350
includes various modules to handle, for example, backspin of an
ESP, sanding of an ESP, flux of an ESP and gas lock of an ESP. The
motor controller 350 may include any of a variety of features,
additionally, alternatively, etc.
[0083] In the example of FIG. 3, the VSD unit 370 may be a low
voltage drive (LVD) unit, a medium voltage drive (MVD) unit or
other type of unit (e.g., a high voltage drive, which may provide a
voltage in excess of about 4.16 kV). As an example, the VSD unit
370 may receive power with a voltage of about 4.16 kV and control a
motor as a load with a voltage from about 0 V to about 4.16 kV. The
VSD unit 370 may include control circuitry such as the
SPEEDSTAR.TM. MVD control circuitry (Schlumberger Limited, Houston,
Tex.).
[0084] FIG. 4 shows an example of a wellsite system 400,
specifically, FIG. 4 shows the wellsite system 400 in an
approximate side view and an approximate plan view along with a
block diagram of a system 470. Such a system may implement one or
more technologies (e.g., drilling, artificial lift, hydraulic
fracturing, etc.).
[0085] In the example of FIG. 4, the wellsite system 400 can
include a cabin 410, a rotary table 422, drawworks 424, a mast 426
(e.g., optionally carrying a top drive, etc.), mud tanks 430 (e.g.,
with one or more pumps, one or more shakers, etc.), one or more
pump buildings 440, a boiler building 442, an HPU building 444
(e.g., with a rig fuel tank, etc.), a combination building 448
(e.g., with one or more generators, etc.), pipe tubs 462, a catwalk
464, a flare 468, etc. Such equipment can include one or more
associated functions and/or one or more associated operational
risks, which may be risks as to time, resources, and/or humans.
[0086] As shown in the example of FIG. 4, the wellsite system 400
can include a system 470 that includes one or more processors 472,
memory 474 operatively coupled to at least one of the one or more
processors 472, instructions 476 that can be, for example, stored
in the memory 474, and one or more interfaces 478. As an example,
the system 470 can include one or more processor-readable media
that include processor-executable instructions executable by at
least one of the one or more processors 472 to cause the system 470
to control one or more aspects of the wellsite system 400. In such
an example, the memory 474 can be or include the one or more
processor-readable media where the processor-executable
instructions can be or include instructions. As an example, a
processor-readable medium can be a computer-readable storage medium
that is not a signal and that is not a carrier wave.
[0087] FIG. 4 also shows a battery 480 that may be operatively
coupled to the system 470, for example, to power the system 470. As
an example, the battery 480 may be a back-up battery that operates
when another power supply is unavailable for powering the system
470. As an example, the battery 480 may be operatively coupled to a
network, which may be a cloud network. As an example, the battery
480 can include smart battery circuitry and may be operatively
coupled to one or more pieces of equipment via a SMBus or other
type of bus.
[0088] In the example of FIG. 4, services 490 are shown as being
available, for example, via a cloud platform. Such services can
include data services 492, query services 494 and drilling services
496. As an example, the services 490 may be part of a system such
as the system 300 of FIG. 3.
[0089] FIG. 5 shows an example of a graphical user interface (GUI)
500 that includes information associated with a well plan.
Specifically, the GUI 500 includes a panel 510 where surfaces
representations 512 and 514 are rendered along with well
trajectories where a location 516 can represent a position of a
drillstring 517 along a well trajectory. The GUI 500 may include
one or more editing features such as an edit well plan set of
features 530. The GUI 500 may include information as to individuals
of a team 540 that are involved, have been involved and/or are to
be involved with one or more operations. The GUI 500 may include
information as to one or more activities 550. As shown in the
example of FIG. 5, the GUI 500 can include a graphical control of a
drillstring 560 where, for example, various portions of the
drillstring 560 may be selected to expose one or more associated
parameters (e.g., type of equipment, equipment specifications,
operational history, etc.). FIG. 5 also shows a table 570 as a
point spreadsheet that specifies information for a plurality of
wells.
[0090] In the example of FIG. 5, the drillstring graphical control
560 includes components such as drill pipe, heavy weight drill pipe
(HWDP), subs, collars, jars, stabilizers, motor(s) and a bit. A
drillstring can be a combination of drill pipe, a bottom hole
assembly (BHA) and one or more other tools, which can include one
or more tools that can help a drill bit turn and drill into
material (e.g., a formation).
[0091] FIG. 6 shows an example of a graphical user interface 600
that includes a schedule organized with respect to time (days,
dates, etc.) and with respect to various types of operations. The
GUI 600 can be part of a well planning system, which may be part of
a field development framework. For example, the various operations
in the GUI 600 can be implemented to drill at least a portion of a
well in a geologic environment (e.g., an oil field or oilfield)
where the well may be completed for one or more purposes (e.g.,
production of hydrocarbons, injection of fluid(s), fracturing of
rock, etc.).
[0092] As an example, the GUIs 500 and 600 can be part of a field
development framework and/or an execution framework for execution
of one or more actions (e.g., field actions). For example, the well
plan 510 of the GUI 500 may be based at least in part on
information rendered in the GUI 600. As an example, an interaction
with the GUI 500 may be processed by one or more processors to
generation information that can be rendered to the GUI 600 and, for
example, vice versa. As an example, the GUIs 500 and 600 may be
utilized for operations that may occur after drilling. For example,
consider one or more artificial lift operations that may be
performed in a well or wells as associated with the GUI 500 or the
GUI 600. For example, rather than a drillstring 560, the graphic
may be of an ESP system. As to the GUI 600, operation phases in the
columns may be for one or more artificial lift operations.
[0093] As an example, a framework may be implemented using
computing resources (e.g., hardware, communication equipment, etc.)
as may be available, for example, in the cloud, a server, a
workstation, etc.
[0094] As an example, a framework can include components that can
take certain inputs and generate certain outputs. The outputs of a
component may be used as inputs of another component or other
components such that a real-time workflow can be constructed.
[0095] As explained, various types of equipment can be utilized in
various types of operations that aim to produce a natural resource
from a reservoir, where operations can include logging, drilling,
completing, injecting, fracturing, artificial lifting, etc. Various
types of operations may be particular to certain types of wells,
certain types of formations, etc. For example, in the Permian
Basin, high gas-to-oil ratio can be a challenge for ESP operations
(e.g., gas lock, insufficient lift, etc.). As an example, a method
can include detection of one or more events as to numerous wells in
a field such as the Permian Basin, which may help to manage and/or
reduce undesirable consequences (e.g., frequent shut downs, etc.)
through one or more actions (e.g., control actions, etc.). In such
an example, the field may experience reduced ESP downtime, reduced
number of site visits and, hence, reduced human safety and other
risks. Where a shut down or other power supply condition occurs
(e.g., electrical power supply interruption, etc.), it may be
followed by a restart, which can be time consuming, particularly if
performed manually. As an example, a method may reduce shut downs
and/or reduce restart time responsive to a shut down or a power
supply issue. Rapid restarting after an unexpected power
interruption may help to reduce deferred production.
[0096] As an example, a method can include monitoring operation of
an electric submersible pump (ESP). Such a method may include
receiving data signals indicating values for a plurality of
parameters regarding operation of the electric submersible pumping
system; establishing, for at least some of the plurality of
parameters, an associated reference signal; and detecting a
deviation of one of the parameters from the reference signal
associated with that parameter. As a result of the deviation having
a rate of change below a predetermined threshold, the method can
include updating the value of the reference signal to reflect the
deviation. As a result of the deviation having a rate of change
above the predetermined threshold, the method can include detecting
an event and generating an indication of the event. The indication
of the event may further depend on a type of the parameter and a
direction of the deviation from the reference signal.
[0097] Over time, well performance tends to gradually change, which
affects channels such as static intake pressure, intake pressure,
average drive current, and the like. To adapt those signals to
changes over time, certain examples can include constructing a time
dependency reference signal. In such an approach, the reference
signal may be described as a function of time, which can capture a
correlation between raw measurements with time and reflect
relationships in its coefficients. As an example, a linear curve
can be fit to raw measurements where coefficients of the curve are
computed by minimizing residuals between the curve and the real,
raw measurements. For example, let X be the observations, Coeff be
the set of coefficients a, b, c, d, e and R be the residuals where
R can be minimized using a least square regression, outputting the
coefficients Coeff. In such an example, reference values can be
reconstructed based on t and on Coeff.
[0098] For channels that depend on time and another variable, but
also on drive frequency, another approach may be employed to model
such dependencies. Such channels can include, for example,
discharge pressure, intake pressure, well head pressure, and
average drive current. Correlation may be discovered based on real
measurements of those channels. In situations where there is no
correlation between the channels, this too may be automatically
learned and reflected by the determined coefficients. For example,
the coefficient associated with drive frequency may be negligible.
To adapt such signals to changes over time and frequency, certain
examples can include constructing a time and frequency dependency
reference signal. For example, a reference signal can depend on
time and frequency where various coefficients can be determined. As
an example, consider a set of Coeff{a, b, c, d, e} that may be
derived using the approach explained above with respect to
time-dependent channels.
[0099] As an example, a method can include an approach for
temperature as dependent on power where power can depend, for
example, on current (e.g., amperage). In such an example, power can
be converted into heat; whereas, power can itself depends on
frequency.
[0100] As one example of the above determination of reference
signals, consider reference signals for Pd and P. When an event
detection process (e.g., via an AED engine) first begins, data
relating to real values of various parameters can be collected,
which can allow for various coefficients to be determined. Then,
for subsequent restarts, the AED engine can first use reference
values from the time-based reference. For example, when the ESP is
restarted, the frequency may be gradually increased while still
remaining below a minimum frequency. As a result, low flow (LF)
events are not detected if the reference value is calculated based
on frequency, which is why the time-based reference value can be
utilized to ensure LF events at restart can be detected.
[0101] During normal operating conditions, the AED engine can use
reference values from a time- and frequency-based model (e.g.,
Ref.sub.tf). Such an approach can help to reduce risk of a LF false
alarm when, for example, rig operators change a frequency to
operate at another stable flow rate during normal operations. In
this example, outliers are not fed to the input of the AED learning
engine (e.g., by filtering), and the AED learning engine can use a
selected and potentially programmable number of observations (e.g.,
10,000 observations) to calculate coefficients.
[0102] As discussed above, when certain events occur, signals tend
to deviate from their reference values. These deviations, when not
explainable by other context information (e.g., shutting off the
pump, opening or closing various valves, and the like), may be
utilized to detect events. As an example, a method can include
estimating static intake pressure and utilizing an LF-IL event
detection process. As an example, a reference value for frequency
can be computed to detect a LF event, for example, when a pump is
running below its minimum frequency. The following are examples of
events that may be selected for detection by an AED engine.
[0103] As an example, an AED engine may detect an event when, at
restart, the intake pressure increases back to the static intake
pressure after decreasing and the pressure difference decreases.
The AED engine may also detect an event when, during normal
operation, the intake pressure increases back to the static intake
pressure and the pressure difference decreases.
[0104] An AED engine may detect an event when, during normal
operation, pressures are fluctuating. For example, intake pressure
tends to increase back to static intake pressure and the pressure
difference tends to decrease. Such an approach can detect a gas
slugging situation where a large volume of gas causes the
fluctuation of pressures and decreases the flow rate. An AED engine
may detect an event when, during normal operation, the pressure
difference is too low compared to its reference value. An AED
engine may detect an event when, at start-up (e.g., when the pump
is first installed and turned on), the intake pressure increases up
to the static intake pressure after decreasing, which suggests the
annulus emptying. An AED engine may also detect an event when,
during normal operation, the frequency is substantially lower than
its reference value. With regard to ESP surveillance, a concept may
be applied to detecting other low-flow events, such as a closed
valve, gas interference, or the like.
[0105] Another example of an ability to detect an event is where
the event corresponds to a scenario in which an AED engine is to
reestablish one or more reference values. For example, when the
pump is off, if the static pressure is fluctuating substantially,
it likely indicates some well intervention that could modify its
productivity. In this scenario, an AED engine may restart and
reestablish reference signals for various parameters without using
previously established reference signals.
[0106] As an example, an AED approach may utilize a training phase.
For example, consider a logistic regression classification model
that may be used to train with "good" and "bad" samples for LF-GI
detection. In logistic regression, a sigmoid function can be
utilized to calculate the probability of a given sample belonging
to one of the two classes (e.g., "good" or "bad"). A sigmoid
function approach can predict a label for each sample where, based
on this prediction, a cost function may be calculated and
minimized.
[0107] As an example, a surveillance workflow and visualization can
be based on Automated Events Detection (AED), contextual
information and capturing of expert knowledge. As an example, an
Automated Events Detection (AED) system can be referred to as an
AED framework (AEDF) or an AED platform (AEDP).
[0108] The term "ground truth" can refer to information provided by
direct observation (e.g., empirical sensor data) as opposed to
information provided by inference.
[0109] In machine learning, the term "ground truth" can refer to
accuracy of a training set's classification for supervised learning
techniques. Classification can be for purposes of labeling where,
for example, data may be labeled depending on how they are
classified. Above, an example is given for use of a sigmoid
function to classify data and label data as "good" or "bad".
[0110] As an example, consider Bayesian filtering via supervised
learning. In such an example, a Bayesian filter can be taught the
difference between classes using ground truth data (e.g., human
review messages classified as being spam messages or non-spam
messages). In such an example, inaccuracies in the ground truth
will correlate to inaccuracies in operation of the Bayesian filter,
which can, as a consequence, erroneously classify input (e.g., an
input spam message as non-spam or a non-spam message as spam).
[0111] In oilfield operations, there can be a very sparse set of
ground truth data or ground truth labels or "labels" to evaluate
performance of a machine learning model that is to be used to
detect abnormal patterns (e.g., consider a neural network or other
type of machine model that can be trained). As a result, challenges
include, first, since the number of labels tends to be small, it
can be difficult to train a machine learning model to recognize
patterns; and second, it is desirable to validate the model and
generate the PIs (Performance Indicators) such as number of false
alarms, detection rate, etc., in a development cycle. To address
such challenges, at scale, an AEDF can include a tool or tools to
can facilitate one or more validation workflows that aim to
validate model outputs and record ground truth labels.
[0112] As an example, a set of tools can facilitate development and
use processes, which may be utilized in real-time and/or offline
scenarios. An AEDF may provide an ability to automate the
validation processing of a nearly unlimited number of equipment
operational datasets, to generate the PIs for each of the datasets
to quickly spot problems and to speed up the development
process.
[0113] FIG. 7 shows an example of a method 700, an example of a
method 781, an example of a method 786 and an example of a system
790. The method 700 includes a detection block 710 for detecting an
event, a render block 720 to render an event to a GUI, a
performance block 730 for performing an action, an assessment block
740 for assessing the impact(s) of a performed action, a decision
block 750 for deciding whether the detected event is resolved
and/or completed, an interaction block 760 for interacting with a
framework (e.g., AEDF), a result block 770 for generating an
interaction result and a revision block 780 for revising the
framework (e.g., AEDF). In the example of FIG. 7, the render block
720 can allow for viewing of an event, for example, as it is
happening in real-time along with other information (e.g.,
contextualized information). As an example, the interaction block
760 can involve interaction via one or more GUIs such as a "Truth
Marking" GUI that allows for expert interaction as to what may be
considered a "Ground Truth". As to the result block 770, it can
include performing calculations, for example, as to one or more
performance indicators (PIs) which may compare output of an AEDF
with a "Truth". As to the revision block 780, it may revise one or
more databases, etc., by altering a data structure and/or a data
structure entry. As shown in the example of FIG. 7, the method 700
can include one or more loops, for example, after a decision (e.g.,
a determination) as to resolution or completion (e.g., termination
of an event), the method may continue to the detection block 710,
the performance block 730 or another block. As an example, the
method 700 can include various threads, loops, etc., that may occur
in series and/or in parallel. As an example, after framework
revision per the revision block 780, the method 700 may continue to
perform an action per the performance block 730 and/or to detect an
event per the detection block 710. As an example, a revision can be
or include a revision to a model or models, which may include one
or more machine models that can be trained, for example, via
interaction, a result of interaction, etc. As an example, one or
more actions of a method such as the method 800 of FIG. 8 may be
utilized for revision as in the revision block 780, etc.
[0114] As to the method 781, it includes a review block 782 for
reviewing events with completed status, a validation block 783 for
validating an event with completed status that has been reviewed, a
modification block 784 for modifying an event with completed status
that has been reviewed, and a storage block 785 for storing the
reviewed events with completed status in a data store such that the
stored events can be utilized as labels (e.g., ground truth
labels). As shown, the method 786 can include creating events not
picked up by an AEDF per a creation block 787 and an input block
788 for inputting attributes associated with one or more created
events where the output thereof may be stored per the storage block
785, for example, for adding information to truths that can be
labels (e.g., a database, etc.).
[0115] In the example of FIG. 7, a system 790 includes one or more
information storage devices 791, one or more computers 792, one or
more networks 795 and instructions 796. As to the one or more
computers 792, each computer may include one or more processors
(e.g., or processing cores) 793 and memory 794 for storing the
instructions 796, for example, executable by at least one of the
one or more processors. As an example, a computer may include one
or more network interfaces (e.g., wired or wireless), one or more
graphics cards, a display interface (e.g., wired or wireless),
etc.
[0116] FIG. 8 shows an example of a system 800 that can be utilized
in a workflow or workflows and examples of one or more data
structures 805. As an example, one or more components of the system
800 can be part of an AEDF.
[0117] In FIG. 8, the system 800 includes a data component 801 that
can receive data (e.g., a digital data interface), an AED component
810 that can process received data to detect events, an output
component 820 that can output an event as detected with contextual
information, a development component 830 that can utilize one or
more contextualized events for development of a resource, a label
database 840 as a component that can be a resource that includes
labeled events as output ground truth events or possible ground
truth events, an artificial intelligence (AI) training component
850 that can utilize the label database 840 for training a machine
model to output a trained machine model, a comparator 860 that can
compare contextualized output to information stored in the label
database 840, a validation component 870 that can be utilized to
assess one or more comparisons made by the comparator 860 and a
formatted output component 880 that can output validated events,
optionally in a contextualized manner that can be formatted to
facilitate storage, rendering, transmission, editing, etc. For
example, consider the formatted output component 880 including
circuitry that can generate output in an extensible mark-up
language (XML), which may be rendered to a display and/or utilized
to generate a graphical user interface (GUI) that can be rendered
to a display.
[0118] As shown in FIG. 8, the one or more data structures 805 can
include time series data and non-time series data. As indicated,
the system 800 can include an AED component 810 that can receive
data via the data component 801. As an example, such data can
include data organized according to one or more data structure
specifications, which can include specifications for time series
and non-time series data.
[0119] As an example, the AED component 810 can detect events and
generate output with appropriate quality and context (see, e.g.,
the output component 820). As an example, such output can be in the
form of real-time streams of event transitions, which can include
an "on" transition such as an event start and an "off" transition
such as an event end (see, e.g., the non-time series data of the
one or more data structures 805). As an example, various
transitions can be from off to on and from on to off. As an
example, an event can be assigned an active status when on and a
completed status when an on is followed by (e.g., paired with) an
off. Events may be extracted and stored in a database making it
possible to associate additional data with an event.
[0120] The one or more data structures 805 show various types of
data that can be related to an event. In the example of FIG. 8,
context is provided by the non-time series data, together with
associated channels of measurements and AED time series data. As
shown, a "+/-" feature can be utilized to account for surveillance
demands, for example, where lead-up and follow-on data are of
interest (e.g., for review, analysis, control action, etc.). As an
example, a data processing component may strip off pre-event and/or
post-event data. As an example, a database can include one or more
data structures that are accessible via one or more application
programming interface (API) specifications. For example, consider
an API call that aims to receive in response a portion of data in
one or more data structures (e.g., with or without pre-event,
post-event, etc.), which may include time series data and/or
non-time series data. As an example, the pre- and post-times can be
predefined, optionally be event type. For example, a pre-period may
be a percentage of a time span that is expected for a particular
type of event, which may depend on the physical dynamics and/or
control dynamics of the event, lead-up to the event and resolution
of the event (e.g., settling dynamics, etc.).
[0121] FIG. 9 shows an example of a GUI 900 where various types of
data are rendered and classified, for example, via labels, markers,
etc. As shown, various channels are rendered with respect to time.
In the example of FIG. 9, channels include total current (TC),
intake pressure (InP), motor temperature (MT), frequency (Freq),
and discharge pressure (DP) and references include motor
temperature reference (TmRef) and various other references. As
shown, an indicator of an AED event is rendered where various
channels show changes. For example, motor temperature (MT)
increases along with discharge pressure (DP). Total current trends
upwardly late in the AED window and, in response to issuance of a
command, begins to stabilize in the post AED window period along
with discharge pressure (DP).
[0122] The GUI 900 shows an example of how contextualization may be
performed for an event (e.g., an AED event). The GUI 900 shows time
series data, event start and event stop, data leading to the event,
data after the event, one or more alarms (e.g., low level threshold
alarms), one or more other events, a log of one or more actions,
etc. As an example, contextualization can include type of event
and/or severity of an event. The GUI 900 also shows a request and a
response followed by one or more commands (Cmd). As an example, a
framework can receive a request and issue a response where one or
more commands may be made based on the response. As an example, a
controller can provide for receiving a request, issuing a response
and issuing one or more commands.
[0123] As an example, a framework can include executable
instructions that can render one or more graphical user interfaces
(GUIs). For example, consider GUIs that are rendered for event
promotion and/or event creation (see, e.g., the method 700 of FIG.
7, etc.). As an example, consider an event promotion GUI that
includes an event type field, a description field as to the event
type, a severity field, a start time field, an end time field and a
comment field. Such a GUI can include a graphical control that can
add the event as a label (e.g., a ground truth label). As to a
modification GUI, consider a source field that can indicate a
source of the event (e.g., underlying data, etc.) as well as one or
more of the fields mentioned above for the event promotion GUI. In
such an example, the GUI may include one or more graphical controls
such as a "new" graphical control and a "modify" graphical control.
Such GUIs may be utilized to store events to a database such as a
label database (see, e.g., the label database 840 of the system 800
of FIG. 8).
[0124] FIG. 10 shows an example of an operational architecture for
an example of a GUI 1000 that includes various controls for
selection of views. As shown, an event and/or well selector view, a
time window selector view, a real-time update selector view, etc.,
may be selected using one or more graphical controls rendered to a
display as part of the GUI 1000. Such a GUI may be utilized in one
or more workflows, for example, consider a workflow as shown in
FIG. 8 with respect to the system 800.
[0125] In the example of FIG. 10, a commands graphical control is
indicated that can be utilized to render a view of one or more
command graphical controls. For example, consider a GUI that
includes a graphical control for a frequency command that can be
issued to control frequency. In such an example, the GUI can render
a value that can be a set point or other value to be issued to
equipment. For example, consider a frequency value that can be
issued responsive to actuation of a graphical control that causes a
motor drive to change an operational frequency to the frequency
value, for example, to cause a change in rotational speed of a
multiphase electric motor of an electric submersible pump (ESP). As
another example, consider a choke value of a surface choke valve of
a well that can be utilized to adjust a choke value (e.g., to open,
to open to a percentage of fully open, to close, etc.).
[0126] FIG. 11 shows an example of a system, a method (or methods)
and a GUI or GUIs 1100. As shown in FIG. 11, a framework such as an
AEDF can be utilized to detect a heat rise and/or other
condition(s) with respect to equipment such as an ESP and identify
one or more root causes and call for one or more remedial actions,
which can be control actions that call for controlling one or more
physical pieces of equipment that can alter an environment and/or a
piece of equipment. Such control actions may be one or more of
automatic, semi-automatic and manual.
[0127] In the example of FIG. 11, an event 1101 is indicated as a
low or no flow condition for equipment where damage and/or a risk
of damage 1110 may be indicated, where one or more causes 1130 may
be indicated and/or where one or more actions 1150 may be
indicated. As shown, the one or more causes 1130 can include a
sub-minimal rotational speed cause (IL), an outflow restriction
cause (DH/PR), an inflow restriction cause (PO), a gas interference
cause (GI/GL) and/or a stuck pump cause (SP). As shown, an action
or actions can be indicated, which may include one or more remedial
actions that aim to address the event, for example, as to one or
more operations performed by the equipment, one or more conditions
of the equipment, one or more causes of the event, etc.
[0128] The example of FIG. 11 can pertain to a single system such
as, for example, a single ESP as installed in a well. As mentioned,
various low level alarms may be set as part of a monitoring system
where an event such as the event in the example of FIG. 11 can
cause issuance of one or more of such low level alarms. For an
individual that is responsible for monitoring the single ESP, there
can be multiple low level alarms in progress, which may take some
time for the individual to sort out and comprehend, either
individually or collectively. Where the individual is responsible
for more than a single ESP, the situation becomes more taxing on
the individual. For example, consider an individual that is
responsible for monitoring fifty ESPs where each includes multiple
low level alarms for multiple channels of data (e.g., temperature,
frequency, pressure, current, flow, etc.). The burden placed on the
individual to discern and prioritize the information generated can
be substantial.
[0129] As an example, a framework can be utilized for monitoring
one or more systems where the framework includes a triage engine
that can prioritize events. Such a framework can be useful for a
single system and can be particularly useful for multiple systems,
especially as the number of systems increases.
[0130] FIG. 12 shows an example of a method 1200 that includes a
reception block 1210 for receiving time series data acquired during
equipment operations at a plurality of natural resource sites; a
detection block 1220 for detecting operational events using the
time series data; a rank block 1230 for ranking the operational
events; an association block 1240 for associating each of the
operational events with a corresponding operational action; and an
output block 1250 for outputting at least a portion of the ranked
operational events, each with its corresponding operational
action.
[0131] The method 1200 is shown along with various
computer-readable media blocks 1211, 1221, 1231, 1241 and 1251
(e.g., CRM blocks). Such blocks may be utilized to perform one or
more actions of the method 1200. For example, consider the system
790 of FIG. 7 and the instructions 796, which may include
instructions of one or more of the CRM blocks 1211, 1221, 1231,
1241 and 1251.
[0132] As an example, the method 1200 can include outputting that
includes rendering graphics for the at least a portion of the
ranked events to a graphical user interface, where the graphical
user interface includes graphical controls linked to the graphics
that associate each of the at least a portion of the ranked events
with its corresponding operational action. As an example, an
operational action can be particular for a system, equipment, etc.
For example, in FIG. 11, the actions listed in the action block
1150 include operational actions that can be taken for a well that
includes an ESP installed therein.
[0133] FIG. 13 shows an example of a system 1300 and examples of
workflows 1320. The system 1300 includes a graphical user interface
(GUI) block 1310 that can include GUI components 1312 and 1314,
which can be operatively coupled to a field component 1350 and/or
to a production component 1370.
[0134] The GUI component 1312 can provide an event dashboard across
a population of assets such as, for example, a multi-well list with
events in real-time; can provide graphical controls for real-time
mitigation of various events (e.g., triage); can provide for event
disposition (e.g., status), acknowledgment, etc.; and live graphics
such as charts, contextual graphics of events and acquired data,
etc.
[0135] The GUI component 1314 can provide for historical
presentations of events in context, for example, via tabular views,
event-driven charts, grids, etc. and can provide for event
disposition, acknowledgment, editing, etc.
[0136] The field component 1350 can generate output for AED
signals, which may be normal, ranked, alarms, etc., where, for
example, alarms can be tagged to facilitate filtering (e.g.,
reducing number, classifying, analyzing, etc.).
[0137] The production component 1370 can provide for access to a
truth (e.g., label) and event database, for example, to prepare
organized analyses, which may include analyses of uptime, downtime,
number of events, event duration (e.g., based on event status,
etc.), etc.
[0138] Various components of the system 1300 may be extensible and
adaptable for various operations, workflows, etc. The system 1300
may be part of an AEDF.
[0139] As to the workflows 1320, these are shown in the form of a
type of state diagram, which may be AEDF states. For example, an
AEDF may have states of operation. As an example, a single AEDF may
be in a particular operational state. As an example, an AEDF may be
implemented as a parallel processing machine such that multiple
states can exist at a time. As an example, multiple instances of an
AEDF and/or AEDA may be generated and utilized to perform one or
more aspects in series and/or in parallel.
[0140] In the example of FIG. 13, the workflows 1320 can utilize a
field systems block 1321 operatively coupled to field equipment,
which can output acquired data 1322 that can be loaded to a
historian 1327 for storage in a historian database 1330 and that
can be pushed 1323 for visualization 1324 (e.g., to one or more
GUIs, etc.) and for AED analysis 1325, which can generate output
1326, which may be fed back to be pushed 1323 and/or be loaded to
the historian 1327. The workflows 1320 also show loading of
historical data 1331 from the historian database 1330 where the
historian database 1330 can include truth marked data 1332, which
may be labels, for visualization 1324 and aggregation 1333 of
historical data, which may be stored in another database such as a
SQL database 1334 for generating output 1335.
[0141] As an example, consider an AED engine as part of an AEDF
that can include: tools to visualize and validate results and to
record expert knowledge in the context of the input dataset where
the tools: provide the ability to convert disparate historical data
provided by different clients in different timestamp formats, data
formats, units, and signal names into a common form, which can
allow clean, efficient comparisons of results generated from data
from different clients, fields, and equipment; handle datasets,
supporting efficient visualization including panning, and zooming
of results and input time series data together; are adaptable to
different data, addition of new outputs, layouts, and visualization
parameters; validate model outputs and create and maintain truth
labels relative to outputs in a persistent store; and allow offline
or real-time operations functioning in a cloud based or other
environment.
[0142] As an example, in a development cycle of a machine learning
algorithm that trains a machine model (e.g., neural network, etc.),
a user can analyze PIs to identify one or more specific datasets
that may have an issue as to potential problems to be resolved. As
an example, a user can query a database for sets of labels to
retrain the machine learning model if one or more PIs are not met.
As an example, as the set of labels grow, the expert knowledge
database is enriched such that the model becomes more capable of
replicating expert knowledge and reproducing expected results
(e.g., to some specified confidence level).
[0143] As an example, a detection engine can be automated and can
operate without human interaction during a detection phase, for
example, adapting itself to each of the wells it monitors. As an
example, an AED framework can perform multi-variate analysis,
combining measurements, and exploiting complex correlations between
them to provide a consolidated output to one or more end-users.
[0144] As an example, an engine can be built around multiple
processing steps including data conditioning, data quality and
event detectors which output multiple diagnostics to a monitoring
system. As an example, an AED framework can include capability of
performing real-time surveillance, while also benefitting from
historical data across multiple fields and wells.
[0145] As explained, there can be multiple root causes that could
lead to an operational event/alarm; examples include data quality,
sensor malfunctions, operational changes and flow-related events.
An AEDF can identify one or more of such root causes and provide
coherent reports on the events detected. An AEDF can include one or
more workflows, for example, with experts who can validate,
re-classify and develop "truths" that can be used to further
improve the engine.
[0146] As an example, AEDF instances can have a configuration that
may change over time. Configurations may be managed including an
upgrade/rollback strategy. As an example, consider an associated
"saved-state" file that preserves cumulative history learned by the
AED engine allowing AED to pick up where it left off after a
restart following an upgrade.
[0147] As to input and output signals, a set of input telemetry
signals (e.g., channels, etc.) can be specified for each well. As
an example, consider an AEDF that can include (1) a data quality
(DQ) engine that produces output data streams indicating the
quality of the input signals, and (2) reference signals for each
input signal.
[0148] As an example, one or more AEDF event detectors can produce
event transition output data streams, one for each detector. Each
detector may include an associated event severity and detector
quality signal.
[0149] Examples as to input can include for one or more operations
(e.g., artificial lift, other production, etc.): discharge
pressure, drive frequency, intake temperature, intake pressure,
motor current, motor temperature, wellhead pressure, and wellhead
temperature. Examples as to output can include for one or more
operations: detector reference signals, a reference for each input
signal, detector event outputs, deadhead surface (DH1), deadhead
downhole (DH2), gas interference (GI), insufficient lift (IL),
stuck pump (SP), pump off event (PO), other event outputs (e.g.,
pump status (ON/OFF), startups, shutdowns, etc.).
[0150] As an example, an AEDF can include detector event severity
outputs (e.g., one signal per-detector indicating severity of event
(SVxx)) and/or detector status/quality (e.g., one signal
per-detector indicating status of detector (QVxx)) and/or data
quality event outputs (e.g., event transition output data
streams).
[0151] Quality of multiple detector outputs concurrently can
include missing data, frozen data, gauge failure, etc. (e.g.,
GFd--broken discharge tube, GFt--broken thermocouple, DEt--downhole
electrical tool, DEc--downhole electrical cable, etc.).
[0152] AEDF detector event and DQ event outputs can be streams of
event transitions. As an example, two transitions can be combined
(off-on+on-off) to form a completed event. These events may be
extracted and stored in a database making it possible to associate
additional data with the event. An event created with a start
transition and no end transition is termed an `active` event. An
event that includes both start and end transitions can be a
`completed` event.
[0153] As an example, context can be provided by non-time series
data, together with other of the associated measurements and AED
time series data. As an example, a +/- feature can be included
where a user wants to see a lead up to and/or after the event.
Various components may optionally remove these heads and tails
portions.
[0154] An AEDF GUI can allow a user to quickly focus attention on
an event including some context before, during and after an event.
As an example, a GUI can display historical events as well as
events that are currently active in real-time and, for example,
events may be marked for other uses beyond immediate
surveillance.
[0155] An AEDF GUI can include various components, for example, a
real-time portion designed around surveillance and taking
immediate, mitigating actions on detected events, and a historical
component tailored to analysis, disposition, and editing of past
events for reporting and optimization purposes.
[0156] As an example, AEDF output may also be utilized in a
framework such as the Connected Production framework (Rockwell
Automation, Milwaukee, Wis.) screens as signals/alarms, and the
truth and event data may be utilized by the AVOCET framework
(Schlumberger Limited, Houston, Tex.) to prepare summary/macro
level reports such as # of events in a field, metrics on event
duration, top `offenders` for events in a month, uptime, downtime,
etc.
[0157] As an example, a framework can include features such as to
automate workflows, consider model-driven workflows that can
automate standard operating procedures to help improve efficiency
and meet regulatory requirements. Such workflows may be configured
for a wide range of use cases and initiate an ERP system, user or
field event (e.g., a process condition); centralize production
monitoring, consider using oil and gas equipment that incorporates
remote monitoring to allow for visualizing production and equipment
diagnostics across multiple wellheads from one or more location;
and improve response times, consider real-time connectivity with
seamless integration across automation systems to adjust production
equipment or other equipment in response to changes or demands.
Such a framework may help to reduce unplanned downtime via
diagnoses and evaluation and/or control of performance.
[0158] As an example, an AEDF may include features that, as a user
is working to resolve an event, control actions can be issued to
change one or more operational parameters (e.g., for artificial
lift, consider drive frequency and to change the choke
position).
[0159] As an example, an AEDF can include or be operatively coupled
to a ground truth database, which may be or include a label
database. In such an example, the ground truth can be a collection
of events that have been validated and recorded by one or more
domain experts. An expert can look at the context of an event and
determines the event type, severity, and duration that the system
state represents and records it in an events database. Additional
information such as a comment or more fine-grained event
classification may also be added to the truth event. As an example,
a truth event may be cross referenced to an event in another event
management system.
[0160] As to event triage, it can be a process of ranking a set of
active events and picking the most relevant/highest priority one to
handle first. As an example, consider an approach that includes
primary parameters for ranking active AED events that can include:
severity, duration and event type.
[0161] As an example, one or more actions may be taken to resolve
an event. In such an example, once an event is resolved, the event
can be marked to support ongoing development and analytics (e.g.,
consider a change in status from active to completed). As to
events, a workflow can include one or more of: promote the AED
event as truth to an event database; and promote an AED event as
truth to an event database with modifications. As an example, a
workflow can indicate duration; event type; severity; finer-grained
classification; comment addition; mark event as false alarm;
etc.
[0162] As an example, AEDF generated events can be compared with
truth events where statistics can be computed. As an example, an
event database can be accessed for automated validation and
regression testing.
[0163] As an example, an AEDF can include one or more GUIs for
create, read, update, or delete (CRUD) of one or more events, which
can include one or more truth events (e.g., labeled events) in an
event database, optionally without promotion from an AED event
(e.g., AEDF event). As an example, one or more truth events can be
displayed in context with one or more channels of data from one or
more assets (e.g., for event maintenance).
[0164] As an example, an audit trail can be generated for
operations on an event database, for example, including one or more
of the following: original source of event definition (RT AED,
offline AED (backfilling events from historical data), user);
author(s); and edit date(s) and/or time(s).
[0165] As an example, changes may be tracked as from/to pairs or a
history of previous states kept; previous states can be reviewed
(e.g., where it is desirable to enable a user to step back to
revisions to see what the original event duration was, or what the
initial, automatically determined event start time was prior to
editing).
[0166] Examples of AEDF UI Elements can include: charts; trends
showing context for events and events themselves; input telemetry;
AED events; truth events; DQ events; low-level threshold alarms;
graphical interaction for truth editing; interactive legend
groupings for usability; real-time updates; grid; show events from
selected time range in tabular form; sort/filter/paging/counts;
real-time updates of active events; ability to acknowledge an
event, etc.
[0167] As an example, in well-centric mode, a user may select a
well graphic and a GUI can updates to show events related to the
selected well in a selected time range. As an example, grid
contents can be pre-filtered for the well and multiple events can
be rendered (e.g., in one or more charts). As an example, in an
event-centric mode, a well selection can be made to select one or
more wells and event grid updates can occur to show events from the
selected well(s) within a selected time range. As an example, a
default behavior may show a real-time, automatically updating
stream of events.
[0168] As an example, in a well-centric mode, selecting an event in
the grid can show a static view of the event for the currently
selected event in the grid. As an example, in a well-centric mode,
real-time operation can show a window of data streaming in (e.g.,
as a FIFO, etc.). Completed events in the grid may be unselected.
And, if there is an active event, it may update in the chart and in
the grid.
[0169] As an example, in event-centric mode, real-time operation
can update active events in the grid and update chart data stream
for active event selected in the grid.
[0170] As an example, events shown in the grid may be sorted and
filtered by severity and duration to visually rank then for triage.
As an example, when an event has been addressed, an operator can
acknowledges it in the GUI.
[0171] As to features of a GUI, consider one or more of pan; zoom;
paging and decimation when moving beyond data extents; operations
that cause multiple AED events to come into view; visual
highlighting of an event in a chart for a well/event selected in a
grid; cursors; channel legends; markers; scales; ability to select
and interactively change visible region in time to support managing
truth events; and interactions with grid rows to view different
wells and events.
[0172] As an example, a GUI can provide for AED events as to truth
and interact with truth events can be provided as based on time
range selections, selected grid events and context shown in a
chart.
[0173] A GUI may issue signals/information to communicate with a
controller or equipment in a control room (e.g., for execution,
etc.). As an example, one or more displays can provide content
(e.g., adjust ESP speed set point or choke position, etc.) that can
depend on particulars of a workflow. In such an example, the
content may be associated with a selected event such as one or more
actions to mitigate the event.
[0174] Some actions may take time to complete and resolve an event.
To help manage a workflow of managing triage of many parallel
events, these actions can be added to a work in progress graphic
and a reminder set up for a deferred review or action related to an
unresolved event.
[0175] As explained, an AEDF can assist in detecting events. As an
example, multiple individual AED instance can be running,
communicating, getting good input, and have built up solid
references to work optimally. In some instances, an executing AED
can still provide degraded output for certain conditions (e.g.,
lack of data from a channel, noisy data, etc.). In such instances,
a GUI may inform an operator as to such conditions or degraded
output. As an example, a visual indication may be provided on a per
well basis, a per detector basis and/or a per channel basis.
[0176] As an example, consider conditions where a given AED
instance may not generate signals for some time. An AEDF can
monitor AED heartbeats and notify a user if it is not receiving
periodic heartbeats from an AED instance.
[0177] As an example, an AEDF can include a built in data quality
engine that outputs DQ events indicating problems with the input
data streams that the detectors use. As an example, consider an AED
detector status as to signals that indicate the general health of
running detectors.
[0178] As an example, a system can respond to severe events
promptly. For example, latency between when the event happens and
when a user can see an indication of the event can be a metric
rendered in a GUI. As an example, once a poor condition is
indicated in the GUI, a user can then drill down to try to
determine the source and attempt to resolve the problem. As an
example, an AED can have a corresponding alarm hierarchy.
[0179] As an example, a framework can include: channel name
identification; a timestamp: microseconds; a value: represents the
telemetry data value of a given tag/channel/IO; context: data
segregated by some context so that the framework can automatically
scale and process several wells at the same time (e.g., context as
the well name and comes as a header or label with the incoming
real-time data); etc.
[0180] As mentioned, via an AEDF, users can be able to see events
being automatically detected across multiple wells in an event-view
fashion and will be given a chance to acknowledge that, promote to
truth and navigate through the events captured so far. As an
example, AED alarms may be fed into a more expansive surveillance
alarm management system to enable a controller, an operator, a
production engineer to have access to alerts.
[0181] As an example, an AEDF can operate using one or more
application programming interfaces (APIs). For example, an AEDF
and/or a portion thereof (e.g., AED instances) can be isolated
using APIs. For example, an I/O API can help to isolate one or more
AEDF components from database specifics and/or
communication/protocol technologies. As an example, results may be
output using an I/O API approach. As an example, an AEDF can issue
API calls and receive information responsive to such API calls. As
an example, an AEDF can receive API calls and transmit information
responsive to such API calls.
[0182] As an example, a method can include: 1) acquiring
time-series (TS) data where real-time data are acquired from/by
various systems; 2) pushing real-time messages to subscribers
(e.g., transforming acquired data into a specified API format and
then pushing); 3) feeding an AED (e.g., AED running on incoming
real-time data, which may be via an API or APIs); 4) outputting new
signals (e.g., AED transforms its output/results into a format
defined by an API); 5) loading time-series (TS) to a historian
database (e.g., transforming real-time data (telemetry or AED
output) into a schema that may be saved into a non-SQL historian
database); 6) loading historical data/information (e.g., access to
a non-SQL historian database to visualize and/or perform
computations (e.g., aggregation)); 7) intelligent aggregating
(e.g., extraction of meaningful information from raw and/or
calculated real-time data, which may then be stored in a static
database (e.g., PDMS)) for reporting, etc.); 8) visualizing (e.g.,
allows user(s) to see real-time data, historical data and/or other
information (e.g., truth, labels, etc.)); 9) truth marking (e.g.,
truth may be created in real-time, on a historical basis, after the
fact, etc.). As an example, a non-SQL historian database can
include a schema that allows truth to be created, read, updated,
deleted, etc. (e.g., CRUD). As an example, truths may be retrieved
by a service that loads historical data.
[0183] As an example, an AEDF can include or allow for clients
running against a load balanced webserver; browser based client or
another frontend calling web services; middleware (e.g., a HTTP
REST API that a frontend may use to access time-series and event
databases in a convenient and secure manner), which may provide for
AED event extraction and storing of events in an AED event
database; one or more backend databases (e.g., for SQL queries
behind stored procedures executed by a specific service account,
which may prohibit SQL injection exposure, where a time-series
database may include a native REST API, etc.).
[0184] As an example, one or more features of a machine learning
platform may be utilized. For example, consider the TENSORFLOW
platform (Google, Mountain View, Calif.), which may be utilized as
part of an AEDF, to train one or more structures of an AEDF (e.g.,
model or models), etc.
[0185] As an example, a convolution neural network system (CNNS)
can be implemented using one or more platforms such as, for
example, a computational platform that includes neural network
features. As an example, a computational framework can include an
analysis engine that can include one or more features of the
TENSORFLOW platform, which includes a software library for dataflow
programming that provides for symbolic mathematics, which may be
utilized for machine learning applications such as artificial
neural networks (ANNs), etc.
[0186] As an example, the CAFFE framework (Berkeley AI Research,
Berkeley, Calif.) may be utilized. The CAFFE framework includes
models and optimization defined by configuration where switching
between CPU and GPU setting can be achieved via a single flag to
train on a GPU machine then deploy to clusters. As an example, a
framework may be at least in part cloud-based where computing
resources can include cloud-based resources, which may be
provisioned in one or more manners, optionally on demand.
[0187] As an example, a system, a method, a GUI, etc., can be for
one or more surveillance workflows and visualization based on AED,
contextual information and capturing of expert knowledge.
[0188] Various examples of complementary concepts demonstrate how
user interaction for an asset surveillance and management system
may occur. Various examples utilize one or more artificial lift
systems as examples of some types of equipment that may be
assessed, interacted with, understood, etc.
[0189] Various example systems include GUIs that can be utilized by
human operators to visualize, understand, interact, etc., with
machines and/or people. A single human operator may be overloaded
with tasks, duties, data, etc., as may be associated with various
assets and operations thereof, which can be dynamic and change
responsive to conditions, equipment interactions with other
equipment, the environment, people, etc. Dynamic behaviors may be
directed, at least in part, to perform desired actions of one or
more workflows. Equipment and/or people may issue notifications,
communications, etc., that can overwhelm a single operator, which
may be trying to handle multiple "threads" for various different
assets where each thread may be associated with one or more
workflows, with "stop and go" actions that may depend on
conditions, equipment, people, resources, etc. For example,
consider a single operator that works an 8 hour shift (480 minutes
or 28,880 seconds) that receives over 4,000 notifications,
communications, etc., during that 8 hour shift, which is, on
average, one new item each 7.2 second interval. The operator's
focus is to be keen to track multiple assets and multiple workflow
threads, which, again, can be dynamic.
[0190] As an example, to streamline an operator's environment, a
system can utilize a triage score, which can be a single triage
score that is numeric and characterizes an item, an incident, a
condition, etc., in a manner that can be compared to other items,
incidents, conditions, etc. As an example, a system can include a
ranking mechanism that is interoperable with a triage scoring
component and one or more real-time interfaces, such a ranking
mechanism can be utilized, for example, to trigger rendering of
graphics, text, etc., to a display. For example, consider a display
that includes graphics that represent threads where each thread is
associated with a particular asset and one or more workflows for
that particular asset. Where a high ranking triage score emerges
responsive to receipt of data, information, etc., at an interface,
a GUI can render a new thread graphic, which may be at a top row
position, a left column position, etc., such that an operator can
quickly become aware of the new thread and commence appropriate
action. For example, consider a new thread with a graphic that can
be selected to render a workflow for handling a triage issue that
is particular to an asset. In such a manner, an operator can in a
near immediate manner begin to address the triage issue by
commencing a suggested workflow. As mentioned, a workflow can be
interactive and depend on actions performed by one or more
machines, one or more people, etc. Hence, as an example, a wait
graphic may be rendered to indicate that after commencement of the
workflow to address the triage issue, the system is waiting for
input. In such an example, a wait graphic may be a clock graphic
with a spinning hand, a slowly blinking graphic, a heartbeat
graphic, a colored graphic, etc., which may be visible but not
distracting to the point that the operator's eyes become overly
strained when viewing one or more system related displays. Once
input is received, the wait graphic may transition to a different
style such that an operator knows that the workflow is ready to
proceed to a next action.
[0191] As explained, a single triage score can simplify matters and
a triage score can be utilized to sort and/or highlight issues on a
dashboard (GUI). As explained, a user may interact with a GUI to
select an asset and/or a triage score and commence a workflow to
address a triage issue, which may be a recommended workflow. As
explained, a workflow can be represented as a thread that can
involve many actions, waiting for responses, etc. A GUI can allow
that workflow/thread to progress while a user gets back to the
dashboard to handle one or more other new or existing
issues/workflows/threads. In the instance that a user has ample
time (a break in the action), the dashboard may be used to
tailor/optimize one or more assets, as may be highlighted via
various GUIs. As an example, a system can aim to make a user's job
more "free", mentally, as the user may forego having to "remember"
what's going on in each of many workflows as swim lanes or other
graphics can show existing workflows/threads and status
thereof.
[0192] As an example, a single triage score can be a way to
prioritize, which can simplify a complex system, providing the
greatest return and most efficiency of a user's time/efforts given
the number of assets/issues that may exist.
[0193] In the context of artificial lift, hundreds of thousands of
artificially lifted wells can be connected for remote
visualization, surveillance, and/or control. The number is expected
to rapidly increase as operators seek increased operations
efficiencies.
[0194] Operating complex electromechanical systems in the harsh
environment of a hydrocarbon reservoir presents a number of
challenges to operators. Surveillance engineers and operators are
often overwhelmed by "alarm floods" and often work in a reactive
mode just trying to mitigate emergencies. This leaves less time for
work on run-life or production optimization, potentially resulting
in shortened run-life for equipment or deferred production. Alarm
flood, a high number of manual tasks, and the demand for extreme
multi-tasking can result in surveillance engineers making mistakes
or, most commonly, overlooking the initial signs of an
equipment-damaging event. Various systems, methods, GUIs, etc.,
described herein can enable surveillance engineers to focus on the
right problem at the right time, ultimately resulting in improved
equipment run-life and increase production.
[0195] FIG. 14 shows an example of a method 1400 along with some
example illustrations of wells 1401 and 1403 and graphical user
interfaces 1405 and 1407. As shown, the method 1400 can include a
reception block 1410 for receiving sensor data for wells (e.g.,
assets, equipment at/in wells as assets, etc.); a computation block
1420 for, using at least a portion of the sensor data, computing
triage scores for operations of at least some of the wells (e.g.,
equipment operations, etc.); a render block 1430 for rendering a
graphical user interface (GUI) that includes a visualization of
ranked triage scores (e.g., raw, normalized, etc.); and a render
block 1440 for, responsive to a selection of one of the ranked
triage scores for one of the wells, rendering a workflow graphical
user interface (GUI) for commencing a workflow to control at least
one piece of equipment associated with the one of the wells.
[0196] As an example, a workflow can include one or more actions.
As an example, a ranked triage score may be associated with a
corresponding action, which may be an action of a workflow. In such
an example, the action may be a recommended action, which is
generated using an AEDF or an action engine operatively coupled to
an AEDF framework. As an example, a recommended action can be a
control action that controls equipment at a wellsite in an effort
to mitigate one or more conditions as associated with a triage
score, etc.
[0197] As to the illustrations, the wells 1401 may number more than
10, more than 100, more than 1000; some of the wells 1403 may be
associated with a particular portion of a surface network of
conduits, etc., that provide for transport of fluid (e.g., a
natural resource) produced to one or more processing facilities. As
an example, where gas lift is implemented as an artificial lift
technology, gas (e.g., natural gas, etc.) may be separated from
fluid produced and pumped into a well to facilitate further fluid
production. In such an example, the gas may be from one or more of
the wells 1401 (e.g., gas in a reservoir, etc.). As to the GUI
1405, it includes a visualization as to various wells such as the
wells 1401, which may be grouped (e.g., two or more groups, etc.),
where one of the groups includes the wells 1403, etc., which may be
operatively coupled to a portion of a surface network. As to the
GUI 1407, it includes an indication of an issue (e.g., insufficient
lift), along with a duration (e.g., 12 minutes and 3 seconds).
Further, the type of technology involved is indicated (e.g.,
"electric submersible pump"). As an example, the GUI 1407 may be
utilized to commence a workflow, for example, to address control of
the ESP at the Longhorn 12 well as being indicated in appropriate
visual coding (e.g., color coding, etc.) due to a high triage
score. As an example, a GUI such as, for example, a GUI 1900 of
FIG. 19, a GUI 2500 of FIG. 25, etc., may be utilized to commence a
workflow, issue one or more control actions, etc. As an example,
the GUI 1407 may be operatively coupled to a GUI that includes one
or more of the features of the GUI 1900 of FIG. 19, the GUI 2500 of
FIG. 25, etc.
[0198] The method 1400 is shown along with various
computer-readable media blocks 1411, 1421, 1431 and 1441 (e.g., CRM
blocks). Such blocks may be utilized to perform one or more actions
of the method 1400. For example, consider the system 790 of FIG. 7
and the instructions 796, which may include instructions of one or
more of the CRM blocks 1411, 1421, 1431 and 1441.
[0199] FIG. 15 shows examples of GUIs 1510 and 1530 that include
graphics for groups of wells with names Tranquility, Imbrium and
Cognitum where each group includes over 50 wells (e.g., over 50
assets). The GUIs 1510 and 1530 include a graphical control for
selecting one of a plurality of different ways to code the wells.
For example, the GUI 1510 includes coding by production (e.g.,
production of a natural resource) and the GUI 1530 including coding
by triage score (e.g., as to one or more events as may be detected
using an AEDF). In such an approach, a user may toggle between
different coding mechanisms to understand one or more aspects of an
asset and its operation. As an example, a coding approach can
include coding for components that are considered in calculating a
triage score. For example, production can be a component that is
used for calculating a triage score. In such an example, a triage
score may be higher where production is high (e.g., an issue places
high production at risk). By toggling between views, a user may
ascertain whether a triage score is high due in part to high
production or otherwise understand production in relationship to a
triage score (e.g., code, which may be a color, etc.).
[0200] FIG. 16 shows an example of a GUI 1600 that includes various
data as to operations in various fields. The GUI 1600 can include a
summary fora selected field or fields that can show a number of
assets (e.g., 28), percentage of assets in operation (e.g., 83
percent), a number of shutdowns as to operations (e.g., 28), a
total number of fields (e.g., 4), a number of decommissioned assets
(e.g., 3), and a number of operations with late restarts (e.g., 4)
where time lines may be shown with historic data. As mentioned,
graphics can illustrate assets per field or other manner, which can
include color or other coding. As an example, an events graphic can
show a number of events for a selected field or fields (e.g., one
or more assets), a number of alarms, etc., which may be coded in a
manner that is utilized for bulk graphical representations of
assets. As an example, a graphic can show a number of outstanding
alarms and/or events for a particular individual or team, which may
be along a timeline. As an example, a statistical representation of
net alarms and/or events within a time period may be rendered
(e.g., as a bar graph, etc.).
[0201] FIG. 17 shows an example of a GUI 1700 that includes various
graphical controls and information as to various assets. As shown,
columns can include assigned, client, field, triage score, AED
type, autopilot (e.g., automatic control), level "Lo", rate of
change "RoC" and level "Hi". As an example, the levels can be
adjusted such as a level "LoLo" and a level "HiHi". In FIG. 17, the
GUI 1700 shows various triage scores, which are in a range, for
example, of 0 to 1 where a higher score provides for a higher
ranking. As shown, well EB-12 has a highest ranked AED event as
indicated by the triage score of 0.95, which may be color coded,
etc. The AED type is indicated as "pump off" with a duration of 24
minutes, which may be compared to well EB-11, which has a triage
score of 0.37 with "pump off" for 17 minutes. Such an approach can
allow a user to discern differences in wells given triage scores
where a user may understand components that make up a triage score.
In such an example, well EB-12 may be higher scored due to
production (e.g., being higher than production for well EB-11) or
another factor that is used to compute the triage score.
[0202] FIG. 18 shows an example of a GUI 1800 that is for a
particular asset such as, for example, the well EB-12. The GUI 1800
provides a graph of the triage score for the asset with respect to
time. Further, various types of data from various channels are
rendered along with particular indications of alarms, limits, etc.,
and corresponding values for the channel data. The plots include a
time line with a "live" indicator where numeric values are shown to
the right of the live indicator. As shown in the GUI 1800, the well
EB-12 has an ESP that is experiencing gas interference and
insufficient lift. Further, various instances of "frozen" data are
indicated as well as a data quality indicator (see, e.g., bar
graph). The event is experienced at least in part over a time
period between day 14 and day 15. Various drops in frequency and
current are shown with respect to operation of the ESP.
[0203] In FIG. 18, the GUI 1800 also provides various data as to
particular equipment. For example, a serial number is given along
with a device type (e.g., cortex). As an example, a method can
include accessing data for a particular manufacturer, model,
device, etc., which may include accessing a database of updates
(e.g., a knowledge base, recalls, firmware upgrades, etc.), a
database of historical data (e.g., operation history, repair
history, maintenance history, etc.) and/or one or more other
databases. As an example, past operational history may include
efficiency data with operations parameters, experienced operational
limits (e.g., flow, efficiency, temperature, current, etc.), etc.
As shown in the GUI 1800, time-series and model data with the known
asset details (e.g. pump construction, reservoir/formation details,
etc.) can be rendered where one or more of such types of data may
be utilized for triage score calculation for an event and/or
associating one or more actions with an event. For example,
consider a database that indicates that the specific ESP
experienced an event on a prior job (e.g., another well, etc.) that
was mitigated/remedied by a taking a particular action. In such an
example, that action can be associated with the same type of event
or a related type of event as a recommended action. Such an
approach may be tiered, for example, where data for the specific
ESP is not available (or not indicating the same or similar event),
a multi-ESP databased, an ESP model database and/or ESP
manufacturer database may be accessed, which can include event
related data and one or more types of actions that may be
appropriate for event mitigation, etc.
[0204] As an example, a method can include utilizing a combination
of time-series and model data with one or more of equipment, asset,
and reservoir specific details. For example, consider an analysis
that assesses pressures in view of what data are available about a
reservoir (e.g., as to possible damage to a reservoir, as to pump
performance, expected duration of artificial lift employment,
etc.); or, for example, an analysis that assesses motor temperature
in view of the maximum operating temperature of the motor (e.g.,
where a higher operating temperature may shorten operational life,
shorten time to maintenance, etc.); or, for example, an analysis
that assesses pump operating point in view of a manufacturer's
operating curve (e.g., deviation from manufacturer's operating
curve, etc.). Such approaches can, for example, help to detect an
event and/or associate an action with an event. For example,
consider a sandface pressure related event that can be mitigated by
a control action of an ESP that reduces risk of reservoir damage.
As to temperature, it may be related to flow, as fluid flow may
cool an electric motor of an ESP. In such an example, an action can
be recommended that balances heat generated by the electric motor
and cooling of the electric motor by transfer of heat to pumped
fluid.
[0205] FIG. 19 shows an example of a GUI 1900 that may optionally
be co-rendered with one or more other GUIs such as, for example,
the GUI 1800 of FIG. 18. As an example, the GUI 1800 and/or the GUI
1900 may be rendered responsive to interaction with a GUI such as
the GUI 1510, the GUI 1530, the GUI 1600 and/or the GUI 1700. The
GUI 1900 includes a list of various operational events along with
duration, source, severity, start, end, and action. As an example,
the list of operational events can be ordered by ranking of triage
scores as computed for each of the events. As shown, an operational
event, which may be an AED event (e.g., from an AEDF) can be
rendered with a corresponding action, which may be, for example, a
workflow (see, e.g., various workflows "WF"). In the example of
FIG. 19, the first two events (top listed events) have a start time
but no end time, which means that their status can be "active";
whereas, one or more of the other events may have a status
"completed". In the example of FIG. 19, the "pump off" event is an
AED event that is deemed to be severe with a start time and no end
time where an associated action is to perform a workflow WFX1. In
such an example, a user may select the event using the GUI 1900
(e.g., and a human input device) to cause the workflow WFX1 to
commence or otherwise to cause information pertaining to the
execution of the workflow to be rendered and/or transmitted. In
such an example, a user can readily discern various events and
their status as well as actions that may have been taken to resolve
the events, which may give rise to their corresponding end
times.
[0206] As mentioned, a triage score may be calculated, which may be
via a computational triage engine that is operatively coupled to
one or more interfaces that can receive data, etc.
[0207] FIG. 20 shows an example of a method 2000 for computing a
triage score 2060, for example, by a triage engine 2050. As shown,
the method 2000 includes a sensor data block 2010, a
model/algorithm block 2020, and a virtual sensor data block 2030,
where such blocks can provide input or inputs to the triage engine
2050 such that the triage engine 2050 can output the triage score
2060, which can be an event specific triage score, which may be raw
or normalized.
[0208] As shown in FIG. 20, the triage engine 2050 can include
various inputs as may be provided by input blocks such as, for
example, a calculation and weights block 2041; an RTU alarm and
event detection (ED) block 2042; an edge, gateway alarm and/or ED
block 2043, a failure prediction and/or PHM block 2044, a digital
twin (e.g., digital avatar, etc.) and/or system model(s) block
2045, and a surveillance system alarm and/or ED block 2046. As
shown, the virtual sensor data block 2030 can be operatively
coupled to various input blocks and may provide virtual sensor data
where, for example, a sensor does not exist, a sensor has failed,
sensor data is not being received as expected, etc.
[0209] As an example, a triage engine can receive multiple forms of
information, including raw sensor data, event and/or alarm
detections from either edge devices such as the RTU or gateway,
event and/or alarm detections from server/cloud-side processing,
and optionally one or more virtual sensor, and then implement a
calculation and weight algorithm to combine these sources of
information using various techniques to arrive at a single triage
score for each event, each asset under control, each protection
(e.g., consider an asset to be protected from certain operation,
operational conditions, etc.), or each surveillance. As an example,
virtual sensors may include such triage engine inputs as "virtual
flow", "modeled pump temperature", or "estimated slip". As an
example, event detector sources may include threshold alarms or
higher-level diagnostics such as the output of an advance failure
prediction model, prognostic health monitoring model, or
comprehensive "digital twin" (e.g., an artificial lift system
avatar, etc.).
[0210] FIG. 21 shows examples of graphical user interfaces (GUIs)
that include examples of a table of measurements and estimates
2110, examples of plots 2130 of numbers that have been assigned to
the curves for motor temperature delta, time, and production, and
an example table 2150, which includes ranked normalized triage
scores.
[0211] As an example, consider a scenario where the measurements
and estimates 2110 are obtained from assets with operational
equipment such as electric submersible pumps. Such a table may be a
GUI, for example, with color coding to show rank with peers.
[0212] In the example of FIG. 21, each of the three
measured/estimated parameters can be assigned a cost function. Both
motor temperature delta from threshold and estimated time from
threshold temperature in this example can utilize a non-linear
exponential function of form: y=a*e.sup.bx.
[0213] And estimated BOE/day production may follow a linear
function: y=m*x+b.
[0214] In FIG. 21, the plots 2130 shows, for illustrative purposes,
numbers that have been assigned to the curves for motor temperature
delta, time, and production. In FIG. 21, the plots 2130 show
various parameter values below each of the plots. By applying these
to the relevant measurement/estimate, a method can provide a table
of costs that may be summed, ranked, and normalized.
[0215] In FIG. 21, the example table 2150 includes ranked
normalized triage scores. While the table 2150 shows numeric
values, as an example, graphics may be rendered to a GUI,
optionally with numeric values.
[0216] As explained, a triage score can provide a surveillance
engineer or other user tasked with actively managing and protecting
assets with a rank-able numerical score to guide their decision on
which asset event to manage first.
[0217] As an example, a system may provide for triage expression
editing, testing, and refinement. For example, consider a triage
engine that utilizes weights and calculations that are defined by
an asset owner and or key stakeholders in asset stewardship. As an
example, a system can be tailored to operator specific demands and
the operating conditions that exist in a specific field, regulatory
regime, or environment. As an example, a triage engine can be
generated that provides for codification of best practices to
ensure consistency across a population of asset managers. As an
example, with a configurable triage ruleset, one operator may wish
to slightly prioritize production over the likelihood of equipment
deterioration.
[0218] As an example, an expression editor tool can enable
clients/stakeholders to ensure their business logic, PIs, POs, and
other inputs are captured in a reviewable, auditable, and testable
fashion. Additional tools such as backtesters can assist with
running a retrospective review of how the rules would have worked
in the past. Such an approach can provide a sanity check on the
rules behavior before they are put in to place.
[0219] As an example, alternatively or additionally, an option may
be to collect user input either through running the triaging system
in a `training` mode for a short period of time, days or weeks, to
capture how the most senior experts select the top issues. For
example, a naive system can present issues in a list ranked by
classification and number of events, for example the number of
major, minor events and threshold alarms. As an example, expert
users can then work on this list while the system would tracks and
collects the sequence of interaction to enable future analysis or
training.
[0220] As an example, an option can exist to collect input to have
the system generate multiple scenarios with representative data.
These scenarios may then be distributed to senior asset management
people (e.g. surveillance engineers) within the stakeholder
organizations, and where they then rank the assets in priority. A
modified approach may be used to ingest the human-ranked input and
turn this into a training set for machine-learning/neural-network
AI techniques that would ultimately form the basis of the triage
engine. Such an approach can be less demanding as to a complex and
time consuming step of manually generating, testing, and adjusting
the weighting techniques. Evaluation techniques combined with a
large corpus of historical data may provide confidence in the
consistency of operation.
[0221] As an example, assets can provide a varied amount of
instrumentation and data which will in turn affect the amount of
higher-level analysis, such as event detection, that may be
performed on the asset. For example, an ESP well missing the
downhole tool lacks sufficient measurements to enable automated
event detection. This does not mean that the ESP will not have
protection from the triage system, rather the triage system can
include a mode that automatically adjusts ranking to account for
missing sensors, signals, or event identifiers. As an example, an
event detection engine can inform the triage engine on the state of
its operation, so the triage engine can be explicitly informed on
whether higher-level modeling or analysis is available for each
asset and can adjust the weighting accordingly.
[0222] As an example, parameters definitions may be updated as
frequently or infrequently as desired (e.g., optionally responsive
to one or more triggers as to condition(s)). For example, one
client may desire a highly regimented process that demands
infrequent updates and extensive reviews; another client may desire
a highly dynamic system capable of on-the-fly, real-time tuning by
either or both human and machine learning tools. As an example, a
triage engine can be adaptable and can accommodate a spectrum of
update frequency.
[0223] As an example, a system can provide for severity and
priority grouping. For example, a system can allow for triage and
alarms to be administered to logical groups to increase granularity
and applicability. As an example, triage rules, algorithms and
weights may differ across clients, but may be further refined by
applying the rules to fields, pads, or logical asset grouping. As
an example, one or more alarms may be defined with differing
weights/severities by group.
[0224] As an example, to help assure appropriate weighting of an
entire population, a hierarchical ranking system may be applied.
For example, a client with a small number of wells may frequently
have disproportionally high triage scores vs. a client with
hundreds of wells. Also worth considering is that a small
population of high-tier offshore wells with a higher-level service
contract may benefit from an extra weighting factor to ensure these
assets are treated with priority ahead of low-tier, low-cost land
wells with a basic service contract.
[0225] As an example, a triage score can enable a dynamic dashboard
to be created showing assets in precarious states, with the top of
the list being the one most urgently demanding
intervention/attention (see, e.g., FIG. 19). As the issue(s)
is(are) mitigated, the triage score can automatically begin to
decrease, as the factors that lead to it being highly ranked begin
to fall back towards safe or acceptable levels, resulting in a
lower score. As an example, where a workflow thread is graphically
rendered, the thread may be positioned accordingly to reflect a
change in triage score of an underlying asset.
[0226] As an example, a GUI can include delta cursors in a line
chart. For example, two cursors may be used to track the rate of
change for each measurement/channel presented in a line chart. Such
an approach can provide the user with a rapid means of
understanding how fast a measurement signal is increasing or
decreasing over time. As an example, cursors may include the
following capabilities or attributes: machine determination of
relevant timeframe, e.g. appropriate slope such as -0.8 degrees
C./hour instead of 0.0002 degrees C./second; draggable cursors that
may up across multiple stacked line charts and extend into the
previously described timelines; features to set delta cursors to
the start and end of a region selected in the timeline; and
features to set one of the delta cursor positions to a specific
point in time selected from the timeline.
[0227] As an example, a system can utilize one or more of
auto-tuning thresholds and rate-of-change alarms. For example,
setting threshold alarms tends to be a time-consuming, manual task
to be performed routinely to account for the evolving nature of a
producing reservoir. As the reservoir is depleted various
characteristics can change, which leads to threshold alarms that
become stale and potentially triggering too early (nuisance alarms)
or too late (allowing excessive risk or equipment damage). As such,
many operations call for routine alarm threshold reviews and
updates, and this process can take up a considerable portion of
time for operations managing many wells and/or locations with
highly complex alarming schemes. Such manual intervention can be
detrimental to addressing one or more high ranking triage score
asset issues.
[0228] As an example, via combining automation with event detection
components (such as AED) and/or advanced models, such as a digital
twin, a system can simplify threshold and/or alarm-related
processes and, for example, result in better protection while
freeing up a considerable amount of human time. As an example, a
system can provide for thresholds that can be automatically updated
on a much more frequent interval with more appropriate
thresholds.
[0229] As an example, a space can be defined by amplitude, one or
more variates and time. As an example, a system can utilize an
auto-adjustment approach to adjusting thresholds (e.g., alarm,
surveillance, etc.). For example, operational changes and/or events
may be taken into consideration.
[0230] As an example, the GUIs 1510 and 1530 may be heatmaps, which
can be coded for monitoring various assets. As an example, a system
can provide for rendering of space-optimized heatmaps to allow a
user to quickly visualize the status of multiple assets, for
example, by using color to indicate either a quantitative or
qualitative measure. For example, a heatmap grid can help an asset
manager or surveillance engineer rapidly visualize an asset's:
alarm state; estimated health; production rate; energy utilization;
instantaneous power; asset uptime or downtime, etc. As explained,
the GUIs 1510 and 1530 can include selectable items in a menu such
that a user may simultaneously render or toggle between views.
[0231] As an example, in the GUIs 1510 and 1530, a mouse-over
tooltips (e.g., finger hover, stylus hover, voice command, etc.)
with graphical indicators can provide quick context on the asset to
the user. Tooltip information can include the most relevant
information for the user to determine if an action is to occur. For
example: operating state; alarm state; asset identifying
information; asset type; and state duration.
[0232] As mentioned, trends may be rendered, for example, consider
the GUI 1600 of FIG. 16 and the GUI 1800 of FIG. 18. As an example,
a trend that starts with a baseline count at the start of the shift
can give the user a baseline to work against, and indicate in a
readily understood visualization if the number of issues is
decreasing or increasing as the user or team works to address tasks
and mitigate problems.
[0233] As an example, a GUI can provide for
attributes/characteristics of a short-term trend, where one or more
of: the performance trends may reset at the start of the user/team
shift; the performance trend may be bound to the total number of
issues, or a filtered list of issues (e.g. total count of
particular issues); and the performance trend may be bound to a
specific user or team (e.g. issues assigned to user John Doe). As
an example, consider attributes/characteristics of the long-term
trend, where one or more of: the trend may indicate a macro view of
how well that particular user or shift is performing over a longer
period of time (e.g., n shifts); a positive indicator (direction,
color, etc.) can indicate that the user or group addressed more
problems than were generated for the observation duration (e.g.,
shift); a mildly negative indicator can indicate that the user or
group addressed slightly fewer problems than were generated for the
observation period; a strongly negative indicator can indicate that
the user or group addressed considerably fewer problems than were
generated for the observation period; and a long-term trend view
may include benchmark lines such as the a PI or objective and/or a
peer benchmark.
[0234] As shown in the example GUIs 1700 of FIG. 17 and 1900 of
FIG. 19, a table format may be rendered, which can be for various
actions. As an example, as part of multi-monitoring workflows, a
system can include a dedicated actions screen that helps the users
manage their ongoing work. For example, consider a GUI that
includes one or more of: a live countdown timer until they are
scheduled to follow up on the next task; a current state/triage as
well as the initial state/triage; how long the issue has been
actively managed; who or what is assigned to next act on the
action; and what next action is recommended, which may be a
workflow or workflow action (see, e.g., workflows "WF" of the GUI
1900 of FIG. 19).
[0235] As an example, a system may automatically reassign actions
to a hand-over/shift-replacement user when the system is being used
in a shift-scheduled workplace. For example, such an action may be
handled in one or more manners, such as: a user logging out at the
end of their shift may delegate any outstanding actions to their
shift replacement, e.g.: "assign my (3) outstanding actions to J.
Doe"; a user logging in to start their shift may pull actions to
their shift. The system may suggest users that have a shift that
has recently ended or will soon end. For example: "assign
responsibility for (3) of J. Doe's outstanding actions to me."
[0236] FIG. 22 shows an example of a method 2200, which may be
utilized for incidents and model updates and retraining. In FIG.
22, the method 2200 includes an incident identification block 2212
and a user defined incident block 2214. In such an approach, the
block 2212 may operate using a machine that automatically detects
incidents while the block 2214 may operate using a human input
device (HID) that is operatively coupled to a machine. As shown,
the method 2200 includes a review/validation block 2216 and an
analysis block 2218 that can provide for analysis of incidents
against collected incidents. As shown, the analysis block 2218 can
provide output to an identification improvement feedback block
2222, a model adjustment and improvement block 2224 and an incident
recommendation block 2226 for evaluation of an incident
recommendation against, for example, historical data, etc. As
shown, the method 2200 can include a model improvement block 2232
for improving one or more models and can include an incident
recommendation update block 2234 for updating a recommendation with
respect to an incident.
[0237] As an example, a system can output an incident where the
incident characterizes condition(s) that may be caused many
individual events, alarms, user actions, and comments into a more
readily understood concept. For example, a shutdown may spawn a
dozen notifications, threshold alarms, and other warnings to the
user. Addressing each of these in isolation can be time consuming
and repetitive. As an example, a system can provide an ability to
group such items together under a descriptive type of incident
(e.g., "power loss incident", etc.). Such an approach may be
automatic, semi-automatic and/or via user interactions with one or
more GUIs. As an example, a grouping component can provide for
streamlined alarm/event handling for a surveillance user; and/or
simplified incident reporting to a client (e.g., telling the client
there was a "power loss" is more immediately useful than showing
many different threshold alarms such as low intake pressure, low
discharge pressure, low motor amps, low drive frequency, etc.).
[0238] FIG. 23 shows an example of a method 2300 that includes a
detection block 2312 for detecting an undesired event, a review
block 2314 for reviewing and classifying the detected undesired
event, a decision block 2316 for deciding whether the
classification is acceptable, a modification block 2318 for
modifying an unacceptable classification, a decision block 2320 for
deciding whether details and/or attributes of the classified,
undesired event are acceptable, a modification block 2322 for
modifying one or more unacceptable details and/or attributes, a
recordation block 2324 for recording the classified, undesired
event versus a ground truth (e.g., a label, etc.), a decision block
2326 for deciding whether data are sufficient to train and/or
re-train an automatic event detection engine, a continuation block
2328 for continuing to acquire data, a training block 2330 for
training and/or re-training an automatic event detection engine
(e.g., a machine learning model, etc.), an intervention block 2332
for intervening in one or more operations associated with the
undesired event, which may be an undesired operational event, and a
proceed block 2334 for proceeding with an intervention based on a
recommendation tailored to address the detected, undesired event,
which can be based on one or more details of the detected,
undesired event. As shown, the block 2330 can be utilize for
further detection(s), for example, per the block 2312, which may
operate using an automatic event detection engine.
[0239] As an example, the method 2300 may operate in conjunction
with one or more triage engines. For example, the detected,
undesired event can be utilized to generate a triage score, which
may be ranked, associated with an action, etc. For example, the
intervention block 2332 may be operatively coupled to a triage
engine such that the intervention occurs in a manner that depends
on a triage score and, for example, an associated action. As
explained, a triage score that may be ranked lower than one or more
others may be not as, relatively, urgent as to intervention. As
shown in the example of FIG. 23, the method 2300 can call for
intervention and can call for training and/or re-training of an
automatic event detection engine (e.g., of an AEDF, etc.).
[0240] The method 2300 can, for example, provide for decision
making to continue acquiring training data, training/retraining of
an event detection system, proceeding to intervention, etc.
[0241] As an example, based on event classification, duration, and
well-specific details, a system can provide tailored intervention
recommendations to a user via one or more GUIs. Such an approach
can, for example, result in shortened intervention and mitigation
cycles, as a user may tend to have fewer potential courses of
action to analyze and choose from (see, e.g., the GUI 1900 of FIG.
19).
[0242] As an example, a system can acquire data on success rate of
system-provided suggestions and how users act on guidance. As these
metrics are collected, a system may feed into further analysis
tools such as, for example: one or more machine learning or AI
tools that can then make improved recommendations based on the
effectiveness of historical recommendations and corresponding
actions; and/or one or more operator efficacy/performance
evaluation tools that can determine which system users are meeting
performance objectives or how to rank operators by ability to
protect assets in the shortest amount of time where, for example,
quantitative information can be utilized to further prioritize or
deprioritize the expert's future actions for the training of future
models. For example, if user A tends to take the right action while
user B does not, user A's actions will be used to positively inform
the model while user B's actions will not.
[0243] FIG. 24 shows an example of a method 2400 that includes a
training block 2412 for training and/or re-training a
recommendation engine, a tailoring block 2414 for tailoring a
recommendation based on an event and/or asset details, a review
block 2416 for reviewing a recommendation, optionally with
additional contextual information, an action block 2318 for acting
according to the recommendation, a decision block 2420 for deciding
whether the action is a proscribed action or an action derived from
the recommendation, a recordation block 2422 for recording the
taking of the selected action, a recordation block 2424 for
recording the action as being an action not from the recommendation
(e.g., a rejected recommendation), a monitor block 2426 for
monitoring mitigation of the event responsive to taking the action
per the action block 2418, and a recordation block 2428 for
recording efficacy of the action, along with asset data and one or
more other details. As indicated, the method 2400 can include a
loop such that the recordation block 2428 can be utilized for
training and/or re-training per the training block 2412.
[0244] As explained, a method can provide for training and/or
re-training of one or more types of engines, which may be utilized
for detection, decision making, recommendations, etc. As an
example, a system can provide for collecting expert feedback on
event classification in real-time or near-real-time such that the
system may more rapidly incorporate a growing body of truth data to
retrain an automated event detection engine. Compared to a training
cycle that demands a separate phase of retraining an underlying
machine learning component of a detection system on acquired
historical truth, an online truth collection system may utilize the
information more frequently to retrain the system, evaluate the new
performance against success criteria, and even automatically
self-deploy if the criteria are met. Such an approach can shorten
an improvement cycle and can result in a rapidly improving
detection system with reduced human input.
[0245] As shown in various GUIs (see, e.g., FIGS. 16, 17, 18 and
19), a system can include an event comparison tool that allows a
user to evaluate a selected event against one or more of the same
type of events, for example, from the same or similar assets (e.g.,
or other criterion or criteria). For example, a user may wish to
compare startups, and look at how similar the drive frequency,
choke position, and motor current are from each start on that
asset.
[0246] As an example, a comparison tool can allow a user to select
the n-th last event with navigation tools, so the user can select
the last event or an earlier event as the baseline for
comparison.
[0247] As an example, with respect to artificial lift as
implemented by ESPs, events may include, for example, one or more
of: starts, stops, AED events, such as: gas interference, stuck
pump, insufficient lift, dead head, etc.; first start (compared to
similar peers); etc.
[0248] As an example, a system can provide for multi-asset startup
or shutdown orchestration. For example, starting or stopping
multiple assets can present challenges on both asset inputs and
outputs. As an example, a system can provide for execution of bulk
actions on a number of assets. Such an approach may be automated
and customized for one or more purposes in a manner that may
proceed without a user's particular consideration to constraints,
which may create ripple effects on the larger system. For example,
a system can implement an intentional, rational approach that can
result in minimized disruption.
[0249] As an example, consider, after a field, pad, or multi-pad
shutdown: excessive demands can be placed on the electrical grid
and/or generators when attempting to restart all of the electrical
equipment at the same time. A system that has reasonably accurate
estimates of the asset power requirements and startup profiles can
create an optimized startup schedule that can bring the assets
online as fast as possible without overstressing the electrical
supply and potentially resulting in unintended sags, brownouts, or
further `trips` necessitating additional restart attempts.
[0250] As an example, consider, after field, pad, or multi-pad
shutdown, downstream production infrastructure and/or facilities
may not be prepared to deal with the rapid transition from zero
production to the assets producing nearly simultaneously again.
This can result in reactionary changes to manage the incoming
production, and this reactionary approach can result in restricting
flow or production from the wrong assets (e.g., assets that can be
considered above others).
[0251] As an example, a system can provide a user with "smart"
bulk-action tools that can identify common problems, such as excess
power demand on the infrastructure, and offer recommendations to
the user that will address the bottleneck or restraints.
[0252] As an example, to reduce mental strain and the problems
associated with vigilance tasks that demand frequent mental
"context switching", multiple, dedicated displays can be
coordinated by a system (e.g., a coordination application) and used
to perform very specific, related tasks. Such an approach can
address issues that may arise from copying and pasting information
between windows or applications, complex navigation, or arranging
multiple graphical user interface panels or windows to work through
a complex task.
[0253] As an example, dedicated displays can present an asset
manager with a simplified workspace that uses spatial consistency
to simplify the mental tasks of working through a problem. For
example, consider an arrangement that allows a user to: use their
left-most display to assess emergent situations that jeopardize
operations or assets; use their center display to investigate the
situation and take the corrective action; and use the right-most
display to keep track of various multi-step asset management tasks
that are in progress.
[0254] As an example, consider dedicated displays on the outside
(e.g., left-most and right-most) can both drive a center display,
which is where a user tends to spend most of the time performing
complex and demanding tasks. In such an example, the user can focus
her attention immediately in front and temporarily ignore potential
distractions of the other displays while she performs
time-sensitive, high-risk corrective action or investigation. Once
a high-intensity task has been completed, she can then resume
observing the outside, secondary displays for issues that are
either developing and deserve attention (left-most display), or
actions that are coming due for follow up (right-most display).
[0255] As an example, GUIs can provide a timeline, where the
timeline may utilize an X-axis as a trend chart/x-y scatter chart,
which may provide a user with a highly-intuitive view of various
things, such as specific points in time where an annotation,
hazard/event, or action was taken. As an example, placement of
lines/bars and graphical indicators/icons can be driven by the
X-axis as the time-series trends above or below the timeline. As an
example, a GUI can provide, for a specific point in time, rendering
of signals related to an event region or regions with defined start
and end points, as well as events with specific points in time. As
an example, consider rendering of colored bars and point-in-time
events indicated with graphical symbols to indicate comments,
alarms, and actions.
[0256] As an example, a system can provide for interactions between
users and/or "bots" that may interact with various users in an
automated manner. For example, a bot may prompt a user to make a
comment (e.g., "this trend is pertaining to what issue?"). In turn,
the input may be utilized to label and/or suggest labels for trends
in data for one or more other assets, which may be under monitoring
by the user and/or by another user. As an example, a bot approach
may spread a labeled trend amongst a community of user, which may
help to confirm and/or deny and/or customize (e.g., refine, etc.) a
trend. Such an approach may operate in a crowdsourcing manner,
where "votes" may be accumulated and/or comments, for example, in
one or more conversations. As an example, a user may highlight one
or more of the conversations as indicative of details as to
reasoning (e.g., underlying cause), prevention, action, etc. As an
example, an AI approach may be utilized to learn from votes,
comments, etc., which may be a bot driven and/or human interaction
drive approach to improving a system. As an example, a feature may
be switched on, for example, to train new users and, for example,
switched off, where an experienced user does not desire to be
directly involved in one or more aspects of a community-based
approach.
[0257] As an example, a GUI can render a tabular list of events
(see, e.g., the GUI 1900 of FIG. 19). As an example, a tabular view
of events can include regions, point-in-time events, actions and
comments. Such a tabular view may be filtered and navigated as an
ascending or descending list sorted by multiple criteria. As an
example, when an item from a list is selected, it can move a
timeline and line-chart to cover that region in time, so that the
user can quickly and easily see what the signals looked like around
that event. Such an approach can provide a much faster and more
intuitive way to review events without a user having to manually
`scrub` or navigate through a timeline or historical chart to try
to match up events and signals.
[0258] As an example, a GUI can include a visualization of one or
more past events, for example, in the context of an unfolding
event. For example, consider a GUI that presents data associated
with a previous startup, which may include accompanying comments as
a new startup is executed on the same well/platform. As an example,
comments may be presented along a timeline that includes various
startup actions.
[0259] As an example, a user may select an item from a timeline of
a GUI, where a system automatically selects a corresponding item in
a tabular list of events.
[0260] FIG. 25 shows an example of a GUI 2500 that includes various
graphics that include a "P" and an "EN", which stand for present
(P) and estimated new (EN). In such an example, a user can readily
assess consequences of transitioning from a present state to an
estimated new state. Such an approach may be utilized for
optimization and/or for addressing one or more issues that may
arise, for example, as classified by a triage score. In the example
of FIG. 25, the issue is indicated to be gas interference, with a
time duration of approximately 14 minutes and 23 seconds. As shown,
the drive frequency is approximately 51.2 Hz and a EN is 53.6 Hz;
while a choke position in percent is at 25.1 (e.g., for a choke
flow valve at a wellhead that controls flow of fluid out of the
well to a surface equipment network). As shown, an "execute
control" graphic can be rendered that allows a user to cause a
system to issue one or more control instructions to, for example,
change the operational frequency from 51.2 Hz to 53.6 Hz. The GUI
2500 also shows various comments in a comment log, which can
include various concerns, learnings, etc., which may guide a user
in deciding whether or not to cause the system to issue the control
instruction(s). The GUI 2500 can also include a "compute estimates"
graphical control, which may provide for detailed views of what may
happen if the recommended change in frequency is implemented.
[0261] As an example, a system can provide for model-assisted
interventions and control actions. For example, in the context of
an ESP, functionality provided by a system via a GUI can allow a
user to perform power optimization with surface voltage and/or
volts/Hz adjustments along with frequency.
[0262] As shown in the GUI 2500, there can be a variety of
performance envelopes to consider when making changes to an
operating point of a production asset (e.g., from 51.2 Hz to 53.6
Hz). As an example, even a change of a single operating point, for
example drive frequency or surface choke position, can result in
various underlying parameters shifting within a performance
envelope. In the example GUI 2500, the envelopes pertain to an ESP
variable frequency drive frequency and include pump efficiency,
power factor, inflow performance, motor efficiency, head and GOR.
As shown, in moving from P to EN, some envelopes improve while
others worsen. As such, a user may visual tradeoffs. As shown, an
underlying range indicator can facilitate review where a worsening
envelope may still be within an acceptable operational range (see,
e.g., motor efficiency where the EN is within a green operational
range).
[0263] As explained, by linking the ESP surveillance and control
system with models, the operator has the ability to estimate the
impact of the new operating point before making the change. In the
example GUI 2500, the operator is going to increase the variable
drive frequency from 51.2 Hz to 53.6 Hz. Before executing the
control, the operator can run the estimation with the model(s), and
the user interface can present the estimates to the user in an easy
to understand format, which can include one or more of the
following: 1. A net change, indicating if the change is positive or
negative; 2. The present position on the curve or within the model,
with optional additional context of how that relates to the
equipment, system, or subsystem performance envelope (represented
above by red, yellow, and green bars along the bottom of the
curve); 3. The estimated new position along the curve or within the
model; and 4. The present value and the estimated new value once
the change has been executed and the system becomes stable at the
new operating point.
[0264] A GUI such as the GUI 2500 can present various types of data
to a user, which can allow the user to determine if the new point
is likely to fall within the safe operating envelope and check for
potentially hazardous or unintended consequences, such as putting
the pump into upthrust, entering pump-off, or moving the motor
efficiency outside the recommended operating range. By integrating
the modeling into the workflow, the user can make this a regular
part of a workflow, increasing the safe operation of the system. As
mentioned, the issue "gas interference" may be characterized by a
triage score as computed by a triage engine. In such an example, a
dashboard may provide an indication of the triage score where a
user may interact with the dashboard to commence a workflow (e.g.,
a thread) to address the issue, which may cause rendering of one or
more graphical controls such as in the example GUI 2500 to allow
the user to assess and/or take one or more actions.
[0265] Managing a large population of assets operating within a
complex system becomes challenging for humans as the number of
variables to be managed increases. For example, consider the
following abbreviated list of variables to consider when managing a
number of electromechanical machines installed in hydrocarbon
reservoirs: reservoir drawdown versus optimal production rate for
maximum revenue; reservoir pressure versus minimum sandface
pressure before damage to the reservoir occurs; nameplate ratings
of the electric submersible pump motor, including maximum current;
available lift energy for the field (e.g., electricity for ESPs,
gas for gas lift, etc., where a goal may be to optimize power
consumption to maximize overall production at the field level);
pump operating curve, including regions of upthrust/downthrust;
rate at which the motor temperature is increasing; motor/equipment
temperature vs. the maximum operating temperature of the equipment
where failure, degradation, or shortening of the equipment life
occurs; production rate of the pump; energy dissipated in pump;
water cut (e.g., percentage of the fluid being produced is
marketable hydrocarbons); etc.
[0266] In isolation, an experienced individual may manage the asset
and successfully mitigate dangerous events, controlling the pump
speed (RPM) or pressure control valves after consulting with
information that will inform the safe operating envelope of the
equipment. This becomes extremely challenging though when the
operator is responsible for dozens or even hundreds of assets and
when multiple assets are in dangerous events/scenarios at one time.
In this case, the human operator can often resort to making an
immediate decision on which asset to sacrifice or jeopardize, and
which asset to save (e.g., mitigate). To address such a local
operator-to-operator based decision making process, a system can
utilize a triage engine as a computational tool for weighing
multiple criteria in accordance with the asset owner/stakeholder
objectives and business goals as to technological processes at
hand, and then presenting the user with a single score per asset
that indicates priority of action.
[0267] Without the triage engine, if a user is presented with three
assets experiencing a rapidly escalating, time-sensitive event, the
user may not intuitively know which asset is to be worked on first
due to the large number of factors to be considered. With a system
utilizing a triage engine, each of the three wells presenting a
triage score, which may be ranked, a user can focus on the asset
with the highest triage score, as this is the asset determined to
objectively present the biggest risk to the enterprise with respect
to one or more technological processes.
[0268] FIG. 26 shows an example of a system 2600 and various
components thereof. As shown, the system 2600 can include a data
component 2601 that is operatively coupled to a data storage
component 2620, which can be operatively coupled to a data storage
2640 that, for example, is utilized for production management
(e.g., production decision making, control, etc.). As shown, the
system can include or be operatively coupled to various equipment
in various environments such as a control room for control room
operations 2610, a surveillance environment for surveillance
operations 2630, and a production environment for production
operations 2650. As an example, an alarm engine 2622 may be
utilized for transmitting alarms for the control room operations
2610, an AED engine 2624 may be utilized for detecting and
transmitting events for the surveillance operations 2630, and one
or more simulation models 2642 may be utilized for transmitting
results as to production for the production operations 2650.
[0269] In FIG. 26, various example components are illustrated such
as an AED framework 2680, an AED application 2690 and a data bus
2695 (e.g., wired and/or wireless). As shown, at a level of the
AEDF 2680, there are an I/O interface 2682 and one or more AED
cores 2684 that can be utilized to host one or more AED
applications (e.g., AEDAs) 2690 (see, e.g., implementations 2692
and 2694), which can interface with one or more data busses 2695.
As shown, an AEDA can receive and/or transmit data, where
transmission may include transmission of one or more signals that
can call for a control action with respect to one or more pieces of
equipment. As shown in FIG. 26, AEDF 2680 is practically applied
through use of various types of technology, which can include
expert-based or expert-tuned technology, which can be implemented
via one or more types of GUIs, which can allow for real-time and/or
offline interactions.
[0270] As development, production, etc., of a field progresses, the
system 2600 can become "smarter", for example, able to generate
more accurate output and/or select more particular input for
purposes of generating more accurate output. As mentioned, an
expert may interact with a GUI to add something that an AEDF did
not detect. In response, an AEDF can adjust to call for one or more
different types of input, call for analysis of inputs at certain
times, call for analysis of inputs not previously analyzed
together, call for different types of control actions, etc.
[0271] As an example, a method can include detecting an event
occurring in an oilfield via a computational framework; rendering
the event to a graphical user interface of the computational
framework; responsive to the detecting, performing an action in the
oilfield; assessing an impact of the action; determining whether
the event is terminated; and, responsive to the event not being
terminated, interacting with the computational framework to revise
the computational framework.
[0272] As an example, an event can be an artificial lift event, a
drilling event, a stimulation event (e.g., hydraulic fracturing,
chemical treatment, water flooding, SAGD, etc.), or another type of
oilfield operational event.
[0273] As an example, a computational framework can include one or
more processors and memory accessible by at least one of the one or
more processors. As an example, a computational framework can be
operatively coupled to at least one piece of equipment in the
oilfield. As an example, computational framework can be or include
a field equipment controller.
[0274] As an example, a computational framework can be operatively
coupled to a database where interacting with the computational
framework revises the database.
[0275] As an example, detecting can be performed via a trained
machine model and a method can include re-training the machine
model based at least in part on interacting to generate a
re-trained machine model for detecting events.
[0276] As an example, a system can include a processor; memory
accessible by the processor; processor-executable instructions
stored in the memory and executable to instruct the system to:
detect an event occurring in an oilfield via a computational
framework; render the event to a graphical user interface of the
computational framework; responsive to detection of an event,
perform an action in the oilfield; assess an impact of the action;
determine whether the event is terminated; and, responsive to the
event not being terminated, interact with the computational
framework to revise the computational framework. As to termination
of an event, resolution and/or completion may cause
termination.
[0277] As an example, one or more computer-readable storage media
can include processor-executable instructions to instruct a
computing system to: detect an event occurring in an oilfield via a
computational framework; render the event to a graphical user
interface of the computational framework; responsive to detection
of an event, perform an action in the oilfield; assess an impact of
the action; determine whether the event is terminated; and,
responsive to the event not being terminated, interact with the
computational framework to revise the computational framework.
[0278] As an example, a method can include receiving time series
data acquired during equipment operations at a plurality of natural
resource sites; detecting operational events using the time series
data; ranking the operational events; associating each of the
operational events with a corresponding operational action; and
outputting at least a portion of the ranked operational events,
each with its corresponding operational action. In such an example,
outputting can include rendering graphics for the at least a
portion of the ranked events to a graphical user interface, where
the graphical user interface includes graphical controls linked to
the graphics that associate each of the at least a portion of the
ranked events with its corresponding operational action.
[0279] As an example, time series data can include one or more of
temperature time series data, pressure time series data, fluid flow
time series data and electrical time series data. For example,
temperature time series data can include equipment temperature time
series data for pieces of equipment that perform the equipment
operations; flow time series data can include associated fluid
composition data (e.g., gas fraction, gas ratio, hydrocarbon,
fluid, water, etc.); pressure time series data can include one or
more of reservoir fluid pressure data, wellbore fluid pressure
data, pump inlet pressure data, and pump outlet pressure data; and
electrical time series data can include electrical time series data
for power utilized by individual pieces of equipment that perform
at least a portion of the equipment operations.
[0280] As an example, a method can include ranking of operational
events by computing an operational event score for each of the
operational events. Such an operational event score may be a triage
score. As an example, consider computing the operational event
score by utilizing time series natural resource production data. In
such an example, equipment operations can include pumping
operations performed by pumps where the time series natural
resource production data include fluid flow time series data for a
natural resource pumped from a reservoir by the pumps. As an
example, equipment operations can include pumping operations
performed by pumps where time series natural resource production
data include pressure time series data for a natural resource
pumped from a reservoir by the pumps. As an example, a method can
include comparing at least a portion of time series natural
resource production data to model data, where computing an
operational event score increases the operational event score for a
decrease in natural resource production at one of the natural
resource sites.
[0281] As an example, a method can include classifying each of a
plurality of operational events as active or completed.
[0282] As an example, a method can include, for each of a plurality
of operational events, determining one or more of a severity, a
duration and a type.
[0283] As an example, a method can include, responsive to receipt
of a mode indicator, organizing at least a portion of ranked
operational events according to the mode indicator. For example,
consider using a natural resource site mode or an equipment mode.
As an example, a mode indicator can be for a natural resource site
mode where natural resource sites include wells in fluid
communication with a common reservoir and where a method can output
at least a portion of ranked operational events by outputting a
ranked list of at least a portion of the wells that correspond to
the at least a portion of the ranked operational events.
[0284] As an example, a mode indicator can be for an equipment mode
where equipment operations are performed by pumps and where a
method can output at least a portion of ranked operational events
by outputting a ranked list of at least a portion of the pumps that
correspond to the at least a portion of the ranked operational
events.
[0285] As an example, a plurality of natural resource sites can
include wells in fluid communication with a common reservoir and a
method can include detecting operational events using time series
data by detecting an operational event that decreases sandface
pressure in a wellbore of one of the wells in relationship to
reservoir pressure of the common reservoir. As mentioned, such a
condition may possibly give rise to reservoir damage.
[0286] As an example, a method can include determining an
operational event status. For example, consider an operational
event status that is an active status or a completed status. As an
example, a method can include, responsive to determining that one
of a plurality of operational events has a completed operational
event status, a method can include ranking the operational events
without that one of the operational events.
[0287] As an example, time series data can include natural resource
site identifiers, channel identifiers, timestamps and values.
[0288] As an example, a method can include, responsive to receipt
of a selection of one of a plurality of output ranked operational
events, issuing a control instruction that instructs equipment to
perform a corresponding operational action. For example, consider a
method that includes rendering a graphic to a graphical user
interface for the selected one of the output ranked operational
events, determining a control status of the selected one of the
output ranked operational events, and dynamically updating the
graphic responsive to the determined control status. In such an
example, rendering can include rendering the graphic adjacent to a
graphic for another selected one of the output ranked operational
events. In such an example, a method can include dynamically
adjusting an order of the graphics responsive to a change in the
ranking of the selected output ranked operational events.
[0289] As an example, a method can include outputting an
operational action graphic that includes at least one optimal
equipment operation parameter value. For example, consider
equipment operations that include pumping performed by pumps where
the at least one optimal equipment operation parameter value is for
optimal efficiency of one of the pumps.
[0290] As an example, a system can include a processor; memory
accessible to the processor; processor-executable instructions
stored in the memory and executable by the process to instruct the
system to: receive time series data acquired during equipment
operations at a plurality of natural resource sites; detect
operational events using the time series data; rank the operational
events; associate each of the operational events with a
corresponding operational action; and output at least a portion of
the ranked operational events, each with its corresponding
operational action.
[0291] As an example, one or more computer-readable storage media
can include computer-executable instructions executable to instruct
a computing system to: receive time series data acquired during
equipment operations at a plurality of natural resource sites;
detect operational events using the time series data; rank the
operational events; associate each of the operational events with a
corresponding operational action; and output at least a portion of
the ranked operational events, each with its corresponding
operational action.
[0292] A method can be associated with various computer-readable
media (CRM) blocks. Such blocks generally include instructions
suitable for execution by one or more processors (or cores) to
instruct a computing device or system to perform one or more
actions. While various blocks are shown, a single medium may be
configured with instructions to allow for, at least in part,
performance of various actions of a method. As an example, a CRM
block can be a computer-readable storage medium that is
non-transitory, not a carrier wave and not a signal. As an example,
such blocks can include instructions that can be stored in memory
and can be executable by one or more of processors.
[0293] As an example, a method may be implemented in part using
computer-readable media (CRM), for example, as a module, a block,
etc. that include information such as instructions suitable for
execution by one or more processors (or processor cores) to
instruct a computing device or system to perform one or more
actions. As an example, a single medium may be configured with
instructions to allow for, at least in part, performance of various
actions of a method. As an example, a computer-readable medium
(CRM) may be a computer-readable storage medium (e.g., a
non-transitory medium) that is not a carrier wave.
[0294] According to an embodiment, one or more computer-readable
media may include computer-executable instructions to instruct a
computing system to output information for controlling a process.
For example, such instructions may provide for output to sensing
process, an injection process, drilling process, an extraction
process, an extrusion process, a pumping process, a heating
process, etc.
[0295] In some embodiments, a method or methods may be executed by
a computing system. FIG. 27 shows an example of a system 2700 that
can include one or more computing systems 2701-1, 2701-2, 2701-3
and 2701-4, which may be operatively coupled via one or more
networks 2709, which may include wired and/or wireless
networks.
[0296] As an example, a system can include an individual computer
system or an arrangement of distributed computer systems. In the
example of FIG. 27, the computer system 2701-1 can include one or
more modules 2702, which may be or include processor-executable
instructions, for example, executable to perform various tasks
(e.g., receiving information, requesting information, processing
information, simulation, outputting information, etc.).
[0297] As an example, a module may be executed independently, or in
coordination with, one or more processors 2704, which is (or are)
operatively coupled to one or more storage media 2706 (e.g., via
wire, wirelessly, etc.). As an example, one or more of the one or
more processors 2704 can be operatively coupled to at least one of
one or more network interface 2707. In such an example, the
computer system 2701-1 can transmit and/or receive information, for
example, via the one or more networks 2709 (e.g., consider one or
more of the Internet, a private network, a cellular network, a
satellite network, etc.).
[0298] As an example, the computer system 2701-1 may receive from
and/or transmit information to one or more other devices, which may
be or include, for example, one or more of the computer systems
2701-2, etc. A device may be located in a physical location that
differs from that of the computer system 2701-1. As an example, a
location may be, for example, a processing facility location, a
data center location (e.g., server farm, etc.), a rig location, a
wellsite location, a downhole location, etc.
[0299] As an example, a processor may be or include a
microprocessor, microcontroller, processor module or subsystem,
programmable integrated circuit, programmable gate array, or
another control or computing device.
[0300] As an example, the storage media 2706 may be implemented as
one or more computer-readable or machine-readable storage media. As
an example, storage may be distributed within and/or across
multiple internal and/or external enclosures of a computing system
and/or additional computing systems.
[0301] As an example, a storage medium or storage media may include
one or more different forms of memory including semiconductor
memory devices such as dynamic or static random access memories
(DRAMs or SRAMs), erasable and programmable read-only memories
(EPROMs), electrically erasable and programmable read-only memories
(EEPROMs) and flash memories, magnetic disks such as fixed, floppy
and removable disks, other magnetic media including tape, optical
media such as compact disks (CDs) or digital video disks (DVDs),
BLUERAY.RTM. disks, or other types of optical storage, or other
types of storage devices.
[0302] As an example, a storage medium or media may be located in a
machine running machine-readable instructions, or located at a
remote site from which machine-readable instructions may be
downloaded over a network for execution.
[0303] As an example, various components of a system such as, for
example, a computer system, may be implemented in hardware,
software, or a combination of both hardware and software (e.g.,
including firmware), including one or more signal processing and/or
application specific integrated circuits.
[0304] As an example, a system may include a processing apparatus
that may be or include a general purpose processors or application
specific chips (e.g., or chipsets), such as ASICs, FPGAs, PLDs, or
other appropriate devices.
[0305] As an example, a device may be a mobile device that includes
one or more network interfaces for communication of information.
For example, a mobile device may include a wireless network
interface (e.g., operable via IEEE 802.11, ETSI GSM,
BLUETOOTH.RTM., satellite, etc.). As an example, a mobile device
may include components such as a main processor, memory, a display,
display graphics circuitry (e.g., optionally including touch and
gesture circuitry), a SIM slot, audio/video circuitry, motion
processing circuitry (e.g., accelerometer, gyroscope), wireless LAN
circuitry, smart card circuitry, transmitter circuitry, GPS
circuitry, and a battery. As an example, a mobile device may be
configured as a cell phone, a tablet, etc. As an example, a method
may be implemented (e.g., wholly or in part) using a mobile device.
As an example, a system may include one or more mobile devices.
[0306] As an example, a system may be a distributed environment,
for example, a so-called "cloud" environment where various devices,
components, etc. interact for purposes of data storage,
communications, computing, etc. As an example, a device or a system
may include one or more components for communication of information
via one or more of the Internet (e.g., where communication occurs
via one or more Internet protocols), a cellular network, a
satellite network, etc. As an example, a method may be implemented
in a distributed environment (e.g., wholly or in part as a
cloud-based service).
[0307] As an example, information may be input from a display
(e.g., consider a touchscreen), output to a display or both. As an
example, information may be output to a projector, a laser device,
a printer, etc. such that the information may be viewed. As an
example, information may be output stereographically or
holographically. As to a printer, consider a 2D or a 3D printer. As
an example, a 3D printer may include one or more substances that
can be output to construct a 3D object. For example, data may be
provided to a 3D printer to construct a 3D representation of a
subterranean formation. As an example, layers may be constructed in
3D (e.g., horizons, etc.), geobodies constructed in 3D, etc. As an
example, holes, fractures, etc., may be constructed in 3D (e.g., as
positive structures, as negative structures, etc.).
[0308] Although only a few examples have been described in detail
above, those skilled in the art will readily appreciate that many
modifications are possible in the examples. Accordingly, all such
modifications are intended to be included within the scope of this
disclosure as defined in the following claims. In the claims,
means-plus-function clauses are intended to cover the structures
described herein as performing the recited function and not only
structural equivalents, but also equivalent structures. Thus,
although a nail and a screw may not be structural equivalents in
that a nail employs a cylindrical surface to secure wooden parts
together, whereas a screw employs a helical surface, in the
environment of fastening wooden parts, a nail and a screw may be
equivalent structures. It is the express intention of the applicant
not to invoke 35 U.S.C. .sctn. 112, paragraph 6 for any limitations
of any of the claims herein, except for those in which the claim
expressly uses the words "means for" together with an associated
function.
* * * * *