DRILLSTRING STICKING MANAGEMENT FRAMEWORK

BACKGROUND

A resource field can be an accumulation, pool or group of pools 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 reservoir may be shaped in a manner that can trap hydrocarbons and may be covered by an impermeable or sealing rock. 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.

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.

Field planning 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.). Other phases can include appraisal, development and production phases.

SUMMARY

A method can include receiving information during a drilling operation for a drillstring disposed in a bore in a formation; estimating uncertainty associated with the information; analyzing at least a portion of the information using a physics-based model to generate a result; computing, via a Bayesian network, a risk probability of the drilling string sticking in the bore in the formation based at least in part on the result and the estimated uncertainty; and, based at least in part on the risk probability, issuing a signal. 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: receive information during a drilling operation for a drillstring disposed in a bore in a formation; estimate uncertainty associated with the information; analyze at least a portion of the information using a physics-based model to generate a result; compute, via a Bayesian network, a risk probability of the drilling string sticking in the bore in the formation based at least in part on the result and the estimated uncertainty; and, based at least in part on the risk probability, issue a signal. One or more computer-readable storage media can include processor-executable instructions to instruct a computing system to: receive information during a drilling operation for a drillstring disposed in a bore in a formation; estimate uncertainty associated with the information; analyze at least a portion of the information using a physics-based model to generate a result; compute, via a Bayesian network, a risk probability of the drilling string sticking in the bore in the formation based at least in part on the result and the estimated uncertainty; and, based at least in part on the risk probability, issue a signal. Various other apparatuses, systems, methods, etc., are also disclosed.

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

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.

FIG. 1 illustrates examples of equipment in a geologic environment;

FIG. 2 illustrates examples of equipment and examples of hole types;

FIG. 3 illustrates an example of a system;

FIG. 4 illustrates an example of a wellsite system and an example of a computing system;

FIG. 5 illustrates an example of a graphical user interface;

FIG. 6 illustrates an example of a framework and an example of a workflow;

FIG. 7 illustrates an example of a method and an example of a system;

FIG. 8 illustrates examples of events;

FIG. 9 illustrates examples of events;

FIG. 10 illustrates examples of events;

FIG. 11 illustrates an example of a method;

FIG. 12 illustrates an example of a graphical user interface;

FIG. 13 illustrates an example of a graphical user interface;

FIG. 14 illustrates an example of a graphical user interface;

FIG. 15 illustrates an example of a system and example workflows;

FIG. 16 illustrates an example of a method and examples of graphical user interfaces;

FIG. 17 illustrates examples of graphical user interfaces;

FIG. 18 illustrates examples of graphical user interfaces;

FIG. 19 illustrates an example of a graphical user interface;

FIG. 20 illustrates an example of a system and an example of a scenario;

FIG. 21 illustrates an example of a system;

FIG. 22 illustrates an example of computing system; and

FIG. 23 illustrates example components of a system and a networked system.

DETAILED DESCRIPTION

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.

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.).

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.

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.

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.

A derrick can be a structure used to support a crown block and a traveling block operatively coupled to the crown block at least in part via line. A derrick may be pyramidal in shape and offer a suitable strength-to-weight ratio. A derrick may be movable as a unit or in a piece by piece manner (e.g., to be assembled and disassembled).

As an example, drawworks may include a spool, brakes, a power source and assorted auxiliary devices. Drawworks may controllably reel out and reel in line. Line may be reeled over a crown block and coupled to a traveling block to gain mechanical advantage in a “block and tackle” or “pulley” fashion. Reeling out and in of line can cause a traveling block (e.g., and whatever may be hanging underneath it), to be lowered into or raised out of a bore. Reeling out of line may be powered by gravity and reeling in by a motor, an engine, etc. (e.g., an electric motor, a diesel engine, etc.).

As an example, a crown block can include a set of pulleys (e.g., sheaves) that can be located at or near a top of a derrick or a mast, over which line is threaded. A traveling block can include a set of sheaves that can be moved up and down in a derrick or a mast via line threaded in the set of sheaves of the traveling block and in the set of sheaves of a crown block. A crown block, a traveling block and a line can form a pulley system of a derrick or a mast, which may enable handling of heavy loads (e.g., drillstring, pipe, casing, liners, etc.) to be lifted out of or lowered into a bore. As an example, line may be about a centimeter to about five centimeters in diameter as, for example, steel cable. Through use of a set of sheaves, such line may carry loads heavier than the line could support as a single strand.

As an example, a derrickman may be a rig crew member that works on a platform attached to a derrick or a mast. A derrick can include a landing on which a derrickman may stand. As an example, such a landing may be about 10 meters or more above a rig floor. In an operation referred to as trip out of the hole (TOH), a derrickman may wear a safety harness that enables leaning out from the work landing (e.g., monkeyboard) to reach pipe in located at or near the center of a derrick or a mast and to throw a line around the pipe and pull it back into its storage location (e.g., fingerboards), for example, until it a time at which it may be desirable to run the pipe back into the bore. As an example, a rig may include automated pipe-handling equipment such that the derrickman controls the machinery rather than physically handling the pipe.

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.

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 rotary drilling; noting that various example embodiments may also use directional drilling.

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).

The wellsite system 200 can provide for operation of the drillstring 225 and other operations. As shown, the wellsite system 200 includes the platform 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.

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.

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.

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.).

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.).

The mud pumped by the pump 204 into the drillstring 225 may, after exiting the drillstring 225, form a mudcake that lines the wellbore which, among other functions, may reduce friction between the drillstring 225 and surrounding wall(s) (e.g., borehole, casing, etc.). A reduction in friction may facilitate advancing or retracting the drillstring 225. During a drilling operation, the entire drill string 225 may be pulled from a wellbore and optionally replaced, for example, with a new or sharpened drill bit, a smaller diameter drill string, etc. As mentioned, the act of pulling a drill string out of a hole or replacing it in a hole is referred to as tripping. A trip may be referred to as an upward trip or an outward trip or as a downward trip or an inward trip depending on trip direction.

As an example, consider a downward trip where upon arrival of the drill bit 226 of the drill string 225 at a bottom of a wellbore, pumping of the mud commences to lubricate the drill bit 226 for purposes of drilling to enlarge the wellbore. As mentioned, the mud can be pumped by the pump 204 into a passage of the drillstring 225 and, upon filling of the passage, the mud may be used as a transmission medium to transmit energy, for example, energy that may encode information as in mud-pulse telemetry.

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.

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.).

As an example, the drillstring 225 may be fitted with telemetry equipment 252 that includes a rotatable drive shaft, a turbine impeller mechanically coupled to the drive shaft such that the mud can cause the turbine impeller to rotate, a modulator rotor mechanically coupled to the drive shaft such that rotation of the turbine impeller causes said modulator rotor to rotate, a modulator stator mounted adjacent to or proximate to the modulator rotor such that rotation of the modulator rotor relative to the modulator stator creates pressure pulses in the mud, and a controllable brake for selectively braking rotation of the modulator rotor to modulate pressure pulses. In such example, an alternator may be coupled to the aforementioned drive shaft where the alternator includes at least one stator winding electrically coupled to a control circuit to selectively short the at least one stator winding to electromagnetically brake the alternator and thereby selectively brake rotation of the modulator rotor to modulate the pressure pulses in the mud.

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.

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.

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.

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.

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.

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.

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.

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).

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.).

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.

As an example, a drillstring can include an azimuthal density neutron (ADN) tool for measuring density and porosity; a MWD tool for measuring inclination (INCL), azimuth (AZI) 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.

As an example, geosteering can include intentional directional control of a wellbore based on results of downhole geological logging measurements in a manner that aims to keep a directional wellbore within a desired region, zone (e.g., a pay zone), etc. As an example, geosteering may include directing a wellbore to keep the wellbore in a particular section of a reservoir, for example, to minimize gas and/or water breakthrough and, for example, to maximize economic production from a well that includes the wellbore.

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).

As an example, one or more of the sensors 264 can be provided for tracking pipe, tracking movement of at least a portion of a drillstring, etc.

As an example, the system 200 can include one or more sensors 266 that can sense and/or transmit signals to a fluid conduit such as a drilling fluid conduit (e.g., a drilling mud conduit). For example, in the system 200, the one or more sensors 266 can be operatively coupled to portions of the standpipe 208 through which mud flows. As an example, a downhole tool can generate pulses that can travel through the mud and be sensed by one or more of the one or more sensors 266. In such an example, the downhole tool can include associated circuitry such as, for example, encoding circuitry that can encode signals, for example, to reduce demands as to transmission. As an example, circuitry at the surface may include decoding circuitry to decode encoded information transmitted at least in part via mud-pulse telemetry. As an example, circuitry at the surface may include encoder circuitry and/or decoder circuitry and circuitry downhole may include encoder circuitry and/or decoder circuitry. As an example, the system 200 can include a transmitter that can generate signals that can be transmitted downhole via mud (e.g., drilling fluid) as a transmission medium.

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.

As to the term “stuck pipe”, this can refer to a portion of a drillstring that cannot be rotated or moved axially. As an example, a condition referred to as “differential sticking” can be a condition whereby the drillstring cannot be moved (e.g., rotated or reciprocated) along the axis of the bore. 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. Differential sticking can have time and financial cost.

As an example, a sticking force can be a product of the differential pressure between the wellbore and the reservoir and the area that the differential pressure is acting upon. This means that a relatively low differential pressure (delta p) applied over a large working area can be just as effective in sticking pipe as can a high differential pressure applied over a small area.

As an example, 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.

FIG. 3 shows an example of a system 300 that includes various equipment for evaluation 310, planning 320, engineering 330 and operations 340. For example, a drilling workflow framework 301, a seismic-to-simulation framework 302, a technical data framework 303 and a drilling framework 304 may be implemented to perform one or more processes such as a evaluating a formation 314, evaluating a process 318, generating a trajectory 324, validating a trajectory 328, formulating constraints 334, designing equipment and/or processes based at least in part on constraints 338, performing drilling 344 and evaluating drilling and/or formation 348.

In the example of FIG. 3, the seismic-to-simulation framework 302 can be, for example, the PETREL® framework (Schlumberger Limited, Houston, Tex.) and the technical data framework 303 can be, for example, the TECHLOG® framework (Schlumberger Limited, Houston, Tex.).

As an example, a framework can include entities that may include earth entities, geological objects or other objects such as wells, surfaces, reservoirs, etc. Entities can include virtual representations of actual physical entities that are reconstructed for purposes of one or more of evaluation, planning, engineering, operations, etc.

Entities may include entities based on data acquired via sensing, observation, etc. (e.g., seismic data and/or other information). An entity may be characterized by one or more properties (e.g., a geometrical pillar grid entity of an earth model may be characterized by a porosity property). Such properties may represent one or more measurements (e.g., acquired data), calculations, etc.

A framework may be an object-based framework. In such a framework, entities may include entities based on pre-defined classes, for example, to facilitate modeling, analysis, simulation, etc. A commercially available example of an object-based framework is the MICROSOFT™ .NET™ framework (Redmond, Wash.), which provides a set of extensible object classes. In the .NET™ framework, an object class encapsulates a module of reusable code and associated data structures. Object classes can be used to instantiate object instances for use in by a program, script, etc. For example, borehole classes may define objects for representing boreholes based on well data.

As an example, a framework can include an analysis component that may allow for interaction with a model or model-based results (e.g., simulation results, etc.). As to simulation, a framework may operatively link to or include a simulator such as the ECLIPSE® reservoir simulator (Schlumberger Limited, Houston Tex.), the INTERSECT® reservoir simulator (Schlumberger Limited, Houston Tex.), etc.

The aforementioned PETREL® framework provides components that allow for optimization of exploration and development operations. The PETREL® framework includes seismic to simulation software components that can output information for use in increasing reservoir performance, for example, by improving asset team productivity. Through use of such a framework, various professionals (e.g., geophysicists, geologists, well engineers, reservoir engineers, etc.) can develop collaborative workflows and integrate operations to streamline processes. Such a framework may be considered an application and may be considered a data-driven application (e.g., where data is input for purposes of modeling, simulating, etc.).

As an example, one or more frameworks may be interoperative and/or run upon one or another. As an example, consider the commercially available framework environment marketed as the OCEAN® framework environment (Schlumberger Limited, Houston, Tex.), which allows for integration of add-ons (or plug-ins) into a PETREL® framework workflow. The OCEAN® framework environment leverages .NET™ tools (Microsoft Corporation, Redmond, Wash.) and offers stable, user-friendly interfaces for efficient development. In an example embodiment, various components may be implemented as add-ons (or plug-ins) that conform to and operate according to specifications of a framework environment (e.g., according to application programming interface (API) specifications, etc.).

As an example, a framework can include a model simulation layer along with a framework services layer, a framework core layer and a modules layer. The framework may include the commercially available OCEAN® framework where the model simulation layer can include or operatively link to the commercially available PETREL® model-centric software package that hosts OCEAN® framework applications. In an example embodiment, the PETREL® software may be considered a data-driven application. The PETREL® software can include a framework for model building and visualization. Such a model may include one or more grids.

As an example, the model simulation layer may provide domain objects, act as a data source, provide for rendering and provide for various user interfaces. Rendering may provide a graphical environment in which applications can display their data while the user interfaces may provide a common look and feel for application user interface components.

As an example, domain objects can include entity objects, property objects and optionally other objects. Entity objects may be used to geometrically represent wells, surfaces, reservoirs, etc., while property objects may be used to provide property values as well as data versions and display parameters. For example, an entity object may represent a well where a property object provides log information as well as version information and display information (e.g., to display the well as part of a model).

