multi-domain controller

The computer runtime environment with multi-domain code compilation and the planning domain definition language planner solve the problem of multi-domain information integration during drilling, thereby improving drilling efficiency and the synergy of planning execution.

CN115298623BActive Publication Date: 2026-05-12GEOQUEST SYSTEMS BV
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
GEOQUEST SYSTEMS BV
Filing Date
2021-02-24
Publication Date
2026-05-12

AI Technical Summary

Technical Problem

Existing technologies struggle to effectively integrate information and operations from multiple domains during drilling at resource sites, resulting in low planning and execution efficiency.

Method used

A computer runtime environment that employs multi-domain code compilation receives and dispatches actions to execute physical operations through a domain definition language planner, thereby achieving collaborative planning and control of multiple domains.

Benefits of technology

It improved the efficiency of planning and execution during the drilling process, enhanced the integration of multi-domain information and the synergy of operations, and optimized the development process at the resource site.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115298623B_ABST
    Figure CN115298623B_ABST
Patent Text Reader

Abstract

A method can include, in a runtime environment for compiled multi-domain code describing a plurality of different domains of physical operations performed using equipment, in response to input, issuing a call to a planning domain definition language planner, in response to the call, receiving a plan including at least one action, and dispatching at least one of the at least one action to require performance of at least a portion of at least one of the physical operations.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] Related applications

[0002] This application claims priority and benefit to U.S. Provisional Application No. 62 / 980919, filed on February 24, 2020, which is incorporated herein by reference. Background Technology

[0003] A resource site can be an accumulation, reservoir, or group of reservoirs of one or more resources (e.g., oil, natural gas, petroleum and natural gas) in a subsurface environment. A resource site may include at least one reservoir. The reservoir may be shaped in a manner capable of trapping hydrocarbons and may be covered by impermeable or sealed rock. A borehole may be drilled in the environment, in which a borehole (e.g., a wellbore) can be used to form a well that can be used to produce hydrocarbons from the reservoir.

[0004] A drilling rig can be a component system operable to form a borehole in an environment, transport equipment into or out of the borehole, etc. As an example, a drilling rig may include systems that can be used to drill boreholes and obtain information about the environment, about the well, etc. The resource site can be an onshore site, an offshore site, or an onshore and offshore site. The drilling rig may include components for performing operations onshore and / or offshore. The drilling rig may be, for example, ship-based, offshore platform-based, onshore, etc.

[0005] Site planning and / or development may be carried out through one or more phases, which may include an exploration phase aimed at identifying and assessing the environment (e.g., prospective structures, prospective areas, etc.), which may include drilling one or more boreholes (e.g., one or more exploratory wells, etc.). Summary of the Invention

[0006] A method may include: in a computer runtime environment of compiled multi-domain code describing physical operations performed using equipment, responding to input, issuing a call to a planning domain definition language planner; responding to the call, receiving a plan including at least one action; and dispatching at least one of the at least one actions to request the execution of at least a portion of at least one of the physical operations. A system may include a processor; memory accessible to the processor; processor-executable instructions stored in the memory and executable by the processor to instruct the system to: in a runtime environment of compiled multi-domain code describing physical operations, responding to input, issuing a call to a planning domain definition language planner; responding to the call, receiving a plan including at least one action; and dispatching at least one of the at least one actions to request the execution of at least a portion of at least one of the physical operations. One or more computer-readable storage media may include computer-executable instructions that are executable to instruct a computing system to:, in response to input, issue a call to a planning domain definition language planner in a runtime environment of compiled multi-domain code for multiple different domains describing physical operations; receive a plan including at least one action in response to the call; and dispatch at least one of the at least one actions to request the execution of at least a portion of at least one of the physical operations. Various other devices, systems, methods, etc., are also disclosed.

[0007] This overview is provided to introduce the selection of concepts that will be further described in the detailed description below. This overview is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid to limiting the scope of the claimed subject matter. Attached Figure Description

[0008] The features and advantages of the described implementation can be more easily understood by referring to the following description in conjunction with the accompanying drawings.

[0009] Figure 1 Examples of equipment in geological environments are shown;

[0010] Figure 2 Examples of equipment and well types are shown;

[0011] Figure 3 An example of the system is shown;

[0012] Figure 4 Examples of well site systems and computing systems are shown;

[0013] Figure 5 Examples of equipment in geological environments are shown;

[0014] Figure 6 An example of a graphical user interface is shown;

[0015] Figure 7 An example of the system is shown;

[0016] Figure 8 An example of the code is shown;

[0017] Figure 9 An example of a graphical user interface (GUI) is shown;

[0018] Figure 10 An example of a graphical user interface (GUI) is shown;

[0019] Figure 11 An example of a graphical user interface (GUI) is shown;

[0020] Figure 12 An example of a graphical user interface (GUI) is shown;

[0021] Figure 13 An example of the code is shown;

[0022] Figure 14 An example of the code is shown;

[0023] Figure 15 An example of the method is shown;

[0024] Figure 16 Examples of methods and systems are shown;

[0025] Figure 17 An example of the system is shown;

[0026] Figure 18 An example of a computing system is shown; and

[0027] Figure 19 Example components of the system and network system are shown. Detailed Implementation

[0028] The following description includes the best mode currently anticipated for practicing the described implementation. This description should not be construed in a restrictive sense, but is intended solely for the purpose of describing the general principles of the implementation. The scope of the described implementation should be determined with reference to the published claims.

[0029] Figure 1 An example of geological environment 120 is shown. Figure 1In this context, the geological environment 120 may be a sedimentary basin comprising multiple layers (e.g., stratified), said layers including reservoir 121 and intersecting, for example, through faults 123 (e.g., or multiple faults). As an example, the geological environment 120 may be equipped with any of a variety of sensors, detectors, actuators, etc. For example, equipment 122 may include communication circuitry for receiving and transmitting information relative to one or more networks 125. Such information may include information associated with downhole equipment 124, which may be equipment used for information acquisition, assisting resource recovery, etc. Other equipment 126 may be located remotely from the well site and include sensing, detection, transmitting, or other circuitry. Such equipment may include storage and communication circuitry for storing and transmitting data, instructions, etc. As an example, one or more pieces of equipment may provide the measurement, collection, transmission, storage, analysis, etc., of data (e.g., regarding one or more mined resources). As an example, one or more satellites may be provided for communication, data acquisition, and other purposes. For example, Figure 1 A satellite communicating with a network 125 that can be configured for communication is shown. It should be noted that the satellite may additionally or alternatively include circuitry for imaging (e.g., spatial, spectral, temporal, radiometric, etc.).

[0030] Figure 1 The geological environment 120 is also shown as optionally including equipment 127 and 128 associated with a well, the well comprising a basic horizontal (or lateral) 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 into a laterally extending reservoir. In such examples, there may be lateral variations in properties, stresses, etc., where assessment of such variations can aid in planning, operations, etc., to develop the reservoir (e.g., via fracturing, injection, extraction, etc.). As an example, equipment 127 and / or 128 may include components, one or more systems, etc., for fracturing, seismic sensing, seismic data analysis, assessment of one or more fractures, injection, production, etc. As an example, equipment 127 and / or 128 may provide, for example, the measurement, collection, transmission, storage, and analysis of data such as production data (e.g., regarding one or more mined resources). As an example, one or more satellites may be provided for communication, data acquisition, and other purposes.

[0031] Figure 1 Examples of equipment 170 and equipment 180 are also shown. Such equipment (which may be a system of components) can be adapted to geological environment 120. Although equipment 170 and 180 are shown as land-based, various components can be adapted to marine systems (e.g., offshore drilling rigs, etc.).

[0032] Equipment 170 includes a platform 171, a derrick 172, a crane 173, a wire rope 174, a traveling block assembly 175, a winch 176, and a loading / unloading platform 177 (e.g., a second-level platform). As an example, the wire rope 174 can be controlled at least partially via the winch 176, causing the traveling block assembly 175 to travel vertically relative to the platform 171. For example, by pulling the wire rope 174, the winch 176 can cause the wire rope 174 to travel through the crane 173 and lift the traveling block assembly 175 away from the platform 171 upwards; however, by allowing the wire rope 174 to extend, the winch 176 can cause the wire rope 174 to travel through the crane 173 and lower the traveling block assembly 175 toward the platform 171. When the traveling block assembly 175 carries drill pipe (e.g., casing, etc.), tracking the movement of the traveling block 175 can provide an indication of how much drill pipe has been deployed.

[0033] A derrick can be a structure used to support an overhead crane and a traveling block that is at least partially operatively coupled to the crane via wire ropes. The derrick can be pyramidal in shape and provide a suitable strength-to-weight ratio. The derrick can be moved as a unit or piece by piece (e.g., it can be assembled and disassembled).

[0034] As an example, a winch may include a spool, brake, power source, and various auxiliary devices. The winch can controllably release and wind up a wire rope. The wire rope can be wound around a crane and coupled to a traveling block to obtain the mechanical advantages of a "pulley" or "roller". Releasing and winding up the wire rope causes the traveling block (e.g., and anything that may be suspended below it) to be lowered into or raised out of the borehole. Releasing the wire rope can be powered by gravity and wound up by a motor, engine, etc. (e.g., electric motor, diesel engine, etc.).

[0035] As an example, a crane may include a set of pulleys (e.g., grooved sheaves) located at or near the top of the derrick or drilling rig, with a wire rope passing through them. A traveling block may include a set of grooved sheaves that can move up and down within the derrick or drilling rig via wire ropes passing through the grooved sheaves of the traveling block and the crane. The crane, traveling block, and wire ropes can form a pulley system for the derrick or drilling rig, enabling the handling of heavy loads (e.g., drill string, drill pipe, casing, liner, etc.) to lift them away from or lower them into the borehole. As an example, the diameter of the wire rope can be from about one centimeter to about five centimeters, such as steel cable. By using a set of grooved sheaves, such a wire rope can carry loads heavier than the weight that a single strand of wire rope can support.

[0036] As an example, a derrickman can be a member of the drilling team working on a platform attached to a derrick or rig. The derrick may include a loading platform where the derrickman can stand. As an example, such a loading platform may be located approximately 10 meters or higher above the rig. In an operation known as tripping (TOH), the derrickman wears a safety harness that allows him to lean outward from the work platform (e.g., a second-level platform) to reach the drill pipe located at or near the center of the derrick or rig, and to wind a rope around the drill pipe and pull it back to its storage position (e.g., a finger beam) until it may be necessary to lower the drill pipe back into the borehole. As an example, the drilling rig may include automated drill pipe handling equipment, allowing the derrickman to control the machinery rather than handle the drill pipe manually.

[0037] As an example, tripping in and out of the borehole can refer to the actions of retrieving equipment from the borehole and / or running equipment into the borehole. As an example, equipment may include drill strings that can be retrieved from and / or run into or replaced in the wellbore. As an example, tripping in and out of the drill string can be performed if the drill bit has become dull or has otherwise ceased to drill effectively and needs to be replaced. As an example, the stroke of retrieving equipment from the wellbore may be referred to as tripping in (POOH), while the stroke of running equipment into the wellbore may be referred to as running in (RIH).

[0038] Figure 2 An example of a well site system 200 is shown (e.g., at a well site that may be located onshore or offshore). As shown, the well site system 200 may include: a mud tank 201 for storing mud and other materials (e.g., where the mud may be drilling fluid); a suction line 203 serving as the inlet of a mud pump 204 for pumping mud from the mud tank 201 to a vibratory hose 206; a winch 207 for winching one or more drilling wire ropes 212; a riser 208 for receiving mud from the vibratory hose 206; a square drill pipe hose 209 for receiving mud from the riser 208; one or more gooseneck pipes 210; a traveling block 211; and a crane 213 for carrying the traveling block 211 via one or more drilling wire ropes 212 (e.g., see...). Figure 1 173 (the overhead crane); 214 (for example, see...) Figure 1 The derrick 172; 218 or top drive 240; 219; rotary table 220; drill platform 221; bell-shaped sub 222; one or more blowout preventers (BOPs) 223; drill string 225; drill bit 226; casing head 227; and flow pipe 228 for conveying mud and other materials to, for example, mud tank 201.

[0039] exist Figure 2 In the example system, a wellbore 232 is formed in the underground formation 230 by rotary drilling; note that various example implementations may also use one or more directional drilling technologies, equipment, etc.

[0040] like Figure 2 As shown in the example, drill string 225 is suspended within wellbore 232 and has drill string assembly 250, which includes drill bit 226 at its lower end. As an example, drill string assembly 250 may be a bottom hole assembly (BHA).

[0041] The well site system 200 can provide operation of the drill string 225 and other operations. As shown, the well site system 200 includes a traveling block 211 and a derrick 214 positioned above the wellbore 232. As mentioned, the well site system 200 may include a rotary table 220 through which the drill string 225 passes.

[0042] like Figure 2 As illustrated in the example, the well site system 200 may include a crisscross drill pipe 218 and associated components, or a top drive 240 and associated components. Regarding the example of the crisscross drill pipe, the crisscross drill pipe 218 may be a square or hexagonal metal / alloy rod with holes drilled to serve as a mud flow path. The crisscross drill pipe 218 can be used to transmit rotational motion from the rotary table 220 via the crisscross drill pipe insert 219 to the drill string 225, while allowing the drill string 225 to be lowered or raised during rotation. The crisscross drill pipe 218 may pass through the crisscross drill pipe insert 219, which can be driven by the rotary table 220. As an example, the rotary table 220 may include a main insert operatively coupled to the crisscross drill pipe insert 219, such that rotation of the rotary table 220 can rotate the crisscross drill pipe insert 219 and thus rotate the crisscross drill pipe 218. The square drill rod insert 219 may include an internal profile (e.g., square, hexagonal, etc.) of the square drill 218 that matches the external profile; however, it is slightly larger in size, so that the square drill 218 can move freely up and down inside the square drill rod insert 219.

[0043] Regarding the top drive example, top drive 240 can provide functionality performed by the kelly and rotary table. Top drive 240 can rotate drill string 225. As an example, top drive 240 may include one or more (e.g., electric and / or hydraulic) motors connected via suitable transmissions to a short section of tubing called a hollow shaft, which can be screwed into a protective fitting or the drill string 225 itself. Top drive 240 can be suspended on traveling block 211, thus allowing the rotating mechanism to move freely up and down along derrick 214. As an example, top drive 240 may allow drilling to be performed using more individual drill strings than with the kelly / rotary table method.

[0044] exist Figure 2 In the example, mud tank 201 can store mud, which can be one or more types of drilling fluid. As an example, a wellbore can be drilled to extract fluids, inject fluids, or both (e.g., hydrocarbons, minerals, water, etc.).

[0045] exist Figure 2In the example, drill string 225 (e.g., including one or more downhole tools) may consist of a series of drill pipes threaded together to form a long tube with a drill bit 226 at its lower end. As drill string 225 enters the wellbore for drilling, before or at some point coinciding with drilling, mud may be pumped from mud tank 201 (e.g., or from another source) via lines 206, 208, and 209 to a port of kelly 218, or, for example, to a port of top drive 240, via pump 204. The mud may then flow through channels (e.g., multiple channels) in drill string 225 and exit through a port located on drill bit 226 (e.g., see directional arrows). As the mud exits drill string 225 through the port in drill bit 226, it may circulate upwards through the annulus region between one or more outer surfaces of drill string 225 and one or more surrounding wellbore walls (e.g., open borehole, casing, etc.), as indicated by the directional arrows. In this way, the mud lubricates the drill bit 226 and carries heat energy (e.g., friction or other energy) and formation cuttings to the surface, where the mud (e.g., and the cuttings) can be returned to the mud tank 201 for example for recycling (e.g., by treatment to remove cuttings, etc.).