As an example, data may be stored in one or more data sources (or data stores, generally physical data storage devices), which may be at the same or different physical sites and accessible via one or more networks. As an example, a model simulation layer may be configured to model projects. As such, a particular project may be stored where stored project information may include inputs, models, results and cases. Thus, upon completion of a modeling session, a user may store a project. At a later time, the project can be accessed and restored using the model simulation layer, which can recreate instances of the relevant domain objects.

As an example, the system 300 may be used to perform one or more workflows. A workflow may be a process that includes a number of worksteps. A workstep may operate on data, for example, to create new data, to update existing data, etc. As an example, a workflow may operate on one or more inputs and create one or more results, for example, based on one or more algorithms. As an example, a system may include a workflow editor for creation, editing, executing, etc. of a workflow. In such an example, the workflow editor may provide for selection of one or more pre-defined worksteps, one or more customized worksteps, etc. As an example, a workflow may be a workflow implementable at least in part in the PETREL® software, for example, that operates on seismic data, seismic attribute(s), etc.

As an example, seismic data can be data acquired via a seismic survey where sources and receivers are positioned in a geologic environment to emit and receive seismic energy where at least a portion of such energy can reflect off subsurface structures. As an example, a seismic data analysis framework or frameworks (e.g., consider the OMEGA® framework, marketed by Schlumberger Limited, Houston, Tex.) may be utilized to determine depth, extent, properties, etc. of subsurface structures. As an example, seismic data analysis can include forward modeling and/or inversion, for example, to iteratively build a model of a subsurface region of a geologic environment. As an example, a seismic data analysis framework may be part of or operatively coupled to a seismic-to-simulation framework (e.g., the PETREL® framework, etc.).

As an example, a workflow may be a process implementable at least in part in the OCEAN® framework. As an example, a workflow may include one or more worksteps that access a module such as a plug-in (e.g., external executable code, etc.).

As an example, a framework may provide for modeling petroleum systems. For example, the commercially available modeling framework marketed as the PETROMOD® framework (Schlumberger Limited, Houston, Tex.) includes features for input of various types of information (e.g., seismic, well, geological, etc.) to model evolution of a sedimentary basin. The PETROMOD® framework provides for petroleum systems modeling via input of various data such as seismic data, well data and other geological data, for example, to model evolution of a sedimentary basin. The PETROMOD® framework may predict if, and how, a reservoir has been charged with hydrocarbons, including, for example, the source and timing of hydrocarbon generation, migration routes, quantities, pore pressure and hydrocarbon type in the subsurface or at surface conditions. In combination with a framework such as the PETREL® framework, workflows may be constructed to provide basin-to-prospect scale exploration solutions. Data exchange between frameworks can facilitate construction of models, analysis of data (e.g., PETROMOD® framework data analyzed using PETREL® framework capabilities), and coupling of workflows.

As mentioned, a drillstring can include various tools that may make measurements. As an example, a wireline tool or another type of tool may be utilized to make measurements. As an example, a tool may be configured to acquire electrical borehole images. As an example, the fullbore Formation MicroImager (FMI) tool (Schlumberger Limited, Houston, Tex.) can acquire borehole image data. A data acquisition sequence for such a tool can include running the tool into a borehole with acquisition pads closed, opening and pressing the pads against a wall of the borehole, delivering electrical current into the material defining the borehole while translating the tool in the borehole, and sensing current remotely, which is altered by interactions with the material.

Analysis of formation information may reveal features such as, for example, vugs, dissolution planes (e.g., dissolution along bedding planes), stress-related features, dip events, etc. As an example, a tool may acquire information that may help to characterize a reservoir, optionally a fractured reservoir where fractures may be natural and/or artificial (e.g., hydraulic fractures). As an example, information acquired by a tool or tools may be analyzed using a framework such as the TECHLOG® framework. As an example, the TECHLOG® framework can be interoperable with one or more other frameworks such as, for example, the PETREL® framework.

As an example, various aspects of a workflow may be completed automatically, may be partially automated, or may be completed manually, as by a human user interfacing with a software application. As an example, a workflow may be cyclic, and may include, as an example, four stages such as, for example, an evaluation stage (see, e.g., the evaluation equipment 310), a planning stage (see, e.g., the planning equipment 320), an engineering stage (see, e.g., the engineering equipment 330) and an execution stage (see, e.g., the operations equipment 340). As an example, a workflow may commence at one or more stages, which may progress to one or more other stages (e.g., in a serial manner, in a parallel manner, in a cyclical manner, etc.).

As an example, a workflow can commence with an evaluation stage, which may include a geological service provider evaluating a formation (see, e.g., the evaluation block 314). As an example, a geological service provider may undertake the formation evaluation using a computing system executing a software package tailored to such activity; or, for example, one or more other suitable geology platforms may be employed (e.g., alternatively or additionally). As an example, the geological service provider may evaluate the formation, for example, using earth models, geophysical models, basin models, petrotechnical models, combinations thereof, and/or the like. Such models may take into consideration a variety of different inputs, including offset well data, seismic data, pilot well data, other geologic data, etc. The models and/or the input may be stored in the database maintained by the server and accessed by the geological service provider.

As an example, a workflow may progress to a geology and geophysics (“G&G”) service provider, which may generate a well trajectory (see, e.g., the generation block 324), which may involve execution of one or more G&G software packages. Examples of such software packages include the PETREL® framework. As an example, a G&G service provider may determine a well trajectory or a section thereof, based on, for example, one or more model(s) provided by a formation evaluation (e.g., per the evaluation block 314), and/or other data, e.g., as accessed from one or more databases (e.g., maintained by one or more servers, etc.). As an example, a well trajectory may take into consideration various “basis of design” (BOD) constraints, such as general surface location, target (e.g., reservoir) location, and the like. As an example, a trajectory may incorporate information about tools, bottom-hole assemblies, casing sizes, etc., that may be used in drilling the well. A well trajectory determination may take into consideration a variety of other parameters, including risk tolerances, fluid weights and/or plans, bottom-hole pressures, drilling time, etc.

As an example, a workflow may progress to a first engineering service provider (e.g., one or more processing machines associated therewith), which may validate a well trajectory and, for example, relief well design (see, e.g., the validation block 328). Such a validation process may include evaluating physical properties, calculations, risk tolerances, integration with other aspects of a workflow, etc. As an example, one or more parameters for such determinations may be maintained by a server and/or by the first engineering service provider; noting that one or more model(s), well trajectory(ies), etc. may be maintained by a server and accessed by the first engineering service provider. For example, the first engineering service provider may include one or more computing systems executing one or more software packages. As an example, where the first engineering service provider rejects or otherwise suggests an adjustment to a well trajectory, the well trajectory may be adjusted or a message or other notification sent to the G&G service provider requesting such modification.

As an example, one or more engineering service providers (e.g., first, second, etc.) may provide a casing design, bottom-hole assembly (BHA) design, fluid design, and/or the like, to implement a well trajectory (see, e.g., the design block 338). In some embodiments, a second engineering service provider may perform such design using one of more software applications. Such designs may be stored in one or more databases maintained by one or more servers, which may, for example, employ STUDIO® framework tools, and may be accessed by one or more of the other service providers in a workflow.

As an example, a second engineering service provider may seek approval from a third engineering service provider for one or more designs established along with a well trajectory. In such an example, the third engineering service provider may consider various factors as to whether the well engineering plan is acceptable, such as economic variables (e.g., oil production forecasts, costs per barrel, risk, drill time, etc.), and may request authorization for expenditure, such as from the operating company's representative, well-owner's representative, or the like (see, e.g., the formulation block 334). As an example, at least some of the data upon which such determinations are based may be stored in one or more database maintained by one or more servers. As an example, a first, a second, and/or a third engineering service provider may be provided by a single team of engineers or even a single engineer, and thus may or may not be separate entities.

As an example, where economics may be unacceptable or subject to authorization being withheld, an engineering service provider may suggest changes to casing, a bottom-hole assembly, and/or fluid design, or otherwise notify and/or return control to a different engineering service provider, so that adjustments may be made to casing, a bottom-hole assembly, and/or fluid design. Where modifying one or more of such designs is impracticable within well constraints, trajectory, etc., the engineering service provider may suggest an adjustment to the well trajectory and/or a workflow may return to or otherwise notify an initial engineering service provider and/or a G&G service provider such that either or both may modify the well trajectory.

As an example, a workflow can include considering a well trajectory, including an accepted well engineering plan, and a formation evaluation. Such a workflow may then pass control to a drilling service provider, which may implement the well engineering plan, establishing safe and efficient drilling, maintaining well integrity, and reporting progress as well as operating parameters (see, e.g., the blocks 344 and 348). As an example, operating parameters, formation encountered, data collected while drilling (e.g., using logging-while-drilling or measuring-while-drilling technology), may be returned to a geological service provider for evaluation. As an example, the geological service provider may then re-evaluate the well trajectory, or one or more other aspects of the well engineering plan, and may, in some cases, and potentially within predetermined constraints, adjust the well engineering plan according to the real-life drilling parameters (e.g., based on acquired data in the field, etc.).

Whether the well is entirely drilled, or a section thereof is completed, depending on the specific embodiment, a workflow may proceed to a post review (see, e.g., the evaluation block 318). As an example, a post review may include reviewing drilling performance. As an example, a post review may further include reporting the drilling performance (e.g., to one or more relevant engineering, geological, or G&G service providers).

Various activities of a workflow may be performed consecutively and/or may be performed out of order (e.g., based partially on information from templates, nearby wells, etc. to fill in any gaps in information that is to be provided by another service provider). As an example, undertaking one activity may affect the results or basis for another activity, and thus may, either manually or automatically, call for a variation in one or more workflow activities, work products, etc. As an example, a server may allow for storing information on a central database accessible to various service providers where variations may be sought by communication with an appropriate service provider, may be made automatically, or may otherwise appear as suggestions to the relevant service provider. Such an approach may be considered to be a holistic approach to a well workflow, in comparison to a sequential, piecemeal approach.

As an example, various actions of a workflow may be repeated multiple times during drilling of a wellbore. For example, in one or more automated systems, feedback from a drilling service provider may be provided at or near real-time, and the data acquired during drilling may be fed to one or more other service providers, which may adjust its piece of the workflow accordingly. As there may be dependencies in other areas of the workflow, such adjustments may permeate through the workflow, e.g., in an automated fashion. In some embodiments, a cyclic process may additionally or instead proceed after a certain drilling goal is reached, such as the completion of a section of the wellbore, and/or after the drilling of the entire wellbore, or on a per-day, week, month, etc. basis.

Well planning can include determining a path of a well that can extend to a reservoir, for example, to economically produce fluids such as hydrocarbons therefrom. Well planning can include selecting a drilling and/or completion assembly which may be used to implement a well plan. As an example, various constraints can be imposed as part of well planning that can impact design of a well. As an example, such constraints may be imposed based at least in part on information as to known geology of a subterranean domain, presence of one or more other wells (e.g., actual and/or planned, etc.) in an area (e.g., consider collision avoidance), etc. As an example, one or more constraints may be imposed based at least in part on characteristics of one or more tools, components, etc. As an example, one or more constraints may be based at least in part on factors associated with drilling time and/or risk tolerance.

As an example, a system can allow for a reduction in waste, for example, as may be defined according to LEAN. In the context of LEAN, consider one or more of the following types of waste: transport (e.g., moving items unnecessarily, whether physical or data); inventory (e.g., components, whether physical or informational, as work in process, and finished product not being processed); motion (e.g., people or equipment moving or walking unnecessarily to perform desired processing); waiting (e.g., waiting for information, interruptions of production during shift change, etc.); overproduction (e.g., production of material, information, equipment, etc. ahead of demand); over Processing (e.g., resulting from poor tool or product design creating activity); and defects (e.g., effort involved in inspecting for and fixing defects whether in a plan, data, equipment, etc.). As an example, a system that allows for actions (e.g., methods, workflows, etc.) to be performed in a collaborative manner can help to reduce one or more types of waste.

As an example, a system can be utilized to implement a method for facilitating distributed well engineering, planning, and/or drilling system design across multiple computation devices where collaboration can occur among various different users (e.g., some being local, some being remote, some being mobile, etc.). In such a system, the various users via appropriate devices may be operatively coupled via one or more networks (e.g., local and/or wide area networks, public and/or private networks, land-based, marine-based and/or areal networks, etc.).

As an example, a system may allow well engineering, planning, and/or drilling system design to take place via a subsystems approach where a wellsite system is composed of various subsystem, which can include equipment subsystems and/or operational subsystems (e.g., control subsystems, etc.). As an example, computations may be performed using various computational platforms/devices that are operatively coupled via communication links (e.g., network links, etc.). As an example, one or more links may be operatively coupled to a common database (e.g., a server site, etc.). As an example, a particular server or servers may manage receipt of notifications from one or more devices and/or issuance of notifications to one or more devices. As an example, a system may be implemented for a project where the system can output a well plan, for example, as a digital well plan, a paper well plan, a digital and paper well plan, etc. Such a well plan can be a complete well engineering plan or design for the particular project.

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.

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.

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.

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.

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.

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.

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).

As an example, the term stuck can refer to a condition, a state, a varying degree of inability to move or remove a drillstring from a bore. Stuck can be a condition where it is possible to rotate a pipe or lower it back into a bore, or it might be a condition as to an inability to move a drillstring vertically in a vertical portion of a bore or horizontally in a horizontal portion of a bore or otherwise in a direction along a longitudinal axis of a bore; in one or more of such instances, rotation may or may not be possible. Stuck may refer to a condition where an inability to move a drillstring exists (e.g., inability to rotate and inability to translate). A stuck condition can change with respect to time depending on circumstances, forces, material, fluids, pressures, etc.

As an example, a method can include detecting onset of stuck pipe during well construction. For example, during a well construction process, there are various mechanisms that can cause the drill pipe, BHA, casing, wireline tool or whatever tool is in the hole to become stuck. A method can include detecting one or more pre-cursors to one or more sticking events and, for example, computing the risk that a pipe and/or tool is about to become stuck. Various different indictors may be analyzed in a probabilistic manner, for example, using a probabilistic framework.

U.S. Pat. No. 7,003,439 B2, to Aldred et al., issued 21 Feb. 2006, assigned to Schlumberger Technology Corporation, is incorporated by reference herein. U.S. Pat. No. 6,549,854 B1, to Malinverno et al., issued 15 Apr. 2002, assigned to Schlumberger Technology Corporation, is incorporated by reference herein. An article by Borjas et al., entitled “Real-Time Drilling Engineering: Hydraulics and T&D Modeling for Predictive Interpretation While Drilling”, Society of Petroleum Engineers (SPE) 150069, March 2012, is incorporated by reference herein.

As an example, a method can include propagating uncertainty of one or more observations and risks (e.g., using a Bayesian methodology, etc.) to compute a probability of a risk of getting stuck (e.g., optionally in conjunction with a discrete on/off alarm). As an example, a method can include utilizing various types of relevant data (e.g., real-time and static measurements, historical data, modelled predictions, etc.). As an example, a method can include utilizing data in a dynamic manner where, for example, data inputs are changed to assess conditions, etc. For example, a method can operate using one type of data from one type of equipment and then call for input of another type of data, which may be from another type of equipment. As an example, a method can determine on-the-fly the appropriate type of data to assess probability of a risk of getting stuck, which may be based on one or more types of physical phenomena as to one or more different types of sticking mechanisms. As an example, a method can utilize a single indictor, a sub-set of available data or a full set of available data.

As an example, a method can be robust to different rig configurations and available input. As an example, a method may allow for handling of sparse data or otherwise incomplete data, whether incomplete with respect to time, with respect to depth, with respect to a type of mechanical operation, with respect to a type of fluidic operation, etc. As an example, a method can include handle different types of measurements and/or missing measurements from one or more types of measurements.

As an example, a method can include generating information (e.g., output or result(s)) about a possible or probable cause of a risk (e.g., where a risk may be coming from). Such an approach can be alternative to or additional to generating information that indicates that there might be a problem. For example, a method can include outputting information that indicates that a problem has a high probability of occurrence and information that explains why that problem is deemed to have a high probability of occurrence. As an example, a method can include generating information and outputting such information in one or more manners to mitigate risk and, for example, avoid occurrence of a condition, a state, etc. As an example, information may be output for rendering to a display and/or for input to a controller that can control one or more pieces of equipment.

As an example, a method can operate in real-time or near real-time as may be appropriate for a drilling operation. For example, a method may receive data as that data becomes available during a drilling operation and include analyzing at least a portion of that data to generate one or more outputs (e.g., output information) where a delay between data reception and output information may be of the order of a few minutes, which can provide for, in a drilling operation context, real-time interpretation. As an example, timing of results may be provided and/or adjusted in relationship to a rate of penetration (ROP). Rate of penetration is the speed at which a drill bit can break rock and thus further the distance into a bore. ROP may be reported in units of feet per hour or meters per hour. As an example, consider a ROP in a range from about one meter per hour to tens of meters per hour. As an example, a method may receive data and output information based at least in part on such data within a time period that is less than a time to drill approximately 10 centimeters.

As an example, a method can operate based at least in part on a model that is built from a combination of learning from past data and a physical model of the wellbore, etc. A model can include equations that represent physical phenomena (e.g., differential equations as to various types of pressure, flow, etc., phenomena). Where a model is tied to physical phenomena, a method can more readily generate a reason or reasons why an alarm might be high and thus what mitigation action needs to be taken. In such an example, a backward progression may be utilized where, for example, a Bayesian network may provide for identifying one or more inputs as being one or more causes of an indicator or indicators being issued (e.g., an alarm, etc.).

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.

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.

FIG. 6 shows an example of a framework 600 (e.g., a computational framework) that can be adapted to generate one or more workflows, for example, as indicated by various arrows. As shown in the example of FIG. 6, the framework 600 can receive information as input such as, for example, one or more rigstates (e.g., operational states, non-operational states, etc.), surface torque, mud cake thickness and/or quality, BHA stab type and/or slickness, wellbore inclination, information from one or more offset bores (e.g., wells), mud logs, real-time caliper measurements, rate of penetration, flow rate(s), etc.

As mentioned, a framework can be at least in part model-based. In FIG. 6, models can include a torque and drag (T&D) model comparison component 652, a hydraulics model 654, a geomechanics model 656, and optionally one or more other types of models, which may be selectable and utilized in a dynamic manner during execution of a workflow (e.g., adaptive execution of a model-based workflow).

In the example of FIG. 6, the framework 600 is shown as including various input components such as a pickup/slack-off (PU/SO) determination (autocall) component 612, a stationary time determination component 614, and a sign(s) of borehole washout component 616. The framework 600 can include, for example, a torque spikes at rotation start component 622, a cavings detection/observation component 642, an amount of overbalance component 644, a stand pipe pressure (SPP) condition decision component 662, a wellbore stability decision component 664, a cuttings detection/observation component 666 (e.g., cutting carried to surface, etc.), and a mud balance component 668 (e.g., a decision or decision making component as to mud/drilling fluid, etc.). In such a framework, the various components can be associated with one or more sources of information, which can include, for example, one or more sensors that are at one or more field sites where field operations may be performed.

As an example, as to mud balance, information pertaining to mud balance may be acquired via one or more sensors that can measure density (weight) of mud, cement or other liquid or slurry. As an example, a mud balance can be determined via a fixed-volume mud cup with a lid on one end of a graduated beam and a counterweight on the other end. In such an example, a slider-weight can be moved along the beam where a bubble indicates when the beam is level. In such an example, density may be read at the point where the slider-weight sits on the beam at level. As an example, accuracy of mud weight may be within approximately +/−0.01 g/cm³. As an example, a mud balance may be calibrated with water or other liquid of known density by adjusting a counter weight. As an example, one or more pressurized mud balance sensors may be utilized. As shown in FIG. 6, the mud balance component 668 can output information to the risk of solids-induced pack-off component 684.

As to output information, components of the framework 600 can include, for example, a potential for differential sticking component 672, a risk of getting differentially stuck component 682, and a risk of solids-induced pack-off component 684. The framework 600 may be extensible in that one or more components can be added, deleted, updated, etc. In such an example, the framework 600 may be adapted to particular types of equipment, fluid, energy sources, etc., at a site.

As mentioned, one component of the framework 600 may generate output that can be received by one or more other components of the framework 600. For example, the risk of solids-induced pack-off component 684 may receive output from the T&D model comparison component 652, from the hydraulic model component 654, from the wellbore stability decision component 664, the cutting detection/observation component 666, etc. In such an approach, the framework 600 provides for forward progression from input(s) to output(s) as well as, for example, backward progression where an output or outputs may be traced backwards to one or more reasons, causes, datum, data, source of data, sources of data, etc. In such an example, an identified cause (e.g., contributing cause, etc.) to an output (e.g., an indicator such as an alarm, etc.), may be utilized to generate one or more signals that can be issued from the framework 600 to one or more pieces of equipment (e.g., to effectuate control of such one or more pieces of equipment as to one or more field operations, etc.).

As an example, the framework 600 may be adaptable in real-time, for example, where caliper information becomes available, the signs of borehole washout component 616 may be utilized to provide output to the wellbore stability decision component 664. As another example, where mud log data indicates that cavings are observed per the component 642, information may be transmitted to and received by the wellbore stability component 664. In such an approach, the quality of information provided to the risk of solids-induced pack-off component 684 may be enhanced, which may increase accuracy of output of the risk of solids-induced pack-off component 684.

In the example of FIG. 6, the arrows in the framework 600 pertain to an example of a workflow, as may be enabled to assess conditions germane to stuck pipe. Inputs to the various components are illustrated along the left side in FIG. 6 while some outputs are illustrated along the right side in FIG. 6. As an example, inputs can include raw measurements, for example, acquired and/or made at a rigsite during real-time execution and/or, for example, acquired pre-job such as from one or more offset wells and/or, for example, from a well plan (e.g., and/or from one or more analyses made before drilling). In the framework 600, components toward the right edge can compute various types of risk such as, for example, a risk that a pipe and/or tool may be about to become stuck. In such an example, the framework 600 may issue one or more signals, which can include one or more of an alarm signal, a control signal or another type of signal. As an example, the framework 600 may progress backwards from an output such as an alarm to one or more likely contributing causes of the alarm (e.g., one or more components of the framework 600 and associated input, etc.). In such an example, the framework 600 may issue one or more recommendations (e.g., one or more recommended actions) and/or one or more control signals, which may, for example, be issued via one or more network interfaces addressed to one or more pieces of equipment at a rigsite for control of at least one of the one or more pieces of equipment at the rigsite.

In the example of FIG. 6, the framework 600 can provide for combinations of various indicators, which may include those that have been tried in the past (e.g., with or without success). Various indicators may be one or more of data-driven, physics-based model-driven, etc.

As an example, the framework 600 can include estimating uncertainty of one or more variables and optionally propagating such uncertainty from one component to another component (e.g., in a chain or chains). Such an approach can allow for different measurements of similar quantities to be merged. For example, the two components 682 and 684 that compute risk of stuck pipe can take multiple indicators of stuck pipe as inputs and generate a single probability of risk.

As an example, the components 682 and 684 can be part of a Bayesian network, which can optimally consider uncertainty of each input to compute risk. In such an example, the Bayesian network can allow the computation of risk in a manner that differs from a “black-box” approach. For example, when the risk of stuck pipe is high, a user can interrogate the framework 600 to estimate which of the inputs are generating the high risk and why. Such an interrogation can include performing a backwards progression through the various components to identify an input or inputs, which, as mentioned, may be a basis for issuing one or more signals as to control of one or more pieces of field equipment (e.g., rigsite equipment, whether surface, subsurface, etc.).

As an example, a Bayesian network can include weights where the weights are associated with data acquired from equipment such as equipment in a field that performs one or more field operations. For example, a Bayesian network can include weights that are applied to data-based numbers where the data are acquired from equipment at a rigsite, which can include surface and downhole equipment.

In terms of an arc of a graph of a network (e.g., directed acyclic graph (DAG), etc.), an individual arc may have a weight or value associated with it, indicating a strength of interaction between nodes that the arc connects. The nature of such a weight can be application dependent. For example, it may represent a cost associated with a particular action, the strength of a connection between two nodes or, in the case of probabilistic models, the probability that a particular event will occur. As an example, a Bayesian belief network (e.g., a Bayesian network) can be conducive to understanding a scenario or scenarios as they can be constructed such that a parent(s) of a variable can be a direct cause. Such an approach can help to facilitate a process of determining weights for arcs that connect nodes of a network (e.g., assessment of conditional probabilities, etc.).

As an example, a Bayesian network can be implemented as part of a computational framework that includes one or more interfaces (e.g., one or more network interfaces, etc.) that can receive data acquired at one or more sites such as one or more rigsites. As an example, a computational framework can include one or more processors, memory, interfaces, etc. As mentioned, a computational framework can include receiving data, which may include sensor data from one or more sensors. As an example, a computational framework can provide for sensor fusion utilizing at least in part a Bayesian network (e.g., or Bayesian networks).

Sensor fusion refers to the class of problems where data from various sources can be integrated to arrive at an interpretation of a situation (e.g., a scenario). For example, data from various rigsite sensors, which may be for different sampling rates, different data formats, different units, etc., can be integrated to determine a status of one or more rigsite operations, which may include one or more operations that are associated with sticking (e.g., actual sticking, breaking free or becoming unstuck, risk of sticking, likelihood of success of breaking free, etc.). As an example, a sensor fusion approach may include receiving data from a plurality of sensors where a state can be discerned for a system by integrating at least a portion of the received data.

As an example, a computational framework that implements one or more Bayesian networks may provide for handling of data that may differ as to one or more of temporal resolution and spatial resolutions. In such an example, the framework may solve a so-called correspondence problem that can include deciding which event(s) from one sensor correspond to the same event(s) as reported in one or more other sensors. As an example, a Bayesian network approach can be implemented in a manner that tends to be robust to missing data via combining data from a plurality of sources (e.g., a plurality of sensors, etc.). As an example, a Bayesian network approach may address scenarios where each sensor individually may have a limited chance of providing an acceptable interpretation by combining information from a plurality of sensors to increase the likelihood of providing an acceptable interpretation (e.g., valid in terms of physics, matching real-world conditions, etc.).

As an example, a computational framework that implements one or more Bayesian networks can provide for diagnosing one or more issues that a system may be experiencing, may have experienced, may likely experience, may experience given one or more sets of operational conditions, etc. As an example, a computational framework may provide for deciding when to issue a signal, which may be a control signal and alert signal, etc.

As an example, parameters of a Bayesian network may be tuned as conditional probability tables, which may be relative weights of the Bayesian network. In such an example, data can be used to tune parameters where the parameters have physical meaning as they refer to input indicators. In such an example, where output of a computational framework that implements at least one Bayesian network indicates that a risk for a sticking or other issue at a rigsite is high (e.g., compared to a threshold), as various parameters are associated with real-world data acquired at the rigsite, a method can include working backwards through a Bayesian network to help identify one or more causes of the indicated risk where such a method can include issuing one or more signals that aim to address the one or more causes. For example, where an indicated risk is for differential sticking of a drillstring in a borehole that is being drilled, working backwards may identify that a hole cleaning index (HCI) may be a cause where the hole cleaning index is based at least in part on a flow rate for drilling fluid (e.g., mud) such that a signal may be issued to control a pump or pumps that pump drilling fluid to, for example, increase the flow rate for the drilling fluid. In such an example, where the increase in the flow rate for the drilling fluid does not adequately address the indicated risk (e.g., sticking occurs), one or more weights may be adjusted as to flow rate for the drilling fluid on the hole cleaning index or, for example, a weight for the hole cleaning index may be adjusted where another cause may be contributing, at least in part, to the indicated risk.