[0046] The mud pumped into the drill string 225 by pump 204 forms a mud cake adhering to the wellbore after leaving the drill string 225. This reduces friction between the drill string 225 and one or more surrounding wellbore walls (e.g., wellbore, casing, etc.), among other functions. This reduction in friction facilitates the advance or retraction of the drill string 225. During drilling operations, the entire drill string 225 can be retrieved from the wellbore and optionally replaced, for example, with a new or sharper drill bit, a smaller diameter drill string, etc. As mentioned, the act of retrieving the drill string from the wellbore or replacing the drill string within the wellbore is called tripping. Depending on the direction of tripping, tripping can be referred to as tripping up, tripping outward, tripping down, or tripping inward.

[0047] As an example, consider drilling downwards, where, as the drill bit 226 of the drill string 225 reaches the bottom of the wellbore, the pumping of mud begins to lubricate the drill bit 226 for drilling purposes to enlarge the wellbore. As mentioned, mud can be pumped into the channels of the drill string 225 by pump 204, and while filling the channels, the mud can be used as a medium for transmitting energy (e.g., energy that can encode information, such as mud pulse telemetry).

[0048] As an example, mud pulse telemetry equipment may include a downhole device configured to realize pressure changes in the mud to generate one or more acoustic waves that can be used to modulate information. In such an example, information from downhole equipment (e.g., one or more modules of drill string 225) can be transmitted up to a wellhead device, which can then relay this information to other equipment for processing, control, etc.

[0049] As an example, telemetry equipment can operate by transmitting energy via the drill string 225 itself. For example, consider a signal generator that transmits an encoded energy signal to the drill string 225, and a repeater that can receive and relay this energy for further transmission of the encoded energy signal (e.g., information, etc.).

[0050] As an example, drill string 225 may be equipped with telemetry equipment 252, which includes: a rotatable drive shaft; a turbine impeller mechanically coupled to the drive shaft such that the drilling mud can rotate the turbine impeller; a modulator rotor mechanically coupled to the drive shaft such that rotation of the turbine impeller causes rotation of the modulator rotor; a modulator stator mounted adjacent to or near the modulator rotor such that rotation of the modulator rotor relative to the modulator stator generates pressure pulses in the drilling mud; and a controllable brake for selectively braking the rotation of the modulator rotor to modulate the pressure pulses. In such an example, an alternator may be coupled to the aforementioned drive shaft, wherein the alternator includes at least one stator winding electrically coupled to a control circuit to selectively short-circuit the at least one stator winding to electromagnetically brake the alternator, thereby selectively braking the rotation of the modulator rotor to modulate the pressure pulses in the drilling mud.

[0051] exist Figure 2 In one example, the wellhead control and / or data acquisition system 262 may include circuitry for sensing pressure pulses generated by the telemetry equipment 252 and (for example) transmitting the sensed pressure pulses or information derived therefrom for processing, control, etc.

[0052] The component 250 shown in the example includes a logging-while-drilling (LWD) module 254, a measurement-while-drilling (MWD) module 256, an optional module 258, a rotary steerable system (RSS) and / or a motor 260, and a drill bit 226. Such components or modules may be referred to as tools, and the drill string may include multiple tools.

[0053] For RSS, it relates to techniques used in directional drilling. Directional drilling involves drilling into the earth to form an skewed borehole, such that the borehole's trajectory is not vertical; instead, the trajectory deviates from vertical along one or more sections of the borehole. As an example, consider a target located at a lateral distance from a surface location where a drilling rig might be anchored. In such an example, drilling could begin at a vertical section and then deviate from vertical, causing the borehole to align with and eventually reach the target. Directional drilling can be implemented when a target is not reachable from a vertical location on the earth's surface, when there are materials on the earth that could hinder drilling or otherwise harm it (e.g., consider salt domes), when the formation extends laterally (e.g., consider relatively thin but laterally extending reservoirs), when multiple boreholes are to be drilled from a single surface borehole, when a decompression well is desired, etc.

[0054] One method of directional drilling involves mud motors; however, mud motors can present some challenges depending on factors such as the rate of penetration (ROP) and the transfer of pressure on the drill bit due to friction (e.g., WOB). Mud motors can be operated (e.g., during directional drilling) to drive a positive displacement motor (PDM) of the drill bit. The PDM operates as drilling fluid is pumped through it, converting the hydraulic power of the drilling fluid into mechanical power to rotate the drill bit.

[0055] As an example, PDM can operate in a combined rotary mode, where the drill string bit is rotated using surface equipment (e.g., rotary table, top drive, etc.) by rotating the entire drill string, and the drill string bit is rotated using drilling fluid. In such examples, the surface RPM (SRPM) can be determined using surface equipment, and the downhole RPM of the mud motor can be determined using various factors such as drilling fluid flow rate and mud motor type. As an example, in combined rotary mode, assuming the SRPM and mud motor RPM are in the same direction, the bit RPM can be determined or estimated as the sum of the SRPM and mud motor RPM.

[0056] As an example, when the drill string is not rotating from the ground, the PDM mud motor can operate in a so-called slippery mode. In such examples, the drill bit RPM can be determined or estimated based on the mud motor's RPM.

[0057] RSS (Rotating Steering Module) can be used in directional drilling where there is continuous rotation on the surface, which can reduce slippage of the directional motor (e.g., PDM). RSS can be deployed during directional drilling (e.g., deviated, horizontal, or extended wells). RSS can be designed to minimize interaction with the wellbore wall, which can help maintain wellbore quality. RSS can be designed to apply a relatively consistent lateral force similar to that of a stabilizer that rotates with the drill string or orients the drill bit in the desired direction while rotating continuously at the same rate as the drill string per minute.

[0058] LWD module 254 can be housed in a suitable type of drill collar and may contain one or more logging tools of the selected type. It should also be understood that more than one LWD and / or MWD module may be employed, for example, as represented by module 256 of drill string assembly 250. When referring to the location of an LWD module, by way of example, it may refer to the module at the location of LWD module 254, module 256, etc. An LWD module may include the ability to measure, process, and store information, as well as the ability to communicate with surface equipment. In the illustrated example, LWD module 254 may include a seismic measuring device.

[0059] MWD module 256 can be housed in a suitable type of drill collar and may include one or more devices for measuring the characteristics of drill string 225 and drill bit 226. As an example, MWD tool 254 may include equipment for generating electricity, for example, to power various components of drill string 225. As an example, MWD tool 254 may include telemetry equipment 252, for example, where a turbine impeller generates electricity via the flow of mud; it should be understood that other power sources and / or battery systems may be used for the purpose of powering various components. As an example, MWD module 256 may include one or more measuring devices of the following types: drill pressure measuring device, torque measuring device, vibration measuring device, impact measuring device, stick-slip measuring device, direction measuring device, and inclination measuring device.

[0060] Figure 2 Some examples of the types of wells that can be drilled are also shown. For example, consider the inclined straight well 272, the S-shaped well 274, the deeply inclined well 276, and the horizontal well 278.

[0061] As an example, drilling operations may include directional drilling, where, for example, at least a portion of the well includes a curved axis. Consider, for instance, a radius defining the curvature, where the inclination relative to the vertical can vary up to an angle between approximately 30 degrees and approximately 60 degrees, or, for example, an angle of approximately 90 degrees or possibly greater than approximately 90 degrees.

[0062] As an example, directional wells can include various shapes, each designed to meet specific operational requirements. As an example, drilling procedures can be performed based on information passed to the drilling engineer. As an example, inclination and / or direction can be modified based on information received during the drilling process.

[0063] As an example, borehole deflection can be achieved in part by using a bottom-hole motor and / or turbine. Regarding the motor, for example, the drill string may include a positive displacement motor (PDM).

[0064] As an example, the system can be a guidance system and include equipment for performing methods such as geological guidance. As mentioned, the guidance system can be or include an RSS (Resistivity to Seismic) system. As an example, the guidance system can include a PDM (Precision Deflection Machine) or turbine located at the bottom of the drill string, just above the drill bit, and can be fitted with a bend joint. As an example, above the PDM, MWD (Modulation to Deflection) equipment and / or LWD (Low-Modulation) equipment can be installed to provide real-time or near-real-time data of interest (e.g., inclination, direction, pressure, temperature, actual weight on the drill bit, torque stress, etc.). For the latter, the LWD equipment can transmit various types of data of interest to the surface, including, for example, geological data (e.g., gamma-ray logging, resistivity, density, and sonic logging, etc.).

[0065] Coupled sensors providing real-time or near-real-time information about the wellbore trajectory (e.g., one or more logging curves characterizing the formation from a geological perspective) can allow for the implementation of geosteering methods. These methods can include navigating the subsurface environment, for example, to follow a desired route to reach one or more desired targets.

[0066] As an example, a drill string may include an azimuth density neutron (ADN) tool for measuring density and porosity; a MWD tool for measuring tilt, azimuth, and vibration; a compensated dual resistivity (CDR) tool for measuring resistivity and gamma-ray related phenomena; one or more variable diameter stabilizers; one or more bend joints; and a geological guidance tool that may include a motor and optional equipment for measuring and / or responding to one or more of tilt, resistivity, and gamma-ray related phenomena.

[0067] As an example, geological steering can include intentional directional control of the wellbore based on downhole geological logging measurements in a manner aimed at keeping the directional wellbore within a desired area, zone (e.g., oil-producing layer). As an example, geological steering can include guiding the wellbore to keep it within a specific section of the reservoir, for example, to minimize gas and / or water breakthroughs, and for example, to maximize the economic production of the well including the wellbore.

[0068] Refer again Figure 2The well site system 200 may include one or more sensors 264, which are operatively coupled to a control and / or data acquisition system 262. As an example, the one or more sensors may be located at a surface location. As an example, the one or more sensors may be located at a downhole location. As an example, the one or more sensors may be located at one or more remote locations within approximately one hundred meters of the well site system 200. As an example, the one or more sensors may be located at a compensation well site, wherein the well site system 200 and the compensation well site are located in a common oil and gas field (e.g., an oil field and / or a gas field).

[0069] As an example, one or more sensors 264 may be provided for tracking the movement of the drill pipe, tracking the movement of at least a portion of the drill string, etc.

[0070] As an example, system 200 may include one or more sensors 266 that can sense and / or transmit signals to fluid conduits, such as drilling fluid conduits (e.g., drilling mud conduits). For example, in system 200, one or more sensors 266 may be operatively coupled to a portion of riser 208 through which mud flows. As an example, a downhole tool may generate pulses that can pass through the mud and be sensed by one or more of the one or more sensors 266. In such examples, the downhole tool may include associated circuitry, such as coded circuitry that can encode signals to reduce transmission requirements. As an example, surface-based circuitry may include decoding circuitry to decode encoded information transmitted at least partially via mud pulse telemetry. As an example, surface-based circuitry may include encoder and / or decoder circuitry, and downhole circuitry may include encoder and / or decoder circuitry. As an example, system 200 may include a transmitter that can generate signals that can be transmitted downhole via mud (e.g., drilling fluid) as a transmission medium.

[0071] As an example, one or more portions of the drill string may become stuck. The term "stuck" can refer to one or more different degrees of inability to move or remove the drill string from the borehole. For example, in a stuck state, it may be possible to rotate the drill string or lower it back into the borehole, or, for instance, in a stuck state, it may be impossible to move the drill string axially in the borehole, but some degree of rotation is possible. For example, in a stuck state, at least a portion of the drill string may not be able to move axially and rotationally.

[0072] The term "stuck" can refer to a portion of the drill string that is unable to rotate or move axially. As an example, a condition known as "differential stuck" can be a situation where the drill string cannot move along the axis of the borehole (e.g., rotate or reciprocate). Differential stuck can occur when high contact forces, caused by low reservoir pressure, high wellbore pressure, or both, are applied over a sufficiently large area of ​​the drill string. Differential stuck can have both time and economic costs.

[0073] As an example, stuck force can be the product of the pressure differential between the wellbore and the reservoir and the area over which the pressure differential acts. This means that applying a relatively low pressure differential (Δp) over a large working area can be just as effective at causing stuck force as applying a high pressure differential over a small area.

[0074] As an example, a condition known as "mechanical stuck" can be one in which the movement of the drill string is restricted or prevented by a mechanism other than differential pressure stuck. For example, mechanical stuck can be caused by one or more of the following: debris in the wellbore, abnormal wellbore geometry, cement, keyway, or cuttings accumulation in the annulus.

[0075] Figure 3 An example of system 300 is shown, which includes various equipment for evaluation 310, planning 320, engineering design 330, and operation 340. For example, a drilling workflow framework 301, a seismic-to-simulation framework 302, a technical data framework 303, and a drilling framework 304 can be implemented to perform one or more processes, such as evaluating formation 314, evaluating processes 318, generating trajectories 324, validating trajectories 328, establishing constraints 334, designing equipment and / or processes 338 at least in part based on constraints, performing drilling 344, and evaluating drilling and / or formations 348.

[0076] exist Figure 3 In the example, the earthquake simulation frame 302 can be, for example, the PETREL frame (Schlumberger, Houston, Texas), and the technical data frame 303 can be, for example, the TECHLOG frame (Schlumberger, Houston, Texas).

[0077] As an example, the framework may include entities, which may include earth entities, geological objects, or other objects such as wells, surfaces, reservoirs, etc. Entities may include virtual representations of actual physical entities reconstructed for one or more purposes such as assessment, planning, engineering design, operation, etc.

[0078] An entity can be based on data acquired through sensing, observation, etc. (e.g., seismic data and / or other information). An entity can be characterized by one or more attributes (e.g., a geometric strut mesh entity of an Earth model can be characterized by a porosity attribute). These attributes can represent one or more measurement results (e.g., acquired data), calculation results, etc.

[0079] A framework can be an object-based framework. In such a framework, entities can include entities based on predefined classes, for example, to facilitate modeling, analysis, simulation, etc. An example of an object-based framework is the MICROSOFT .NET Framework (Redmond, Washington), which provides a set of extensible object classes. In the .NET Framework, object classes encapsulate modules of reusable code and associated data structures. Object classes can be used to instantiate object instances for use by programs, scripts, etc. For example, a wellbore class can define objects representing wellbores based on well data.

[0080] As an example, the framework can be implemented within the DELFI Cognitive Exploration and Production (E&P) environment (Schlumberger, Houston, Texas) or coupled with the operations of the DELFI Cognitive Exploration and Production (E&P) environment, a secure, cognitive, cloud-based collaborative environment that integrates data and workflows using digital technologies such as artificial intelligence and machine learning. As an example, such an environment can provide operations involving one or more frameworks.

[0081] As an example, the framework may include analytical components that allow interaction with the model or model-based results (e.g., simulation results). Regarding simulation, the framework may be operatively linked to or include simulators such as the ECLIPSE reservoir simulator (Schlumberger, Houston, Texas), the INTERSECT reservoir simulator (Schlumberger, Houston, Texas), etc.

[0082] The PETREL framework mentioned above provides components that allow for the optimization of exploration and development operations. The PETREL framework includes seismic-to-simulation software components that can output information to improve reservoir performance, for example, by increasing the productivity of asset teams. By using 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 can be considered an application and can also be considered a data-driven application (e.g., in cases where data is input for modeling, simulation, etc.).

[0083] As mentioned regarding the DELFI environment, one or more frameworks can be interoperable and / or run on one or the other. As an example, a framework environment with the trade name OCEAN Framework Environment (Schlumberger, Houston, Texas) can be utilized, which allows the integration of add-ons (or plug-ins) into the PETREL framework workflow. In the example implementation, various components can be implemented as add-ons (or plug-ins) conforming to the framework environment's specifications and operating according to the framework environment's specifications (e.g., according to the Application Programming Interface (API) specification, etc.).

[0084] As an example, a framework may include a model simulation layer, as well as a framework service layer, a framework core layer, and module layers. In a framework environment (e.g., OCEAN, DELFI, etc.), the model simulation layer may include or be operatively linked to the model-centric framework. In example implementations, a framework can be considered a data-driven application. For example, the PETREL framework may include features for model building and visualization. As an example, a model may include one or more grids, where the grids may be spatial grids conforming to the spatial location of each acquired data point (e.g., satellite data, well logging data, seismic data, etc.).