As an example, a computational framework that includes a Bayesian network or networks can provide for backward progressions from an outcome (e.g., an indicator) to data and/or one or more sources of data. Such an approach can help to associate the outcome with particular, specific data and/or one or more specific sources of data (e.g., equipment, acquisition equipment, etc.). As to specific data, as mentioned, data may be temporal and/or spatial with respect to resolution such that a backward progression may provide for identifying where temporal and/or spatial aspects of data can be improved. In such an example, a signal may be issued by a computational framework that controls one or more temporal and/or spatial aspects of a sensor or sensors that acquire particular data. Such an approach can help the computational framework to operate with an enhanced ability to provide more beneficial outputs (e.g., operate with greater certainty, both in a forward mode and in a backward mode, etc.).

As an example, a computational framework can be extensible such that one or more components can be added, removed, updated, etc. For example, where the computational framework includes a Bayesian network as to risk of differential sticking and where a new piece of equipment is implemented at a rigsite that outputs data, the Bayesian network may be augmented via instantiation of a component that adds the data as an input, which may be appropriately weighted, etc.

As an example, a Bayesian network can provide for computation of “potential risk” (e.g., for the case of differential sticking, see the component 672). Such an approach can consider the environment or set-up to determine prior risk. For example, a workflow may consider that certain BHAs are more susceptible to differential sticking, or that the chance of becoming differentially stuck increases with overbalance pressure (see, e.g., the component 644). Potential risk can be computed for a given environment and well plan, for example, before drilling commences and may be used to help design the well plan. As an example, the framework may provide output that can assist in choosing a BHA and/or mud weight that minimizes potential for differential sticking. Such an approach may utilize a component or components that may be part of a Bayesian network and/or a physics-based model (e.g., of a process of differential sticking).

As an example, one or more outputs from the framework 600 may be received as one or more inputs to a system that can generate information suitable for rendering to a display (e.g., instructions to control a graphics processing unit, etc.). For example, where a BHA is being designed, information may be output to a well plan GUI such as the GUI 510. In such an example, the drillstring GUI 560 may highlight a portion of the drillstring graphic that can be selected based at least in part on output from the framework 600. For example, where the framework 600 indicates a risk of getting stuck at a certain depth during drilling operation, a tool may be highlighted and information rendered to the display as to the type of sticking event, the risk of the sticking event occurring, the conditions and/or causes of the sticking event (e.g., and associated risk and/or uncertainty and/or contribution to the cause or causes) and, for example, a recommended change or adaption to the drillstring, whether physically or operationally that may be implemented in an effort to reduce the risk of getting stuck.

As an example, an output from a framework such as the framework 600 may include a suggested alteration to a well trajectory and/or to a completion of a well. As an example, an output from the framework 600 may provide for highlighting one or more points in the point spreadsheet 570 as to one or more parameters of a well or wells. As an example, a user may accept a change and/or otherwise adapt a well plan based at least in part on output from the framework 600. For example, a user may utilize the GUI 500 to edit one or more portions of a well plan, optionally based at least in part on information communicated with one or more members of the team 540.

As illustrated in the example framework 600 of FIG. 6, which includes arrows as to an example of a workflow, risk of getting stuck can be based on two mechanisms: risk of differential sticking per the component 682 and risk of solids-induced pack-off per the component 684. As mentioned, these components can be part of a Bayesian network. Such a network may be extended to compute the risk of getting stuck based on one or more other mechanisms (e.g., key seating, shale swelling, etc.), alternatively or additionally.

As to various operations, conditions, etc., associated with sticking, consider hole cleaning, hydraulics, and torque and drag as factors that can be considered. As shown in FIG. 6, the framework 600 can include components associated with such factors (see, e.g., the component 654 as to hydraulics and hole cleaning index (HCI), the components 662 and 652 as to torque and/or drag, etc.).

As an example, a method can include one or more of assessing stand pipe pressure (SPP) actual versus model (e.g., monitor separation of curves and determine whether a result is to be part of a workflow, etc.; see also the component 662 of the framework 600), assessing equivalent circulating density (ECD) actual versus model (e.g., monitor separation of values and determine whether a result is to be part of a workflow, etc.), assessing torque and drag (T&D) actual versus model (e.g., monitor for deviation of trend and model and determine whether a result is to be part of a workflow, etc.; see also the component 652 of the framework 600).

As an example, a framework may be operatively coupled to one or more services such as, for example, one or more of the THEMA™ services (Schlumberger Limited, Houston, Tex.).

A service may provide for analysis of real-time data streams from a number of sensors to provide real-time status of a well, for example, by combining depth- and time-based data related to wellbore pressure balance, drilling mechanics, and/or hole condition.

A service may provide wellbore pressure balance for detection of fluid influx or loss in the wellbore, even at very low volumes. Early kick detection may be supported by pump-off gas analysis to identify potential underbalance situations. An automatic flowback fingerprint may be captured.

A service may provide for drilling mechanics analysis such as wear and behavior of a drill bit, which may be assessed by monitoring one or more drilling parameters (e.g., axial (bit bouncing) and torsional (stick/slip) vibration frequencies and energy) through measurements made by one or more sensors. Potential issues may include bit balling, drillstring vibration, and bit wear, which may be predicted as to risk and risk potential where one or more drilling parameters may be optimized to improve ROP and increase equipment life.

A service may provide for assessing hole condition such as wellbore stability and hole-cleaning efficiency, which may be analyzed in real-time by comparing measurements of relevant parameters (e.g., pickup, slack-off, and free-rotating weights; torque; and equivalent circulating density (ECD)), with theoretical values calculated using one or more models. As an example, hole-condition monitoring can be linked with data from one or more cuttings flowmeters.

As an example, one or more of a hydraulics physics-based model, a geomechanics physics-based model, or other type of physics-based model may be implemented as part of a framework, for example, to perform one or more workflows. As an example, the framework 600 of FIG. 6 may be operatively coupled to a framework such as the PETREL® framework (e.g., optionally via the OCEAN® framework, etc.), which may include and/or be operatively coupled to one or more physics-based models.

As an example, a computational framework may output information with respect to one or more operational parameters as to one or more operators, one or more service providers, one or more suppliers, etc. As an example, a computational framework may output information that associates decision making and one or more operators (e.g., individual, team, etc.). Such an approach may help to identify how decisions are made during operations in the field. Such an approach may help to assess decision making by an individual, a team, etc., which may provide for tuning of one or more parameters of a computational framework (e.g., one or more Bayesian network parameters, etc.).

As an example, a computational framework can respond to real-time decision making in the field during operations. As a Bayesian network can include inputs as to acquired, real-time data, outputs of the Bayesian network can depend on the acquired, real-time data. As an example, a computational framework may associate changes in real-time data with real-time decision making by one or more operators, controllers, etc. As an example, an output of the computational framework can include issuing a query to one or more onsite devices such as, for example, an operations computer, etc. As an example, consider issuing a query to a device that asks “was the mud flow rate increased?” In such an example, a response can be received by the computational framework, which may be utilized to adjust one or more parameters (e.g., one or more weights, etc.).

FIG. 7 shows an example of a method 700 that can include a reception block 710 for receiving information during a drilling operation for a drillstring disposed in a bore in a formation; an estimation block 720 for estimating uncertainty associated with the information; an analysis block 730 for analyzing at least a portion of the information using a physics-based model to generate a result; a computation block 740 for computing, via a Bayesian network, a risk probability of the drilling string sticking in the bore in the formation based at least in part on the result and the estimated uncertainty; and an issuance block 750 for, based at least in part on the risk probability, issuing a signal. In such an example, the signal may be one or more types of signals. For example, a signal may be an alert, a control signal (e.g., a command, etc.), or another type of signal. As an example, a signal can be received by one or more pieces of equipment to control one or more pieces of equipment. As an example, a signal may be an actuation signal that upon receipt by a piece of equipment actuates the piece of equipment such that the piece of equipment performs an action, changes state, etc. As to a controller, a sensor, etc., a signal may instruct such equipment to transmit information upstream and/or downstream, change an acquisition parameter, change a control parameter, etc.

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.

The method 700 is shown in FIG. 7 in association with various computer-readable media (CRM) blocks 711, 721, 731, 741, and 751. 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 the method 700. 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 such as the memory 794 of the system 790 and can be executable by one or more of the processors 793 of the system 790.

As an example, a method can include receiving information during a drilling operation for a drillstring disposed in a bore in a formation; estimating uncertainty associated with the information; analyzing at least a portion of the information using a physics-based model to generate a result; and computing, via a Bayesian network, a risk probability of the drilling string sticking in the bore in the formation based at least in part on the result and the estimated uncertainty. As mentioned, a method can include issuing a signal based at least in part on a risk probability (see, e.g., FIG. 13 as to a graphic 1350 of probability information, etc.). In such an example, the Bayesian network can include a risk of differential sticking component and a risk of pack-off sticking component and, for example, a potential for differential sticking component. In such an example, a method can include determining potential for differential sticking via the differential sticking component prior to performing the drilling operation.

As an example, a method can include computing a risk probability during a drilling operation. As an example, a physics-based model can be one or more of a torque and drag model, a hydraulics model, and a geomechanics model. As an example, a method can include receiving information that is drilling fluid information, which can be mud information where mud is a drilling fluid.

As an example, a method can include determining at least one cause of a risk probability. As an example, a method can include determining at least one action to mitigate a risk probability (e.g., reduce the probability of the risk). In such an example, at least one action can include an action that aims to prevent cuttings from packing off around the drillstring. In such an example, the action can be an action that is at least one of increasing rotation rate and increasing circulation rate to clean the bore. In such an example, an action can include associated parameters that decrease likelihood of creating a hole or washout.

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: receive information during a drilling operation for a drillstring disposed in a bore in a formation; estimate uncertainty associated with the information; analyze at least a portion of the information using a physics-based model to generate a result; and compute, via a Bayesian network, a risk probability of the drilling string sticking in the bore in the formation based at least in part on the result and the estimated uncertainty. Such a system may include instructions to issue one or more signals based at least in part on one or more risk probabilities.

As an example, one or more computer-readable storage media can include processor-executable instructions to instruct a computing system to: receive information during a drilling operation for a drillstring disposed in a bore in a formation; estimate uncertainty associated with the information; analyze at least a portion of the information using a physics-based model to generate a result; and compute, via a Bayesian network, a risk probability of the drilling string sticking in the bore in the formation based at least in part on the result and the estimated uncertainty. In such an example, instructions can be included to issue a signal or signals based at least in part on one or more risk probabilities.

FIG. 8 shows some example events 800 that include differential sticking, geopressure, unconsolidated zone, fracture or faulted zone, undergauge hole, and seating. As shown in FIG. 8, the example events 800 can be associated with interactions between a drillstring and a formation, drillstring related operations and a drillstring, drillstring related operations and a formation, etc.

FIG. 9 shows some example events 900 that include reactive formation, mobile formation, collapsed casing, junk in hole, cement-related and drillstring vibration. As shown in FIG. 9, the example events 900 can be associated with interactions between a drillstring and a formation, drillstring related operations and a drillstring, drillstring related operations and a formation, etc.

FIG. 10 shows some example events 1000 that include a wellbore geometry event and a poor hole cleaning event. As shown in FIG. 10, the example events 1000 can be associated with interactions between a drillstring and a formation, drillstring related operations and a drillstring, drillstring related operations and a formation, etc.

As an example, loose or unconsolidated formation sands or gravels can collapse into a borehole and pack-off a drillstring as supporting rock is removed by a bit. Schists, laminated shales, fractures and faults can create loose rock that caves into the hole and jam a drillstring. As an example, one or more of such factors may be taken into consideration by a framework such as the framework 600 (e.g., as inputs, models, etc.).

In regions where tectonic stresses are high, rock is being deformed by movement of the Earth's crust. In such areas, the rock around a bore may collapse into the bore. In some cases, hydrostatic pressure to stabilize a hole may be much higher than the fracture initiation pressure of exposed formations. As an example, one or more of such factors may be taken into consideration by a framework such as the framework 600 (e.g., as inputs, models, etc.).

As an example, a mobile formation (e.g., salt or shale) can behave in a plastic manner. When compressed by overburden, material may flow and squeeze into a bore, thereby constricting or deforming the hole and trapping the tubulars. As an example, one or more of such factors may be taken into consideration by a framework such as the framework 600 (e.g., as inputs, models, etc.).

As an example, overpressured shales can be characterized by formation pore pressures that exceed normal hydrostatic pressure. Insufficient mud weight in these formations may permit a hole to become unstable and collapse around pipe. As an example, one or more of such factors may be taken into consideration by a framework such as the framework 600 (e.g., as inputs, models, etc.).

Reactive shales and clays tend to absorb water from drilling fluid. Over time—ranging from hours to days—they can swell into a bore. As an example, one or more of such factors may be taken into consideration by a framework such as the framework 600 (e.g., as inputs, models, etc.).

As an example, drillstring vibration may cause caving of a bore. Such cavings can pack around a pipe, causing it to stick. Downhole vibration may be controlled by monitoring parameters such as weight on bit, rate of penetration and rotary speed, which can be adjusted from a driller's console or, for example, via issuance of one or more signals from a framework. As an example, one or more of such factors may be taken into consideration by a framework such as the framework 600 (e.g., as inputs, models, etc.).

As an example, differential sticking may happen when a drillstring is held against a bore by hydrostatic overbalance between bore pressure and pore pressure of a permeable formation. Such an issue may occur when a stationary or slow-moving drillstring contacts a permeable formation, and where a thick filtercake is present. As an example, a depleted reservoir may be a cause of differential sticking. As an example, one or more of such factors may be taken into consideration by a framework such as the framework 600 (e.g., as inputs, models, etc.).

As an example, keyseating can take place when rotation of a drillpipe wears a groove into the borehole wall. When the drillstring is tripped, the bottomhole assembly (BHA) or larger-diameter tool joints can be pulled into the keyseat and become jammed. A keyseat may also form at the casing shoe if a groove is worn in the casing or the casing shoe splits. Such an issue can occur at abrupt changes in inclination or azimuth, for example, while pulling out of the hole and after sustained periods of drilling between wiper trips. Wireline logging tools and cables may be susceptible to keyseating. As an example, one or more of such factors may be taken into consideration by a framework such as the framework 600 (e.g., as inputs, models, etc.).

As an example, an undergauge hole may develop while drilling hard, abrasive rock. As the rock wears away the bit and stabilizer, the bit drills an undergauge, or smaller than specified, hole. When a subsequent in-gauge bit is run, it can encounter resistance in the undergauge section of hole. If a string is run into a hole too quickly or without reaming, a bit can jam in the undergauge section. Such an issue may occur when running a new bit, after coring, while drilling abrasive formations, when a PDC bit is run after a roller cone bit, etc. As an example, one or more of such factors may be taken into consideration by a framework such as the framework 600 (e.g., as inputs, models, etc.).

As an example, cement blocks may pack-off a drillstring, for example, when hard cement around a casing shoe breaks off and falls into a new openhole interval drilled out from under casing. Uncured, or green, cement may trap a drillstring after a casing job. For example, when the top of cement is encountered while tripping in the hole, a higher than expected pressure surge may be generated by a BHA, causing the cement to set instantaneously around the BHA. As an example, one or more of such factors may be taken into consideration by a framework such as the framework 600 (e.g., as inputs, models, etc.).

As an example, a collapsed casing can occur when pressures exceed a casing collapse pressure rating or when casing wear or corrosion weakens the casing. The casing may also buckle as a result of aggressive running practices. Such conditions may be discovered when a BHA is run in the hole and hangs up inside the casing. As an example, one or more of such factors may be taken into consideration by a framework such as the framework 600 (e.g., as inputs, models, etc.).

As an example, one or more hole cleaning problems may prevent solids from being transported out of a bore. When cuttings settle at the low side of deviated wellbores, they may form layered beds that may pack around a BHA. Cuttings and cavings may also slide down an annulus when pumps are turned off, thus packing around a drillstring. Such issues may occur due to one or more of low annular flow rates, inadequate mud properties, insufficient mechanical agitation and short circulation time. As an example, one or more of such factors may be taken into consideration by a framework such as the framework 600 (e.g., as inputs, models, etc.).

As mentioned, a framework, which can be a computational framework, can include one or more Bayesian networks. A Bayesian network, Bayes network, belief network, Bayes(ian) model or probabilistic directed acyclic graphical (DAG) model is a probabilistic graphical model (a type of statistical model) that represents a set of random variables and their conditional dependencies via a directed acyclic graph (DAG). For example, a Bayesian network may represent the probabilistic relationships between sticking as a result and causes of sticking. Given causes of sticking as related to conditions, a network can be used to compute the probabilities of the presence of various results (e.g., sticking).

As mentioned, a network can include nodes and arcs where arcs may be assigned weights. As mentioned, such weights may determine, at least in part, how acquired data impacts an outcome. As mentioned one or more weights may be adjustable, optionally based on data (e.g., one or more real-world outcomes, etc.).

Bayesian networks can be DAGs whose nodes represent random variables in the Bayesian sense: they may be observable quantities, latent variables, unknown parameters or hypotheses. Edges can represent conditional dependencies; nodes that are not connected (there is no path from one of the variables to the other in the Bayesian network) represent variables that are conditionally independent of each other. Each node can be associated with a probability function that takes, as input, a particular set of values for the node's parent variables, and gives (as output) the probability (or probability distribution, if applicable) of the variable represented by the node. For example, if m {\displaystyle m} m parent nodes represent m {\displaystyle m} m Boolean variables then the probability function could be represented by a table of 2 m {\displaystyle 2̂{m}} 2̂{m} entries, one entry for each of the 2 m {\displaystyle 2̂{m}} 2̂{m} possible combinations of its parents being true or false.

Various algorithms may perform inference and learning in Bayesian networks. Bayesian networks that model sequences of variables may be referred to as dynamic Bayesian networks. Generalizations of Bayesian networks that can represent and solve decision problems under uncertainty may be characterized as influence diagrams.

An influence diagram (ID) can be a relatively compact graphical and mathematical representation of a decision situation that is a generalization of a Bayesian network, in which probabilistic inference problems and decision making problems (e.g., following the maximum expected utility criterion) can be modeled and solved.

An ID can be a directed acyclic graph (DAG) with three types (plus one subtype) of node and three types of arc (or arrow) between nodes. Nodes can include decision nodes, corresponding to each decision to be made; uncertainty nodes, corresponding to each uncertainty to be modeled; deterministic nodes, corresponding to a special kind of uncertainty that its outcome is deterministically known whenever the outcome of some other uncertainties are also known; and value nodes, corresponding to each component of additively separable Von Neumann-Morgenstern utility function.

An influence diagram can include arcs such as functional arcs (ending in value node) that indicate that one of the components of additively separable utility function is a function of all the nodes at their tails; conditional arcs (ending in uncertainty node) that indicate that the uncertainty at their heads is probabilistically conditioned on all the nodes at their tails; conditional arcs (ending in deterministic node) that indicate that the uncertainty at their heads is deterministically conditioned on all the nodes at their tails; and informational arcs (ending in decision node) that indicate that the decision at their heads is made with the outcome of all the nodes at their tails known beforehand.

As an example, decision nodes and incoming information arcs can collectively state alternatives (e.g., what can be done when the outcome of certain decisions and/or uncertainties are known beforehand). As an example, uncertainty/deterministic nodes and incoming conditional arcs can collectively model information (e.g., what are known and their probabilistic/deterministic relationships). As an example, value nodes and incoming functional arcs can collectively quantify a preference (e.g., how things are preferred over one another).

In an ID, alternative, information, and preference are termed decision basis in decision analysis, as they represent three components of a valid decision situation.

An influence diagram representing a situation where a decision-maker is planning their vacation can include a decision node (Vacation Activity), uncertainty nodes (Weather Condition, Weather Forecast), and a value node (Satisfaction). In such an example, functional arcs (ending in Satisfaction), a conditional arc (ending in Weather Forecast), and an informational arc (ending in Vacation Activity) can be included. Functional arcs ending in Satisfaction indicate that Satisfaction is a utility function of Weather Condition and Vacation Activity. In other words, their satisfaction can be quantified if they know what the weather is like and what their choice of activity is (note that they do not value Weather Forecast directly). A conditional arc ending in Weather Forecast indicates their belief that Weather Forecast and Weather Condition can be dependent. An informational arc ending in Vacation Activity indicates that they will know Weather Forecast, not Weather Condition, when making their choice. In other words, actual weather will be known after they make their choice, and forecast is what they can count on at this stage. In the foregoing example, it follows semantically, for example, that Vacation Activity is independent on (irrelevant to) Weather Condition given Weather Forecast is known.

As an example, a Bayesian network can include accounting for uncertainty in probabilistic inference, node absorption, sensitivity analysis, etc. As an example, a value may be classified as an uncertain value or a type of uncertain value. For example, different types of uncertain values can be accounted for and propagated accordingly in a Bayesian network. As an example, a type of uncertainty can be specified via a Gaussian approach such as, for example, via a mean and a standard deviation. As an example, uncertainties in measurements from one or more sensors may be expressed with a ± notation and indicate a Gaussian distribution. As another example, an uncertain value may be expressed as an interval with one or more of a lower endpoint and an upper endpoint (e.g., 0≤X<10) where a likelihood within the interval is one and a likelihood outside the interval is zero. As yet another example, consider an unbounded Interval, which may, for example, extend to a very large number or to a known maximum value or minimum value for the variable. In such an example, a likelihood within the interval can be one and a likelihood outside the interval can be zero. Another example of uncertainty is a set of possibilities where, for example, {s1, s2, . . . sn} can be a set where each si is a state name. Such a set may be, for example, unbounded interval or Gaussian as well. As an example, consider {lo, med} and {red, blue, green}. As an example, a type of uncertainty can be a set of impossibilities. Various other types of uncertainties can include likelihood (e.g., s1 p1, s2 p2, . . . sn pn) (e.g., {flow above X 0.8, flow below X 0.3}). As an example, arbitrary likelihood distributions for continuous variables can be formed by a series of adjacent intervals, each with its own probability. Or, for example, elements may overlap where their likelihoods may be combined. For example, {[0,10] 0.1, [2,4] 0.2} can be the combination of a rect function extending from 0 to 10 with height 0.1, and another rect from 2 to 4 with a height of 0.2. Another type of distribution can be a weighted combination of Gaussians. For example, {3+−1 0.2, 7+−2 0.4} can be a bi-modal distribution with peaks at 3 and 7. As an example, a method can include mixing weighted Gaussians, intervals, and discrete states within a single { . . . } likelihood vector. As an example, yet another type of uncertainty can involve relative likelihood. As an example, a type of uncertainty may be complete uncertainty, which may be utilized for missing information, faulty equipment (e.g., a faulty sensor, etc.).

As an example, a system can be a drilling event analysis system, which can include an analysis engine, which may include a Bayesian network. As an example, consider the APACHE STORM engine (Apache Software Foundation, Forest Hill, Md.). As another example, consider the NETICA framework (Norsys Software Corp., Vancouver, Canada).

As an example, a method can include identifying one or more types of events by implementing a topology that includes a directed acyclic graph. For example, the APACHE STORM application can include utilization of a topology that includes a directed acyclic graph (DAG). A DAG can be a finite directed graph with no directed cycles that includes many vertices and edges, with each edge directed from one vertex to another, such that there is no way to start at any vertex v and follow a consistently-directed sequence of edges that eventually loops back to v again. As an example, a DAG can be a directed graph that includes a topological ordering, a sequence of vertices such that individual edges are directed from earlier to later in the sequence. As an example, a DAG may be used to model different kinds of information.

Risk probability may be described as a measure of the likelihood that the consequences described in a risk statement will occur and may be expressed, for example, as a numerical value. For example, risk probability can be greater than zero where a risk poses a threat and, for example, risk probability can be less than 100 percent where it is other than a certain problem (e.g., a known problem).

Probabilistic risk assessment or PRA involves evaluation of risks associated with the use of various types of technology, which can include associated implementation of various techniques. As an example, risk may be characterized by two quantities: Magnitude of Severity (e.g., intensity or seriousness of the situation) and Probability of Occurrence (e.g., chance a high risk event could occur, which may be in part based on historical occurrences of similar events). Whether or not it is feasible to invest in the risk of concern may be determined based on the probability of the event and its severity. For example, risk being equal to a product of frequency and consequence.

As an example, a physics-based model approach can enhance PRA through use of information such as real-time data that can be input to one or more physics-based models. Such an approach can help to address low frequency and high consequence events. As an example, a framework may assess information and/or results with respect to underlying uncertainty, which may be characterized as to quantifiability, and linked with estimation of probability.

As an example, a framework can provide for generation of one or more probability and impact matrixes that can uses a combination of probability and impact scores of individual risks and rank/prioritize them to help to determine which risks need detailed risk response plans (e.g., actions, etc.).

Likelihood can refer to the possibility of a risk potential occurring measured in qualitative values such as low, medium, or high. Likelihood can be a qualitative assessment that is subjective (e.g., possibly with little objective measurement).

Probability can refer to the percentage of possibilities that one or more foreseen outcomes will occur based on parameters of values. Probability can be a quantitative measurement of outcome (e.g., there is a 70% chance of rain tomorrow).

Probabilities may be utilized where information may be limited. A probability assessment can provide a level of uncertainty about a risk event occurring. Scoring on a scale of low, medium, high may provide little valuable information about the occurrence uncertainties. A probability can provide information that can be actionable by a machine and/or a person for making one or more decisions. Perfect information about risk removes uncertainty.

As an example, a computational framework such as the framework 600 of FIG. 6 may be implemented to perform one or more methods. As an example, a method can include receiving data from one or more field operations and transmitting output based at least in part on the received data. As an example, a framework may be interactive such that a method can be interactive. For example, a method can include receiving information that may be generated by a computing device operatively coupled to a display that can render one or more graphical user interfaces (GUIs) that include one or more graphical controls (e.g., actuatable features that, when actuated, cause a command, a signal, etc. to be generated, which may be transmitted).

FIG. 11 shows an example of a method 1100 that includes a login block 1110, a render block 1120 for rendering a multi-well dashboard (see, e.g., a graphical user interface 1200 of FIG. 12, etc.), a selection block 1130 for selecting an alerted well (e.g., as may be indicated via the GUI 1200, etc.), a render block 1140 for rendering a stuck pipe quick view graphical user interface (see, e.g., a graphical user interface 1300 of FIG. 13, etc.), and a render block 1150 for rendering a stuck pipe drilldown analysis graphical user interface (see, e.g., a graphical user interface 1400 of FIG. 14, etc.). The method 1100 may be implemented at least in part via a computational framework such as, for example, the framework 600 of FIG. 6.

As shown in FIG. 11, the method 1100 (e.g., or workflow) may include interactions with various blocks. For example, the block 1150 may continue at the block 1120 or the block 1140. As an example, a system can include a plurality of GUIs that can be rendered to one or more displays, simultaneous, sequentially, etc. A user may interact with one or more GUIs as part of a monitoring process for a plurality of wells (e.g., rigsites). In such an example, the user may address one or more alerts, statuses, etc., that are based on data received from equipment at one or more wells (e.g., rigsites). As to GUIs, as mentioned, FIGS. 12, 13 and 14 show example GUIs 1200, 1300 and 1400, respectively.