[0085] As an example, the model simulation layer can provide domain objects, act as a data source, provide rendering, and provide various user interfaces. Rendering capabilities can provide a graphical environment where applications can display their data, while the user interface can provide a common look and feel for the application's user interface components.

[0086] As an example, domain objects can include entity objects, attribute objects, and optionally other objects. Entity objects can be used to geometrically represent wells, surfaces, reservoirs, etc., while attribute objects can be used to provide attribute values, data versioning, and display parameters. For example, an entity object can represent a well, where attribute objects provide logging information, as well as versioning and display information (e.g., displaying the well as part of the model).

[0087] As an example, data can be stored in one or more data sources (or data storage areas, typically physical data storage devices), which may be located at the same or different physical sites and can be accessed via one or more networks. As an example, the model simulation layer can be configured to model a project. This allows specific projects to be stored, where the stored project information can include inputs, models, results, and cases. Therefore, a user can save a project upon completion of a modeling session. Later, the project can be accessed and retrieved using the model simulation layer, which can recreate instances of the relevant domain objects.

[0088] As an example, system 300 can be used to execute one or more workflows. A workflow can be a process that includes several work steps. Work steps can manipulate data, such as creating new data, updating existing data, etc. As an example, a workflow can, for instance, operate on one or more inputs based on one or more algorithms and create one or more results. As an example, the system can include a workflow editor for creating, editing, and executing workflows. In such examples, the workflow editor can provide selections for one or more predefined work steps, one or more custom work steps, etc. As an example, a workflow can be at least partially implementable in the PETREL framework; for example, the workflow operates on seismic data, one or more seismic attributes, etc.

[0089] As an example, seismic data can be acquired via seismic surveys, where the source and receiver are located in the geological environment to emit and receive seismic energy, at least a portion of which can be reflected away from subsurface structures. As an example, one or more seismic data analysis frameworks (e.g., consider the OMEGA framework sold by Schlumberger, Inc., Houston, Texas) can be used to determine the 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 subsurface areas of the geological environment. As an example, the seismic data analysis framework can be part of or operatively coupled to a seismic-to-simulation framework (e.g., the PETREL framework, etc.).

[0090] As an example, a workflow can be a process that is at least partially achievable within a framework environment and can be implemented by one or more frameworks. As an example, a workflow can include one or more work steps that access a set of instructions such as a plugin (e.g., external executable code). As an example, a framework environment can be cloud-based, utilizing cloud resources that can be operatively coupled to one or more field devices, enabling the use of the framework environment's features to acquire, transfer, store, process, and analyze data. For example, a framework environment can employ various types of services, which can be backend services, frontend services, or a combination of both. For example, consider a client-server type architecture where communication can occur via one or more application programming interfaces (APIs), one or more microservices, etc.

[0091] As an example, frameworks can provide modeling for hydrocarbon systems. For instance, the modeling framework PETROMOD (Schlumberger, Houston, Texas) includes features for inputting various types of information (e.g., seismic, well, geological, etc.) to model the evolution of sedimentary basins. The PETROMOD framework provides hydrocarbon system modeling by inputting various data, such as seismic data, well data, and other geological data, to model the evolution of sedimentary basins. The PETROMOD framework can predict whether and how reservoirs are filled with hydrocarbons, including, for example, the source and timing of hydrocarbon generation, migration routes, quantities, pore pressures, and the type of hydrocarbons in subsurface or surface conditions. Combining frameworks such as the PETREL framework allows for the construction of workflows to provide basin-scale exploration solutions. Data exchange between frameworks can facilitate the coupling of model building, data analysis (e.g., analyzing PETROMOD framework data using the capabilities of the PETREL framework), and workflows.

[0092] As mentioned, the drill string can include a variety of tools capable of performing measurements. As an example, measurements can be performed using a cable tool or another type of tool. As an example, the tool can be configured to acquire electrical wellbore images. As an example, a full-bore formation microimager (FMI) tool (Schlumberger, Houston, Texas) can acquire wellbore image data. A data acquisition sequence for such a tool may include running the tool into the wellbore with the acquisition pad closed, opening the pad and pressing it against the wellbore wall, delivering current to the material defining the wellbore as the tool is moved through the wellbore, and remotely sensing the changes in current due to interaction with the material.

[0093] Analysis of stratigraphic information can reveal features such as caverns, dissolution planes (e.g., dissolution along bedding planes), stress-related characteristics, and tilting events. As an example, tools can acquire information that may help characterize reservoirs (optionally, fractured reservoirs), where fractures can be natural and / or artificial (e.g., hydraulic fractures). As an example, information acquired by one or more tools can be analyzed using a framework such as the TECHLOG framework. For example, the TECHLOG framework may be interoperable with one or more other frameworks (such as the PETREL framework).

[0094] As an example, the MANGROVE framework (Schlumberger Limited, Houston, Texas) can be used in one or more production enhancement workflows. This framework helps optimize production enhancement designs in reservoir-centric environments, such as by predicting the geomechanical propagation of hydraulic fractures and / or production prediction within 3D reservoir models. This approach can help understand the heterogeneous interactions between hydraulic and natural fracture networks and / or optimize the number and location of fracture treatment stages, for example, contributing to improved perforation efficiency and recovery. As an example, the workflow may include integrating microseismic data and discrete fracture network (DFN) models in unconventional fracture modeling, which can help operators understand and characterize fracture geometry.

[0095] Hydraulic fracturing, also known as production enhancement treatment, is applicable to oil and gas wells in low-permeability reservoirs. In this operation, engineering fluids are pumped at high pressure and high speed into the reservoir space to be treated, causing fractures to open. These fractures may have flanks extending in opposite directions away from the wellbore due to natural stresses within the formation. Hydraulic fracturing operations may involve the use of proppant, such as sand grains of a specific size, which can be mixed with the treatment fluid to keep the fractures open upon completion of the treatment. Hydraulic fracturing can facilitate the formation of highly conductive connections to large areas of formation and avoid potential damage in the near-wellbore zone.

[0096] As an example, microseismic monitoring can be used in conjunction with hydraulic fracturing. This technology can help track the propagation of hydraulic fracturing as it penetrates the formation. For example, sensors can be used to detect microseisms, which can be located and displayed in a timely manner to approximate the location and propagation of hydraulic fractures during the fracturing operation. As an example, computational frameworks can provide modeling, exploration design, microseismic detection and location, uncertainty analysis, data integration, and visualization for interpretation. As an example, computer imagery can be used to monitor activity in a multidimensional space relative to the fracturing treatment location. As an example, monitored activity can be animated to show progressive fracture growth and subsurface response to changes in pumping. When displayed in real time, microseismic activity can provide insights into changes to production enhancement operations, such as helping to ensure optimal reservoir contact (e.g., fluid networks contacting the reservoir so that fluids can be produced from it). The effectiveness of reservoir enhancement can be used to improve reservoir development, such as in shale gas well completions.

[0097] As an example, various aspects of a workflow can be automated, partially automated, or performed manually, such as through human users interacting with software applications executed using hardware (e.g., local and / or remote). As an example, a workflow can be cyclical and may include, for example, four phases, such as an evaluation phase (e.g., see evaluation equipment 310), a planning phase (e.g., see planning equipment 320), an engineering design phase (e.g., see engineering design equipment 330), and an execution phase (e.g., see operation equipment 340). As an example, a workflow may begin at one or more phases and can proceed to one or more other phases (e.g., sequentially, in parallel, cyclically, etc.).

[0098] As an example, the workflow can begin with an assessment phase, which may include the geological service provider assessing the formation (see, for example, assessment block 314). As an example, the geological service provider may use a computational system that executes software packages tailored for this activity to perform the formation assessment; or, as an example, one or more other suitable geological platforms may be employed (e.g., alternatively or additionally). As an example, the geological service provider may use, for example, geophysical models, basin models, petroleum technology models, combinations thereof, etc., to assess the formation. Such models can take into account a variety of different inputs, including compensation well data, seismic data, pilot well data, other geological data, etc. The models and / or inputs may be stored in a database maintained by a server and accessible to the geological service provider.

[0099] As an example, the workflow may proceed to a geology and geophysics (“G&G”) service provider, which can generate a well trajectory (e.g., see generation block 324), which may involve executing one or more G&G software packages. Examples of such software packages include the PETREL framework. As an example, the G&G service provider may determine the well trajectory or portions thereof based on one or more models, such as those provided by formation assessment (e.g., according to assessment block 314) and / or other data, such as data accessed from one or more databases (e.g., maintained by one or more servers, etc.). As an example, the well trajectory may take into account various “design basis” (BOD) constraints, such as general surface location, target (e.g., reservoir) location, etc. As an example, the trajectory may incorporate information about tools that can be used in drilling, bottom hole assembly, casing size, etc. Well trajectory determination may take into account various other parameters, including risk tolerance, fluid weight and / or planning, bottom hole pressure, drilling time, etc.

[0100] As an example, the workflow may proceed to a first engineering design service provider (e.g., one or more processors associated with it), which can verify the well trajectory and, for example, the design of a rescue well (see, for example, verification block 328). This verification process may include evaluating physical characteristics, calculations, risk tolerance, integration with other aspects of the workflow, etc. As an example, one or more parameters used for such determination may be maintained by a server and / or the first engineering design service provider; note that one or more models, well trajectories(s), etc., may be maintained by the server and accessed by the first engineering design service provider. For example, the first engineering design service provider may include one or more computing systems executing one or more software packages. As an example, if the first engineering design service provider refuses or otherwise suggests adjustments to the well trajectory, the well trajectory may be adjusted or a message requesting such modification or other notification may be sent to the G&G service provider.

[0101] As an example, one or more engineering design service providers (e.g., a first, a second, etc.) may provide casing design, bottom hole assembly (BHA) design, fluid design, etc., to achieve well trajectory (e.g., see design block 338). In some embodiments, a second engineering design service provider may use one or more software applications to perform such designs. Such designs may be stored in one or more databases maintained by one or more servers, which may employ, for example, the STUDIO framework tool (Schlumberger, Houston, Texas), and may be accessible to one or more other service providers in the workflow.

[0102] As an example, a second engineering design service provider may seek approval from a third engineering design service provider for one or more designs established together with the well trajectory. In such an example, the third engineering design service provider may consider various factors regarding the acceptability of the well engineering design plan, such as economic variables (e.g., oil production forecasts, cost per barrel, risks, drilling time, etc.), and may request expenditure authorizations, such as from representatives of the operating company, well owner, etc. (see, for example, Block 334). As an example, at least some of the data on which such determinations are based may be stored in one or more databases maintained by one or more servers. As an example, the first, second, and / or third engineering design service providers may be provided by a single team of engineers or even a single engineer, and therefore may or may not be separate entities.

[0103] As an example, in situations where economics may be unacceptable or authorization may be denied, the engineering design service provider may recommend changes to the casing, bottom hole assembly, and / or fluid design, or otherwise notify and / or return control to a different engineering design service provider so that the casing, bottom hole assembly, and / or fluid design can be adjusted. Where modifying one or more of such designs is impractical within drilling constraints, trajectory, etc., the engineering design service provider may recommend adjustments to the well trajectory and / or the workflow may be returned to or otherwise notified to the initial engineering design service provider and / or the G&G service provider so that either or both can modify the well trajectory.

[0104] As an example, a workflow may include consideration of the well trajectory, including accepted well engineering design plans and formation assessments. Such a workflow can then pass control to the drilling service provider, which can implement the well engineering design plan, establish safe and efficient drilling, maintain well integrity, and report progress and operational parameters (e.g., see blocks 344 and 348). As an example, operational parameters, encountered formations, and data collected during drilling (e.g., using logging-while-drilling or measurement-while-drilling techniques) can be fed back to the geoservice provider for evaluation. As an example, the geoservice provider can then reassess the well trajectory or one or more other aspects of the well engineering design plan, and in some cases, may adjust the well engineering design plan based on actual drilling parameters (e.g., based on field-acquired data, etc.), within predetermined constraints.

[0105] Depending on the specific implementation plan, the workflow can proceed to post-review (e.g., see evaluation block 318) regardless of whether the well is fully drilled or only partially completed. As an example, post-review may include reviewing drilling performance. As an example, post-review may also include (e.g., reporting drilling performance to one or more relevant engineering, geology, or G&G service providers).

[0106] The various activities of a workflow can be performed sequentially and / or out of order (e.g., based in part on information from templates, nearby wells, etc., to fill any gaps in information that will be provided by another service provider). As an example, performing one activity may affect the outcome or basis of another activity, and therefore changes to one or more workflow activities, work products, etc., can be invoked manually or automatically. As an example, a server may allow information to be stored on a central database accessible to various service providers, where changes can be sought through communication with the appropriate service provider, changes can be implemented automatically, or changes can otherwise manifest as recommendations to the relevant service providers. This approach can be considered a holistic approach to drilling workflows compared to an ordered, segmented approach.

[0107] As an example, various actions in the workflow can be repeated multiple times during wellbore drilling. For instance, in one or more automated systems, feedback from the drilling service provider can be provided in real-time or near real-time, and data acquired during drilling can be fed to one or more other service providers, who can adjust portions of their workflow accordingly. Such adjustments can be integrated into the workflow, for example, in an automated manner, due to dependencies that may exist in other areas. In some implementations, the cyclical process can be performed additionally or alternatively after a drilling objective (such as completing a portion of the wellbore) and / or after drilling the entire wellbore, or on a daily, weekly, monthly, or other basis.

[0108] Well planning may include determining the path (e.g., trajectory) of a well that can extend into the reservoir, for example, to economically extract fluids, such as hydrocarbons. Well planning may include selecting drilling and / or completion components that can be used to achieve the well plan. As an example, various constraints may be imposed as part of well planning that can influence well design. As an example, such constraints may be imposed based at least in part on known geology of the subsurface domain, one or more other wells existing in the area (e.g., actual and / or planned, etc.) (e.g., considering collision avoidance), etc. As an example, one or more constraints may be imposed based at least in part on the 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.

[0109] As an example, a system can allow for the reduction of waste, such as waste as defined by LEAN. In the LEAN context, consider one or more of the following types of waste: transport (e.g., unnecessary movement of items, whether physical or data); inventory (e.g., parts, whether physical or informational, as work-in-process and unfinished finished goods); motion (e.g., unnecessary movement or walking of people or equipment to perform required processing); waiting (e.g., waiting for information, production interruptions during shift changes, etc.); overproduction (e.g., production of materials, information, equipment, etc., ahead of demand); overprocessing (e.g., caused by inferior tools or product design activities); and defects (e.g., work involved in inspecting and repairing defects in plans, data, equipment, etc.). As an example, a system that allows actions to be performed collaboratively (e.g., methods, workflows, etc.) can help reduce one or more types of waste.

[0110] As an example, a system can be used to implement methods for facilitating distributed well engineering design, planning, and / or drilling system design across multiple computing devices, where collaboration can occur among various different users (e.g., some local users, some remote users, some mobile users, etc.). In such a system, various users can be operatively coupled via one or more networks (e.g., local area networks and / or wide area networks, public networks and / or private networks, land-based, sea-based, and / or regional networks) through appropriate means.

[0111] As an example, the system may allow well engineering design, planning, and / or drilling system design via a subsystem approach, where the well site system comprises various subsystems, which may include equipment subsystems and / or operational subsystems (e.g., control subsystems, etc.). As an example, calculations may be performed using various computing platforms / devices operatively coupled via communication links (e.g., network links, etc.). As an example, one or more links may be operatively coupled to a public database (e.g., server sites, etc.). As an example, specific servers (one or more) may manage receiving notifications from one or more devices and / or issuing notifications to one or more devices. As an example, the system may be implemented for a project, whereby the system can output well plans as (e.g.) digital well plans, paper well plans, digital and paper well plans, etc. Such well plans may be complete well engineering design plans or designs for a specific project.