As to the render block 1140, a GUI may render contextual information, historical trends, observables in a multi-pass manner, etc. As an example, a rendered GUI may include information that helps to address a cause of stuck pipe or a risk of a pipe sticking. For example, a GUI may render information that allows a user to answer a question “where is it coming from” as to sticking or risk of sticking. In response, a system can include rendering information as to one or more actions that can be taken to solve a sticking problem and/or to reduce risk of sticking. As an example, a system may issue one or more signals to one or more pieces of equipment (e.g., rigsite equipment, field equipment, etc.) to address sticking or a risk of sticking. In such an example, the one or more signals may be issued via one or more network interfaces of the system. As an example, a signal may be issued automatically. As an example, a signal may be issued responsive to receipt of input via a GUI such as, for example, via receipt of an actuation signal as to one or more graphical controls that cause the system to issue a corresponding signal. In such an example, input may be via a pointing device (e.g., mouse, trackball, etc.), via a voice command (e.g., via a microphone of the system), via a touch (e.g., a trackpad, a keystroke, a touchscreen display, etc.), etc.

As to the render block 1150, a GUI may include an analysis tab and a “what if?” tab for various functionalities, features, etc., that can be performed at least in part by a system. For example, a GUI may include analysis information such as a time plot, a depth plot, a synchronization log with a bottom hole assembly (BHA), a broomstick plot, a scatter plot, etc. Such information may allow a user and/or a system to drilldown as to why sticking has occurred, is occurring and/or might occur (e.g., where conditions may exist that give rise to an elevated risk of sticking, etc.). As an example, a GUI may provide for rendering of evidence gathered by a system, where such evidence may be data, modeled data, simulation data, historical data, etc., as associated with sticking. As to a “what if?” analysis, a system may allow for interactions via one or more GUIs as to a variety of scenarios. In such an example, a user may assess results for one or more scenarios to understand better one or more actions to take with respect to field operations at one or more wells (e.g., one or more rigsites). For example, consider a scenario that utilizes a particular rate of penetration (ROP) or scenarios that utilize a range of rates of penetrations (ROPs) for one or more drilling operations. In such an example, the system may calculate information such as hole cleaning information (e.g., a hole cleaning index (HCI), etc.) where hole cleaning is a physical factor related to sticking.

As an example, a system (e.g., a computational framework, etc.) may generate one or more graphics, optionally in the form of videos (e.g., animations) that can show an approximate graphical view of a drillstring (e.g., BHA, etc.) in a subterranean environment that is being drilled. For example, consider FIG. 10 and the poor hole cleaning graphic, which illustrates cutting being accumulated in a lower portion of an annular region between a drillstring (e.g., BHA) and a borehole. In such an example, where cuttings are not “cleaned” away upwardly, risk of sticking can increase and/or sticking may occur. FIG. 10 also shows curvature of the borehole along with some amount of curvature of the drillstring. In such an example, factors such as BHA equipment, trajectory from a well plan, etc., can be taken into account in an analysis, which, as mentioned, may be part of a “what if?” analysis that aims to arrive at a course of action to take in the field to reduce risk of getting stuck and/or unstick a drillstring in a borehole. As an example, a system may include storing information as to successful scenarios for particular conditions where, for example, given such conditions in the future (e.g., according to a well plan, real-time data, etc.), the system may provide one or more recommendations as to one or more particular actions that can be taken to address one or more sticking related problems.

As shown in FIG. 11, the render block 1150 for stuck pipe drilldown analysis can include outputting one or more actionable recommendations. As mentioned, a system may issue one or more signals via one or more interfaces (e.g., network interfaces, etc.) where such one or more signals are commands, provide information, etc. that is received by one or more pieces of equipment that are thereby controlled at least in part thereby. For example, consider a ROP recommendation where a top drive may be instructed to operate in a particular manner to control ROP. As another example, consider a mud flow recommendation where a mud pump may be instructed to operation in a particular manner to control flow of mud (e.g., drilling fluid). As mentioned, hole cleaning can be a factor as to sticking and, for example, increasing flow of drilling fluid by increasing a pump rate of a mud pump may help to clean at least a portion of a borehole of cuttings. As shown in FIG. 10, such a portion may be at or near a BHA where a BHA may be in a curved portion of a borehole where an annular region about the BHA may tend to establish one or more fluid flow paths (e.g., with respect to gravity, etc.) that may give rise to one or more types of cleaning issues (e.g., flow being more prominent in one portion of an annular region as cutting settle under the influence of gravity in another portion of the annular region, etc.).

FIG. 12 shows an example of the GUI 1200 as mentioned with respect to FIG. 11. As shown, the GUI 1200 includes various features including an alert field that includes one or more graphical controls (e.g., dismiss, acknowledge, view, acknowledge and view, etc.). The GUI 1200 includes information such as well name, measured depth (MD), bit depth (BD), rig state (e.g., Pull Up), next survey (e.g., date, time, etc.), last survey (e.g., MD, INCL, AZI, etc.), rig connection, action, alert, type of alert, etc. As shown, the GUI 1200 can be an operations dashboard and may include a query field such that a query may be entered to search for information. For example, a user may enter a query as to a well name, as to depth, as to state, as to survey, etc. where the GUI 1200 then receives search results from a system that performs the query, noting that the GUI 1200 may be part of that system, whether locally or remotely (e.g., via a web browser interface, etc.). In the example of FIG. 12, the GUI 1200 can be a multi-well dashboard. As shown, two well names are present while one of the wells has associated information illustrated in the GUI 1200.

FIG. 13 shows an example of the GUI 1300 as mentioned with respect to FIG. 11. The GUI 1300 includes a panel 1310 where surfaces representations 1312 and 1314 are rendered along with well trajectories where a location 1316 can be selected, for example, via a touch to a touchscreen, a pointing device that controls a cursor, etc. In the example of FIG. 13, the panel 1310 may be akin to the panel 510 of the GUI 500 of FIG. 5 (e.g., as to well planning, etc.). The GUI 1300 of FIG. 13 also shows a graphical representation of a drillstring (e.g., a BHA, etc.) 1330 where a portion 1336 may be selected. FIG. 13 also shows a graphic 1350 of probabilities versus level of risk of sticking. As an example, the graphic 1350 can correspond to a selected location such as the selected location 1316 or, for example, to a portion of a drillstring such as the selected portion 1336. In such an example, an operator may interrogate a scenario as to risk of sticking for a location along a trajectory and/or with respect to a piece of equipment of a drillstring with respect to one or more locations along a trajectory. As an example, the graphical representation of the drillstring 1330 may include coding such that levels of risk are highlighted to indicate what portion or portions of the drillstring may be a cause of a particular level of risk. For example, a high level of risk may be associated with one or more pieces of equipment that make up a portion or portions of the drillstring. Such levels of risk may be associated with one or more of physical dimensions of a piece of equipment and/or one or more of operational parameters of a piece of equipment. Where a level of risk is associated with an operational parameter or operational parameters, an operator may interrogate further to understand what parameter value or values may be a cause or a possible solution to diminish risk of sticking where a control signal may be issued to equipment that controls one or more portions of the drillstring to diminish the risk of sticking during one or more field operations.

As shown in FIG. 13, the panel 1310 may render multiple trajectories where, for example, one of the trajectories may be active or highlighted as corresponding to a selected well, which may be selected, for example, based at least in part on an indicator being generated by a computational framework (see, e.g., FIG. 6, FIG. 15, FIG. 21, etc.). As mentioned, a computational framework can include one or more Bayesian networks, which may, for example, be implemented via processor-executable instructions that are executable by one or more processors to generate one or more Bayesian networks and related calculations for determining information such as information associated with sticking of equipment in a borehole in a geologic environment, etc. As an example, output of such a computational framework may be in the form of probability versus level of risk of sticking (e.g., for a plurality of predefined risk levels, etc.). As an example, such information may be output with respect to one or more of depth (e.g., bit depth, measured depth, total vertical depth, etc.), equipment, etc.

As mentioned, regarding uncertainty, a computational framework can estimate values of indicators and of risk as well as uncertainty. As an example, uncertainty may be represented in one or more different manners. For example, consider a mean and standard deviation or a portion of a probability distribution or a full probability distribution (e.g., consider a vector of numbers representing the probability that the risk is a certain amount). As an example, a computational framework can include storing an uncertainty metric for one or more indicators as well as computing a full probability distribution of risk. In such an example, consider an indicator such as amount of break-over torque, which may have an associated standard deviation as an uncertainty metric. As shown in the example of FIG. 13, the graphic 1350 includes a distribution, which may be a full distribution with respect to risk as a dimension (e.g., levels of risk). Thus, as an example, a computational framework may output a single number for risk (e.g., risk of getting stuck is 95%) and/or may output a distribution (e.g., at least a portion of a distribution). As an example, a Bayesian network of a computational framework may output a distribution such as the distribution in the graphic 1350 of the GUI 1300 of FIG. 13. As mentioned, such a graphic may be interactive in that input can be received to facilitate identification of one or more causes of a probability of the distribution (e.g., as an equipment characteristic, as an operational condition, as a trajectory characteristic, as a formation characteristic, etc.).

As to the framework 600 of FIG. 6 and/or the system 1500 of FIG. 15 and/or the system 2100 of FIG. 21, uncertainty can be computed and passed from one component to another. For example, a mean and a standard deviation may be computed for sensor data as input where the mean and standard deviation are passed along and into one or more Bayesian networks. In such an example, the standard deviation can be an uncertainty metric and output of a Bayesian network can be a probability distribution that is based at least in part on such an uncertainty metric. In such a manner, uncertainties can be estimated and taken into account to provide output as to one or more indicators associated with drilling operations (e.g., indicators relevant to sticking, unsticking, etc.).

As an example, the GUI 1300 may render historical, future and/or present information. As an example, a time line may be presented as to data acquired and analysis results thereof.

As mentioned, the GUI 1300 may aim to help answer a question “where is sticking or risk of sticking coming from?” or, “what is the cause of sticking or risk of sticking?”. The GUI 1300 can present contextual information, one or more historical trends of potential and observable multi-pass types of information, etc. As an example, the GUI 1300 may present information based on a plurality of wells, which may be wells in a common field (e.g., a common type of formation, etc.). Such information may be multi-pass in that each of the plurality of wells represents a pass through particular rock(s) in a subterranean environment (e.g., a type or types of formations). In such an example, information for one or more wells may be for a common reservoir that is to be produced by a plurality of wells. As an example, a user may transition from the GUI 1300 to the GUI 1400 of FIG. 14 where, for example, one or more features of the GUI 1400 may be utilized for purposes of analysis (e.g., further analysis, etc.).

FIG. 14 shows an example of the GUI 1400 as mentioned with respect to FIG. 11. In the example GUI 1400, various fields are shown for various types of performance information as to drilling of a well or wells. In the example of FIG. 14, the GUI 1400 shows information for a particular well having a well name, which may be a selected well from a plurality of wells (e.g., selected via interactions with a GUI, selected by a system as having an issue, etc.). As shown, the GUI 1400 can include log information which may include operational log information (e.g., ROP, HKLD, etc.) and/or one or more other types of log information. As an example, log information can include sensor information as to measurement while drilling (MWD) and/or logging while drilling (LWD) operations. As an example, log information can include sensor information as to one or more operations of a BHA in a downhole environment. For example, consider vibration information as to vibrations experienced by a BHA during one or more drilling operations.

The GUI 1400 may be rendered along with various types of gathered information (e.g., gathered evidence from one or more sources). As an example, the GUI 1400 can include a “what if?” graphical control that can be actuated to allow a user to understand better one or more scenarios as to the well where a system may output one or more actionable recommendations (e.g., to follow one or more of the scenarios, etc.).

FIG. 15 shows an example of a system 1500 that is illustrated with various example workflows. As an example, the system 1500 can be or include a computational framework. As an example, the system 1500 can include one or more features of the framework 600 of FIG. 6 and, for example, the framework 600 of FIG. 6 can include one or more features of the system 1500 of FIG. 15.

As shown, the system 1500 can include various operational blocks including, for example, a contextual information block 1514, a channel data block 1514, a hydraulics engine block 1522 (e.g., for modeling hydraulic phenomena based at least in part on contextual information and/or channel data, etc.), a stationary time computation block 1524 (e.g., in a BOT detection function, etc.), a results block 1532, an output block 1534 (e.g., displayable output results, etc.), a channel block 1540 (e.g., as to information acquired at a data rate for one or more conditions, etc.), a contextual information block 1552, a channel block 1554, a contextual information block 1562 (e.g., for information that can be utilized in one or more potential of differential sticking (PoDS) computations, which may include static and/or changed conditions types of contextual information, etc.), and a differential sticking potential block 1570 that can compute one or more potentials for differential sticking (PoDSs) given various inputs, which include various types of outputs from one or more features of the system 1500.

As shown in the example of FIG. 15, the differential sticking potential block 1570 can include an overbalance pressure computation block 1582 that can output data as to overbalance per a data overbalance block 1584, which can provide such data to a PoDS computation block 1592. As shown in FIG. 15, the data overbalance block 1584 can include information that is based at least in part on output of the hydraulics engine block 1522 along with, for example, information from one or more channels (see, e.g., the channel blocks 1514, 1540, 1554, etc.).

As shown in FIG. 15, the system 1500 can include one or more blocks associated with hole conditions, which may be part of a hole conditions manager (HCM) functionality of the system 1500 (e.g., as an integral part of the system 1500, as a plug-in, as an API accessible function, etc.). As to hole conditions, these can include various types of conditions that may be factors as to sticking or increased risk of a drillstring becoming stuck in a borehole. HCM functionality may provide for dynamically updating one or more wellbore condition models to provide substantially instantaneous display of borehole condition information. A US Patent Application Publication having a Publication No. US20150134257 A1, entitled Automatic Wellbore Condition Indicator and Manager, to Schlumberger Technology Corporation, is incorporated by reference herein (257 publication). The '257 publication provides information as to calculation of hole conditions factors (HCFs), hole conditions indexes (HCIs), etc. HCF is a parameter that may be derived from other parameters related to various hole conditions such as, for example, drag (axial friction between a bore wall and a drillstring), torque applied to a drillstring to effect rotation thereof, equivalent circulating density (ECD, e.g., equivalent density of drilling fluid when moving through a drillstring and wellbore) and equivalent static density (ESD) of the drilling fluid, drilling fluid standpipe pressure (SPP, e.g., pressure at a discharge side of a pump), a hole cleaning index (HCI), Filter Cake Quality, and a Vibration Parameter.

As shown in FIG. 15, the differential sticking potential block 1570 can include computing various types of HCM interpretations as outputs per the output blocks 1594 and 1596. As shown, one or more outputs may be outputs for a Bayesian Network (BN) and one or more outputs may be outputs for rendering to a display or displays.

As an example, the system 1500 may be utilized to implement at least a portion of the method 700 of FIG. 7. As shown in FIG. 7, the method 700 includes an analysis block 730 that utilizes a physics-based model and includes a compute block 740 that utilizes a Bayesian network (BN). As an example, the system 1500 may include one or more features of the system 790 of FIG. 7.

As an example, the system 1500 may provide for one or more functionalities of the framework 600 of FIG. 6, which includes, for example, the hydraulics model 654 (see, e.g., the hydraulics engine block 1522), which may output information as to a hole cleaning index (HCI), which may be utilized for one or more purposes.

The framework 600 of FIG. 6, as mentioned, includes a stationary time determination component 614, which may take as input one or more rigstates and that may output information to the potential for differential sticking component 672 (e.g., a PoDS component).

As shown in the example of FIG. 6, the framework 600 can include the amount of overbalance component 644 that receives input from the hydraulics model 654 (e.g., a hydraulics engine) where the amount of overbalance component 644 can output information to the potential for differential sticking component 672. As shown in the example of FIG. 6, the framework 600 can include a risk of getting differentially stuck component 682 that receives input from the potential for differential sticking component 672 and, for example, information as to torque (e.g., torque and drag). As mentioned, the system 1500 of FIG. 15 and the framework 600 of FIG. 6 may include one or more common features and may be considered examples of various types of systems, frameworks, etc. that can provide for drillstring sticking management (e.g., and optionally control, etc.).

FIG. 16 shows an example of a method 1600 and examples of graphical user interfaces 1612, 1622 and 1632. In the example of FIG. 16, the method 1600 includes a measurement block 1610 for acquiring measurements (e.g., measurement information, data, etc.); an indicators block 1620 for generating indicators (see, e.g., a stuck pipe indicator as a solid black line that crosses the GUIs 1612, 1622 and 1632); and a Bayesian network block 1630 for outputting information such as, for example, risk of sticking information, which may be classified into different categories (e.g., high, medium, low, etc.). As mentioned, where a risk of sticking is high, a method can include identifying one or more causes (e.g., likely causes) of the risk. In such an example, the method may include issuing one or more signals (e.g., an alert as to a cause, a control signal, etc.).

As shown in FIG. 16, the GUI 1632 is coded to indicate high, medium and low levels of probabilities at various times that correspond to times of the plots in the GUIs 1612 and 1622. As mentioned with respect to FIG. 13, output of a computational framework can include probabilities, which may be rendered as in the graphic 1350 of FIG. 13 or, for example, as in the GUI 1632 of FIG. 16. In particular, the GUI 1632 of FIG. 16 shows, for each time, a coded portion of low level, medium level and/or high level. As can be seen in the GUI 1632, for early times, the probability distribution is largely low level (coded white) and then transitions to a region where it is largely a combination of medium level (coded hatched) and high level (coded checkered). The rig then transitions to a region (e.g., a period of time) where there is a relative balance between low level and medium level and then to another region where high level risk increases and, correspondingly, low level risk decreases (e.g., as to probability distribution). As mentioned, a solid black line indicates “stuck pipe”. The time for the stuck pipe can be visually inspected across the GUIs 1612, 1622 and 1632 where output of a computational framework, inputs to the computational framework and/or intermediate results of the computational framework can be examined (e.g., interrogated) as to one or more causes of the stuck pipe. Per the GUI 1612, factors such as hook load (HKLD), flow rate, downhole equivalent circulating density (ECD), surface torque may be considered as one or more contributing factors to an elevated level of risk as illustrated in the GUI 1632; noting that one or more other factors may be considered, alternatively or additionally.

As to hook load, it can be a sensor value or sensor values acquired by a sensor or sensors at a rigsite that measure (e.g., sense) force pulling down on a hook (see, e.g., the traveling block 211, the crown block 173, 213, the top drive 240, etc.). The force may be a total force that includes the weight of the drillstring in air, the drill collars and any ancillary equipment, reduced by force(s) that tend to reduce that weight. For example, some examples of forces that might reduce the weight include friction along a borehole wall (e.g., especially in deviated wells) and buoyant forces on the drillstring caused by its immersion in drilling fluid. As hook load can be associated with friction, hook load can be a factor that can be taken into account in one or more calculations as to sticking, unsticking, etc. As mentioned, hook load can depend on buoyant forces, which can be associated with drilling fluid (e.g., mud). As such, one or more characteristics of drilling fluid (e.g., density, circulating density, etc.) may be related factors that can be taken into account in one or more calculations as to sticking, unsticking, etc.

As mentioned, uncertainty information such as in the form of one or more uncertainty metrics may accompany a value (e.g., a measured or sensed value). For example, a standard deviation may accompany a hook load value, which may be estimated (e.g., calculated) via a framework, a system, etc. and/or via equipment that may be rigsite equipment. As an example, a load sensor or load sensors can acquire load data (e.g., hook load data) from which one or more uncertainty metrics can be estimated (e.g., standard deviation, etc.) such that a framework or a system may account for such uncertainty. As mentioned, such uncertainty can be taken into account via one or more Bayesian networks that can output probability information (see, e.g., the GUI 1632 of FIG. 16).

As mentioned, the graphical information of FIG. 16 may correspond to information of the framework 600 of FIG. 6 (e.g., or the system 1500 of FIG. 15, etc.) such that an operator may determine a primary contributing factor (e.g., or other factors) that may provide information as to one or more actions that can be taken in the field, optionally automatically or semi-automatically via issuance of a signal or signals from the framework 600, the system 1500 of FIG. 15, the system 2100 of FIG. 21, etc. As an example, an operator may interact with a framework, a system, etc., to render various GUIs such as a GUI of the framework components of the framework 600 and GUIs as in FIG. 16 where relationships can be examined, for example, to determine one or more causes and/or one or more actions that can mitigate a situation (e.g., stuck pipe, risk of pipe sticking, etc.). As an example, an interrogation as to a cause may progress from risk information to indicator information to measurement information, for example, working backwards in the method 1600 of FIG. 16 (e.g., or in the GUIs 1612, 1622, 1632 and/or the framework components of the framework 600, the system 1500, etc.).