[0112] Figure 4 An example of a well site system 400 is shown, specifically, Figure 4 The diagram shows the well site system 400 in an approximate side view and an approximate plan view, as well as a block diagram of the system 470.

[0113] exist Figure 4 In the example, well site system 400 may include compartment 410, rotary table 422, winch 424, rig 426 (e.g., optionally carrying top drive, etc.), mud tank 430 (e.g., having one or more pumps, one or more vibrators, etc.), one or more pump houses 440, boiler house 442, HPU house 444 (e.g., having rig oil tank, etc.), assembly house 448 (e.g., having one or more generators, etc.), piping 462, narrow passage 464, flare 468, etc. Such equipment may include one or more associated functions and / or one or more associated operational risks, which may be risks related to time, resources, and / or personnel.

[0114] like Figure 4As illustrated in the example, well site system 400 may include system 470, which includes one or more processors 472, memory 474 operatively coupled to at least one of the processors 472, instructions 476 that may be stored, for example, in memory 474, and one or more interfaces 478. As an example, system 470 may include one or more processor-readable media comprising processor-executable instructions that can be executed by at least one of the processors 472 to enable system 470 to control one or more aspects of well site system 400. In such examples, memory 474 may be or include one or more processor-readable media, wherein processor-executable instructions may be or include instructions. As an example, processor-readable media may be computer-readable storage media that is not a signal and is not a carrier wave.

[0115] Figure 4 A battery 480 is also shown, which can be operatively coupled to system 470, for example, to power system 470. As an example, battery 480 can be a backup battery that operates when another power source is unavailable to power system 470. As an example, battery 480 can be operatively coupled to a network, which can be a cloud network. As an example, battery 480 can include smart battery circuitry and can be operatively coupled to one or more devices via SMBus or other types of buses.

[0116] exist Figure 4 In the example, service 490 is shown to be available, for example, via a cloud platform. Such services may include data service 492, query service 494, and drilling service 496. As an example, service 490 could be such as... Figure 3 It is part of a system like System 300.

[0117] As an example, system 470 can be used to generate one or more sequences and / or receive one or more sequences, which can be used, for example, to control one or more drilling operations. For example, consider sequences including slippery modes and drilling modes, and transitions therebetween.

[0118] Figure 5 A schematic diagram illustrating an example of drilling operations for directional wells in multiple sections is shown. Figure 5 The drilling operations depicted include a well site drilling system 500 and a field management tool 520, which manages various operations associated with the wellbore 550 of the directional well 517. The well site drilling system 500 includes various components (e.g., drill string 512, annulus 513, bottom hole assembly (BHA) 514, rib drill pipe 515, mud pit 516, etc.). Figure 5As shown in the example, the target reservoir may be located away from the surface location of well 517 (rather than directly at the surface location of the well). In such examples, special tools or techniques can be used to ensure that the target reservoir is reached at a specific location along the path of borehole 550.

[0119] As an example, BHA 514 may include sensor 508, rotary steerable system (RSS) 509, and drill bit 510 to guide drilling toward a target guided by a predetermined exploration procedure for measuring location details within the well. Furthermore, the subsurface formation drilled by the directional well 517 may include multiple layers (not shown) with different compositions, geophysical properties, and geological conditions. Drilling planning during the well design phase and actual drilling according to the drilling plan can both be carried out in multiple sections (e.g., see sections 501, 502, 503, and 504), which may correspond to one or more of multiple layers in the subsurface formation. For example, due to specific formation composition, geophysical properties, and geological conditions, certain sections (e.g., sections 501 and 502) may use cement 507 reinforced casing 506.

[0120] exist Figure 5 In the example, surface unit 511 can be operatively linked to well site drilling system 500 and field management tool 520 via communication link 518. Surface unit 511 can be configured to control and monitor drilling activities in each section in real time via communication link 518. Field management tool 520 can be configured to store oilfield data (e.g., historical data, actual data, surface data, subsurface data, equipment data, geological data, geophysical data, target data, anti-target data, etc.) and determine relevant factors for configuring drilling models and generating drilling plans. Oilfield data, drilling models, and drilling plans can be transmitted via communication link 518 according to the drilling operation workflow. Communication link 518 may include communication sub-components.

[0121] During various operations at the well site, data can be acquired for analysis and / or monitoring of one or more operations. Such data may include, for example, subsurface formation data, equipment data, historical data, and / or other data. Static data may relate to, for example, stratigraphic structure and geological stratigraphy that define the geological structure of the subsurface formation. Static data may also include data about the borehole, such as inner diameter, outer diameter, and depth. Dynamic data may relate to, for example, fluids flowing through the geological structure of the subsurface formation over time. Dynamic data may include, for example, pressure, fluid composition (e.g., oil-gas ratio, water cut, and / or other fluid composition information), and the status of various equipment, as well as other information.

[0122] Three-dimensional models of one or more subsurface formations can be created and / or updated using static and dynamic data collected via boreholes, formations, equipment, etc. As an example, three-dimensional models can be created and / or updated using static and dynamic data from one or more other boreholes, the field, etc. As an example, data can be collected using hardware sensors, core sampling, and logging techniques. As an example, static measurement results can be collected using downhole measurements such as core sampling and logging techniques. Logging involves deploying downhole tools into the wellbore to collect various downhole measurement results at different depths, such as density, resistivity, etc. Such logging can be performed using, for example, drilling tools and / or wireline tools or sensors located on downhole production equipment. Once the well is formed and completed, depending on the well's purpose (e.g., injection and / or production), fluids can flow to the surface (e.g., and / or out of the surface) using tubing and other completion equipment. As the fluid flows, various dynamic measurements, such as fluid velocity, pressure, and composition, can be monitored. These parameters can be used to determine various characteristics of subsurface formations, downhole equipment, downhole operations, etc.

[0123] As an example, a system may include a framework that acquires data, such as real-time data associated with one or more operations (such as, for example, one or more drilling operations). As an example, consider the PERFORM toolkit framework (Schlumberger, Houston, Texas).

[0124] As an example, the service may be or may include one or more of OPTIDRILL, OPTILOG, and / or other services sold by Schlumberger Inc. of Houston, Texas.

[0125] OPTIDRILL technology can help manage downhole conditions and BHA dynamics as a real-time drilling intelligence service. This service can be combined with a drilling site display (e.g., a well site display) that integrates downhole and surface data, providing actionable information to mitigate risk and improve efficiency. As an example, such data can be stored in, for instance, a database system (e.g., consider a database system associated with the STUDIO framework).

[0126] OPTILOG technology can help evaluate drilling system performance by measuring drilling dynamics and internal temperatures at single or multiple locations from the recorder. As an example, post-run data can be analyzed to provide input for future well planning.

[0127] As an example, information from a drill bit database can be accessed and utilized. For instance, consider information from Smith Bits (Schlumberger Inc. in Houston, Texas), which may include information from various operations (e.g., drilling operations) associated with different drill bits, drilling conditions, formation types, etc.

[0128] As an example, one or more QTRAC services (Schlumberger, Houston, Texas) can be provided for one or more well site operations. In such examples, data can be acquired and stored, which may include time-series data that can be received and analyzed.

[0129] As an example, one or more MI SWACO services (MI Ltd., Houston, Texas) could be provided for one or more well site operations. For instance, consider value-added well completion and reservoir drilling fluids, additives, cleaning tools, and engineering design services. In such examples, data can be acquired and stored, which could include time-series data that can be received and analyzed.

[0130] For example, one or more ONE-TRAX services can be provided for one or more well site operations (e.g., via the ONE-TRAX software platform, MI Ltd., Houston, Texas). In such examples, data can be acquired and stored, which may include time-series data that can be received and analyzed.

[0131] For example, various operations can be defined with respect to WITS or WITSML, which are acronyms for Well Site Information Transmission Specification or Standard (WITS) and Markup Language (WITSML). WITS / WITSML specifies how drilling platforms or offshore platforms communicate data. For example, for slips, which are components used to clamp and suspend the drill string in a relatively non-destructive manner in a rotary table, WITS / WITSML defines operations such as "bottom to slip" time as the time interval between leaving the bottom and setting the slip for the current connection; "inside slip" as the time interval between setting the slip and releasing the slip for the current connection; and "slip to bottom" as the time interval between releasing the slip and returning to the bottom for the current connection (e.g., setting the bit pressure).

[0132] Well construction can be carried out according to various procedures, which can take many forms. As an example, procedures can be specified digitally and can be, for example, digital plans, such as digital well plans. A digital well plan can be an engineering design plan for constructing the wellbore. As an example, procedures may include well geometry, casing procedures, mud considerations, well control issues, initial drill bit selection, compensation well information, pore pressure estimation, economics, and special procedures that may be used during well construction and production. While drilling procedures can be carefully developed and specified, various conditions may arise that require adjustments to the drilling procedures.

[0133] As an example, adjustments can be made at the drilling site when the acquisition equipment obtains information about conditions, such as the conditions of the drilling equipment, formation conditions, fluid conditions, and environmental conditions (e.g., weather, sea conditions). These adjustments can be made based on the personal knowledge of one or more individuals at the drilling site. For example, an operator might understand that conditions require increasing mud flow, decreasing drilling pressure, etc. Such an operator can evaluate data acquired via one or more sensors (e.g., torque, temperature, vibration, etc.). Such an operator might request the execution of procedures, which could be test procedures to obtain additional data to better understand the actual physical conditions and phenomena that may be occurring or are occurring. The operator may be subject to one or more time constraints that may be driven by physical phenomena, such as fluid flow, fluid pressure, rock compaction, wellbore stability, etc. In such examples, the decisions made by the operator can depend on time as conditions evolve. For example, in an environment with changing fluid pressures, a decision made at one fluid pressure might be suboptimal at another. In such examples, the timing of a decision made as an adjustment to a procedure can have a wide-ranging impact. Adjusting a procedure too late or too early, compared to adjusting it at the optimal time (e.g., and implementing it at the optimal time), can have adverse effects on other procedures.

[0134] As an example, the system may include one or more automated auxiliary features. As an example, consider a feature that can generate and / or receive one or more sequences, which can be used to control drilling operations. In this example, the driller can use the generated sequences to control one or more pieces of equipment to drill a wellbore. As an example, where automation can signal one or more pieces of equipment, the controller can use the generated sequences or a portion thereof for automated control. As explained, where the driller is involved in decision-making and / or control, the generated sequences can be helpful in drilling because the driller can rely on the generated sequences to make one or more adjustments to the drilling operations. Drilling operations can be performed more efficiently, for example, relative to the time required to drill a section, a portion of a section, the entire wellbore, etc., when one or more generated sequences are received in advance and / or in real time. This approach can take into account equipment integrity (e.g., health status, etc.). For example, this approach can take into account the risk of contact between the drill bit body and the formation and / or the performance of the mud motor, which can be used to drive the drill bit.

[0135] Figure 6An example of a graphical user interface (GUI) 600 including information associated with well planning is shown. Specifically, GUI 600 includes a panel 610, where surfaces 612 and 614 are presented along with the well trajectory, and a position 616 may represent the position of the drill string 617 along the well trajectory. GUI 600 may include one or more editing features, such as editing a well planning feature set 630. GUI 600 may include information about individuals in teams 640 who are involved, have been involved, and / or will be involved in one or more operations. GUI 600 may include information about one or more activities 650.

[0136] like Figure 6 As shown in the example, GUI 600 may include graphical control of drill string 660, where, for example, various parts of drill string 660 can be selected to expose one or more associated parameters (e.g., equipment type, equipment specifications, operation history, etc.). Figure 6 In the example, the drill string graphic control 660 includes components such as drill pipe, heavy-duty drill pipe (HWDP), joints, drill collars, slappers, stabilizers, motors, and drill bits. The drill string can be a combination of drill pipe, bottom hole assembly (BHA), and one or more other tools, which may include one or more tools that can help the drill bit steer and drill into material (e.g., formations).

[0137] As an example, the workflow may include using graphical controls on the drill string 660 to select and / or expose information associated with components such as, for example, the drill bit and / or mud motor. As an example, in response to the selection of the drill bit and / or mud motor (e.g., considering a combination of drill bit and mud motor), a computational framework (e.g., via a sequence engine) may generate one or more sequences that can be used to operate the drilling rig, for example, in a specific mode (e.g., sliding mode, rotary mode, etc.). Figure 6 In the example, a graphical control 665 is shown, which can be rendered in response to interaction with the graphical control of the drill string 660, such as in response to selecting the type of component and / or generating one or more sequences.

[0138] Figure 6 An example of Table 670 is also shown, serving as a point spreadsheet specifying information for multiple wells. As shown in example Table 670, coordinates such as “x” and “y” and “depth” can be specified for various characteristics of the wells, including pad parameters, spacing, toe height, step distance, initial inclination, directional drilling, etc.

[0139] Figure 7 This demonstrates an example of a system 700 that can provide services to multiple domains. Figure 7The diagram also illustrates features of the single-domain approach, including domain 702 and a Planning Domain Definition Language (PDDL) runtime 710, which can interact with various other features (see dashed lines, for example). In the single-domain approach, a problem is posed to a PDDL planner using a single domain, and the planner generates a plan in response. The plan may include various actions that can be assigned by a plan dispatcher 760. The PDDL runtime 710 can receive input, to which it responds. For example, a specific input may trigger the PDDL runtime 710 to output a problem to the PDDL planner 750. In the illustrated single-domain approach, a one-to-one relationship exists between domain 702, the PDDL runtime 710, and the PDDL planner 750. In this approach, when the problem is complex, the PDDL planner may spend a considerable amount of time generating a plan, which could impact implementation in real-time implementations and / or other types of time-sensitive implementations.

[0140] For services targeting multiple domains, system 700 includes a multi-domain compiler (MDC) 720, which can handle multiple domains 704-1, 704-2, ..., 704-N via a multi-domain description language (MDDL) 722. In this approach, two or more domains can be utilized, where one or more types of relationships can exist between the two or more domains. For example, consider a parent-child relationship, where the parent domain may be designed to handle the overall objective of a workflow, and the child domain may be designed to handle discrete objectives within the overall objective, such that the overall objective depends on the discrete objectives. In a drilling context, the overall objective might be drilling X feet to extend the wellbore, while the discrete objective might be drilling a stand-up, where the stand-up is Y feet, and Y feet is less than X feet. In this example, it is contemplated that the discrete objective will be executed multiple times, such as, for example, N times. dg N times, of which dg This can be calculated as X feet divided by Y feet. While the previous example refers to a single child, in various implementations there may be more than one child, and for example, one or more grandchildren. Therefore, multi-domain approaches can include hierarchical domains.

[0141] For example, system 700 can provide services for domain 702 and one or more additional domains 704-1, 704-2, ..., 704-N. System 700 can provide such services by implementing a multi-domain compiler 720 and a multi-domain runtime 740.

[0142] In the Java language platform, the Java Runtime Environment (JRE) is a software container for various components that can be executed to instantiate a Java Virtual Machine (VM or JVM) (e.g., using suitable computer hardware). This JVM can then be used to run applications written in the Java language, which can be packaged into files with the ".jar" extension (Java archive files or JAR files). The JRE may also include features such as various Java class libraries and Java class loaders. The JVM is responsible for ensuring that Java applications have the resources to run on devices, cloud environments, etc. As mentioned, Java applications can be packaged into JAR files, which aggregate various Java class files along with associated metadata and resources (e.g., text, images, etc.) into a single file suitable for distribution.

[0143] Regarding "runtime," it can refer to the runtime phase of a program's (e.g., an application's) execution. It can also refer to a runtime system, which includes executable code and appropriate resources for executing the executable code, whereby the runtime system operates during the runtime phase.

[0144] A compiler can take information in one form and output it in another. For example, a compiler can be specified for a programming language to receive source code files (e.g., written in the programming language) and output code suitable for execution in a runtime environment. Consider, for example, Java programming language source code transformed into Java class files containing Java bytecode. In this example, the JVM can translate the Java bytecode into native code. For instance, the JVM can use its execution engine to read the Java bytecode and execute iteratively (e.g., using an interpreter and a just-in-time (JIT) compiler to optimize and translate the bytecode into machine code for execution).

[0145] exist Figure 7 In the example, the multi-domain compiler 720 can utilize one or more domains 704-1, 704-2, ..., 704-N and MDDL 722 to generate a compiled image 724 as an executable file, which can be executed in a runtime environment as shown by the multi-domain runtime 740. The multi-domain runtime 740 is a real-time instance suitable for receiving input, interacting with one or more planners, and generating output.

[0146] exist Figure 7In the example, compiled image 724 includes multi-domain information suitable for the runtime phase, which can formulate the questions submitted to the planner, allowing the planner to generate a corresponding plan in response. As an example, compiled image 724 can be adapted for use in a runtime environment (e.g., a runtime system) where multiple planners can be used to receive one or more questions and generate one or more corresponding plans in response. As an example, where domains can be hierarchical, such as a parent domain with subdomains, sub-questions can be processed in parallel when multiple planners are available. This approach can speed up the runtime process. For example, consider issuing question A to planner 1 and question B to planner 2 essentially simultaneously, where planner 1 returns plan A and planner 2 returns plan B.

[0147] exist Figure 7 In the example, the multi-domain compiler 720 can perform various actions, including error checking, optimization, etc. As an example, the multi-domain compiler 720 can be used in the development phase prior to the runtime phase. As shown, the multi-domain compiler 720 can receive input from one or more domains 704-1, 704-2, ..., 704-N and utilize MDDL 722 to generate a compiled image 724.

[0148] exist Figure 7 In the example, the Multi-Domain Runtime (MDR) 740 can execute a compiled image 724, where various actions can be performed in response to and / or based on one or more inputs. Figure 7 In the example, programs 708-1, 708-2, ..., 708-N are shown as capable of providing one or more inputs to the MDR 740. In this example, the input could come from a piece of equipment, a graphical user interface (GUI) presented to a device display, etc. For example, consider a piece of equipment that includes a network interface that can transmit one or more types of information (e.g., data, status, alarms, etc.) to the MDR 740. This information could, for example, prompt the MDR 740 to formulate a problem and transmit the problem to a PDDL planner 750, which could, for example, generate a plan and return the plan to the MDR 740. In this example, the piece of equipment could be associated with one or more operations designed to perform tasks that can be associated with one or more objectives, etc.

[0149] In an oilfield environment, a piece of equipment can be a drilling rig site system, which may include surface equipment and / or downhole equipment. For example, consider a drilling rig site system that includes surface equipment operatively coupled to downhole equipment (e.g., logging equipment, drilling equipment, fracturing equipment, perforation equipment, cementing equipment, manual hoisting equipment, etc.). As an example, the system may be a drilling operating system that can be operatively coupled to various types of equipment and may include and / or be operatively coupled to... Figure 7 One or more components of the system 700.

[0150] like Figure 7 As shown in the example, MDR 740 can be operatively coupled to planning dispatcher 760, wherein, for example, during the runtime phase of MDR 740 involving the execution of compiled image 724, MDR 740 may optionally issue one or more signals, commands, etc., in response to one or more inputs, which cause planning dispatcher 760 to issue one or more signals, commands, etc., to one or more motion consumers 770, which may include one or more pieces of equipment. In this example, one or more motion consumers 770 may be and / or operatively coupled to one or more programs 708-1, 708-2, ..., 708-N. For example, consider a mobile device executing a program that may present a graphical user interface to the display of the mobile device, which allows the user to emit inputs to MDR 740 and receive information directly and / or indirectly from planning dispatcher 760. In this example, a loop may exist between dispatch information (e.g., MDR output) from MDR 740 and inputs to MDR 740. Such a loop may include multiple action consumers in one or more action consumers 770. As an example, action consumers, loops, etc., may be automatic or semi-automatic. For example, a semi-automatic loop may include a device with a display and executable instructions for presenting one or more GUIs, wherein human interaction with the device can prompt an action to be performed, confirm the performance of an action, indicate that an action has not been performed, indicate the presence of a problem, etc. This type of interaction can generate input to MDR 740, which, as explained, can formulate a problem (e.g., serial, parallel, etc.) suitable for being emitted to one or more PDDL planners, wherein the problem may be associated with one or more domains (e.g., see domains 704-1, 704-2, ..., 704-N).

[0151] As an example, the MDR 740, the planning dispatcher, one or more action consumers 770, etc., may utilize specific types of protocols. For example, consider using Uniform Resource Locators (URLs), which may include short URLs and / or long URLs. Such outputs can be routed to one or more appropriate destinations (e.g., an equipment as a destination, a mobile device as a destination, a database as a destination, etc.) via one or more network devices.

[0152] exist Figure 7 In this example, MDR 740 can operate in a manner dependent on the input, such as triggering a problem in response to the input. In this example, MDR 740 can be part of a control system (e.g., a controller, etc.), where the input can be real-time input from equipment, etc. In this example, the time for output by MDR 740 (e.g., output to planning dispatcher 760, output to at least one of one or more action consumers 770, etc.) can be reduced, especially when using a multi-domain approach. As explained, when using multiple domains, the planning generation of PDDL planner 750 (e.g., or PDDL planner) can be reduced, said multiple domains may include parent, child, grandparent, grandchild, etc. As mentioned, domains can be hierarchical. As an example, one or more domains can be nested, e.g., within a domain, between domains, etc. As explained, MDDL 722 can provide the use of multiple domains, such that MDC 720 can generate a compiled image 724 as an executable for execution as MDR 740 during the runtime phase.

[0153] As an example, a multi-domain action workflow may include a compilation phase and a runtime phase. In this example, the compilation phase may utilize the MDC 720, and the runtime phase may utilize the MDR 740, which may be used, for example, in an interactive process designed to achieve one or more objectives through various actions.

[0154] As an example, system 700 can provide multi-domain planning execution for one or more oilfield operations. For instance, consider a well construction operation designed to perform one or more operations for constructing a well in a subsurface environment. In this example, system 700 can provide coordination of multiple PDDL plans from different domains regarding the automation of the well construction process.

[0155] like Figure 7As shown in the example, system 700 includes MDDL 722, which can be a programming language type that allows PDDL domain authors to build and allows multiple PDDL domains to interact with each other. In this approach, source code and PDDL domain files can be input into MDC 720, enabling MDC 720 to compile an image that can be loaded into the same framework to be executed for an actual drilling operation, another instance of the same framework, another framework, etc. At runtime, for input purposes, the runtime environment may include and / or be operatively coupled to one or more sources. As mentioned, MDR 740 can accept input from one or more other programs, frameworks, etc., and use said input to formulate one or more problems and / or execute one or more PDDL plans. In this example, the execution of the plan may lead to the dispatch of one or more actions, such as those for equipment, programs, applications, etc.

[0156] As an example, Figure 7 System 700 can handle multiple planning domains in a cohesive manner (e.g., a unified manner), where, for example, dispatching actions in one domain can prompt the execution of plans in another domain. As explained, system 700 can be customized to automate oilfield drilling equipment and, for example, one or more types of actions that optionally involve human interaction (e.g., via various human input devices (HID)).

[0157] like Figure 7 As indicated, system 700 may include one or more loops, which may be or include one or more feedback loops. For example, during the execution of actions that may be performed via one or more pieces of equipment, one or more sensors and / or other devices may generate signals and / or signal absences, which may be used by system 700 as feedback, and the feedback may be or notify one or more inputs of MDR 740. In this example, one or more pieces of equipment, etc., may be used to implement one or more types of automatic or semi-automatic control to perform one or more physical operations.

[0158] As an example, one or more parts of system 700 may operate as a controller, which may be a multi-domain controller. For example, the MDR may receive one or more types of input that may depend on one or more types of feedback, such that the planning dispatcher 760 may dispatch one or more plans, revised plans, etc., to one or more action consumers in action consumers 770, which, as mentioned, may include one or more pieces of equipment capable of performing one or more physical operations (e.g., physical tasks related to producing one or more products, regulating one or more materials, altering one or more geological structures, inducing one or more fluid flows, etc.). As an example, a wellbore may be a product produced by drilling as a physical operation of breaking and removing rock from a formation. In this example, the wellbore may serve as a physical path for further drilling. As an example, a wellbore may serve as a physical path for fluid flow, equipment movement, material (e.g., rock, etc.) movement, etc. As explained, in the oil and gas industry, a wellbore may be formed to reach a fluid reservoir, through which fluid may be generated from the reservoir. In this example, various pipes and materials (e.g., cement, etc.) may be used to complete the wellbore by forming a well completion.

[0159] like Figure 7 As shown in the example, system 700 may include MDC 720 and MDR 740, which may be a single instance of a program operating in two different modes (e.g., compile mode and runtime mode), multiple instances of a program operating in different modes, and / or multiple instances of a dedicated program, wherein the program may be dedicated to operating in compile mode and the program may be dedicated to operating in runtime mode.

[0160] exist Figure 7 In one example, system 700 may include a circuit system (e.g., hardware, software, and other hardware) that compiles and executes multiple PDDL planning domains for the automation of real-time well construction operations. As an example, this approach may include a circuit system for coordinating recording, playback, and commissioning facilities for multiple PDDL planning domains through multi-mode operation.

[0161] While the framework, including features for instantiating MDC 720 and MDR 740, can be targeted at oilfield well construction, it can be applied to one or more other types of problems, including one or more other types of oil and gas automation problems. The various features, along with MDDL 722 for coordinating multiple PDDL domains, can facilitate rapid iteration of more complex domain models that can demonstrate to non-technical personnel how machine model behavior (e.g., artificial intelligence) will operate in production.

[0162] As an example, various features of system 700 can be instantiated as XPlan Operations Producer (XPOP) that provides facilities for developing any number of PDDL domains that can interact with each other so that they can be executed at a later time, wherein one or more other programs, devices, equipment, etc. can consume the dispatched actions generated.

[0163] As an example, a domain author can construct several domains that can be related to each other in one or more ways. Consider, for example, a series of parent and child domains, or a parent domain with multiple independent child domains. Utilizing parent-child relationships, when an action is dispatched in the parent domain, that action can generate a plan for the child domain; this can occur at runtime. As an example, a domain can depend on information from another domain to progress on its proposed plan created by the PDDL planner. To facilitate this information sharing, XPOP can provide appropriate syntax and logic in one or more ways. Figure 7 As shown in the example, system 700 includes a multi-domain description language (MDDL) 722, which may be or include a programming language that provides appropriate syntactic constructions for describing one or more types of relationships between domains.

[0164] Figure 8 An example of code 800 is shown, which may be presented to a display, for example, using one or more GUIs, where a user can generate appropriate code using a keyboard, mouse, etc., and the code may be automatically highlighted, inspected, etc. (e.g., consider a program editor).

[0165] exist Figure 8 In the examples, the code 800 example is shown as runtime code, which, as mentioned, can be an error-checked version, an optimized version, etc. Figure 8 In the example, the domain relates to the action of baking bread, where there are two available ovens and any number of different types of bread dough to be baked. Before a single instance of dough is baked, that single instance first needs to be mixed (e.g., considering the constraints of a single mixer), and a sufficient amount of time is required to rest before baking. In this example, a PDDL planner can be used to address the following questions: (i) what dough will be mixed, and (ii) when (iii) the dough will be baked in a specific oven in order to (iv) reduce the total amount of time required to bake all the doughs. In this example, it should be noted that (i), (ii), and (iii) will be parts of a single problem within a single domain (e.g., considered as a single domain in its entirety). In the XPOP approach, the "problem" can be multi-domain, where XPOP can coordinate multiple domains, coordinate calls to the PDDL planner, and coordinate how the results of the derived plan are distributed. Figure 8The examples also aim to demonstrate how the framework enabling the MDC 720 and MDR740 can be applied to non-oilfield operations (e.g., non-oilfield domains or a hybrid of oilfield and non-oilfield domains).

[0166] exist Figure 8 At the bottom of code 800, there is a ':action-dispatch' clause that states the dough mixing action from the bread domain. When this clause is dispatched, the bread mixing action from the mixing domain is invoked. This serves as an example of the various features provided by runtime PDDL that the authors can combine with PDDL domains, where XPOP methods can produce a compiled image that can be loaded into the XPOP framework (e.g., the runtime environment) at the desired time, such as in a production environment.

[0167] As explained, both the Java ecosystem and the .NET ecosystem have runtime environments, with the .NET ecosystem providing corresponding runtime phases, where the preceding phase can be considered the compilation phase. For example, developers can use Java to compile programs into .jar files, or .NET to compile programs into .exe files. In such examples, the .jar file can be executed using the JRE, and the .exe file can be executed using the .NET runtime environment.

[0168] exist Figure 7 In the example, when the compiled image 724 is utilized in the runtime phase represented by MDR 740, MDR 740 can operate in a conditional manner. For example, the MDR may not execute machine instructions directly from the compiled image 724; instead, it may receive one or more external signals to initiate a problem, call an external PDDL planner one or more times to receive multiple PDDL plans to be executed, and subsequently request the dispatch of one or more corresponding actions of such plans, for example, using one or more of HTTP, RabbitMQ calls, API calls, etc., which can be executed by an external program. As an example, the MDR may be part of a control system (e.g., a controller, etc.) that responds to input, where, depending on the input, the control system may request the generation of plans, where such plans may include one or more actions that can be dispatched for purposes such as control.

[0169] As an example, domain authors can use MDC 740 (such as the XPOP compiler) to perform interactive development of one or more domains from multiple domains.

[0170] Figure 9An example of a graphical user interface (GUI) 900 is shown, which includes a bread baking example with three different domains. For example, GUI 900 could be a compiler-developed user interface for displaying multiple PDDL domains that can be coordinated. As shown, the top-level domain contains the dough-mixing action, highlighted in blue, which is currently being dispatched for execution. However, this action is not intended to be performed by an external program or machine, but rather to instantiate a subproblem of dough mixing, which is the plan shown below it. This new subproblem contains its own dough-mixing action, which is further expanded into another subproblem to be executed, becoming the lowest-level plan containing two actions: mixing and removal. The mixing action has now been dispatched, and since it does not include its own subdomain, it is dispatched to an external consumer for actual execution. Figure 9 In the example, the relationship can be described in one or more runtime files, such as using MDDL, like MDDL 722 for system 722.

[0171] It is possible to see example outputs of this multi-domain hierarchical structure because domain authors can provide simulated inputs that can be received by frameworks (such as multi-domain frameworks, XPOP frameworks, etc.) at runtime.

[0172] Figure 10 Examples of graphical user interfaces (GUIs) 1010 and 1030 are shown. Figure 10 The example demonstrates simulated input, where the author can also see the output of its defined function from a runtime file (e.g., a compiled image). Figure 10 In this example, GUI 1010 includes various "atomic" factors, such as altitude, brick oven, kitchen oven, and mixer connection, while GUI 1030 includes various edits for the brick oven (e.g., brick oven atoms), such as cleaning time, temperature, characteristic quality, characteristic maximum temperature, etc. Example GUIs 1010 and 1030 can serve as development interfaces for inputting simulated inputs.

[0173] Figure 11 This example demonstrates GUI 1100 using another user interface label, showcasing various outputs of a defined function, such as those corresponding to... Figure 10 Analog inputs. For example, the GUI 1100 can be used to present runtime PDDL outputs with analog inputs.

[0174] exist Figure 9 , Figure 10 and Figure 11 The example demonstrates various graphical controls such as play, rewind, and fast forward controls, which can be placed on top of the GUI to allow playback functionality, for example, because the user can simulate different inputs at different points in time.