FIG. 17 shows examples of graphical user interfaces 1710 and 1720, which may be part of a common graphical user interface associated with a single well or drilling operations at a single rigsite. As shown, the GUI 1710 includes a plot of depth versus time as to drilling activity where the plot can include data as to bit depth and data as to hole depth. As shown, the GUI 1720 can include information versus depth where the information may be risk information of one or more physical conditions occurring that can cause sticking of at least a portion of a drillstring. As shown in the example of FIG. 17, the GUI 1720 can include highlighting of risk information according to one or more criteria (e.g., levels, etc.). In the example of FIG. 17, an operator at a rigsite or remote from a rigsite may readily assess progress of drilling with respect to time and associate depths, times and risks. For example, an operator may discern that progress has diminished over a range of depths for a certain period of time where risk of sticking was elevated at those depths (see, e.g., depths greater than approximately 3400 and days 11 September and 12 September. During such periods of time, a framework may be outputting the risk information for rendering to a GUI while also outputting one or more signals as to actions, whether recommended and/or control actions. In such an approach, a framework may be dynamically available for one or more operators and/or controllers.

FIG. 18 illustrates examples of graphical user interfaces 1801, 1803, 1805 and 1900 where the GUI 1805 may include a filter control 1807 for filtering information associated with a plurality of sites. As shown in FIG. 18, the GUIs 1801, 1803 and 1805 can be part of a drilldown workflow for selecting one or more sites. As shown, the GUI 1805 can include indicators that show the status of one or more sites. In the example of FIG. 18, a plurality of sites may be selected and provided (e.g., via identifiers, coordinates, etc.) to a framework for rendering associated information to the GUI 1900.

FIG. 19 shows an example of the graphical user interface 1900 as mentioned in FIG. 18. In the example of FIG. 19, the GUI 1900 includes various types of information for a plurality of sites along with various graphical controls that an operator may interact with to cause one or more actions to occur. For example, an operator may review various sites as to indicators such that an indicator may be addressed or dismissed. As shown, a “Go To Well” graphical control may cause a framework to transition from the GUI 1900 of FIG. 19 to, for example, one or more of the GUIs 1710 and 1720 of FIG. 17, which can be individual site GUIs. As mentioned, the GUI 1805 of FIG. 18 can include the graphical control 1807 for purposes of filtering (e.g., selecting one or more sites based on one or more criteria). In the example of FIG. 19, the GUI 1900 includes a series of graphical controls 1905 for “All”, “Group” and “Filter” such that an operator may selectively control information that is rendered via the GUI 1900.

FIG. 20 shows an example of a system 2000 associated with an example of a wellsite system 2001 and also shows an example scenario 2002. As shown in FIG. 20, the system 2000 can include a front-end 2003 and a back-end 2005 from an outside or external perspective (e.g., external to the wellsite system 2001, etc.). In the example of FIG. 20, the system 2000 includes a drilling framework 2020, a stream processing and/or management block 2040, storage 2060 and optionally one or more other features that can be defined as being back-end features. In the example of FIG. 20, the system 2000 includes a drilling workflow framework 2010, a stream processing and/or management block 2030, applications 2050 and optionally one or more other features that can be defined as being front-end features.

As an example, the stream processing and/or management block 2030 of the system 2000 may include one or more features of the framework 600 of FIG. 6 and/or the system 1500 of FIG. 15. As shown in FIG. 20, the scenario 2002 can include receiving various types of information that can include drilling framework information where such information may be processed and output to one or more applications 2052, which can include local and/or remote applications. As an example, output of the stream processing and/or management block 2030 may include one or more signals as to one or more alerts, control signals, etc.

As an example, a user operating a user device can interact with the front-end 2003 where the front-end 2003 can interact with one or more features of the back-end 2005. As an example, such interactions may be implemented via one or more networks, which may be associated with a cloud platform (e.g., cloud resources, etc.).

As to the example scenario 2002, the drilling framework 2020 can provide information associated with, for example, the wellsite system 2001. As shown, the stream related blocks 2030 and 2040, a query service 2085 and the drilling workflow framework 2010 may receive information and direct such information to storage, which may include a time series database 2062, a blob storage database 2064, a document database 2066, a well information database 2068, a project(s) database 2069, etc. As an example, the well information database 2068 may receive and store information such as, for example, customer information (e.g., from entities that may be owners of rights at a wellsite, service providers at a wellsite, etc.). As an example, the project database 2069 can include information from a plurality of projects where a project may be, for example, a wellsite project.

FIG. 21 shows an example of a system 2100 that includes a publishing engine 2111, an interpretation engine 2112, an equipment registry 2113, a data engine 2114 and a communication engine 2115 as well as application programming interfaces (APIs) 2121 and 2131 and operatively coupled databases 2141, 2142, 2143 and 2144.

As an example, the system 2100 of FIG. 21 may include one or more features of the framework 600 of FIG. 6 and/or the system 1500 of FIG. 15. For example, the interpretation engine 2112 may include one or more Bayesian networks that can receiving information and generate output as, for example, one or more signals. As shown in FIG. 21, the system 2100 can include receiving various types of information that can include drilling related information (e.g., via one or more of the APIs 2121 and/or one or more of the databases 2141, 2142, 2143 and 2144, which can include one or more channels of data, etc.) where such information may be processed and output, optionally via one or more the APIs 2131. As an example, output of the system 2100 may include one or more signals as to one or more alerts, control signals, etc.

In the example of FIG. 21, the components 2111, 2112, 2113, 2114 and 2115 can be hosted by a cloud computing platform. As an example, the equipment registry 2113 can be a registry associated with an equipment provisioning framework that may operate, for example, via resources provided in a cloud computing platform. As an example, the equipment registry 2113 can be rig site specific where each rig site includes a dedicated equipment registry. As an example, the system 2100 may include a plurality of equipment registries for a plurality of rig sites.

In the example of FIG. 21, the data engine 2114 may correspond to and/or be operatively coupled to one or more features of the wellsite system 400 of FIG. 4. As shown in the example of FIG. 21, the data engine 2114 can be operatively coupled to one or more of the APIs 2121 and to the equipment registry 2113 (e.g., or registries). As shown, the data engine 2114 can be operatively coupled to the databases 2141 to 2144. Further, the data engine 2114 can be operatively coupled to the publishing engine 2111 and the interpretation engine 2112 as well as, for example, one or more of the APIs 2131.

In the example of FIG. 21, various components may be in a trusted or secure zone where, for example, the APIs 2121 and/or the APIs 2131 provide predefined calls and responses for components in the trusted or secure zone. As an example, the APIs 2131 can expose functionality of one or more components in the trusted or secure zone. For example, a computing device with a browser application may issue an API call to the system 2100 where the system 2100 responds to the API call with information transmitted to the computing device that can be rendered to a display via the browser application. In such an example, the computing device may be prohibited from accessing functionality of components in a trusted or secure zone where such functionality is not exposed via an API defined call.

As an example, the APIs 2121 can be utilized by rig site equipment, for example, for purposes of provisioning, data transmission, control commands, etc. As an example, the APIs 2121 can provide for handshakes between rig site equipment and one or more components of the system 2100 where information may be transmitted before, during or after a handshake.

As an example, the system 2100 can receive drilling framework information from one or more rig sites (e.g., via a system as in FIG. 4) and/or other information from one or more rig sites.

As an example, the interpretation engine 2112 can issue one or more notifications, which may be based on one or more events. For example, the interpretation engine 2112 can receive information, determine an event and issue a notification for that event. As an example, a notification of the interpretation engine 2112 can be issued to one or more destination addresses, for example, according to the communication engine 2115, which may operating according to information in a communication matrix.

As shown in the example of FIG. 21, the interpretation engine 2112 can be implemented for a single site 2116 and/or for multiple sites 2118. For example, the interpretation engine 2112 can include algorithms for handling single site information and algorithms for handling multiple site information. As an example, where the system 2100 receives information for a plurality of well plans the plurality of well plans may be analyzed individually and/or collectively. As an example, a well plan can be a digital well plan for an individual well to be drilled and/or completed and/or a well plan can be a digital master well plan for a plurality of wells to be drilled and/or completed. As an example, a digital master well plan can include information as to equipment and/or other resources (e.g., human resources, power, water, mud, etc.) that may be utilized at a plurality of sites. In such an example, an event that occurs at one site may possibly impact one or more other sites.

As an example, a method can include generating reports using a system such as, for example, the system 2100. As shown in the example of FIG. 21, the publishing engine 2111 may respond to requests received as API calls by generating and issuing one or more reports.

As shown in FIG. 21, the system 2100 can include features for acquiring information about a rig, which can be state information. As an example, a system may operate automatically to determine a state or states based at least in part on information received by the system, which can include information acquired via one or more sensors, one or more devices with input mechanisms for user input, etc. As an example, a report may be generated based at least in part on a state or states (e.g., based at least in part on state information). As an example, a report may be triggered based on a push system and/or a pull system. For example, an oilfield operator may query a system to determine one or more states of the system (e.g., where a state can be a system state, a subsystem state, etc.). As an example, a report may be triggered based on state information, time, or another type of trigger.

As an example, the system 2100 can include receiving data associated with one or more drilling operations, analyzing at least a portion of the data and identifying one or more events and classifying the events. For example, the interpretation engine 2112 can include interpreting information to identify one or more events and to classify the one or more events. In such an example, an event may be classified as being associated with a particular type of performance (e.g., drilling, formation, equipment, etc.) and, for example, may be classified as being a “good” event or a “bad” event, optionally along one or more axes. For example, an axis from bad to good may be utilized and, for example, an associated cost, which may range from negative to positive. Thus, an event may be classified as being good with a positive financial or other type of cost return on achievement of that event. Such an event may be desirable to achieve while drilling. As an example, another type of event may be classified as being bad with a low financial or other type of cost impact. In such an example, avoidance of such an event may be considered to be optional due to low impact on cost; whereas, for example, a bad event with a high financial or other type of cost impact may be assessed for avoidance. Such an assessment may impact a drilling plan, etc., for one or more wells, which are being drilled, being planned to be drilled, etc.

As an example, the interpretation engine 2112 can be or include an inference engine. As an example, an inference engine can use logic represented as IF-THEN rules. For example, consider a format of such rules as IF <logical expression> THEN <logical expression>. IF-THEN statements (e.g., Modus Ponens) can represent various types of logic including, for example, human psychology as humans can utilize IF-THEN types of representations of knowledge. As an example, an inference engine may implement inductive algorithms that can predict a next state (e.g., next event, worsening of an event, improvement of an event, etc.) based upon a given series of information. As an example, an inductive framework can combine algorithmic information theory with a Bayesian framework (e.g., a computational framework that includes at least one Bayesian network).

As an example, the interpretation engine 2112 can be part of the knowledge base, learning and evaluation blocks or operatively coupled thereto. In such an example, the interpretation engine 2112 may receive information from a knowledge base (e.g., one or more sources of information), may learn by training one or more algorithms (e.g., including retraining one or more algorithms), and may evaluate information based at least in part on one or more trained algorithms. As an example, an “expert” may review information output by an interpretation engine where the expert may approve, disapprove, modify, comment, etc. as to such output. In such an example, a mechanism may capture the expert feedback and utilize at least a portion of the feedback for purposes of training the interpretation engine.

As an example, an expert station may be a computing system that is operatively coupled to an interpretation engine that can intervene in operation of the interpretation engine. For example, where output is deemed lacking, input may be received via an expert station to comment on such output, to halt transmission of such output, to cause reinterpretation of information to generate new output, etc.

As an example, a system can be a drilling event analysis system, which can include an analysis engine, which may be a machine learning engine (e.g., Bayesian, etc.). As an example, consider the APACHE STORM engine (Apache Software Foundation, Forest Hill, Md.).

The APACHE STORM engine can be implemented as a distributed real-time computation system. Such a system can receive and process unbounded streams of data. Such a system may provide for real-time analytics, online machine learning, continuous computation, distributed RPC, ETL, etc. Such a system may integrate with one or more queueing and database technologies. As an example, a topology may be constructed that consumes streams of data and processes those streams in one or more manners, optionally repartitioning streams between each stage of computation. As an example, a topology can be constructed as a graph of computation where, for example, a node in a topology includes processing logic, and links between nodes indicate how data may be passed around between nodes.

As an example, data may be available in the WITSML™ standard (Wellsite Information Transfer Standard Markup Language, Energistics, Sugar Land, Tex.) developed as part of an industry initiative to interfaces for technology and applications (e.g., to monitor wells, manage wells, drilling, fracturing, completions, workovers, etc.). For example, a machine learning system can receive data organized in the WITSML™ standard where such data may pertain to one or more of drilling, completions, interventions data exchange, etc. As an example, a system may be operatively coupled to resources associated with one or more entities (e.g., energy companies, service companies, drilling contractors, application vendors, regulatory agencies, etc.). While WITSML™ is mentioned, one or more other types of data schemes may be utilized.

As an example, a method includes receiving information during a drilling operation for a drillstring disposed in a bore in a formation; estimating uncertainty associated with the information; analyzing at least a portion of the information using a physics-based model to generate a result; computing, via a Bayesian network, a risk probability of the drilling string sticking in the bore in the formation based at least in part on the result and the estimated uncertainty; and, based at least in part on the risk probability, issuing a signal. In such an example, the signal can be or include a control signal that controls drilling equipment of the drilling operation or, for example, the signal can be or include an alert (e.g., that causes a computing device, system, equipment, etc. to render information visually, audibly, etc.).

As an example, a method can include, responsive to comparing a risk probability to a threshold, identifying a primary contributing factor to a risk probability. In such an example, a primary contributing factor may be a factor that gives rise to a risk probability being at an elevated level such that if the contributing factor were altered, the risk probability may be below a particular threshold. As an example, a risk probability can include a plurality of contributing factors where such factors may optionally be ranked as to their effect on the risk probability. In such an example, a top ranked factor may be a primary contributing factor and others may be considered secondary (e.g., or tertiary, or related, etc.). As an example, depending on physical phenomena associated with sticking (e.g., or unsticking), one or more factors can be related (see, e.g., FIG. 6, FIG. 15, etc.). As an example, a method can include identifying one or more contributing factors (e.g., and/or ranking, etc.) by progressing backwards through a Bayesian network to identify an input to the Bayesian network. In such an example, the identified input may be further analyzed, for example, by progressing backwards (see, e.g., FIG. 6, FIG. 15, etc.), which may identify one or more associated inputs.

As an example, a method can include implementing a Bayesian network that includes a risk of differential sticking component and a risk of pack-off sticking component (see, e.g., FIG. 6, etc.). In such an example, the Bayesian network can include a potential for differential sticking component. In such an example, a method can include determining potential for differential sticking via the differential sticking component prior to performing a drilling operation.

As an example, a method can include computing (see, e.g., the computation block 740 of the method 700 of FIG. 7) during a drilling operation (see, e.g., the reception block 710 of the method 700 of FIG. 7). In such an example, the method can include issuing one or more signals (see, e.g., the issuance block 750 of the method 700 of FIG. 7) where at least one of the one or more signals actuates at least one piece of equipment associated with the drilling operation, for example, to control an aspect of the drilling operation (e.g., mud flow, rpm of a bit, sensing, etc.).

As an example, a method can include implementing a physics-based model such as a torque and drag model. As an example, a method can include implementing a physics-based model such as a hydraulics model. As an example, a method can include implementing a physics-based model such as a geomechanics model. As an example, a method can include implementing a plurality of physics-based models, which can include one or more of a torque and drag model, a hydraulics model and a geomechanics model.

As an example, a method can include receiving information such as drilling fluid information (see, e.g., the reception block 710 of the method 700 of FIG. 7). In such an example, the drilling fluid information (e.g., mud information, etc.) may be associated with an ability to clean cuttings from a borehole that is being drilled (see, e.g., the example events 1000 of FIG. 10). Such information may pertain to characteristics of the drilling fluid, flow of the drilling fluid, etc.

As an example, a method can include computing that includes determining at least one cause of a risk probability. As mentioned, such a method may include progressing backwards through a network, computational components, etc. to one or more inputs, which may be one or more factors that cause a risk probability to be at a particular level (e.g., at an elevated level, etc.).

As an example, a method can include computing that includes determining at least one action to mitigate a risk probability. In such an example, the action may be associated with one or more identified causes (e.g., contributing factors, etc.) as to a risk probability being at a particular level (e.g., at an elevated level, etc.). In such an example, consider at least one action that includes an action that aims to prevent cuttings from packing off around a drillstring. In such an example, consider an action that is or includes at least one of increasing rotation rate and increasing circulation rate to clean a bore (e.g., of a borehole being drilled, etc.). In such an example, the action can include, for example, associated parameters that decrease likelihood of creating a hole or washout.

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: receive information during a drilling operation for a drillstring disposed in a bore in a formation; estimate uncertainty associated with the information; analyze at least a portion of the information using a physics-based model to generate a result; compute, via a Bayesian network, a risk probability of the drilling string sticking in the bore in the formation based at least in part on the result and the estimated uncertainty; and, based at least in part on the risk probability, issue a signal. In such an example, the system may include instructions suitable for instructing the system to perform one or more actions of one or more methods.

As an example, one or more computer-readable storage media can include processor-executable instructions to instruct a computing system to: receive information during a drilling operation for a drillstring disposed in a bore in a formation; estimate uncertainty associated with the information; analyze at least a portion of the information using a physics-based model to generate a result; compute, via a Bayesian network, a risk probability of the drilling string sticking in the bore in the formation based at least in part on the result and the estimated uncertainty; and, based at least in part on the risk probability, issue a signal. In such an example, the one or more computer-readable storage media may include instructions suitable for instructing the computing system to perform one or more actions of one or more methods.

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.

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.

In some embodiments, a method or methods may be executed by a computing system. FIG. 22 shows an example of a system 2200 that can include one or more computing systems 2201-1, 2201-2, 2201-3 and 2201-4, which may be operatively coupled via one or more networks 2209, which may include wired and/or wireless networks.

As an example, a system can include an individual computer system or an arrangement of distributed computer systems. In the example of FIG. 22, the computer system 2201-1 can include one or more modules 2202, 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.).

As an example, a module may be executed independently, or in coordination with, one or more processors 2204, which is (or are) operatively coupled to one or more storage media 2206 (e.g., via wire, wirelessly, etc.). As an example, one or more of the one or more processors 2204 can be operatively coupled to at least one of one or more network interface 2207. In such an example, the computer system 2201-1 can transmit and/or receive information, for example, via the one or more networks 2209 (e.g., consider one or more of the Internet, a private network, a cellular network, a satellite network, etc.).

As an example, the computer system 2201-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 2201-2, etc. A device may be located in a physical location that differs from that of the computer system 2201-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.

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.

As an example, the storage media 2206 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.

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® disks, or other types of optical storage, or other types of storage devices.

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.

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.

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.

FIG. 23 shows components of a computing system 2300 and a networked system 2310. The system 2300 includes one or more processors 2302, memory and/or storage components 2304, one or more input and/or output devices 2306 and a bus 2308. According to an embodiment, instructions may be stored in one or more computer-readable media (e.g., memory/storage components 2304). Such instructions may be read by one or more processors (e.g., the processor(s) 2302) via a communication bus (e.g., the bus 2308), which may be wired or wireless. The one or more processors may execute such instructions to implement (wholly or in part) one or more attributes (e.g., as part of a method). A user may view output from and interact with a process via an I/O device (e.g., the device 2306). According to an embodiment, a computer-readable medium may be a storage component such as a physical memory storage device, for example, a chip, a chip on a package, a memory card, etc.

According to an embodiment, components may be distributed, such as in the network system 2310. The network system 2310 includes components 2322-1, 2322-2, 2322-3, . . . 2322-N. For example, the components 2322-1 may include the processor(s) 2302 while the component(s) 2322-3 may include memory accessible by the processor(s) 2302. Further, the component(s) 2322-2 may include an I/O device for display and optionally interaction with a method. The network may be or include the Internet, an intranet, a cellular network, a satellite network, etc.

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®, 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.

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).

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.).

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. § 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.

DRILLSTRING STICKING MANAGEMENT FRAMEWORK

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims

RELATED APPLICATIONS

Provisional Applications (1)