[0175] As explained, the development phase may include the implementation of various features, which may be associated with a compiler. For example, once development is complete, a compiled image can be generated, which can be used in the runtime phase, and can be incidental, responsive, etc., to one or more inputs. In this example, where the framework includes MDC and MDR, MDR can be instantiated for use in the runtime phase (e.g., runtime mode, etc.) where the compiled image can be loaded and run.

[0176] As an example, a compiled image may include various components that can, for example, be provided autonomously for runtime execution. During runtime, the MDR may receive input from one or more external programs, devices, etc. This input may be numbers for computation, natural language, signals that begin a problem statement from a specific domain, etc. As an example, the runtime may be configured to accept input defined as permitted by a runtime PDDL file (e.g., an earlier build). For example, in Figure 8 In the context of the bread domain, there exists a problem called "Baking Bread," which can be initiated by an external program. When a framework (such as MDR) receives this problem signal at runtime, it can begin the appropriate dispatch process.

[0177] like Figure 7 As shown in the example, the MDR 740 can issue a call to the PDDL planner 750 to create a plan, where the PDDL planner 750 can be within a shared framework with the MDR 740 or in a separate framework. As an example, the PDDL planner 750 can be accessed via a network. As mentioned, the MDR can be configured to issue one or more calls to one or more PDDL planners (e.g., serial, parallel, etc.).

[0178] As an example, a PDDL planner could be a program that receives a domain file describing what is being modeled and a problem file describing the current state of the world, the domain file being the same PDDL domain created during the development phase. Figure 7 As shown in the example, the problem file can be generated by an MDR 740 (e.g., XPOP MDR, etc.), where the generated output is determined by various functions written in a runtime PDDL file. As an example, the input can come from one or more external programs that operate at runtime and provide such input. As an example, after the PDDL planner "finds" a suitable plan for the action to be performed, the MDR can dispatch the action using the plan; for example, the MDR 740 can dispatch or can be operatively coupled to a dispatcher, such as a plan dispatcher 760. As explained, the dispatched action can be directed to one or more external consuming programs, devices, etc., for example, which are expected to perform such one or more actions based on semantic meaning.

[0179] Regarding examples within oil well construction, it is anticipated that the action execution unit will translate actions into one or more low-level instructions for hardware control. For instance, the MDR may prompt an assignment to perform an action called "pump shutdown," where the action execution program is expected to translate the action into an appropriate electrical signal to shut down the mud pump on the oil rig.

[0180] As explained, multi-domain planning can improve various types of operations, including, as mentioned, real-time operations. As an example, multi-domain planning can provide reuse, for instance, during the development phase. As mentioned, multi-domain planning can provide scenarios where actions from multiple domains will be performed simultaneously, in parallel, etc., where such actions may be part of a corresponding plan, where each plan may respond to a problem and be output by one or more PDDL planners. In this example, the problem may respond to one or more inputs, which may come from one or more different programs, devices, etc.

[0181] As an example, in oilfield drilling operations, a well can be constructed by drilling multiple standoffs to reach the desired underground depth. In this example, the standoffs may consist of drill pipes joined together, resulting in a standoff length of approximately 90 feet (e.g., approximately 30 meters). The standoffs themselves may be attached to a drill string including a bottom hole assembly (BHA) (e.g., forming a connection), which has a drill bit at its end that can rotate to drill through rock, etc. Once the standoffs have been "drilled" (deepening the wellbore by approximately 90 feet), the drill string, including various individual connecting drill pipes, can be lifted off the bottom ("off the bottom") and placed in "slips" to suspend the drill string, allowing the drilling rig to be used to lift and position new standoffs. Once a new standoff is attached to the drill string, the slips can be released (e.g., "removed from slips"), the drill string rotates, and it is lowered in the wellbore, allowing the drill bit to reach the "bottom," enabling drilling to continue penetrating the rock to deepen the wellbore. Drilling operations can also include various other actions, such as drilling fluid-related actions (e.g., mud pump actions) and exploration actions (e.g., exploration during "kava"). Therefore, stand-to-stand drilling can incorporate various types of actions, including those unrelated to moving or positioning the drill pipe.

[0182] As an example, drilling a stand can involve various actions, such as rotating and lowering the drill string "away from the bottom" until the drill bit contacts the bottom of the wellbore ("on the bottom") while drilling through the rock continues, with the mud pump in operation. As mentioned, when drilling a stand is completed, various actions can include stopping rotation, lifting the drill bit away from the bottom, entering the slips, shutting off the mud pump, making a connection, disengaging from the slips, turning on the mud pump, rotating, reaching the bottom, etc.

[0183] Figure 12Examples of GUIs 1210 and 1230 demonstrate the planning of drilling a single standroot, where the dominant action is drilling the connection, as this action is likely to be the one that takes the most time to complete. GUI 1210 displays various graphs that can be segments, where the width of the segment can correspond to a time amount, such as the expected time amount for executing the planned action. Regarding GUI 1230, it displays a graph of GUI 1210 along with a graph of an upper plan that will drill to a specific depth and includes the action of drilling a single standroot during execution. As shown, the upper plan may include "drilling a standroot with a friction test."

[0184] As an example, a question can be given to the PDDL planner, and in response, a plan can be generated in about 100 milliseconds (e.g., using a computer with sufficient processing power and memory).

[0185] Therefore, as an example, given the problem of drilling a stand, a plan for drilling the stand can be generated. As an example, the workflow could aim to drill multiple stands, such that the goal could be to create a plan where drilling multiple stands is scheduled. However, as mentioned, there may be one or more types of intermediate actions that can occur between stands (e.g., after drilling stand X and before drilling stand X+1), which may be related to drilling operations. In this example, the drilling PDDL domain can be configured to provide such multiple stands and intermediate actions; however, in this single-domain approach, the PDDL planner is scheduling many operations, and the time taken to derive the location of combining multiple such stand plans can be exponentially multiple of the time taken to drill the stated number of feet. For example, calculating a plan to drill a few hundred feet might take about half a second, while calculating a plan to drill a few thousand feet might take several minutes. This exponential increase in time can have a significant impact on the availability and cost of drilling operations, as activities not involving drilling physical actions are considered non-productive time (NPT). Oilfield operations may involve continuously measuring NPT and seeking ways to reduce it. While a single-domain approach may be suitable for generating feasible plans, the cost of doing so can obscure real-time operations and render the approach impractical. Instead, NPT can be reduced or eliminated where planning time can be minimized. Furthermore, details, domains, operations, etc., can provide a more optimized way to customize planning and (therefore) operations, which may include real-time operations.

[0186] As an example, the multi-domain approach can leverage PDDL planning for drilling, where multiple domains can be strategically created. For instance, one domain might be considered to schedule the number of standoffs to be drilled and any intermediate actions, while another domain is considered for drilling the standoffs.

[0187] exist Figure 12As mentioned, GUI 1230 demonstrates an example where the upper plan is a series of actions for "drilling depth," and the blue actions highlighted in the plan are "drilling stand" (e.g., drilling a single stand). In the experimental workflow, the PDDL planner spends approximately 100 milliseconds planning the drill depth and another approximately 100 milliseconds planning the sub-drilling stand. This example demonstrates sequential planning, but it should be noted that the parent plan can have two sub-plans running in parallel. In this scenario, a system such as System 700 could, for example, use two different instances of the PDDL planner to plan in parallel.

[0188] As explained, the multi-domain approach can coordinate this type of planning at runtime and can facilitate one or more types of corrective actions. For example, if a sub-plan in GUI 1230 fails because the user or drilling rig machinery acts in a way that deviates from the plan, the multi-domain approach can replan the sub-plan individually, which would include a new set of actions that still achieve the desired objective. In this example, the replanning can be performed without interrupting the execution of the parent plan; this minimizes the time requirement for computing such plans. As explained, the Multi-Domain Description Language (MDDL) can be used to describe the relationships between different PDDL domains (a situation unknown to the PDDL planner).

[0189] Figure 13 This demonstrates an example of code 1300 used for the drill depth PDDL field, while Figure 14 An example of code 1400 for a corresponding runtime file (e.g., components of the runtime file) is shown, which specifies that when the actions drillAStand, drillLastStandToTargetDepth, drillAStandWithFrictionTest, or drillLastStandToTargetDepthWithFrictionTest are dispatched, the MDR will again invoke the PDDL planner to plan a specific problem within the DrillAStand domain. For example, the MDC 720 may use MDDL 722 to output a compiled image 724, which may include various components of the runtime phases as shown via the MDR 740, wherein one or more programs, such as programs 708-1, 708-2, ..., 708-N, may optionally provide input in response to the operation of the planner dispatcher 760, causing the MDR 740 to invoke the PDDL planner 750 to plan the DrillAStand domain (e.g., as domains 704-1, 704-2, ..., 704-N).

[0190] Figure 13Example code 1300 is shown below, including a header with units, predicates, and a list of functions. Note that the following items are less than 60 lines long.

[0191]

[0192]

[0193] Figure 14 Example code 1400 is shown below. Note that the following items have fewer than 60 lines.

[0194]

[0195]

[0196] Figure 15 An example of method 1500 for performing drilling operations using drilling equipment is shown. As an example, one or more actions of the drilling operation in method 1500 can be optionally planned, for example, using a system such as... Figure 7 System 700.

[0197] like Figure 15 As shown, the drilling equipment includes a drilling rig 1501, a hoisting system 1502, a pulley 1503, a platform 1504, slips 1505, and a bottom drill string assembly 1506. As shown, the drilling rig 1501 supports the hoisting system 1502, which provides movement of the pulley 1503 above the platform 1504. The slips 1505 are used to support a drill string including the bottom drill string assembly 1506, which is shown as including a drill bit that drills into the formation to form a wellbore.

[0198] Regarding the drilling operations, the operations include: a first operation 1510, which completes the erection of the drill string (erector X); a second operation 1520, which pulls the drill string away from the bottom of the wellbore by moving the sled 1503 upward and supports the drill string in the platform 1504 using slips 1505; a third operation 1530, which adds an erection (erector X+1) to the drill string; and a fourth operation 1540, which removes the slips 1505 and lowers the drill string to the bottom of the wellbore by moving the sled 1503 downward. See also... Figure 1 , Figure 2 , Figure 3 , Figure 4 , Figure 5 and Figure 6 This explains various details of examples of equipment and operations.

[0199] As an example, drilling operations can utilize one or more types of equipment to drill, which can provide a variety of drilling modes. As explained, as the wellbore is deepened by drilling, standoffs can be added to the drill string. A standoff can be one or more sections of drill pipe; it should be noted that drill pipe-by-pipe or hybrid standoff methods can be used.

[0200] exist Figure 15 In the examples, operations 1510, 1520, 1530, and 1540 can take a period of time. For example, consider the amount of time spent positioning and connecting a stand to another stand on the drill string. The stand length can be approximately 30 meters, with precautions taken to avoid harmful contact between the stand (metal or metal alloy) and other equipment or personnel. During this period, one or more types of calculations, computations, communications, etc., can be performed. For example, the driller can perform wellbore depth calculations based on the measured stand length, etc. As an example, the driller can analyze survey data obtained from one or more downhole tools on the drill string. This survey data can help the driller determine whether the planned or desired trajectory is being followed, which can help inform the driller about how to drill for an increase in wellbore depth approximately corresponding to the length of the added stand.

[0201] As an example, in the case of using a top drive unit (e.g., trolley 1503 is considered to include a top drive unit), when the top drive unit approaches platform 1504, rotation and circulation can be stopped, and the drill string is lifted a certain distance from the bottom of the wellbore. When the top drive unit is to be coupled to another stand, it will be disconnected, meaning the drill string will be supported, which can be achieved using slips 1505. Slips 1505 may be positioned on a portion of the last stand (e.g., drill pipe) to support the weight of the drill string, allowing the operator to disconnect the top drive unit from the drill string, for example, using a top drive drill pipe handler. Once disconnected, the driller can then raise the top drive unit (e.g., trolley 1503) to a suitable level, such as finger beam level, where another drill pipe stand (e.g., approximately 30m) can be delivered to a set of drill pipe clips suspended on the top drive unit. The stand (e.g., stand X+1) can be raised and inserted into the drill string. The top drive unit can then be lowered until its drive rod engages the upper connector of the stand (e.g., stand X+1). The top drive motor can be engaged to rotate the drive rod, causing the upper and lower connectors of the stand to form simultaneously. In this example, a spare tong can be used at platform 1504 (e.g., drill rig) to prevent drill string rotation during connection. After the connector is properly formed, slips 1505 can be released (e.g., disengaged). Drilling fluid (e.g., mud) circulation can begin (e.g., resume), and once the drill bit of bottom drill string assembly 1506 contacts the bottom of the wellbore, drilling can be performed using the top drive to deepen the wellbore. The entire process, from slips being placed on the drill string (e.g., inside slips), adding a new stand, forming the connector, and slips being released (e.g., disengaged), allowing drilling to resume, can take approximately tens of seconds to several minutes, typically less than 10 minutes under normal and expected conditions.

[0202] Regarding the aforementioned top drive method, compared to kerb drilling (e.g., rotary table drilling), the process of adding new drill string stands and drilling down to the platform (e.g., derrick) involves fewer actions and requires less drilling crew involvement. Drillers and drilling crews can use top drives relatively skillfully. Built-in features such as thread compensation, remotely controlled valves to stop drilling fluid flow, mechanisms for tilting the jacks, and connections to derrickmen or derrick teams enhance the speed, convenience, and safety associated with top drive drilling.

[0203] As an example, while top drive can be used when drilling with a single (e.g., 10m long) stand, greater benefits can be achieved by using three drill pipes (e.g., drill pipe stands). As explained, the entire drill pipe stand can be drilled down in one go as the drill pipe is supported and rotated from the top. This method extends the time the drill bit spends at the bottom and can contribute to a cleaner wellbore. Compared to keel drilling, where a single stand is drilled down and then connected, top drive drilling allows for faster drilling by reducing the need for two-thirds connections.

[0204] As mentioned, the well can be a directional well constructed using directional drilling. Directional wells have brought benefits to oil and gas production, especially in unconventional oil and gas reservoirs, where horizontal and extended reach wells can help maximize wellbore exposure through the production zone.

[0205] One or more of various technologies can be used in directional drilling. For example, consider a steerable mud motor that can be used to achieve a desired wellbore trajectory to reach and / or through one or more target areas. As an example, directional drilling operations may use downhole mud motors during well opening, build-up, drill-cut sections, and trajectory maintenance.

[0206] A mud motor may include a bend in the motor bearing housing for guiding the drill bit to a desired target. The bend may be surface-adjustable (e.g., a surface-adjustable bend (SAB)) and may be set at angles within an operating angle range (e.g., consider 0 to approximately 5 degrees, 0 to approximately 4 degrees, 0 to approximately 3 degrees, etc.). The bend may be designed to be sufficient to point the drill bit in a given direction while being small enough to allow the entire mud motor assembly to rotate during rotary drilling. The deflection produced by the bend can be a factor determining the rate at which the mud motor can build an directional borehole to the desired wellbore. By orienting the bend in a specific direction (called the tool face angle), drilling operations can alter the inclination and azimuth of the wellbore trajectory. To maintain the orientation of the bend, the drill string operates in a sliding mode, where the entire drill string itself does not rotate within the wellbore (e.g., via a top drive, rotary table, etc.), and where the rotation of the drill bit for drilling is driven by the mud motor of the drill string.

[0207] A mud motor is a type of positive displacement motor (PDM) powered by drilling fluid. As an example, a mud motor may include an eccentric helical rotor and a stator assembly drive. When drilling fluid (such as mud) is pumped downhole, the fluid flows through the stator and causes the rotor to rotate. The mud motor converts hydraulic power into mechanical power to rotate a drive shaft, which in turn causes a drill bit operatively coupled to the mud motor to rotate.

[0208] By using a mud motor, directional drilling operations can alternate between rotary drilling and sliding drilling modes. In rotary mode, the rotary table or top drive is operated to rotate the entire drill string to transmit power to the drill bit. As mentioned, rotary mode can include a combination of rotation via surface equipment and rotation via the downhole mud motor. In rotary mode, rotation causes the bends in the motor bearing housing to point equally in the intersecting directions, thereby maintaining a straight drilling path. As an example, one or more measurement-while-drilling (MWD) tools integrated into the drill string can provide real-time inclination and azimuth measurements. These measurements can be used to alert the driller, controllers, etc., to one or more deviations from the desired trajectory (e.g., the planned trajectory). To adjust for deviations or change the trajectory, drilling operations can switch from rotary mode to sliding mode. As mentioned, in sliding mode, the drill string does not rotate; instead, the downhole motor rotates the drill bit and drills the wellbore in the direction the drill bit is pointing, which is controlled by the motor tool face orientation. When adjusting the route and re-establishing the desired trajectory to hit the target (or multiple targets), the drilling operation can switch from sliding mode to rotating mode, which, as mentioned, can be a combination of surface rotating mode and downhole rotating mode.

[0209] In both modes, sliding drilling in sliding mode tends to be less efficient; therefore, lateral extension may come at the cost of rate of penetration (ROP). The ROP achieved using sliding technology is approximately 10% to 25% of the ROP that can be achieved using rotary technology. For example, when the mud motor operates in sliding mode, the axial drag force in the bend and / or lateral sections is used to reduce the effect of surface weight, so that the surface weight is not effectively transferred downhole to the drill bit, resulting in a lower ROP and lower drilling efficiency.

[0210] Various types of automated systems (such as automated drilling rigs) can be designed to help drilling operations achieve gains in horizontal extension at significantly faster drilling rates.

[0211] When transitioning from rotary to sliding mode, the drilling operation can stop the rotation of the drill string and initiate sliding by directional drilling, aligning the drill bit with, for example, the trajectory outlined in the drilling plan. Regarding stopping the rotation of the drill string, as an example, consider a drilling operation that pulls the drill bit away from the bottom and reciprocates the drill pipe to release the torque accumulated within the drill string. The drilling operation can then use real-time MWD toolface measurements to orient the downhole mud motor to ensure the desired wellbore deviation is achieved. Following this relatively time-consuming orientation process, the drilling operation can set the top drive brake to prevent further rotation from the surface. In this example, sliding drilling can begin as the drilling operation releases the winch brake to control the hook load, which in turn affects the magnitude of the weight applied to the drill bit (e.g., WOB). As an example, small left and right torque adjustments (e.g., clockwise and counterclockwise) can be manually applied to guide the drill bit as needed to keep the trajectory on track.

[0212] As depth or lateral extension increases, the drill string tends to experience greater friction and drag. These forces, in turn, affect the ability to transfer weight to the drill bit (e.g., WOB) and the ability to control tool face orientation during slippage, potentially making it more difficult to achieve adequate ROP and maintain the desired trajectory to the target (or multiple targets). Such problems can lead to increased drilling time, which can adversely affect project economics and ultimately limit the length of the lateral sections of the wellbore, and thus the length of the lateral sections of the completion (e.g., production wells).

[0213] The ability to transfer weight to the drill bit affects several aspects of directional drilling. As an example, drilling operations can transfer weight to the drill bit by releasing or loosening the brakes, which can transfer some of the hook load or drill string weight to the bit. The difference between the weight applied to the drill bit and the weight obtainable by releasing the actuators at the surface is primarily due to drag. As the horizontal deviation of the wellbore increases, the longitudinal drag of the drill string along the wellbore tends to increase.

[0214] Throughout the slippery mode, drill string elasticity can make weight control at the drill bit more difficult, allowing disproportionate drill string movement. This elasticity can cause one section of the drill string to move while other sections remain stationary or move at different speeds. Conditions such as poor wellbore cleaning can also affect weight transfer. In slippery mode, wellbore cleaning efficiency tends to be lower due to insufficient drill string rotation; it should be noted that drill string rotation contributes to turbulence in the annulus between the drill string (drill string or standpipe) and the wellbore and / or casing sections. Poor wellbore cleaning is associated with the ability of drilling fluid (e.g., mud) to carry solids (e.g., gravel). When solids accumulate on the lower side of the wellbore due to gravity, the cross-sectional area of ​​the wellbore can decrease, leading to increased friction on the drill string (e.g., drill pipe or standpipe), which can make it more difficult to maintain the required weight on bit (WOB), which can be the desired constant WOB. As an example, poor wellbore cleaning can increase the risk of sticking (e.g., stuck pipe).

[0215] The frictional difference between the drill string inside the casing and the drill string in the open well can cause a sudden release of weight, similar to problems that can arise from keyways and bushings. A sudden transfer of weight to the drill bit exceeding the downhole motor's capacity can cause the drill bit to stop rotating abruptly and the motor to stall. Frequent stalls can damage the stator components of the mud motor, depending on the weight transferred. Drilling operations can aim to operate the mud motor within a relatively narrow load range in an effort to maintain an acceptable ROP without stalling.

[0216] As an example, the system may include a console that may include one or more displays that can present one or more graphical user interfaces (GUIs) including data from one or more sensors. As an example, an impending stall may be indicated by an increase in the WOB (Wastewater Obstruction) as presented to the GUI, for example, where there is no corresponding increase in downhole pressure to indicate that the increase in downhole WOB has actually occurred. In this example, at a certain point in time, the WOB indicator may show a sudden decrease, indicating a sudden transfer of force from the drill string to the drill bit. The increase in drag hinders the ability to remove downhole torque, making it more difficult to set and maintain toolface orientation.

[0217] Tool face orientation can be affected by torque and WOB (Working Object). When weight is applied to the drill bit, the torque at the drill bit tends to increase. As mentioned, torque is transmitted downhole through the drill string, which is typically operated to drill by turning clockwise to the right. When weight is applied to the drill bit, a counter-torque is generated in the opposite direction. Due to the drill string's elastic flexibility in the torsional direction, this left-handed torque (e.g., counter-torque in the counter-clockwise direction) tends to twist the drill string. In such cases, the motor tool face angle may rotate with the torsion of the drill string. When drilling operations attempt to orient the mud motor tool face from the surface, the torsional angle attributable to the counter-torque can be considered. Counter-torque tends to accumulate with increasing weight, reaching its maximum value, for example, when the mud motor stalls. As an example, counter-torque can be considered when drilling operations attempt to orient the mud motor from the surface. In practice, drilling operations can be used to slightly shift the tool face orientation by changing the downhole WOB, thereby altering the counter-torque. To achieve significant changes, drilling operations can lift the drill bit off the bottom and reorient the toolface. However, even after achieving a designated toolface orientation, maintaining that orientation can sometimes be challenging. As mentioned, longitudinal drag tends to increase with lateral extension, and the weight transferred to the drill bit can become more unstable along the length of the horizontal section, thereby accumulating counter-torque and thus altering the toolface angle. The effort and time spent orienting the toolface can adversely affect the rig's production time.

[0218] As explained, directional drilling can involve operating in both rotary and sliding modes, with multiple transitions between these two modes. As mentioned, drilling fluid can be used to drive the downhole mud motor, thus rotating the drill bit in sliding mode, while surface equipment can be used to rotate the entire drill string (e.g., rotary table, top drive, etc.) in rotary mode, optionally in combination with the drilling fluid used to drive the downhole mud motor (e.g., combined rotary mode). Directional drilling operations can depend on various factors, including operating parameters that are at least partially controllable. For example, one or more factors such as mode switching, lift, WOB, RPM, torque, and drilling fluid flow rate can be controlled during drilling operations.

[0219] As mentioned, well construction can include various operations, processes, etc. As explained, such operations can be defined using multiple domains. As an example, domains can include domains for different drilling modes, such as a sliding domain for a sliding mode and a rotating domain for a rotating mode. As an example, such as... Figure 7 The 700 system can be used for multi-domain planning, planning generation and planning execution, and optionally has replanning capabilities.

[0220] As an example, the framework can leverage the Representational State Transfer (REST) ​​API, which is a style that defines a set of constraints used to create web services. Web services conforming to the REST architectural style (referred to as RESTful web services) provide interoperability between computer systems on the Internet. RESTful web services allow one or more requesting systems to access and manipulate a textual representation of a web resource using a uniform and predefined set of stateless operations. One or more other types of web services (e.g., SOAP web services) can be utilized, which can exhibit their own set of operations.

[0221] As an example, a computational controller of equipment operatively coupled to a drilling rig site (e.g., a well site) can interact with a computational framework using one or more APIs, the computational framework including one or more features of the system, such as, for example Figure 7 System 700. In this example, one or more calls can be made, where one or more actions (e.g., control actions for drilling) are provided in response. In this example, the controller can transmit and utilize actions to control drilling at the drilling rig site.

[0222] Figure 16An example of method 1600 is shown, the method comprising a publishing block 1610, configured to, in response to input, issue a call to a Planning Domain Definition Language (PDDL) planner in a runtime environment (e.g., considering one or more physical operations that can be performed using one or more pieces of equipment) for compiled multi-domain code describing multiple different domains of a physical operation; a receiving block 1620, configured to, in response to the call, receive a plan including at least one action; and a scheduling block 1630, configured to dispatch at least one of the at least one actions to request the execution of at least a portion of at least one of the physical operations.

[0223] Method 1600 is shown as including various computer-readable storage medium (CRM) blocks 1611, 1621 and 1631, which may include processor-executable instructions that may instruct a computing system (which may be a control system) to perform one or more of the actions described with respect to method 2900.

[0224] exist Figure 16 In the example, system 1690 includes one or more information storage devices 1691, one or more computers 1692, one or more networks 1695, and instructions 1696. Regarding the one or more computers 1692, each computer may include one or more processors (e.g., processing cores) 1693 and a memory 1694 for storing instructions 1696, which may be executed, for example, by at least one of the one or more processors 1693 (see, for example, blocks 1611, 1621, and 1631). As an example, the computer may include one or more network interfaces (e.g., wired or wireless), one or more graphics cards, display interfaces (e.g., wired or wireless), etc.

[0225] Figure 17 An example of system 1700 is shown, which may be a well-construction ecosystem including one or more instances of a multi-domain framework 1707. This framework can compile multi-domain code for multiple different domains describing physical operations, which can be performed, for example, using equipment; and establish a runtime environment for the compiled multi-domain code, wherein, for example, in response to input, the framework can issue a call to a Planning Domain Definition Language (PDDL) planner, which, in response to the call, can generate a plan, which can be received by the framework; it should be noted that the framework may include one or more PDDL planners. Such a plan may include one or more actions, wherein the framework can dispatch such one or more actions, for example, to require the execution of at least a portion of at least one physical operation. As an example, multi-domain framework 1707 may include... Figure 7 One or more features of system 700.

[0226] As an example, system 700 and / or system 1700 may include one or more features of the DELFI environment, and / or be operatively coupled to one or more features of the DELFI environment.

[0227] As shown, system 1700 may include one or more instances of MD framework 1707 and may include drilling infrastructure 1710 and drilling planning component 1720, which may generate or additionally transmit, for example, via drilling operations layer 1740, information associated with planning performed using drilling infrastructure 1710, including well site component 1742 and off-site component 1744. As illustrated, data acquired and / or generated by drilling operations layer 1740 may be transmitted to data archiving component 1750, which may be used for purposes such as planning one or more operations (e.g., according to drilling planning component 1720).

[0228] exist Figure 17 In the example, the MD frame 1707 is shown to be implemented relative to the drilling planning component 1720, the well site component 1742, and / or the off-site component 1744.

[0229] As an example, the MD frame 1707 can interact with one or more components in system 1700. As shown, the MD frame 1707 can be used in conjunction with drilling planning component 1720. In this example, data accessed from data archiving component 1750 can be used to evaluate the output of the MD frame 1707, or, for example, as input to the MD frame. As an example, data archiving component 1750 can include drilling data for one or more compensation wells and / or one or more current wells, relating to the specifications and / or operation of one or more types of drill bits, one or more types of mud motors, etc. As an example, the data can be used in conjunction with a frame such as, for example, the IDEAS frame (Schlumberger Ltd., Houston, Texas).

[0230] The IDEAS integrated dynamic design and analysis framework provides 4D simulations of drill string and wellbore geometry to help ensure accurate modeling of drilling and / or milling applications. This dynamic modeling system can generate data, simulations, etc., that can represent interactions in a virtual environment that reflects the actual environment. This can facilitate real-time customization of materials and designs, thereby optionally aiding real-time operations in the field. For example, features that help predict drill bit and milling performance can be considered while reducing the need for costly trial-and-error field testing. In this example, drilling operations can be performed in a way that is more likely to achieve the desired results on the first run. As explained, the IDEAS framework can be integrated into systems such as, for example... Figure 7System 700. In this example, feedback from one or more physical operations can be used to update, revise, etc., one or more framework runs, where the framework output can be used by MDR for planning output purposes (e.g., planning can be consumed at least in part by one or more entities to perform one or more physical operations).

[0231] As an example, the IDEAS framework can be implemented in a manner where one or more of various techniques (e.g., theoretical calculations, finite element packages, internal drilling rig testing, full-scale drilling rig testing, and field testing using MWD or downhole drilling dynamic sensors) are used to validate and validate the model. As an example, the IDEAS framework implementation may include model revisions and / or updates that can undergo validation and / or verification. In this example, for the purpose of generating outputs for one or more projects, the IDEAS framework can dynamically learn and / or revise itself, which can be controlled at least in part by the outputs of the MDR.

[0232] like Figure 17 As shown, various components of the drilling operation layer 1740 can utilize the multi-domain (MD) framework 1707 and / or drilling digital planning (e.g., PDDL planner planning, etc.) output by the drilling planning component 1720. During drilling, execution data can be acquired, and the MD framework 1707 can utilize this execution data to, for example, update one or more plans, actions, etc. This execution data can be archived in the data archiving component 1750, which can be archived during one or more drilling operations, and can be used by the drilling planning component 1720, for example, for replanning, etc.

[0233] As an example, the plan can be a digital plan that directs one or more pieces of equipment, which can be operatively coupled via a network and / or other communication systems. In this example, one piece of equipment may include an embedded controller, or other dedicated controllers that can be operated at least in part using the digital plan. In this example, the digital plan can be updated, revised, etc., depending on the overall plan, as measured using various types of sensor data. For example, in cases where drilling encounters specific conditions that may differ from those anticipated during plan generation, feedback can prompt the automatic generation of a digital plan that can account for such specific conditions. In this example, the digital plan can be distributed and / or its actions can be issued to appropriate equipment to control one or more aspects of physical operation. When utilizing an embedded controller, as an example, a new digital plan can be transferred for instantiation in the embedded controller, where the previous digital plan can be cleared (e.g., or stored in memory dedicated to storing plans that are not currently being implemented). As an example, the embedded controller may utilize one or more types of architectures, such as ARM (e.g., a RISC architecture), which can be adapted to embedded architectures such as System-on-Chip (SoC), System-on-Module (SoM). As an example, at the site, the system may be an Internet of Things (IoT) type system, where one or more IoTs can be operated at least in part via a digital plan generated, such as via MDR.

[0234] As an example, the system can be implemented locally and / or remotely. For example, consider executable... Figure 7 The system 700 comprises various parts of a cloud-based platform, which may include one or more instances thereof for the purpose of assigning one or more digital plans to one or more planning consumers and / or issuing planning actions. In this example, the site system may include one or more pieces of equipment that can operate in a coordinated manner, which may include synchronous and / or asynchronous operation. As an example, in such a site system, one or more types of resources may be limited and / or additionally constrained (e.g., people, power, specific tools, etc.).

[0235] As an example, a coordinated approach to the execution of one or more physical operations may consider one or more constraints, limitations, etc. For instance, consider the example of baking one or more types of bread using one or more recipes and / or one or more ovens, where materials, ovens, people, etc., may be limited or constrained. In such an example, with multiple ovens available, energy consumption can be considered a constraint. For example, if the ovens are electric and consume a known amount of electrical power, there may be a constraint to keep peak electrical power below its maximum value, which may be infrastructure-related. This approach, seemingly beyond the details of the operation, can be considered a “system” approach. In this example, a “system” can be defined as a cohesive group of interconnected and interdependent parts, which may include natural, man-made, and / or human components, where the “system” may be spatially and temporally constrained and, for example, influenced by its environment. A “system” can be defined by its structure and purpose and expressed through its function. In various cases, a “system” can express cooperative or emergent behavior, which may be more than just a “sum of its parts” approach.

[0236] In environments involving various potentially interconnected field operations (e.g., drilling, hydraulic fracturing, seismic surveying, etc.), planning can employ a "systems" approach to generate, implement, revise, etc., plans and / or portions thereof in a manner that considers one or more constraints and / or allows for synergistic and / or emergent expressions. Emergence can exist in complex systems; for example, life can be viewed as the emergent behavior of chemistry. As an example, consider the interrelationship between a hydraulic fracturing operation, which pumps fluid underground to fracture rock, and microseismic sensing aimed at recording the acoustic energy generated by rock fracturing, where microseismic sensing can be used in a control loop to improve the hydraulic fracturing operation, which can improve the operation in real-time or near real-time. In such an example, multiple domains can be integrated through a multi-domain compiler, where the multi-domain runtime can generate outputs for one or more plans that control an interconnected and complex system that may be constrained and / or limited in one or more ways (e.g., pump rate, pump pressure, proppant amount, density of microseismic sensor array, etc.).

[0237] As an example, the system can provide the ability to compile and execute multiple PDDL planning domains for the automation of one or more real-time oil and / or gas physical operations, including equipment and potentially involving one or more human operators. As an example, in coordinating the construction of multiple PDDL planning domains, the system can provide recording, playback, and debugging facilities in various modes.

[0238] As an example, the framework can be a multi-domain framework. Such a framework can be applied to oilfield and / or gasfield operations and can provide solutions to automation problems via one or more interfaces (e.g., a GUI). As another example, various features and a specialized language for coordinating multiple PDDL domains can facilitate rapid iteration of more complex domain models that can demonstrate to personnel (e.g., non-technical personnel) how artificial intelligence behaviors can be implemented in the field.

[0239] As explained, the system can utilize a programming language that allows PDDL domain authors to build and allows multiple PDDL domains to interact with each other. Such a system can utilize source code and PDDL domain files and compile them into an image, which can be loaded into a program to be executed to instruct real-world field operations (e.g., drilling, fracturing, sensing, etc.). In this example, at runtime, the program can accept input from one or more other programs (e.g., frameworks, etc.) and use this input to execute one or more PDDL plans, which can prompt the program to dispatch actions, including actions that can be performed by one or more other programs. As explained, the system can operate in a networked environment, where one or more pieces of equipment can include control capabilities and / or be operatively coupled to one or more controllers, which can be instructed via one or more actions specified by a digital plan.

[0240] As an example, a method may include: in a runtime environment of compiled multi-domain code describing multiple different domains of a physical operation (e.g., a physical operation performed at least partially using equipment), in response to input, issuing a call to a Planning Domain Definition Language (PDDL) planner; in response to the call, receiving a plan including at least one action; and dispatching at least one of the at least one actions to request the execution of at least a portion of the at least one physical operation. In this example, the multiple different domains may include at least one relationship. For example, the at least one relationship may include a parent-child relationship between a parent domain and a child domain. In this example, a plan may be a parent plan of the parent domain, which includes multiple instances of child plans of the child domain (e.g., requesting the child plans to be implemented, etc.). As an example, a child plan may include an action of drilling a wellbore of a certain length, and a parent plan may include actions of drilling multiple times the length (e.g., requesting the child plan to be implemented multiple times, etc.).

[0241] As an example, multiple different domains may include at least two layers. As an example, a layer may be a parent of a child or a child of a parent, or another type of relationship.

[0242] As an example, a plan can correspond to one of several different domains.

[0243] As an example, a method may include issuing multiple calls to multiple Planning Domain Definition Language (PDDL) planners in response to input. In this example, the method may include receiving a corresponding plan in response to each call. As an example, one PDDL planner and another PDDL planner may be independent instances of the same PDDL planner, or, for example, one PDDL planner and another PDDL planner may be instances of different PDDL planners.

[0244] As an example, one approach may include using a multi-domain description language to generate compiled multi-domain code, wherein the multi-domain description language is used to describe at least one relationship between two different domains among a plurality of different domains.

[0245] As an example, one approach may include providing a framework, wherein a runtime environment uses the framework in runtime mode, wherein the framework is capable of operating in development mode to generate compiled multi-domain code.

[0246] As an example, a physical operation described by multiple different domains may include at least one oilfield operation. For example, consider a physical operation that includes at least one drilling operation.

[0247] As an example, one method may include receiving input from an executor on a computing device, wherein the input is received in a runtime environment of compiled multi-domain code, and wherein the input triggers one or more calls to one or more PDDL planners. In this example, one or more plans may be returned, wherein, for example, dispatch may include dispatching at least one action of at least one of the one or more plans.

[0248] As an example, input can be received from a computing device executing a program, and assignment can be made to said computing device or the executing program (e.g., in a distributed computing system). As an example, an apparatus may include one or more processors, and therefore may be a computing device. As an example, a computing device or computing system may be a controller (e.g., a control system). As an example, a method may include assigning at least one planned action to one or more computing devices, computing systems, etc. In this example, a plan may be generated in response to input from one or more computing devices, computing systems, etc. In this example, the input may come from an executing program (e.g., an application, app, firmware, etc.).

[0249] As an example, a system may include a processor; memory accessible to the processor; and processor-executable instructions stored in the memory and executable by the processor to instruct the system to:, in response to input, issue a call to a Planning Domain Definition Language (PDDL) planner in a runtime environment of compiled multi-domain code describing multiple different domains of physical operations; receive a plan including at least one action in response to the call; and dispatch at least one of the at least one actions to request the execution of at least a portion of at least one of the physical operations.

[0250] As an example, one or more computer-readable storage media may include computer-executable instructions that are executable to instruct a computing system to: in response to input, issue a call to a Planning Domain Definition Language (PDDL) planner in a runtime environment for compiled multi-domain code describing multiple different domains of physical operations (e.g., including one or more physical operations that can be performed using equipment); in response to the call, receive a plan including at least one action; and dispatch at least one of the at least one actions to request the execution of at least a portion of at least one of the physical operations.

[0251] As an example, a method can be implemented in part using a computer-readable medium (CRM), such as a module, block, etc., which includes 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 at least partially allow the execution of various actions of the method. As an example, the computer-readable medium (CRM) may be a carrier-free computer-readable storage medium (e.g., a non-transitory medium).

[0252] As an example, a computer program product may include computer-executable instructions that instruct a computing system to perform a method, such as, for example... Figure 16 Methods such as 1610, etc.

[0253] According to one 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 output to a sensing process, an injection process, a drilling process, an extraction process, a squeezing process, a pumping process, a heating process, etc.

[0254] In some implementations, one or more methods can be performed by a computing system. Figure 18An example of a system 1800 is shown, which may include one or more computing systems 1801-1, 1801-2, 1801-3, and 1801-4, which may be operatively coupled via one or more networks 1809, which may include wired and / or wireless networks.

[0255] As an example, the system may include a standalone computer system or an arrangement of distributed computer systems. Figure 18 In the example, computer system 1801-1 may include one or more modules 1802, which may be or may include processor-executable instructions, for example, that are executable to perform various tasks (e.g., receiving information, requesting information, processing information, simulating, outputting information, etc.).

[0256] As an example, the module may execute independently or in cooperation with one or more processors 1804, which are operatively coupled to one or more storage media 1806 (e.g., via wired, wireless, etc.). As an example, one or more of the processors 1804 may be operatively coupled to at least one of one or more network interfaces 1807. In such examples, the computer system 1801-1 may, for example, transmit and / or receive information via one or more networks 1809 (e.g., consider one or more of the Internet, private networks, cellular networks, satellite networks, etc.).

[0257] As an example, computer system 1801-1 may receive information from and / or transmit information to one or more other devices, which may be or include, for example, one or more of computer systems 1801-2. The devices may be located in a different physical location than computer system 1801-1. As an example, the location may be, for example, a processing facility location, a data center location (e.g., a server farm), a drilling rig location, a well site location, a downhole location, etc.

[0258] As an example, a processor can be or may include a microprocessor, microcontroller, processor module or subsystem, programmable integrated circuit, programmable gate array or other control or computing device.

[0259] As an example, storage medium 1806 can be implemented as one or more computer-readable or machine-readable storage media. As an example, storage can be distributed within and / or between multiple internal and / or external housings of the computing system and / or additional computing systems.

[0260] As an example, one or more storage media may include one or more different forms of memory, including: semiconductor memory devices such as dynamic or static random access memory (DRAM or SRAM), erasable and programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; magnetic disks such as fixed disks, floppy disks, and removable disks; other magnetic media, including magnetic tape; optical media such as optical discs (CDs) or digital video discs (DVDs), Blu-ray discs, or other types of optical storage devices; or other types of storage devices.

[0261] As an example, one or more storage media may be located in a machine that runs machine-readable instructions, or at a remote site from which the machine-readable instructions may be downloaded over a network for execution.

[0262] As an example, various components of a system (such as a computer system) can be implemented in hardware, software, or a combination of hardware and software (e.g., including firmware) that includes one or more signal processing and / or application-specific integrated circuits.

[0263] As an example, a system may include a processing device that may be or may include a general-purpose processor or a special-purpose chip (e.g., a chipset), such as an ASIC, FPGA, PLD, or other suitable device.

[0264] Figure 19 The illustration shows components of a computing system 1900 and a networking system 1910 including a network 1920. System 1900 includes one or more processors 1902, memory and / or storage components 1904, one or more input and / or output devices 1906, and a bus 1908. According to one embodiment, instructions may be stored in one or more computer-readable media (e.g., memory / storage component 1904). Such instructions may be read by one or more processors (e.g., one or more processors 1902) via a communication bus (e.g., bus 1908), which may be wired or wireless. The one or more processors may execute such instructions to (wholly or partially) implement one or more attributes (e.g., as part of a method). A user may view the output from the process and interact with the process via I / O devices (e.g., device 1906). According to one embodiment, the computer-readable medium may be a storage component, such as a physical memory storage device, such as a chip, a chip-on-a-package, a memory card, etc.

[0265] According to one embodiment, components may be distributed within a network system such as network system 1910. Network system 1910 includes components 1922-1, 1922-2, 1922-3...1922-N. For example, component 1922-1 may include one or more processors 1902, while one or more components 1922-3 may include memory accessible by one or more processors 1902. Furthermore, one or more components 1922-2 may include I / O devices for display and optionally for interaction with methods. The network may be or include the Internet, intranet, cellular network, satellite network, etc.

[0266] As an example, the device may be a mobile device including one or more network interfaces for information communication. For example, the mobile device may include a wireless network interface (e.g., operating via IEEE 802.11, ETSI GSM, BLUETOOTH, satellite, etc.). As an example, the mobile device may include components such as a main processor, memory, display, display graphics circuitry (e.g., optionally including touch and gesture circuitry), SIM slot, audio / video circuitry, motion processing circuitry (e.g., accelerometer, gyroscope), wireless LAN circuitry, smart card circuitry, transmitter circuitry, GPS circuitry, and battery. As an example, the mobile device may be configured as a cellular phone, tablet computer, etc. As an example, a mobile device may be used to implement a method (e.g., wholly or partially). As an example, a system may include one or more mobile devices.

[0267] As an example, the system can be a distributed environment, such as a so-called "cloud" environment, in which various devices, components, etc., interact for purposes such as data storage, communication, and computing. As an example, a device or system may include one or more components for communicating information via one or more of the Internet (e.g., in the case of communication via one or more Internet protocols), cellular networks, satellite networks, etc. As an example, a method can be implemented in a distributed environment (e.g., wholly or partially as a cloud-based service).

[0268] As an example, information can be input from a display (e.g., consider a touchscreen), output to a display, or both. As an example, information can be output to a projector, laser device, printer, etc., making the information viewable. As an example, information can be output stereoscopically or holographically. Regarding printers, consider 2D or 3D printers. As an example, a 3D printer can include one or more materials that can be output to construct 3D objects. For example, data can be provided to a 3D printer to construct a 3D representation of underground strata. As an example, layers (e.g., horizons, etc.) can be constructed in 3D, geological bodies, etc., can be constructed in 3D. As an example, wellbores, fractures, etc. (e.g., as positive structures, as negative structures, etc.) can be constructed in 3D.

[0269] Although only a few examples have been described in detail above, those skilled in the art will readily understand that many modifications can be made to the examples. Therefore, all such modifications are intended to be included within the scope of this disclosure as defined in the appended claims. In the claims, the device-plus-function clause is intended to cover structures described herein as performing the enumerated functions, including not only structural equivalents but also equivalent structures. Thus, although nails and screws may not be structural equivalents because nails employ a cylindrical surface to hold wooden parts together, while screws employ a helical surface, nails and screws may be equivalent structures in the context of fastening wooden parts.

Claims

1. A method for performing drilling operations using drilling equipment, the method being performed by a system including a multi-domain framework, drilling rig infrastructure, and drilling planning components, the method comprising: In a computer runtime environment that contains compiled multi-domain code for multiple different domains describing physical operations performed using drilling equipment, a call is made to a planning domain definition language planner in response to input, wherein the multi-domain code is compiled by the multi-domain framework. In response to the call, a drilling digital plan including at least one action is generated and received, and information associated with the drilling digital plan executed using the drilling rig infrastructure is transmitted via the drilling operations layer, which utilizes the multi-domain framework and / or the drilling digital plan output by the drilling planning component; and Dispatch at least one of the at least one actions to request the execution of at least a portion of at least one of the physical operations.

2. The method of claim 1, wherein the plurality of different domains includes at least one relation.

3. The method of claim 2, wherein the at least one relationship includes a parent-child relationship between a parent domain and a child domain.

4. The method of claim 3, wherein the planning includes a parent plan of the parent domain, and the parent plan includes multiple instances of sub-plans of the sub-domain.

5. The method of claim 4, wherein the sub-plan includes the action of drilling a wellbore of a certain length, and wherein the parent plan includes the action of drilling a multiple of the length.

6. The method of claim 1, wherein the plurality of different domains comprises at least two layers.

7. The method of claim 1, further comprising, in response to the input, issuing another call to another planning domain definition language planner; and, in response to the other call, receiving another plan.

8. The method of claim 7, wherein the planning domain definition language planner and the other planning domain definition language planner are independent instances of the same planning domain definition language planner.

9. The method of claim 7, wherein the planning domain definition language planner and the other planning domain definition language planner are instances of different planning domain definition language planners.

10. The method of claim 1, further comprising using a multi-domain description language to generate the compiled multi-domain code, wherein the multi-domain description language is used to describe at least one relationship between two different domains of the plurality of different domains.

11. The method of claim 1, comprising a framework, wherein the runtime environment is implemented using the framework in runtime mode, and wherein the framework is operable in development mode to generate the compiled multi-domain code.

12. The method of claim 1, wherein the physical operation comprises at least one oilfield operation.

13. The method of claim 1, further comprising receiving the input from an execution program on a computing device, wherein the dispatching comprises dispatching at least one of the at least one actions to the computing device or a different computing device.

14. A system for performing drilling operations using drilling equipment, comprising: processor; The processor has access to the memory; Processor-executable instructions, stored in the memory and executable by the processor, to instruct the system to perform the method according to any one of claims 1-13.

15. A computer program product comprising computer-executable instructions for instructing a computing system to perform the method according to any one of claims 1 to 13.