US20220112796A1

US20220112796A1 - Expert system for well treatment

Info

Publication number: US20220112796A1
Application number: US17/066,851
Authority: US
Inventors: Mikko Jaaskelainen; Joshua Lane Camp
Original assignee: Halliburton Energy Services Inc
Current assignee: Halliburton Energy Services Inc
Priority date: 2020-10-09
Filing date: 2020-10-09
Publication date: 2022-04-14
Also published as: CA3110596A1; CA3193034A1; CA3110596C

Abstract

A method of controlling a pumping sequence of a fracturing fleet at a wellsite while performing a fracturing job on a treatment wellbore penetrating a subterranean formation. A modeling application receives sensor data from the treatment wellbore and/or a monitoring wellbore, predicts a fracture propagation within the formation, and produces a pumping sequence to obtain the fracture propagation or a real-time update to the pumping sequence. The pumping can include two or more sub-stages, wherein the modeling application employs a first pumping routine model to provide a first sub-stage of the pumping sequence and employs a second pumping routine model to provide a second sub-stage of the pumping sequence. A managing application controls the fracturing fleet in accordance with the pumping sequence to place a fracturing fluid in the treatment well.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

None.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not applicable.

REFERENCE TO A MICROFICHE APPENDIX

Not applicable.

BACKGROUND

Subterranean hydraulic fracturing is conducted to increase or “stimulate” production from a hydrocarbon well. To conduct a fracturing process, high pressure is used to pump special fracturing fluids, including some that contain propping agents (“proppants”) down-hole and into a hydrocarbon formation to split or “fracture” the rock formation along veins or planes extending from the well-bore. Once the desired fracture is formed, the fluid flow is reversed and the liquid portion of the fracturing fluid is removed. The proppants are intentionally left behind to stop the fracture from closing onto itself due to the weight and stresses within the formation. The proppants thus literally “prop-apart”, or support the fracture to stay open, yet remain highly permeable to hydrocarbon fluid flow since they form a packed bed of particles with interstitial void space connectivity. Sand is one example of a commonly-used proppant. The newly-created-and-propped fracture or fractures can thus serve as new formation drainage area and new flow conduits from the formation to the well, providing for an increased fluid flow rate, and hence increased production, of hydrocarbons.
To plan a fracturing fluid pumping process to create a targeted fracture profile in a subterranean formation penetrated by a wellbore, fracturing models can be used which predict the propagation of fractures through a formation of given mechanical properties in relation the pumped volume, pumping rate, and rheologic properties of the fracturing fluid being used. The pumping process can be automated with a pumping sequence utilizing the fracturing model to develop a pumping sequence with the pump rates, fluid volume, and slurry density.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.

FIG. 1 is a schematic diagram of a wellbore penetrating a subterranean formation and associated equipment for recovering resources from the wellbore.

FIG. 2A is a block diagram of a hydraulic fracturing system according to an embodiment of the disclosure.

FIG. 2B is a block diagram of an instrumented package for a hydraulic fracturing system according to an embodiment of the disclosure.

FIG. 3 is a block diagram of a water supply unit for a hydraulic fracturing system according to an embodiment of the disclosure.

FIG. 4 is a block diagram of a hierarchy of an expert system for fracturing modeling and associated wellbore fracturing operations according to an embodiment of the disclosure.

FIG. 5 is a schematic diagram of a communication system according to an embodiment of the disclosure.

FIGS. 6A and 6B are illustrations of a pumping sequence according to an embodiment of the disclosure.

FIG. 7 is a logical flow diagram depicting a plurality of sub-stage scripts associated with a pumping sequence for a fracturing stage according to an embodiment of the disclosure.

FIG. 8 is a logical flow diagram depicting a method for preparing an automated pumping sequence of the type represented by FIG. 7.

FIG. 9 is a logical flow diagram depicting an operational method of carrying out an automated pumping sequence according to an embodiment of the disclosure.

FIG. 10 is a logical flow diagram depicting an operational method of updating an automated pumping sequence via fracture modeling according to another embodiment of the disclosure.

FIG. 11 is a logical flow diagram depicting an operational method of updating an automated pumping sequence via fracture modeling according to another embodiment of the disclosure.

FIG. 12 is a flow chart of method of controlling a pumping sequence of a fracturing fleet at a wellsite while performing a fracturing job on a treatment wellbore penetrating a subterranean formation according to an embodiment of the disclosure.

FIG. 13 is a flow chart of still another method of controlling a pumping sequence of a fracturing fleet at a wellsite while performing a fracturing job on a treatment wellbore penetrating a subterranean formation according to an embodiment of the disclosure.

FIG. 14A is a block diagram of an exemplary communication system according to an embodiment of the disclosure.

FIG. 14B is a block diagram of a 5G core network according to an embodiment of the disclosure.

FIG. 15 is a block diagram of a computer system according to an embodiment of the disclosure.

DETAILED DESCRIPTION

It should be understood at the outset that although illustrative implementations of one or more embodiments are illustrated below, the disclosed systems and methods may be implemented using any number of techniques, whether currently known or not yet in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, but may be modified within the scope of the appended claims along with their full scope of equivalents.
A modern fracturing fleet typically includes a water supply, a proppant supply, one or more blenders, a plurality of frac pumps, and a fracturing manifold connected to the wellhead. The individual units of the fracturing fleet can be connected to a central control unit called a data van. The control unit can control the individual units of the fracturing fleet to provide proppant slurry at a desired rate to the wellhead. The control unit can manage the pump speeds, chemical intake, and proppant density while pumping fracturing fluids and receiving data relating to the pumping from the individual units.
Service personnel have typically directed the pumping of fracturing fluids from the control unit to follow the pumping sequence of a fracturing model. This direction provided by the service personnel can be manual direction, changes to an automated schedule, or both. For example, the service personnel may monitor an automated pumping sequence during a pumping stage then switch to manual control due to an unplanned event, change the pump rate, or some other pumping process. These changes, also called exceptions, to the automated pumping sequence can be due to a change in the pumping equipment (e.g., line leak), a change in the wellbore environment (e.g., sand out, also referred to a sand screen out or simply a screen out), a requested change from the customer, or other considerations. These exceptions may not be predictable but the remedial changes required to the pumping sequence can be predictable and/or selected from a predetermined list of available remedial actions.
Exceptions to an automated pumping sequence can create costly delays and, in some cases, a safety hazard. For example, a frac pump may develop a leak around the plunger seals causing a loss of pumping efficiency and a possible environmental cleanup. The frac pump must be isolated and repaired or replaced. The process of isolating a leaking pump during a pumping stage may be difficult for inexperienced service personnel. The lack of experience can cause a delay in the repair, a premature end to the pumping stage, and a possible health, safety, or environmental (HSE) hazard.
In an embodiment, a managing application can control a pumping sequence for a fracturing fleet at a wellsite. The managing application can retrieve a pumping sequence from a storage server. The pumping sequence can include multiple stages corresponding to a pumping operation such as a pump rate test, a ramp up stage, a single zone fracturing, and clean up. The pumping sequence can include a single zone or multiple zones to be fractured. Each pumping stage can be controlled by a stage script written in a scripting computer language such as Python, Java, Perl, Ruby, Tcl, or Smalltalk. The stage script can be a set of instructions for each fracturing unit to follow during a pumping stage. The stage script may link two or more fracturing units together during a pumping stage. For example, the stage script instructions can include the same instructions to two or more pumps during a pumping stage. The fracturing unit can return data (e.g., pressure, temperature, etc.) to the managing application during the pumping stage. The data from the fracturing units is compared to the expected equipment output based on the pumping sequence. When the equipment data doesn't match the predicted equipment output, the managing application can produce an exception notice that returns control to the service personnel. The exception notice may indicate a leak, a pump failure, or an event in the well (e.g., sandout). The service personnel can take remedial action to correct the exception.
In an embodiment, the automated pumping sequence can have automated exception handling to clear common exceptions. For example, an automated pumping script executed by a managing application may include additional automated exception/remedial scripts that are triggered when an exception occurs. For example, the automated exception handling may idle a leaking pump and close valves to isolate the pump from the manifold. The automated exception handling may attempt one, two, or more automated exception/remedial scripts before issuing an exception notice and returning control to the service personnel.
Disclosed herein are methods of controlling a pumping sequence of a fracturing fleet at a wellsite while performing a fracturing job on a treatment wellbore penetrating a subterranean formation. A modeling application receives one or more user inputs related to the fracturing job, one or more equipment inputs comprising sensor data from one or more frac units of the fracturing fleet, one or more wellbore inputs comprising sensor data from the treatment wellbore and/or sensor data from one or more monitoring wellbores spaced a distance apart from the treatment wellbore, or combinations thereof. The modeling application predicts a fracture propagation within the formation and produces a pumping sequence. In an aspect, the modeling application can produce an updated pumping sequence in real time during the fracturing job. The pumping sequence can include two or more sub-stages, wherein the modeling application employs a first pumping routine model to provide a first sub-stage of the pumping sequence and employs a second pumping routine model to provide a second sub-stage of the pumping sequence. A managing application controls the fracturing fleet in accordance with the pumping sequence to place a fracturing fluid in the treatment well.
As described in detail herein, a method of monitoring a wellbore is provided wherein one or more downhole sensors present in a wellbore provides data gathered with regard to one or more conditions such as pressure and/or temperature within a formation and/or within a wellbore. Turning now to FIG. 1, illustrated is an embodiment of a wellsite monitoring system 50 that can be utilized to gather wellbore data. As depicted, the wellbore 10 penetrates a subterranean formation 8 for the purpose of recovering hydrocarbons. The wellbore 10 can be drilled into the subterranean formation 8 using any suitable drilling technique. The wellbore 10 extends substantially vertically away from the earth's surface 2 over a vertical wellbore portion 24, deviates from vertical relative to the earth's surface 2 over a deviated wellbore portion 26, and transitions to a horizontal wellbore portion 28. In alternative operating environments, all or portions of a wellbore may be vertical, deviated at any suitable angle, horizontal, and/or curved. The wellbore 10 may be a new wellbore, an existing wellbore, a straight wellbore, an extended reach wellbore, a sidetracked wellbore, a multi-lateral wellbore, and other types of wellbores for drilling and completing one or more production zones. Further, the wellbore 10 may be used for both producing wells and injection wells. In an embodiment, the wellbore 10 may be used for purposes other than or in addition to hydrocarbon production, such as uses related to geothermal energy or waste disposal.
In some embodiments, the wellbore 10 can be completed by cementing a casing string 14 (e.g., a conduit) within the wellbore 10 along all or a portion thereof. The cement 12 can be pumped down the interior of the casing string 14, out a float shoe 20 (or other suitable primary cementing equipment), and into the annular space 22 (e.g., the annulus) between the casing string 14 and the wellbore 10. In other embodiments, however, the casing string 14 may be omitted from all or a portion of the wellbore 10, and the principles of the present disclosure can equally apply to an “open-hole” environment. In still other embodiments, however, the primary cementing equipment 20 at the end of the casing string 14 can be drilled out, and a liner can be added to extend the length of the wellbore.
The wellbore 10 can be drilled through the subterranean formation 8 to a hydrocarbon bearing formation 16, also referred to as the formation 16. Perforations 18 in the casing string 14 and cement 12 enable the fluid in the formation 16 to enter the casing string 14.
The cement 12 can have one or more wellbore sensors 30 positioned within the annular space 22 between the casing string 14 and the wellbore 10. The wellbore sensors 30 can include one or more wellbore fibers or cables 32, one or more electronic sensors 34, fiber optic sensors, micro electromechanical sensors (MEMS), or combinations thereof. The wellbore fibers or cables 32 can be routed along the outside of the casing string 14 and attached at various locations (e.g., at a coupling) with cable clamps known to the industry. The wellbore sensors 30 can be attached to the casing string 14 with a casing clamp, attached to casing equipment, integrated within a sensor housing, or suspended along the casing. In some embodiments, the wellbore sensors 30 can be wellbore cables 32 containing distributed optical sensors such as fiber optic cables. In some embodiments, the wellbore sensors 30 can be electronic sensors 34 with wellbore cables 32 transmitting power and communicating data. In some embodiments, the wellbore sensors 30 can be battery powered electronic sensors 34 transmitting data to the surface via sonar, radio, or audio telemetry. In some embodiments, the wellbore sensors 30 can be a combination of sensor types.
In an embodiment, the wellbore sensors 30 can be contained within (e.g., distributed within) the cement. For example, a cement sheath can be disposed within an annulus formed between a conduit disposed within the well and a wall of the wellbore and the one or more sensors can comprise micro electromechanical sensors (MEMS) disposed within the cement sheath, a fiber optic sensor disposed on the conduit (e.g., to read/interrogate the MEMS and/or convey data from the MEMS), or both.
In an embodiment, the wellbore sensors 30 can be located within an annular space without cement. The wellbore sensors 30 may be attached to the casing string 14 along a portion of the casing string 14 without cement. The cement 12 may be isolated from a portion of the casing string 14 by primary cementing equipment such as a cement basket, a packer cementing collar, or similar equipment known to the oilfield.
In an embodiment, the wellbore sensors 30 can be communicatively coupled with the formation 16. The wellbore sensors 30 can gather data from the formation by direct contact or being communicatively connected to the formation 16 (e.g., acoustic energy, electromagnetic waves, radiation, etc. emanating from the wellbore into the surrounding formation).
In an embodiment, the wellbore sensors 30 can be communicatively coupled with the interior 48 of the casing string 14. The wellbore sensors 30 can gather data from the interior 48 of the casing string 14 by direct contact or be communicatively coupled with the inside diameter of the casing string 14. Alternatively, the wellbore sensors 30 can be placed inside the casing string 14.
The data gathered by the wellbore sensors 30 can include mechanical properties such as stress or strain data, flow rate data, pressure data, temperature data, acoustic data, compositional data, or combinations thereof. The wellbore sensors 30 can measure stress and strain from a strain-bridge mounted onto the outside surface or inside surface of the casing string 14. The wellbore sensors 30 can measure pressure and temperature at a discrete location within the cement isolation barrier and/or along a portion of the casing string 14. The wellbore sensors 30 can measure the pressure and temperature of the formation 16. The wellbore sensors 30 can measure data from the interior 48 of the casing string 14. The wellbore sensors 30 may be a fiber optical sensor that can measure a distributed temperature along the fiber optical cable. The wellbore sensors 30 may measure acoustic data from a discrete location of an electronic sensor or along a distributed path of a fiber optical cable. The wellbore sensors 30 may measure flow rate data from a discrete location of an electronic sensor or from a discrete location of an optical sensor.
A wellsite monitoring system 50 can include a production tree 40, a data logging device 38, and a wired communication cable 44. The production tree 40 can anchor the casing string 14 at surface 2. The production tree 40 isolates the pressure within the casing string 14 and connects a production line to the well. The production tree 40 can also include one or more production tree sensors 42 that gather pressure, temperature, and/or flowrate data. Although a production tree 40 is shown, any type of pressure containment equipment connected to the top of the casing string 14 may be used, such as a surface tree, subsea tree, lubricator connector, and blowout preventer. A data logging device 38 can gather data from the wellbore sensors 30 and the production tree sensor 42 for storage and/or transmittal. A transmission cable 36 can pass through a production tree 40 to connect the data logging device 38 to the wellbore cables 32. The data logging device 38 can communicate with the wellbore sensors 30 and production tree sensor 42 via any suitable communication means (e.g., wired, wireless, telemetry, etc.). The data can be gathered in data sets based on a time interval. The data set can be retrieved from multiple wellbore sensors 30 and production tree sensors 42 instantaneously or near instantaneously and logged with a time stamp. The data sets can be recorded in time intervals of milliseconds, seconds, minutes, hours, days, weeks, or months. The time intervals that the data sets are gathered by the wellbore sensors 30 and production tree sensors 42 can change based on the wellbore conditions, user input, or by another application. The data logging device 38 can provide power to and receive data from the wellbore sensors 30. The data logging device 38 can contain an optical interrogator that transmits and receives laser light to the wellbore cables 32 (e.g., fiber optic cables). The data logging device 38 can have a data storage device attached to or integrated within to store the data. The data logging device 38 can store the data in transitory or non-transitory memory, in resident storage media, or in removable storage media. The data logging device 38 can store the data or transmit the data for analysis. The data logging device 38 can transmit the data via wireless communication 46 (e.g., a transceiver) or a wired communication cable 44.
As described in detail herein, a method of controlling a pumping sequence of a fracturing fleet at a wellsite by a managing application while monitoring equipment data provided by sensors on the fracturing units indicative of a pumping stage of the pumping sequence. Turning now to FIG. 2, illustrated is an embodiment of a hydraulic fracturing system 100 that can be utilized to pump hydraulic fracturing fluids into a wellbore. As depicted, a plurality of hydraulic fracturing pumps 122 (also referred to as “frac pumps” or high horsepower pumps) is connected in parallel to a fracturing manifold 124 (also referred to as a “missile”) to provide fracturing fluids to the treatment well 130. The fracturing fluids are typically a blend of gelled fluid (e.g., water, a gelling agent, optionally a friction reducer and/or other additives) and proppant. The gelled fluid is created in the hydration blender 114 with water from the water supply unit 112 and gelling chemicals from the chemical unit 116. The proppant is added at a controlled rate to the gelled fluid in the mixing blender 120 and pumped into the manifold 124 for distribution to the frac pumps 122 by feedlines 126. Although fracturing fluids typically contain a proppant, a portion of the pumping sequence may include a fracturing fluid without proppant (sometimes referred to as a pad fluid or slick water, for example comprising water and a friction reducer). Although fracturing fluids typically include a gelled fluid, the fracturing fluid may be blended without a gelling chemical. Alternatively, the fracturing fluids can be blended with an acid to produce an acid fracturing fluid, for example, pumped as part of a spearhead or acid stage that clears debris that may be present in the wellbore and/or fractures to help clear the way for fracturing fluid to access the fractures and surrounding formation. Although the frac pumps 122, hydration blender 114, chemical unit 116, and mixing blender 120 are typically diesel powered, these frac units and others can be dual fuel (e.g., diesel and/or natural gas), electrically powered with an electric generator, electrically powered with batteries, or any combination thereof.
A control van 110 can be communicatively coupled (e.g., via a wired or wireless network) to any of the frac units wherein the term “frac units” may refer to any of the plurality of frac pumps 122, a manifold 124, mixing blender 120, proppant storage unit 118, hydration blender 114, water supply unit 112, and chemical unit 116. The managing application 136 executing on a computer (e.g., server) 132 within the control van 110 can establish unit level control over the frac units communicated via the network. Unit level control can include sending instructions to the frac units and/or receiving equipment data from the frac units. For example, the managing application 136 within the control van 110 can establish a pump rate of 25 bpm with the plurality of frac pumps 122 while receiving pressure and rate of pump crank revolutions from sensors on the frac pumps 122.
The managing application 136 within the control van 110 can be communicatively coupled to one or more wells located a distance from treatment well 130, for example communicatively coupled to a remote wellsite 138 and a remote wellsite 140. A managing application 136 can receive data from the data logging device 38 at the remote wellsite 138 and the remote wellsite 140. Although two well sites are shown, the managing application 136 can be communicatively coupled to 1, 2, 3, 4, 5, 10, 15, 20, or any number of data logging devices attached to remote well sites (e.g., data logging device 38 at remote wellsite 138 and/or 140).
The control van 110 can have a modeling application 146 executing on the same computer (e.g., server) 132 or on a second computer 142. The modeling application 146 can receive data from the data logging device 38 at the treatment well 130, at the remote or monitoring wellsite 138 and/or 140, or combinations thereof. The modeling application 146 can model the fracture propagation from the pumping sequence based on the data received from the treatment well 130, from the remote wellsites 138 and/or 140, or combinations thereof as described in more detail further hereinafter.
Although the managing application 136 and modeling application 146 are described as executing on a computer 132/142, it is understood that the computer 132/142 can be a computer system or any form of a computer system such as a server, a workstation, a desktop computer, a laptop computer, a tablet computer, a smartphone, or any other type of computing device. The computer 132/142 (e.g., computer system) can include one or more processors, memory, input devices, and output devices, as described in more detail further hereinafter, for example, with reference to FIG. 15. Although the control van 110 is described as having the managing application 136 executing on a computer 132, it is understood that the control van 110 can have 2, 3, 4, or any number of computers 132 (e.g., computer systems) with 2, 3, 4, or any number of applications (e.g., managing application 136 and modeling application 146) executing on the computer 132.
In some embodiments, the hydraulic fracturing system 100 can include an instrumented package 102 coupled to one or more frac units, for example, to isolate one or more frac units upon receipt of a computerized command. The instrumented package 102 can be communicatively coupled to the managing application 136 within the control van 110. Turning to FIG. 2B, an instrumented package 102, is illustrated. The instrumented package 102 can include one or more isolation valves 104 and sensors that measure data at a periodic rate such as milliseconds, seconds, minutes, hours, days, and months. The isolation valve 104 is typically a plug valve that can be manual, hydraulic, electrical, or pneumatic operated. Although one isolation valve 104 is shown, two or more isolation valves 104 may be used. The instrumented package 102 can include sensors to measure temperature, pressure, flow rate, density, viscosity, vibration, strain, accelerometers, exhaust, acoustic, position, and identity. For example, a pressure transducer 106 can be configured to measure the pressure in pounds per square inch (psi). A flow rate sensor 108 can be a turbine, differential, ultrasonic, Coriolis, or any other type of flow meter configured to measure in barrels per minute (bpm). A weight sensor can measure proppant by the weight of material added. For example, the rate that proppant is added to the fracturing fluids can be measured by pounds per gallon (ppg). The periodic data can be communicated to the control van 110. In some embodiments, the managing application 136 within the control van 110 can remotely operate one or more isolation valves 104 in the instrumented package 102 to the open or closed position. In an aspect, the isolation valve 104 is has a fail-safe in a closed position, such that the valve closes in the event of a loss of communication from control van 110.
Turning now to FIG. 3, an example of unit level control of the frac units is illustrated. As an example, the water supply unit 112 includes a water supply tank 148, a unit control module 150, a unit sensor module 152, a water supply pump 156, and a pipeline 160. The water supply unit 112 can further comprise an instrumented package 102, for example, in pipeline 160. The unit control module 150 (e.g., microprocessor controller) is in communication with and can operate the water supply pump 156, an isolation valve 158, and the instrumented package 102. The unit sensors module 152 is in communication with and can receive periodic sensor data from various sensors including temperature, pressure, flow rate, density, viscosity, chemical, vibration, strain, accelerometers, exhaust, acoustic, fluid level, equipment identity, and any other sensors typically used in the oilfield. The sensors can measure data at a periodic rate such as milliseconds, seconds, minutes, hours, days, and months. For example, the unit sensor module 152 can receive periodic data from a water level sensor 154. The managing application 136 within the control van 110 can establish unit level control of the water supply unit 112 by communicatively connected to the unit control module 150 and the unit sensor module 152. The managing application 136 within the control van 110 can control the isolation valve 158, water supply pump 156, and/or the instrumented package 102 via the unit control module 150. The control van 110 can monitor the equipment data, such as water level and flow rate, via unit sensor module 152. Although the water supply unit 112 is shown, all of the frac units can have a unit control module 150 and unit sensor module 152 such as the hydration blender 114, the chemical unit 116, the proppant storage unit 118, the mixing blender 120, the manifold 124, and the plurality of frac pumps 122. The managing application 136 within the control van 110 can direct the frac fleet, illustrated in FIG. 2A, to prepare a fracturing fluid having a desired composition and pump the frac fluid at a desired pressure and flow rate.
In an aspect, one or more frac units of the frac fleet can be connected to the treatment well 130 at a production tree of the treatment well 130. For example, a wellhead isolation tool can connect the manifold 124 to the production tree. The wellhead isolation tool and production tree can include a unit sensor module (e.g., 152) with one or more surface sensors, downhole sensors, and associated monitoring equipment. The sensors on surface frac units can measure the equipment operational conditions including temperature, pressure, flow rate, density, viscosity, chemical, vibration, strain, accelerometers, exhaust, acoustic, fluid level, and equipment identity. Sensors on the wellhead isolation tool and production tree can measure the environment inside the treatment well including temperature, pressure, flow rate, density, viscosity, chemical, vibration, strain, accelerometers, and acoustic. In an aspect, one or more frac units of the frac fleet can connect to the treatment well 130 with a wellhead isolation tool, a wellhead, a production tree, a drilling tree, or a blow out preventer.
In an aspect, one or more frac units of the frac fleet can be downhole tools communicatively connected to the control van 110. For example, a frac sleeve with downhole sensors can be communicatively connected to the production tree and wellhead isolation equipment. In another aspect, a hydrojetting, perforating gun, or other perforating tool deployed downhole via a wireline or coiled tubing unit as part of a perf and frac operation, and one or more sensors may be associated with the surface and/or subsurface equipment associated with such an operation. The downhole sensors can include wellbore cables, electronic sensors, fiber optic sensors, and other types of downhole sensors that measure the wellbore environment. The downhole sensors can connect to a unit sensor module (e.g., 152) communicatively connected to the control van 110. The downhole tools can connect to a unit control module communicatively connected to the control van 110.
A method for creating and/or modifying a pumping sequence for pumping the frac fluid into a wellbore to propagate fractures into a formation is described. The method can be used to establish a pumping sequence (e.g., an initial pumping sequence) in preparation for a pumping operation associated with a fracturing job. The method can also be used during the pumping operation to modify the pumping sequence in real time (e.g., after the start of and prior to the end of the pumping operation) based on sensor data (e.g., surface and/or subsurface data) from one or more well sites. Turning now to FIG. 4, the hierarchy of a method for developing a pumping sequence is illustrated and includes a fracture modeling control component 164, a pumping sequence control component 166, a supervisory control component 168, a plurality of unit control components 170, and a plurality of surface and/or subsurface data sensors providing associated sensor data. The fracture modeling control component 164 can model fracture propagation within a formation based on various inputs and determine a pumping sequence to generate the fractures. The pumping sequence can include a series of steps, also called stages, with one or more defined frac fluid pump rates and applied pumping pressure (e.g., a ramp up flow rate, a steady state flow rate, and a ramp down flow rate for each stage) for one or more frac fluids used in a stage (e.g., acid fluids, pad fluids, slick water, proppant laden fluids, water, etc.). The fracture modeling control component 164 can model fracture propagation during a pumping operation with sensor data 174 from the treated wellbore (e.g., sensor data from the wellsite monitoring system 50 in FIG. 1 that includes subsurface data collected from the wellbore and/or surface data that may be collected from the fracturing spread of FIG. 2A via unit sensors module 152, as shown in FIG. 3). The fracture modeling control component 164 can also use the sensor data 172 and/or sensor data 176 from one or more remote, monitoring well sites (e.g., well site 138 & 140 in FIG. 2 that may be equipped with a wellsite monitoring system 50 of the type described with reference to FIG. 1) to model fracture propagation during a pumping operation. The fracture modeling control component 164 can compare in real time the sensor data generated by the wellsite monitoring system 50 of the treatment well 130 during the pumping operation to the pumping sequence, and the fracture modeling control component 164 can make adjustments to the pumping sequence in real time as needed. The fracture modeling control component 164 can be the modeling application 146 executing on the second computer 142 shown in FIG. 2A and/or the fracture modeling control component 164 can be the modeling application 224 executing on the computer 222 at service center 220. The fracture modeling control component 164 can also determine an initial pumping sequence (e.g., a start of the frac job or start of stage pumping sequence) based on inputs such as wellbore geometry, formation geo-mechanical properties, the number of zones, fluid properties, and other criteria. Also, the pumping sequence (e.g., initial pumping sequence) can be optimized based on customer input such as one or more of the cost of each fracturing stage, the total cost of the fracturing job, a noise emission limit, a greenhouse gas emissions target, a fuel consumption target, a proppant volume target for each fracturing stage, a proppant volume target for the fracturing job, a usage limit of one or more chemicals present in the fracturing fluid used in each fracturing stage, a usage limit of one or more chemicals present in the fracturing fluid used in the fracturing job, or any combination thereof. The pumping sequence and modeled fracture propagation, also called a fracture model, can be sent from the fracture modeling control component 164 to the pumping sequence control component 166 for further processing. In an aspect, the fracture modeling control component 164 includes fracture propagation prediction software such as SmartFleet, available from Halliburton, which can include pumping sequence creation. In an aspect, the fracture modeling control component may employ one or more sub-models (and/or the fracture modeling control component may comprise of a plurality of fracture modeling modules), for example, as shown at blocks 910A-Z and described with reference to FIG. 11.
The pumping sequence control component 166 can convert the pumping sequence to an automated pumping sequence to direct the supervisory control component 168 through each pumping stage. The automated pumping sequence includes instructions for unit level control of each frac unit. The supervisory control component 168 can direct the unit control components 170A-Z to communicate the commands and instructions to the unit control module of each frac unit such as unit control module 150 of the water supply unit 112 shown in FIG. 3. The supervisory control component 168 may direct two or more frac units to work in concert with the same instructions given to each frac unit. For example, the supervisory control component 168 can instruct the unit control 170A-Z to direct two or more frac pumps 122 to operate at the same pump rate. The supervisory control component 168 can direct one or more frac units to operate within the same limits. For example, the supervisory control component 168 can instruct the one or more unit controls 170A-Z to direct the mixing blender 120 to supply frac fluid via feedlines 126 to the plurality of frac pumps 122 at the same flow rate as the frac pumps 122 are pumping. The pumping sequence control component 166 may be the managing application 136 executing on a computer 132 within control van 110. An operator in the control van 110 may install an automated pumping sequence (e.g., received from modeling application 224 or 146) into the pumping sequence control component 166 for example, the managing application 136 executing on the computer 132 within control van 110. In an aspect, the pumping sequence control component 166 includes frac unit management software such as Automated Fleet available from Halliburton, which can include unit level control software.
The fracture modeling, pump sequence, and automated pump sequence can be developed locally at the wellsite or remotely from the wellsite and conveyed or transmitted to the wellsite. The pump sequence can be modified based on sensor data from a monitored wellsite that can be transmitted by various wired or wireless means for further processing. For example, data can be transmitted and received by various wired or wireless means between a service center and the control van 110 at a remote wellsite location for further processing and/or use in modeling. Turning now to FIG. 5, a data communication system 200 is described. The data communication system 200 comprises a wellsite 202 (where the fracturing spread of FIG. 2A can be located), an access node 210, one or more monitored wellsites 216, one or more access nodes 210 (e.g., cellular site), one or more networks 212, one or more storage computers 214, one or more service centers 220, a plurality of user devices 226, and one or more customer devices 228. A wellsite 202 can include a control van 204 as part of a frac fleet (e.g., control van 110 of FIG. 2A) pumping a frac fluid into the wellhead (e.g., treatment well 130 in FIG. 2A). The control van 204 can be communicatively coupled to the monitored wellsite 216, storage computer 214, and service center 220 by a communication device 206 (e.g., transceiver) that can transmit and receive via any suitable communication means (wired or wireless) for example, wirelessly connect to an access node 210 to retrieve data (e.g., pumping sequence) from a storage computer 214. The monitored wellsite 216 can have a communication device 218 (e.g., transceiver) that can be communicatively coupled by wired or wireless means to the control van 204, storage computer 214, or service center 220. The storage computer 214 may also be referred to as a data server, data storage server, or remote server. Wireless communication can include various types of radio communication, including cellular, satellite 215, or any other form of long range radio communication. For example, communication device 206 on the control van 204 can wirelessly connect to access node 210 that is communicatively connected to a network 212. The network 212 can be one or more public networks, one or more private networks, or a combination thereof. A portion of the Internet can be included in the network 212. The storage computer 214 can be communicatively connected to the network 212. The service center 220 can have one or more computers 222 communicatively connected to the network 212.
The service center 220 can have a modeling application 224 and a managing application 225 executing on one or more computers 222. A pumping sequence associated with a wellbore fracturing job can be determined from fracture modeling performed by a fracture modeling application 224 executing on computer 222. A user device 226 can receive a customer request for a fracturing job (e.g., comprising a pump schedule) with various customer inputs from a customer device 228. The customer inputs may include formation properties, a number of zones, well completion information, well logs, a well survey, or combinations thereof. The modeling application 224 can predict the propagation of fractures within a given formation penetrated by a wellbore based on the mechanical properties of the formation and rheologic properties of the fracturing fluid. These formation mechanical properties may be based on rock cores, survey data, or determined from previous fracturing operation performed in the same field. The modeling application 224 executing on a computer 222 can produce a pumping sequence based on the desired fracture propagation. In an aspect, the fracture modeling control component 164 includes fracture propagation prediction software such as SmartFleet, available from Halliburton, which can include pumping sequence creation. The modeling application 224 can send the pumping sequence to the storage computer 214 via network 212. Likewise, the modeling application 224 can send the pumping sequence to the control van 204 via the network 212, the access node 210, and the communication device 206.
An automated pumping sequence can be created from the pumping sequence modeled by the fracture modeling application 224. The automated pumping sequence can be created by the fracture modeling application 224 or another application (e.g., managing application 225) and saved to storage computer 214 and/or transmitted to the control van 204 at the wellsite 202. For example, a user device 226 can be used to direct the managing application 225 to create an automated pumping sequence from the pumping sequence. The managing application 225 can retrieve the pumping sequence from the storage computer 214 via the network 212. The managing application 225 can retrieve the pumping sequence from the control van 204 via the network 212 and access node 210. The managing application 225 can also retrieve the pumping sequence from the computer 222 within the service center 220. The automated pumping sequence can be created from the pumping sequence and saved to storage computer 214 or transmitted to the control van 204 at the wellsite 202.
Although the fracture modeling application 224 is described as executing on a central computer 222, it is understood that the central computer 222 can be a computer system or any form of a computer system such as a server, a workstation, a desktop computer, a laptop computer, a tablet computer, a smartphone, or any other type of computing device. The central computer 222 (e.g., computer system) can include one or more processors, memory, input devices, and output devices, as described in more detail further hereinafter. Although the service center 220 is described as having the fracture modeling application 224 executing on a central computer 222, it is understood that the service center 220 can have 2, 3, 4, or any number of computers 222 (e.g., computer systems) with 2, 3, 4, or any number of modeling applications 224 or second applications 225 (e.g., managing application) executing on the central computers 222.
In an aspect, the network 212 includes a 5G core network with virtual servers in a cloud computing environment. One or more servers of the type disclosed herein, for example, storage computer 214 and central computer 222, can be provided by a virtual network function (VNF) executing within the 5G core network. In an aspect, the access node 210 can be referred to as a gigabit Node B (gNB) of 5G technology generation. In some contexts, the access node 210 can be referred to as a cell site or cell tower, as will be discussed further hereinafter. The control van 204 on the wellsite 202 can be communicatively coupled to the network 212 which includes the 5G network via the access node 210 (e.g., gigabit Node B) and thus can be communicatively coupled to one or more VNFs with virtual servers as will be more fully described hereinafter, for example with reference to FIGS. 14A and 14B.
A pumping sequence may be associated with a pumping stage, and each pumping stage may be separated into a series of pumping sub-stages (e.g., scripts) as a function of time having one or more transitions between each pumping sub-stage. Turning now to FIG. 6A, a pumping sequence, which may also be referred to as a pumping schedule or a plurality of successive time-dependent pumping intervals, 300 is illustrated. The pumping sequence is illustrated as a graph of pressure, flow rate, and proppant density as a function of time. The chart includes a pressure axis 302 with units of pounds per square inch (psi), flowrate axis 304 with units of barrels per minute (bpm), a proppant axis with units of pounds per gallon (ppg), and a horizontal axis of time with units of seconds, minutes, or hours. The graph of the pumping sequence 300 includes a pressure plot line 310, flowrate plot line 312, and proppant plot line 314 for a single zone hydraulic fracturing treatment. A fracturing job can include treatment for 2, 3, 4, 5, 10, 20, 40, 80, or any number of zones, and a corresponding number of pumping sequences 300 of the type illustrated in FIG. 6A can be used. Although the pumping sequence 300 illustrated in FIG. 6A shows a treatment of a single fracturing zone within the wellbore (which may also be referred to as a single stage), the pumping sequence 300 can include other pumping operations including pressure testing of individual pumps, removing air from pumping equipment and pressure lines, pressure testing the pumping system, a rate controlled zonal treatment, a chemical treatment without proppant, releasing a diverter treatment, and treatment pumping with pressure limits. The pumping sequence 300 can include one or more pumping operations within each stage or zone treated.
Turning now to FIG. 6B, the pumping sequence 300 can be broken up into pumping sub-stages containing steady sub-stages and transition sub-stages. The first sub-stage 320 is a transition sub-stage in the pumping sequence 300 where the pressure plot line 310, flowrate plot line 312, and proppant plot line 314 are increasing in value. The transition sub-stages can be a smooth plotline (e.g., 310 & 312), indicating an approximate steady increase in pressure and flowrate or a stepped increase (e.g., 314) indicating an incremental increase in proppant density. The second sub-stage 322 can be a steady sub-stage where the pumping rate remains steady or relatively unchanged. The pressure plot line 310, flowrate plot line 312, and proppant plot line 314 are steady in value. The third sub-stage 324 can be a transition sub-stage where the plotlines are decreasing in value to another steady state sub-stage. The fourth sub-stage 326 can be a steady sub-stage where the pumping rate remains steady. Although seven pumping sub-stages are shown, the pumping sequence 300 can include 10, 20, 30, 40, 50, or any number of pumping sub-stages without deviating from this disclosure.
The pumping sequence 300 can be written (e.g., coded as software) as an automated pumping sequence 350 comprising a set of instructions in a scripting language for execution by managing application 136. Turning now to FIG. 7 with reference to FIG. 4, the automated pumping sequence 350 can include an automated script for each pump stage with multiple instructions (e.g., commands) for each frac unit. The automated script may comprise multiple instructions written in a high level programming language or scripting languages such as Python, Java, Perl, Ruby, Tcl, or Smalltalk. The term instruction includes a command, multiple commands, and/or a line of script (e.g., high level programming language) that can contain one or more instructions. This type of high level programming language may include instructions that control the hardware function (e.g., open, close, on, off, etc.), firmware, and software.
A sub-stage script may be written for each pumping sub-stage. For example, the first sub-stage script 352 in FIG. 7 may be an automatic pumping script for the first sub-stage 320 in FIG. 6B. The second sub-stage script 354 in FIG. 6 may be the automatic script written for the second sub-stage 322 in FIG. 6B. The third sub-stage script 356 may be the automatic script written for the third sub-stage 324 in FIG. 6B. Within each sub-stage script (e.g., first sub-stage script 352), a unit script 360 A-Z may be written for the unit control 170A-Z of each frac unit. For example, with reference to FIG. 3, the automated unit script 360A can instruct the unit control module 150 of the water supply unit 112 within the first sub-stage script 352. The supervisory control component 168 can link the instructions to two or more unit scripts 360A-Z with a supervisory link 362. Although three sub-stage scripts and three pumping sub-stages are described, a sub-stage script can be created for 3, 5, 10, 20, 50, 100, or any number of sub-stages without deviating from the disclosure.
The first sub-stage script 352 can be written to idle the frac units, pressure test the frac units, to prime the equipment (e.g., add water to the equipment linking pipelines), increase the pump rate, increase a fluid density, add a chemical to fluid flow, establish a desired pump rate, decrease the pump rate, decrease a fluid density, drop a mechanical device into the well, cease the pumping operation, or any combination thereof. The first sub-stage script 352 can also be written to establish the frac units available on the wellsite based on a unique identifier associated with each unit (e.g., an identification number encoded within an RFID tag, a bar code, etc.).
With reference to FIGS. 8-11, embodiments of a method for creating and/or modifying a pumping sequence for pumping the frac fluid into a wellbore to propagate fractures into a formation are described. The method can be used to establish a pumping sequence (e.g., an initial pumping sequence) in preparation for a pumping operation associated with a fracturing job. The method can also be used during the pumping operation to modify the pumping sequence in real time (e.g., after the start of and prior to the end of the pumping operation) based on sensor data (e.g., surface and/or subsurface data) from one or more well sites.
With reference to FIGS. 8-11, disclosed herein are methods of controlling a pumping sequence of a fracturing fleet at a wellsite while performing a fracturing job on a treatment wellbore penetrating a subterranean formation. A modeling application receives one or more user inputs related to the fracturing job, one or more equipment inputs comprising sensor data from one or more frac units of the fracturing fleet, one or more wellbore inputs comprising sensor data from the treatment wellbore and/or sensor data from one or more monitoring wellbores spaced a distance apart from the treatment wellbore, or combinations thereof. The modeling application predicts a fracture propagation within the formation and produces a pumping sequence. In an aspect, the modeling application can produce an updated pumping sequence in real time during the fracturing job. The pumping sequence can include two or more sub-stages, wherein the modeling application employs a first pumping routine model to provide a first sub-stage of the pumping sequence and employs a second pumping routine model to provide a second sub-stage of the pumping sequence. A managing application controls the fracturing fleet in accordance with the pumping sequence to place a fracturing fluid in the treatment well.
Turning now to FIG. 8, the method 800 for creating a pumping sequence (e.g., an initial pumping sequence) is described with a logical flow diagram. At block 802, a set of customer inputs are entered into modeling application 224 or 146 from a user device 226. The customer inputs can include a desired or target fracture profile, formation properties, number of zones, type of perforations, fracture geometry, well geometry, well completion information, a well survey, well logs and other associated criteria. The formation properties can include mechanical properties based on rock cores, survey data, and/or determined from previous hydraulic fracturing operations. The customer inputs can also include optimization targets such as one or more of the cost of each fracturing stage, total cost of the fracturing job, a noise emission limit, a greenhouse gas emissions target, a fuel consumption target, a proppant volume target for each fracturing stage, a proppant volume target for the fracturing job, a usage limit of one or more chemicals present in the fracturing fluid used in each fracturing stage, a usage limit of one or more chemicals present in the fracturing fluid used in the fracturing job, reservoir production targets, formation fracture geometry/profile targets, cost targets, exhaust emission targets, acoustic/noise targets, or any combination thereof. At block 804, the modeling application 224/146 (e.g., fracture modeling control component 164) can predict the propagation of fractures within a given formation (e.g., model the fractures) based on the targets inputted, such as the mechanical properties of the formation and rheological properties of the fracturing fluid. At block 806, the modeling application 224/146 can produce a pumping sequence (e.g., an initial pumping sequence) based on the desired fracture propagation. The pumping sequence can be a pumping sequence for the wellbore or a portion of the wellbore, for example an initial pumping sequence that will be used at the start of a fracturing job or operation. For example, the modeling application 224/146 can produce a pumping sequence for one or more stages of a fracturing job or operation such as shown in FIGS. 6A and 6B.
At block 808, the modeling application 224/146 can determine if the pumping sequence is optimized by comparing the pump schedule to the target fracture profile and optimization targets for a given fracturing job for a given customer. If the pumping sequence is not optimized (e.g., exceeds an optimization threshold for one or more target variables such as cost, noise, the pumped volume of fracturing fluid component(s), production rate, fracture profile, etc.), the modeling application 224/146 can return to block 802 and iterate the target inputs. The modeling application 224/146 may ask the user for new inputs at block 802 if iterating the target inputs exceeds a range for target inputs (e.g., exceeds a maximum or minimum value for one or more target variables such as cost, noise, pumped volume of fracturing fluid component(s), production rate, fracture profile, etc.). The modeling application 224/146 can proceed to block 810 if the pumping sequence is optimized (e.g., within an optimization threshold for a given set of target variables). At block 810, the modeling application 224/146 can send the pumping sequence to the managing application 225/136. The automatic pumping sequence can be produced by the managing application 225/136 from the pumping sequence, for example in accordance with the disclosure of co-pending U.S. application Ser. No. ______, entitled “Method for Equipment Control” (attorney docket number 4727-10800), filed concurrently herewith and incorporated herein by reference in its entirety.
In an embodiment, the method 800 can use modeling application 146 executing on the computer 142 within the control van 110 to produce a pumping sequence (e.g., an initial pumping sequence) as disclosed herein, for example with reference to FIG. 8. The managing application 136 executing on computer 132 within the control van 110 can receive the pumping sequence from the modeling application 146 to produce the automated pumping sequence.
In an embodiment, the method 800 can use modeling application 224 executing on the computer 222 within the service center 220 to produce pumping sequence (e.g., an initial pumping sequence) as disclosed herein, for example with reference to FIG. 8. The managing application 136 executing on computer 132 within the control van 110 can receive the pumping sequence from the modeling application 224 or from the storage computer 214 via network 212 to produce the automated pumping sequence.
In an embodiment, the method 800 can use modeling application 224 executing on the computer 222 within the service center 220 to produce pumping sequence (e.g., an initial pumping sequence) as disclosed herein, for example with reference to FIG. 8. The managing application 225 executing on computer 222 within the service center 220 can receive the pumping sequence from the modeling application 224 to produce the automated pumping sequence, which can be saved in storage computer 214 and/or provided via network 212 to managing application 136 executing on computer 132 at control van 110.
In an embodiment, the method 800 can use modeling application 146 executing on the computer 142 within the control van 110 to produce a pumping sequence (e.g., an initial pumping sequence) as disclosed herein, for example with reference to FIG. 8. The modeling application 146 can send the pumping sequence to storage computer 214 via network 212. The managing application 136 executing on computer 132 within the control van 110 can receive the pumping sequence from the modeling application 224 or from the storage computer 214 via network 212 to produce the automated pumping sequence.
In an embodiment, the method 800 can use modeling application 146 executing on the computer 142 within the control van 110 to produce a pumping sequence (e.g., an initial pumping sequence) as disclosed herein, for example with reference to FIG. 8. The modeling application 146 can send the pumping sequence to storage computer 214 via network 212. The managing application 225 executing on computer 222 within the service center 220 can receive the pumping sequence from the storage computer 214 and produce the automated pumping sequence, which can be saved in storage computer 214 and/or provided via network 212 to managing application 136 executing on computer 132 at control van 110.
A method for modifying a pumping sequence in real time during a pumping operation to achieve the desired, targeted fracture propagation is described. Turning now to FIG. 9, the method 820 for modifying a pumping sequence is described with a logical flow diagram. At block 822, the pumping sequence can be loaded into the modeling application 146 executing on the computer 142 within the control van 110. The associated automated pumping sequence (e.g., the automated pumping sequence corresponding to the pumping sequence uploaded to the modeling application 146) can be loaded into the managing application 136 on the computer 132 within the control van 110. In an aspect, modeling application 146 and managing application 136 can be executing on the same computer or server. At block 824, the targets for one or more parameters of a stage of the pumping sequence are identified or determined from the pumping sequence by the modeling application 146 or alternatively, the targets for one or more parameters of a stage of the pumping sequence are loaded into the modeling application 146.
The method 820 can execute an automated sub-stage routine 848 during a pumping stage of the automated pumping sequence. One or more automated sub-stage routines 848 can execute during a pump stage based on instructions present in the automated pumping script and/or based on operational feedback provided by sensor data 828. For example, the automated pumping script may have an automated sub-stage routine 848 to execute during a pumping stage. In another example, the modeling application 146 can add an automated sub-stage routine 848 to the pumping sequence based on operational feedback provided by sensor data 828.
The automated sub-stage routine 848 begins with the initiation of a sub-stage routine at block 826. The sub-stage routine can correspond to a sub-stage of a pumping sequence 300, as shown in FIGS. 6A and 6B, and may comprise set point or target values for parameters associated with the pumping stage such as pumping pressure, pumping flow rate, proppant amount, the composition of the fracturing fluid, or combinations thereof. The sub-stage routine may be a control routine for a plurality of unit level components (e.g., frac units as shown in FIG. 2A) associated with a pumping stage, for example, a pump routine, a proppant ramp routine, a proppant placement routine, a chemical placement routine, a formation conductivity routine, a blender routine, a diversion product drop routine, or combinations thereof. For example, at block 826, sub-stage 1 of the pumping sequence 300 of FIG. 6B may begin by blending a fracturing fluid in accordance with the sub-stage 1 script and ramping up the pumping of the fracturing fluid into the wellbore in accordance with the profile shown in FIG. 6B. In an aspect, the identity of the unit level component of the frac spread (e.g., frac units as shown in FIG. 2A) can be determined automatically, for example, in accordance with the disclosure of co-pending U.S. application Ser. No. ______ entitled “Method for Equipment Control” (attorney docket number 4727-10800), filed concurrently herewith and incorporated herein by reference in its entirety.
At block 830, the modeling application 146 receives sensor data 828, which may include (A) sensor data 174 from the treated wellbore, which may further include (i) sensor data from the wellsite monitoring system 50 in FIG. 1 that includes subsurface data collected from the wellbore and/or surrounding formation; (ii) surface data that may be collected from the fracturing spread of FIG. 2A via unit sensors 152 as shown in FIG. 3); or (iii) both (i) and (ii); (B) sensor data 172 and/or sensor data 176 from one or more remote, monitoring well sites 138 and/or 140, respectively, as shown in FIG. 2A, which may further include subsurface sensor data collected from with a wellsite monitoring system 50 of the type described with reference to FIG. 1 installed at wellsite 138 and/or 140 in FIG. 2A; or (C) both (A) and (B). The modeling application 146 can use the sensor data 828 to determine a current or real time state of the model, which may correspond to a current or real time parameter of the pumping sequence (e.g., pressure, flow rate, proppant amount frac fluid composition, etc.), a current or real time parameter of the fractures in the formation (e.g., size, number, geometry, etc. of fractures), or combinations thereof. The modeling application 146 may further compare the current or real time state of the model (and correspondingly one or more current or real time parameters of the pumping sequence and/or formation fracture profile) to an expected or predicted state of the model to identify any differences between expected/predicted/target values of parameters and current/real time values of parameters associated with the pumping sequence and/or formation fracture profile.
If one or more of the current or real time parameters of the fracturing job derived from sensor data 828 deviate from the corresponding target/predicted parameters by more than a predefined delta, the automated sub-stage routine 848 proceeds to block 834 for exception handling. In an aspect, the automated stage routine determines at block 834, whether an exception script corresponding to the present exception is present and available for execution. The exception script at block 834 can be a script of instructions (e.g., commands) to change the operation of the pumping stage to address (e.g., correct) the exception. In an aspect, the exception script is an automated exception script, for example, in accordance with the disclosure of co-pending U.S. application Ser. No. ______, entitled “Method for Equipment Control” (attorney docket number 4727-10800), filed concurrently herewith and incorporated herein by reference in its entirety. Upon execution, the exception script at block 834 can proceed to block 836 to modify (e.g., automatically and/or via user input) one or more stage targets and thereby provide a corresponding one or more modified stage targets. If the modified stage targets are within a predefined range (e.g., within the acceptable ranges of corresponding values used to develop the initial pumping sequence), the exception script at block 834 returns to block 826 with the modified stage targets. If the modified stage targets are outside a predefined range, the exception script will proceed to block 838 to notify the user (e.g., service personnel) of an exception. At block 838, the automated sub-stage routine 848 notifies the users of an exception and returns control or partial control to the user. The user can perform any or all of the mitigating steps including manually setting one or more new or modified stage targets, terminating the automated sub-stage routine 848, ending the active pumping stage, or manually controlling the frac fleet.
Returning to block 832, if one or more of the current or real time parameters of the fracturing job derived from sensor data 828 does not deviate from the corresponding target/predicted parameters by more than a predefined delta, the automated sub-stage routine 848 proceeds to block 832. At block 832, the automated sub-stage routine 848 checks to see if one or more target values of the pumping stage have been met, for example a given pressure, flow rate, proppant amount, frac fluid composition, or a combination thereof for the stage. If one or more target values of the pumping stage have not been met, the automated sub-stage routine 848 returns to block 826. If the target values of the pumping stage have been met, the automated sub-stage routine 848 proceeds to block 840.
At block 840, the modeling application 146 checks to see if a stage has been completed. If the pumping stage has not finished, the modeling application 146 can return to block 824 and the pumping of fracturing fluid associated with the present stage can be continued. If the pumping stage has been completed, the modeling application 146 can proceed to block 842. At block 842, the modeling application 146 can report out the data (e.g., sensor data 828) and results of the completed pumping stage and proceed to block 844. At block 844, the modeling application 146 checks to see if all of the pumping stages have been completed for a given pumping sequence (e.g., determine whether the fracturing job is complete). If the pumping sequence has not finished, the modeling application 146 can return to block 822 and the fracturing job proceeds with pumping of the next stage. If the pumping sequence has completed all of the pumping stages (e.g., the fracturing job is completed), the modeling application 146 can proceed to block 846. At block 846, the modeling application 146 can report out the data (e.g., sensor data 828) and results of the completed pumping sequence and associated fracturing job. Also, at block 846, the managing application 136 can place the fracturing fleet in an off or standby state.
A method for modifying a pumping sequence in real time during a pumping operation based on monitored well sites to achieve the desired fracture propagation is described. The sensor data from a monitored wellsite (e.g., wellsite 138 & 140 from FIG. 2A) may indicate that the formation is fracturing in a different manner than modeled. A modified fracture model can be generated on the fly (e.g., while the fracturing job is ongoing) using the real time sensor data from the treated wellsite and/or the monitored well sites. Turning now to FIG. 10, a method 850 for modifying a pumping sequence in real time is described as a logical flow diagram. At block 852, the pumping sequence can be loaded into the modeling application 146 executing on the computer 142 within the control van 110. The associated automated pumping sequence (e.g., the automated pumping sequence corresponding to the pumping sequence uploaded to the modeling application 146) can be loaded into the managing application 136 on the computer 132 within the control van 110. In an aspect, modeling application 146 and managing application 136 can be executing on the same computer or server.
At block 854, the modeling application 146 receives sensor data 856, which may include (A) sensor data 174 from the treated wellbore, which may further include (i) sensor data from the wellsite monitoring system 50 in FIG. 1 that includes subsurface data collected from the wellbore and/or surrounding formation; (ii) surface data that may be collected from the fracturing spread of FIG. 2A via unit sensors module 152, as shown in FIG. 3); or (iii) both (i) and (ii); (B) sensor data 172 and/or sensor data 176 from one or more remote, monitoring well sites 138 and/or 140, respectively, as shown in FIG. 2A, which may further include subsurface sensor data collected from with a wellsite monitoring system 50 of the type described with reference to FIG. 1 installed at wellsite 138 and/or 140 in FIG. 2A; or (C) both (A) and (B). The modeling application 146 can use the sensor data 856 to determine a current or real time state of the model, which may correspond to a current or real time parameter of the pumping sequence (e.g., pressure, flow rate, proppant amount frac fluid composition, etc.), a current or real time parameter of the fractures in the formation (e.g., size, number, geometry, etc. of fractures), or combinations thereof. At block 858, the modeling application 146 may further compare the current or real time state of the model (and correspondingly one or more current or real time parameters of the pumping sequence and/or formation fracture profile) to an expected or predicted state of the model to identify any differences between expected/predicted/target values of parameters and current/real time values of parameters associated with the pumping sequence and/or formation fracture profile.
If one or more of the current or real time parameters of the fracturing job derived from sensor data 828 does not deviate from the corresponding target/predicted parameters by more than a predefined delta, the method proceeds to block 859 to determine if the fracturing job is completed. If the frac job is completed, the method proceeds to finish. If the frac job is not completed, the method returns to block 854 to continue iteratively checking the current, real time status of the fracturing job to the modeled, predicted status of the fracturing job. Upon returning to block 854, the modeling application 146 receives updated sensor data 856 (e.g., data that has been updated to correspond with a periodic passage of time) and the method proceeds iteratively as described with reference to blocks 854, 858, and 859.
If one or more of the current or real time parameters of the fracturing job derived from sensor data 828 deviate from the corresponding target/predicted parameters by more than a predefined delta, the automated sub-stage routine 848 proceeds to block 862 to run an automated sub-stage routine 860. The automated sub-stage routine 860 can be a script of instructions (e.g., commands) to change the operation of the pumping stage in response to an update or modification of the fracture model. The automated sub-stage routine 860 can begin at block 862 to generate a modified fracture model using sensor data 856. The modified fracture model can be iterated any number of times to converge within a predefined value based upon the sensor data 856. In an aspect, the modified model produced by the modeling application 146 at block 862 is performed in accordance with the fracture modeling at block 804 of FIG. 8.
The modeling application 146 can step to block 864 to determine if the modified fracture model is optimized per the inputted target values. In an aspect, the optimized model produced by the modeling application 146 at block 864 is performed in accordance with the model optimization at block 808 of FIG. 8.
If the modified fracture model is not optimized at block 864, the method can proceed to block 866, where one or more targets or inputs of a given fracturing job (e.g., a stage of a fracturing job) may be modified (e.g., automatically and/or via user input) and thereby provide a corresponding one or more modified targets (e.g., modified stage targets). If the modified stage targets are within a predefined range (e.g., within the acceptable ranges of corresponding values used by the initial model to develop the initial pumping sequence), the method proceeds to block 862 with the modified stage targets. At block 862, the automated sub-stage routine 860 determines the modified fracture model using the modified targets. If at block 866, the modified stage targets are outside a predefined range, the exception script will proceed to block 868 to notify the user (e.g., service personnel) of an exception. At block 868, the automated sub-stage routine 860 notifies the users of an exception and returns control or partial control to the user. The user can perform any or all of the mitigating steps including manually setting one or more new or modified stage targets, terminating the automated sub-stage routine 860, ending the active pumping stage, or manually controlling the frac fleet. The automated stage routine can proceed iteratively as described with reference to blocks 862, 864, 866, and 868 until the modified model is optimized.
At block 864, if the modified fracture model has been optimized, then the method proceeds to block 870 and the iterative execution of the automated sub-stage routine 860 ends. At block 870, the modeling application 146 generates a modified pumping sequence using the modified fracture model. The modeling application 146 sends the modified pumping sequence to the managing application 136. At block 872, the managing application 136 can generate a modified automated pumping sequence (e.g., comprising a plurality of pumping sub-stage scripts) and use the modified automated pumping sequence to update and continue the fracturing job in real time. The fracture modeling routine/method 850 restarts at block 852 with the modified pumping sequence and modified automated pumping sequence generated at blocks 870 and 872, respectively.
In an embodiment, the fracture modeling routine/method 850 can use modeling application 146 executing on the computer 142 within the control van 110 to produce a pumping sequence (e.g., an initial pumping sequence loaded at block 852 and/or a modified pumping sequence prepared at block 870) as disclosed herein, for example with reference to FIG. 10. The managing application 136 executing on computer 132 within the control van 110 can receive the pumping sequence from the modeling application 146 to produce the automated pumping sequence (e.g., an initial automated pumping sequence loaded at block 852 and/or a modified automated pumping sequence prepared at block 872).
In an embodiment, the fracture modeling routine/method 850 can use modeling application 224 executing on the computer 222 within the service center 220 to produce a pumping sequence (e.g., an initial pumping sequence loaded at block 852 and/or a modified pumping sequence prepared at block 870) as disclosed herein, for example with reference to FIG. 10. The managing application 136 executing on computer 132 within the control van 110 can receive the pumping sequence from the modeling application 224 or from the storage computer 214 via network 212 to produce the automated pumping sequence (e.g., an initial automated pumping sequence loaded at block 852 and/or a modified automated pumping sequence prepared at block 872).
In an embodiment, the method 800 can use modeling application 224 executing on the computer 222 within the service center 220 to produce a pumping sequence (e.g., an initial pumping sequence loaded at block 852 and/or a modified pumping sequence prepared at block 870) as disclosed herein, for example with reference to FIG. 10. The managing application 225 executing on computer 222 within the service center 220 can receive the pumping sequence from the modeling application 224 to produce the automated pumping sequence (e.g., an initial automated pumping sequence loaded at block 852 and/or a modified automated pumping sequence prepared at block 872), which can be saved in storage computer 214 and/or provided via network 212 to managing application 136 executing on computer 132 at control van 110.
In an embodiment, the method 800 can use modeling application 146 executing on the computer 142 within the control van 110 to produce a pumping sequence (e.g., an initial pumping sequence loaded at block 852 and/or a modified pumping sequence prepared at block 870) as disclosed herein, for example with reference to FIG. 10. The modeling application 146 can send the pumping sequence to storage computer 214 via network 212. The managing application 136 executing on computer 132 within the control van 110 can receive the pumping sequence from the modeling application 224 or from the storage computer 214 via network 212 to produce the automated pumping sequence (e.g., an initial automated pumping sequence loaded at block 852 and/or a modified automated pumping sequence prepared at block 872).
In an embodiment, the method 800 can use modeling application 146 executing on the computer 142 within the control van 110 to produce a pumping sequence (e.g., an initial pumping sequence loaded at block 852 and/or a modified pumping sequence prepared at block 870) as disclosed herein, for example with reference to FIG. 10. The modeling application 146 can send the pumping sequence to storage computer 214 via network 212. The managing application 225 executing on computer 222 within the service center 220 can receive the pumping sequence from the storage computer 214 and produce the automated pumping sequence (e.g., an initial automated pumping sequence loaded at block 852 and/or a modified automated pumping sequence prepared at block 872), which can be saved in storage computer 214 and/or provided via network 212 to managing application 136 executing on computer 132 at control van 110.
A method for executing and/or modifying a pumping sequence in real time during a pumping operation based on monitored well sites to achieve the desired fracture propagation is described. The sensor data from a monitored wellsite (e.g., wellsite 138 & 140 from FIG. 2A) gathered during a pumping sequence may indicate that the formation is fracturing in a different manner than modeled. A modified or alternative pumping sequence can be executed based upon the updated model using the sensor data from the treated wellsite and/or the monitored well sites. Turning now to FIG. 11, a method 900 for executing a pumping sequence is described as a logical flow diagram.
At block 902, a list of performance criteria (and an associated ranking of priority or importance for each member of the list of performance criteria) for a given fracturing job is loaded into the modeling application 146 executing on the computer 142 within the control van 110. Additionally, limits for one or more control variables of the fracturing job (e.g., frac unit control variables) may be set and/or modified (e.g., max and min pressures, flow rates, proppant concentration, etc.). In an aspect, the listing and ranking of frac job performance criteria and/or the setting/modifying of control variable limits are performed in accordance with the set targets at block 802 of FIG. 8 (or vice-versa).
At block 904, one or more fracture modeling applications (e.g., one or more modeling applications 146) can be loaded into computer 142 in control van 110 modeling application 146 or otherwise accessed and activated by computer 142 such that a fracture job may be modeled based upon the input at block 802 (e.g., target performance criteria and target limits). Each fracture modeling application can comprise machine algorithms for calculating pumping flowrate, pumping pressure, and proppant density based on the input at block 802 (and/or an input of wellbore sensor data as described herein). The fracture modeling application can provide a pumping sequence 300 of the type shown in FIGS. 6A and 6B. In an aspect, the fracture modeling and production of a resultant pumping sequence are performed in accordance with the hierarchy described for fracture modeling control component 164 and pumping sequence control of FIG. 4 and/or model fracture at block 804 and pumping sequence at block 806 of FIG. 8 (or vice-versa).
At block 906, the modeling application 146 can monitor the equipment data and the wellbore sensor data as the fracturing job starts and progresses (e.g., monitor that status of an automated pumping sequence executing on the managing application 136 as described herein, for example, with reference to pumping sequence control component 166 of FIG. 4). The modeling application 146 can monitor the progress of an ongoing fracturing job, for example, by periodically comparing the equipment data and sensor data (e.g., wellbore sensor data 172, 174, & 176 from FIG. 4) to predetermined setpoints or targets for various performance criteria and/or control variables associated with the fracturing job, for example with reference to block 854 of FIG. 10. The sensor data may include (A) sensor data 174 from the treated wellbore, which may further include (i) sensor data from the wellsite monitoring system 50 in FIG. 1 that includes subsurface data collected from the wellbore and/or surrounding formation; (ii) surface data that may be collected from the fracturing spread of FIG. 2A via unit sensors module 152, as shown in FIG. 3); or (iii) both (i) and (ii); (B) sensor data 172 and/or sensor data 176 from one or more remote, monitoring well sites 138 and/or 140, respectively, as shown in FIG. 2A, which may further include subsurface sensor data collected from with a wellsite monitoring system 50 of the type described with reference to FIG. 1 installed at wellsite 138 and/or 140 in FIG. 2A; or (C) both (A) and (B). In comparing the progress of the present fracturing job (as determined using the sensor data) to the associated progress predicted by the model, the modeling application 146 may employ one or more sub-models (and/or the modeling application 146 may be comprised of a plurality of fracture modeling modules), for example as shown at blocks 910A-Z. The process flow includes a number of sub-models at block 910A-Z, and these sub-models may be more relevant at different times during the frac stage treatment/execution. Some sub-models are used at the beginning of the treatment to achieve specific objects, and others are targeting the middle or end of the treatment schedule.
The modeling application 146 can step to one of the blocks 910A-Z to run a pumping routine model depending on the pumping stage and/or sensor data. Each pumping routine model can include a closed loop algorithm. The algorithm can calculate the pumping equipment settings (flow rate, pressure, etc.) based on proprietary mathematical formulas and sensor data. The algorithm can be closed loop so that the pumping routine model continues to execute until the end of the pumping stage or a change in the sensor data. Various control algorithms/models at blocks 910A-Z may be used to model/calculate treatment schedules/frac spread target parameters to achieve certain outcomes. The various models at blocks 910A-Z may be used individually in a closed loop control mode where the system switch between selected models in a predetermined sequence or in combinations of predictive models/modes where the system seeks to optimize the frac treatment outcome based on various criteria, either in a closed loop or open loop mode or a combination of closed loop/open loop mode. Some of the models may predominantly be used in, e.g., the first 1/10, ¼, ⅓, or ½ of the treatment (ProdigiAB at block 910A, Proppant Ramp at block 910B, Cluster Efficiency at block 910C), whereas others may predominantly be used in the middle ⅘, ½, or ⅓ of the treatment sequence (Diversion at block 910D, Complexity at block 910E) whereas yet others may mainly be used in the last 1/10, ¼, ⅓, or ½ of the treatment schedule (Well Interaction at block 910G) and the transition between the algorithms may be done after a step where the current treatment progress is evaluated against various pre-determined criteria (e.g., at block 906, for example as described with reference to block 854 of FIG. 10). Some algorithms may be used for a longer duration in a pre-determined sequence like, e.g., ProdigiAB at block 910A—ACM at block 910F—Well Interaction at block 910G, where ACM may be used 70-95% of the stage treatment.
The performance criteria (e.g., customer objectives) for evaluating the fracturing job may be one or more of: optimize fracturing of unproduced reservoir volume; minimize misplaced proppant; keep fracture overlap between target volumes within certain boundaries; optimize outcomes of production models based on predicted fracture lengths/widths/heights/contacted reservoir volumes and production rates; achieve financial targets based on the given cost of BOE/cost of treatment/predicted or modeled production; minimize negative well interaction effects within given boundaries; optimize cluster efficiency; maintain treating pressures and proppant/diverter volumes within given/modeled ranges; any other physics based model or data driven model or combinations of physics based/data driven models, or any combination thereof. A set of target criteria and rules may be developed based on customer objectives and these target criteria be developed jointly with the customer or may be based on data driven approaches given that an oilfield service company may pump a large number of frac jobs and may use data from a number of these jobs to develop target criteria/rules/automated treatment schedules. The data driven approaches may use any of the selected treatment data, sensor data, engineered values calculates based on treatment and/or measured sensor data, and/or data from drilling/logging while drilling, and/or surveys/logging runs, and/or data production and well data publicly available, and/or measured production data from individual wells. The data driven approaches may be limited by customer objectives on a field level, pad level, well level and/or individual stage level. Control variables may include one or more of pressure, flow rate, proppant concentration, proppant size/type, chemicals (friction reducers, gelling agents, etc.), volumes, liquid type, the density of pumped fluids, etc. Target variables may include one or more of pressure in treatment well, pressure in monitoring well, flow rate per cluster, misplaced proppant, misplaced volume, fracture lengths/heights/widths, maximum or minimum values of any target variable, growth rates of any target variables or any calculated values as a function of one or more target and/or control variables. Values and/or limits for these performance criteria can be input and/or updated as described in accordance with block 802 of FIG. 8 and block 902 of FIG. 11 (and vice-versa).
At block 910A, the modeling application 146 can execute a pumping routine model for pumping frac fluid in a manner to open (e.g., fill the perforation) with proppant. The pumping routine model may be a closed loop algorithm to establish or modify a pumping sequence with fluid flowrate, proppant density, and pump pressure for uniform fluid allocation among perforations or perforation clusters. In an aspect, one such pumping routine model is ProdigiAB from Halliburton.
At block 910B, the modeling application 146 can execute a pumping routine model for increasing the proppant concentration at a controlled rate based on sensor feedback. The rate of increasing the proppant concentration must be controlled to prevent screen-out where a large concentration of proppant causes a plugging of the perforations. The closed loop algorithm will increase the concentration to maximize the amount of proppant pumped into the formation. In an aspect, one such pumping routine model is Proppant Ramp from Halliburton.
At block 910C, the modeling application 146 can execute a pumping routine model to optimize the placement of proppant into the perforations. The pumping routine model can determine the ratio or percentage of perforations receiving proppant based on sensor data from the treatment well and frac units. The pumping routine model can modify the targets of the pumping sequence or determine a new pumping sequence for the modeling application 134. The algorithm may include misplaced proppant calculations where misplaced proppant is defined as the amount of cumulative proppant pumped through overstimulated clusters beyond the mean or target proppant allocation, and physics based and/or data driven models to minimize misplaced proppant. In an aspect, one such pumping routine model is Cluster Efficiency from Halliburton.
At block 910D, the modeling application 146 can execute a pumping routine model to determine if and/or when to drop diversion material to change the flow distribution of proppant into a set of perforations. The pumping routine model can include a closed loop control algorithm to measure subsurface properties and calculate if/when to drop particulate material with the objective of changing flow distribution between perforations/perforation clusters. The algorithm may include changes of surface flow rate combined while adding diverter material at surface to minimize diverter material dispersion/maximize concentration, ramping up flow rate to move the diverter pill to the subsurface, and also reduce the flow rate when the diverter pill hits the perforations for proper seating/distribution. In an aspect, one such pumping routine model is Diversion from Halliburton.
At block 910E, the modeling application 146 can execute a pumping routine model to determine if a change to the pumping sequence is needed based on the sensor data. The pumping routine model can include a closed loop control algorithm to measure subsurface properties and model complexity based on various treatment scenarios. The algorithm may include data driven models for fracture properties based on changes in pressure, rates, diversion, proppant concentrations and rate of changes of said parameters. In an aspect, one such pumping routine model is Complexity from Halliburton.
At block 910F, the modeling application 146 can execute a pumping routine model to combine diverter drops with changes in pumping rates to achieve a target. The pumping routine model can include a closed loop control algorithm to measure sensor data, model various reservoir properties and control targets/treatment schedule to the automated frac fleet (e.g., managing application) to achieve a combination of diverter drops/rates/pressures within the modeled targets per algorithm. The algorithm calculates a pressure fairway and the target treatment schedule works within an upper/lower bound of pressure as diverter concentration, proppant concentration and/or chemical concentration is varied. In an aspect, one such pumping routine model is ACM from Halliburton.
At block 910G, the modeling application 146 can execute a pumping routine model to measure and monitor reservoir communication between a treatment well and a monitored wellsite, and modify a pumping sequence accordingly. The pumping routine model can include a closed loop control algorithm that measures well interaction related properties and model different scenarios where well interference effects can be controlled. A number of measurements can be used to model well interaction effects: Monitor well pressure changes may indicate pressure communication through reservoir deformation as fractures approach the well where the signature and/or magnitude of the pressure measurement can be used to model well interaction effects and various control actions can be modeled to change the outcome of these well interaction events. Similarly, Distributed Acoustic Sensing (DAS) based MicroSeismic Monitoring (MSM) may be used to measure microseismic events and this data can be used to map/model fracture length/width/height/azimuth and associated growth rates as well as predict final fracture lengths. Distributed Strain Sensing (DSS) can be used to measure strain changes along the wellbore during the fracture operation, and the strain can be used to model the associated fractures/volumes that would be required to generate a similar distributed strain profile. The fracture geometry/volumes as well as associated growth rates can be used to predict the outcome of the fracturing treatment and associated will interference effects. A number of different sub-algorithms can be used to measure/model well interaction effects and make predictions based on various control actions/control variables/target variables.
At block 912, the modeling application 146 can optionally visualize and/or aggregate the sensor data, modeled data/parameters, and equipment and sensor status associated with the present fracturing job. Such visualization can be output to a user, for example via a report, alert, or user interface.
At block 914, the modeling application 146 may further compare the current or real time state of the model or combination of sub-models at block 910A-Z (and correspondingly one or more current or real time parameters of the pumping sequence and/or formation fracture profile) to an expected or predicted state of the model or sub-models at block 910A-Z to identify any differences between expected/predicted/target values of parameters and current/real time values of parameters associated with the pumping sequence and/or formation fracture profile. That is, the modeling application 146 can determine if the pumping sequence needs to be modified by the delta between the sensor data and the updated model. If so, the modeling application 146 can update the the pumping sequence to provide a modified pumping sequence (e.g., to alter the fracture propagation within the formation in real time) based on the updated modeling (e.g., re-modeling). If not, the modeling application 146 can leave the pumping sequence as is (e.g., unmodified pumping sequence). In an aspect, the updating and/or optimization of the model at blocks 906, 910, 912, 914, and 916 can be carried out in accordance with fracture modeling routine/method 850 of FIG. 10.
At block 916, the modeling application 146 can communicate the pumping sequence (e.g., a modified or unmodified pumping sequence) to the user and send the pumping sequence to the managing application (e.g., managing application 136). The managing application can modify the automated pumping sequence with the modified pumping sequence and further proceed with carrying out the fracturing job, for example in accordance with method 820 as shown in FIG. 9.
At block 918, the modeling application 146 can communicate selected data to the user (e.g., service personnel) and/or save the data set to a server (e.g., storage computer 214). The selected data set can be the data set that prompted the execution of a pumping sequence models.
At block 920, the modeling application 146 can determine if a model set point or target needs was modified. If the pumping sequence (e.g., a modified pumping sequence) changed one or more set points or targets, the modeling application returns to block 902 where the modified set point or target can be compared to any applicable corresponding limits (e.g., max or min values). If the pumping sequence did not require any changes to set points or targets, the modeling application proceeds to block 922.
At block 922, the modeling application 146 checks the operational status of the current stage. If the stage is not competed, the modeling application 146 proceeds to block 906 and the pumping stage continues. If the pumping stage is completed, the modeling application 146 proceeds to block 924.
At block 924, the modeling application 146 can perform end of stage activities including writing data to a server (e.g., storage computer 214) and/or sending a report to a user. At block 926, the modeling application checks the operational status of the fracturing job. The modeling application 146 returns to block 902, if the last stage completed is not the last stage of the pumping sequence (i.e., if the job is not complete). If the job is complete, the method proceeds to block 928 and the modeling application 146 can perform end of job activities including writing data to a server (e.g., storage computer 214) and/or sending a report to a user.
An automated pumping sequence 350 may follow the same logical steps through each pump sub-stage (e.g., 320) while fracturing multiple wellbores (e.g., separate and distinct wells, separate wellbores (e.g., lateral wellbores) sharing a common vertical portion or wellhead, or combinations thereof). In an embodiment, a control van 110 of FIG. 2A can be connected to a first set of frac units (e.g., a first frac fleet) and a second set of second frac units (e.g., a second frac fleet). The first frac fleet can be connected to a first treatment well 130 for a hydraulic fracturing treatment. The second frac fleet can be connected to a second treatment well for a hydraulic fracturing treatment. The automated pumping sequence 350 can direct a simultaneous fracture treatment of the first and second treatment well (e.g., 130) or the sequential treatment of the first and second well. In an aspect, the first and second treatment wells can be treated in a combination of simultaneous or sequential fracturing stages where the fracturing fluid can be pumped into the first and second treatment wells simultaneously in some stages or sub-stages, sequentially in some stage or sub-stages, or combinations thereof in accordance with a pumping sequence associated with the fracturing job.
In an embodiment, the managing application 136 can determine the sequence of pump stages with stage targets from the automated pumping sequence 350 for a sequential treatment. The managing application 136 (e.g., pumping sequence control 166 from FIG. 4) can establish supervisory control 168 and unit control 170A-Z on a first frac fleet and on a second frac fleet. The automated pumping sequence 350 can direct the first frac fleet to treat (e.g., pump frac fluid) a first zone in the first treatment well 130, then direct the second frac fleet to treat (e.g., pump frac fluid) a first zone in the second treatment well. The managing application 136 can receive sensor data 174 from the first treatment well 130 and second treatment well during the treatment of the first treatment well. The managing application 136 can receive sensor data 174 from the first treatment well 130 and second treatment well during the treatment of the second treatment well. The managing application 136 can modify one or more of the sub processes (e.g., closed loop pump sequences for the first well, the second well, or both) based on the sensor data received from one or more wellbores.
In an embodiment, the managing application 136 can determine the sequence of pump stages with stage targets from the automated pumping sequence 350 for a simultaneous treatment. The managing application 136 (e.g., pumping sequence control 166 from FIG. 4) can establish supervisory control 168 and unit control 170A-Z on a first frac fleet and on a second frac fleet. The automated pumping sequence 350 can direct the first frac fleet to treat (e.g., pump frac fluid) a first zone in the first treatment well 130 while simultaneously, or near simultaneously, directing the second frac fleet to treat (e.g., pump frac fluid) a first zone in the second treatment well. The managing application 136 can receive sensor data 174 from the first treatment well 130 and second treatment well during the near simultaneous treatment of the first treatment well 130 and second treatment well. The managing application 136 can modify one or more of the sub processes (e.g., closed loop pump sequences for the first well, second well, or both) based on the sensor data received from one or more wells.
Turning now to FIG. 12, a method 230 is described. In an embodiment, the method 230 is a method of controlling a pumping sequence of a fracturing fleet at a wellsite while performing a fracturing job on a treatment wellbore penetrating a subterranean formation. At block 232, the method 230 comprises receiving during the fracturing job, by a modeling application executing on a computer, one or more wellbore inputs comprising sensor data from the treatment wellbore and sensor data from one or more monitoring wellbores spaced a distance apart from the treatment wellbore.
At block 234, the method 230 comprises predicting, by the modeling application, a fracture propagation within the subterranean formation using all or a portion of the inputs.
At block 236, the method 230 comprises producing during the fracturing job, by the modeling application, an updated pumping sequence to obtain the fracture propagation.
At block 238, the method 230 comprises controlling, by a managing application, the fracturing fleet in accordance with the updated pumping sequence to place a fracturing fluid in the treatment well.
Turning now to FIG. 13, a method 250 is described. In an embodiment, the method 250 is a method of controlling a pumping sequence of a fracturing fleet at a wellsite while performing a fracturing job on a treatment wellbore penetrating a subterranean formation.
At block 252, the method 250 comprises receiving, by a modeling application executing on a computer, one or more user inputs related to the fracturing job, one or more equipment inputs comprising sensor data from one or more frac units of the fracturing fleet, one or more wellbore inputs comprising sensor data from the wellbore, or combinations thereof.
At block 254, the method 250 comprises predicting, by the modeling application, a fracture propagation within the subterranean formation using all or a portion of the inputs.
At block 256, the method 250 comprises producing, by the modeling application, a pumping sequence to obtain the fracture propagation, wherein the pumping sequence comprises two or more sub-stages, and wherein the modeling application employs a first pumping routine model to provide a first sub-stage of the pumping sequence and employs a second pumping routine model to provide a second sub-stage of the pumping sequence, wherein the first and second pumping routine models are different.
At block 258, the method 250 comprises controlling, by a managing application, the fracturing fleet in accordance with the pumping sequence to place a fracturing fluid in the treatment well.
Turning now to FIG. 14A, an exemplary communication system 550 is described suitable for implementing one or more embodiments disclosed herein, for example implementing communications or messaging as disclosed herein including without limitation any aspect of wireless communication 46 on FIG. 1; communications with the wellsite of FIG. 2A (e.g., control van 110 and associated computing systems); any aspect of communications with a unit level control system as shown in FIG. 3 (e.g., control module 150, sensors 152); any aspect of communications with the computing components and network associated with FIG. 5 (e.g., data communication system 200); etc. Typically, the communication system 550 includes a number of access nodes 554 that are configured to provide coverage in which UEs 552 such as cell phones, tablet computers, machine-type-communication devices, tracking devices, embedded wireless modules, and/or other wirelessly equipped communication devices (whether or not user operated), can operate. The access nodes 554 may be said to establish an access network 556. The access network 556 may be referred to as a radio access network (RAN) in some contexts. In a 5G technology generation an access node 554 may be referred to as a gigabit Node B (gNB). In 4G technology (e.g., long term evolution (LTE) technology) an access node 554 may be referred to as an enhanced Node B (eNB). In 3G technology (.e.g., code division multiple access (CDMA) and global system for mobile communication (GSM)) an access node 554 may be referred to as a base transceiver station (BTS) combined with a basic station controller (BSC). In some contexts, the access node 554 may be referred to as a cell site or a cell tower. In some implementations, a picocell may provide some of the functionality of an access node 554, albeit with a constrained coverage area. Each of these different embodiments of an access node 554 may be considered to provide roughly similar functions in the different technology generations.
In an embodiment, the access network 556 comprises a first access node 554 a, a second access node 554 b, and a third access node 554 c. It is understood that the access network 556 may include any number of access nodes 554. Further, each access node 554 could be coupled with a core network 558 that provides connectivity with various application servers 559 and/or a network 560. In an embodiment, at least some of the application servers 559 may be located close to the network edge (e.g., geographically close to the UE 552 and the end user) to deliver so-called “edge computing.” The network 560 may be one or more private networks, one or more public networks, or a combination thereof. The network 560 may comprise the public switched telephone network (PSTN). The network 560 may comprise the Internet. With this arrangement, a UE 552 within coverage of the access network 556 could engage in air-interface communication with an access node 554 and could thereby communicate via the access node 554 with various application servers and other entities.
The communication system 550 could operate in accordance with a particular radio access technology (RAT), with communications from an access node 554 to UEs 552 defining a downlink or forward link and communications from the UEs 552 to the access node 554 defining an uplink or reverse link. Over the years, the industry has developed various generations of RATs, in a continuous effort to increase available data rate and quality of service for end users. These generations have ranged from “1G,” which used simple analog frequency modulation to facilitate basic voice-call service, to “4G”—such as Long Term Evolution (LTE), which now facilitates mobile broadband service using technologies such as orthogonal frequency division multiplexing (OFDM) and multiple input multiple output (MIMO).
Recently, the industry has been exploring developments in “5G” and particularly “5G NR” (5G New Radio), which may use a scalable OFDM air interface, advanced channel coding, massive MIMO, beamforming, mobile mmWave (e.g., frequency bands above 24 GHz), and/or other features, to support higher data rates and countless applications, such as mission-critical services, enhanced mobile broadband, and massive Internet of Things (IoT). 5G is hoped to provide virtually unlimited bandwidth on demand, for example providing access on demand to as much as 20 gigabits per second (Gbps) downlink data throughput and as much as 10 Gbps uplink data throughput. Due to the increased bandwidth associated with 5G, it is expected that the new networks will serve, in addition to conventional cell phones, general internet service providers for laptops and desktop computers, competing with existing ISPs such as cable internet, and also will make possible new applications in internet of things (IoT) and machine to machine areas.
In accordance with the RAT, each access node 554 could provide service on one or more radio-frequency (RF) carriers, each of which could be frequency division duplex (FDD), with separate frequency channels for downlink and uplink communication, or time division duplex (TDD), with a single frequency channel multiplexed over time between downlink and uplink use. Each such frequency channel could be defined as a specific range of frequency (e.g., in radio-frequency (RF) spectrum) having a bandwidth and a center frequency and thus extending from a low-end frequency to a high-end frequency. Further, on the downlink and uplink channels, the coverage of each access node 554 could define an air interface configured in a specific manner to define physical resources for carrying information wirelessly between the access node 554 and UEs 552.
Without limitation, for instance, the air interface could be divided over time into frames, subframes, and symbol time segments, and over frequency into subcarriers that could be modulated to carry data. The example air interface could thus define an array of time-frequency resource elements each being at a respective symbol time segment and subcarrier, and the subcarrier of each resource element could be modulated to carry data. Further, in each subframe or other transmission time interval (TTI), the resource elements on the downlink and uplink could be grouped to define physical resource blocks (PRBs) that the access node could allocate as needed to carry data between the access node and served UEs 552.
In addition, certain resource elements on the example air interface could be reserved for special purposes. For instance, on the downlink, certain resource elements could be reserved to carry synchronization signals that UEs 552 could detect as an indication of the presence of coverage and to establish frame timing, other resource elements could be reserved to carry a reference signal that UEs 552 could measure in order to determine coverage strength, and still other resource elements could be reserved to carry other control signaling such as PRB-scheduling directives and acknowledgement messaging from the access node 554 to served UEs 552. And on the uplink, certain resource elements could be reserved to carry random access signaling from UEs 552 to the access node 554, and other resource elements could be reserved to carry other control signaling such as PRB-scheduling requests and acknowledgement signaling from UEs 552 to the access node 554
The access node 554, in some instances, may be split functionally into a radio unit (RU), a distributed unit (DU), and a central unit (CU) where each of the RU, DU, and CU have distinctive roles to play in the access network 556. The RU provides radio functions. The DU provides L1 and L2 real-time scheduling functions; and the CU provides higher L2 and L3 non-real time scheduling. This split supports flexibility in deploying the DU and CU. The CU may be hosted in a regional cloud data center. The DU may be co-located with the RU, or the DU may be hosted in an edge cloud data center.
Turning now to FIG. 14B, further details of the core network 558 are described. In an embodiment, the core network 558 is a 5G core network. 5G core network technology is based on a service based architecture paradigm. Rather than constructing the 5G core network as a series of special purpose communication nodes (e.g., an HSS node, a MME node, etc.) running on dedicated server computers, the 5G core network is provided as a set of services or network functions. These services or network functions can be executed on virtual servers in a cloud computing environment which supports dynamic scaling and avoidance of long-term capital expenditures (fees for use may substitute for capital expenditures). These network functions can include, for example, a user plane function (UPF) 579, an authentication server function (AUSF) 575, an access and mobility management function (AMF) 576, a session management function (SMF) 577, a network exposure function (NEF) 570, a network repository function (NRF) 571, a policy control function (PCF) 572, a unified data management (UDM) 573, a network slice selection function (NSSF) 574, and other network functions. The network functions may be referred to as virtual network functions (VNFs) in some contexts.
Network functions may be formed by a combination of small pieces of software called microservices. Some microservices can be re-used in composing different network functions, thereby leveraging the utility of such microservices. Network functions may offer services to other network functions by extending application programming interfaces (APIs) to those other network functions that call their services via the APIs. The 5G core network 558 may be segregated into a user plane 580 and a control plane 582, thereby promoting independent scalability, evolution, and flexible deployment.
The UPF 579 delivers packet processing and links the UE 552, via the access node 556, to a data network 590 (e.g., the network 560 illustrated in FIG. 6A). The AMF 576 handles registration and connection management of non-access stratum (NAS) signaling with the UE 552. Said in other words, the AMF 576 manages UE registration and mobility issues. The AMF 576 manages reachability of the UEs 552 as well as various security issues. The SMF 577 handles session management issues. Specifically, the SMF 577 creates, updates, and removes (destroys) protocol data unit (PDU) sessions and manages the session context within the UPF 579. The SMF 577 decouples other control plane functions from user plane functions by performing dynamic host configuration protocol (DHCP) functions and IP address management functions. The AUSF 575 facilitates security processes.
The NEF 570 securely exposes the services and capabilities provided by network functions. The NRF 571 supports service registration by network functions and discovery of network functions by other network functions. The PCF 572 supports policy control decisions and flow based charging control. The UDM 573 manages network user data and can be paired with a user data repository (UDR) that stores user data such as customer profile information, customer authentication number, and encryption keys for the information. An application function 592, which may be located outside of the core network 558, exposes the application layer for interacting with the core network 558. In an embodiment, the application function 592 may be execute on an application server 559 located geographically proximate to the UE 552 in an “edge computing” deployment mode. The core network 558 can provide a network slice to a subscriber, for example an enterprise customer, that is composed of a plurality of 5G network functions that are configured to provide customized communication service for that subscriber, for example to provide communication service in accordance with communication policies defined by the customer. The NSSF 574 can help the AMF 576 to select the network slice instance (NSI) for use with the UE 552.
FIG. 15 illustrates a computer system 380 suitable for implementing one or more embodiments disclosed herein, for example implementing one or more computers, servers or the like as disclosed or used herein, including without limitation any aspect of the computing system associated with control van 110 (e.g., computers 132 and 142); any aspect of the computing components and network associated with FIG. 5 (e.g., computer 222); any aspect of a unit level control system as shown in FIG. 3 (e.g., control module 150); etc. The computer system 380 includes a processor 382 (which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage 384, read only memory (ROM) 386, random access memory (RAM) 388, input/output (I/O) devices 390, and network connectivity devices 392. The processor 382 may be implemented as one or more CPU chips.
It is understood that by programming and/or loading executable instructions onto the computer system 380, at least one of the CPU 382, the RAM 388, and the ROM 386 are changed, transforming the computer system 380 in part into a particular machine or apparatus having the novel functionality taught by the present disclosure. It is fundamental to the electrical engineering and software engineering arts that functionality that can be implemented by loading executable software into a computer can be converted to a hardware implementation by well-known design rules. Decisions between implementing a concept in software versus hardware typically hinge on considerations of stability of the design and numbers of units to be produced rather than any issues involved in translating from the software domain to the hardware domain. Generally, a design that is still subject to frequent change may be preferred to be implemented in software, because re-spinning a hardware implementation is more expensive than re-spinning a software design. Generally, a design that is stable that will be produced in large volume may be preferred to be implemented in hardware, for example in an application specific integrated circuit (ASIC), because for large production runs the hardware implementation may be less expensive than the software implementation. Often a design may be developed and tested in a software form and later transformed, by well-known design rules, to an equivalent hardware implementation in an application specific integrated circuit that hardwires the instructions of the software. In the same manner as a machine controlled by a new ASIC is a particular machine or apparatus, likewise a computer that has been programmed and/or loaded with executable instructions may be viewed as a particular machine or apparatus.
Additionally, after the computer system 380 is turned on or booted, the CPU 382 may execute a computer program or application. For example, the CPU 382 may execute software or firmware stored in the ROM 386 or stored in the RAM 388. In some cases, on boot and/or when the application is initiated, the CPU 382 may copy the application or portions of the application from the secondary storage 384 to the RAM 388 or to memory space within the CPU 382 itself, and the CPU 382 may then execute instructions that the application is comprised of. In some cases, the CPU 382 may copy the application or portions of the application from memory accessed via the network connectivity devices 392 or via the I/O devices 390 to the RAM 388 or to memory space within the CPU 382, and the CPU 382 may then execute instructions that the application is comprised of. During execution, an application may load instructions into the CPU 382, for example load some of the instructions of the application into a cache of the CPU 382. In some contexts, an application that is executed may be said to configure the CPU 382 to do something, e.g., to configure the CPU 382 to perform the function or functions promoted by the subject application. When the CPU 382 is configured in this way by the application, the CPU 382 becomes a specific purpose computer or a specific purpose machine.
The secondary storage 384 is typically comprised of one or more disk drives or tape drives and is used for non-volatile storage of data and as an over-flow data storage device if RAM 388 is not large enough to hold all working data. Secondary storage 384 may be used to store programs which are loaded into RAM 388 when such programs are selected for execution. The ROM 386 is used to store instructions and perhaps data which are read during program execution. ROM 386 is a non-volatile memory device which typically has a small memory capacity relative to the larger memory capacity of secondary storage 384. The RAM 388 is used to store volatile data and perhaps to store instructions. Access to both ROM 386 and RAM 388 is typically faster than to secondary storage 384. The secondary storage 384, the RAM 388, and/or the ROM 386 may be referred to in some contexts as computer readable storage media and/or non-transitory computer readable media.
I/O devices 390 may include printers, video monitors, liquid crystal displays (LCDs), touch screen displays, keyboards, keypads, switches, dials, mice, track balls, voice recognizers, card readers, paper tape readers, or other well-known input devices.
The network connectivity devices 392 may take the form of modems, modem banks, Ethernet cards, universal serial bus (USB) interface cards, serial interfaces, token ring cards, fiber distributed data interface (FDDI) cards, wireless local area network (WLAN) cards, radio transceiver cards, and/or other well-known network devices. The network connectivity devices 392 may provide wired communication links and/or wireless communication links (e.g., a first network connectivity device 392 may provide a wired communication link and a second network connectivity device 392 may provide a wireless communication link). Wired communication links may be provided in accordance with Ethernet (IEEE 802.3), Internet protocol (IP), time division multiplex (TDM), data over cable service interface specification (DOCSIS), wavelength division multiplexing (WDM), and/or the like. In an embodiment, the radio transceiver cards may provide wireless communication links using protocols such as code division multiple access (CDMA), global system for mobile communications (GSM), long-term evolution (LTE), WiFi (IEEE 802.11), Bluetooth, Zigbee, narrowband Internet of things (NB IoT), near field communications (NFC), radio frequency identity (RFID). The radio transceiver cards may promote radio communications using 5G, 5G New Radio, or 5G LTE radio communication protocols. These network connectivity devices 392 may enable the processor 382 to communicate with the Internet or one or more intranets. With such a network connection, it is contemplated that the processor 382 might receive information from the network, or might output information to the network in the course of performing the above-described method steps. Such information, which is often represented as a sequence of instructions to be executed using processor 382, may be received from and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave.
Such information, which may include data or instructions to be executed using processor 382 for example, may be received from and outputted to the network, for example, in the form of a computer data baseband signal or signal embodied in a carrier wave. The baseband signal or signal embedded in the carrier wave, or other types of signals currently used or hereafter developed, may be generated according to several methods well-known to one skilled in the art. The baseband signal and/or signal embedded in the carrier wave may be referred to in some contexts as a transitory signal.
The processor 382 executes instructions, codes, computer programs, scripts which it accesses from hard disk, floppy disk, optical disk (these various disk based systems may all be considered secondary storage 384), flash drive, ROM 386, RAM 388, or the network connectivity devices 392. While only one processor 382 is shown, multiple processors may be present. Thus, while instructions may be discussed as executed by a processor, the instructions may be executed simultaneously, serially, or otherwise executed by one or multiple processors. Instructions, codes, computer programs, scripts, and/or data that may be accessed from the secondary storage 384, for example, hard drives, floppy disks, optical disks, and/or other device, the ROM 386, and/or the RAM 388 may be referred to in some contexts as non-transitory instructions and/or non-transitory information.
In an embodiment, the computer system 380 may comprise two or more computers in communication with each other that collaborate to perform a task. For example, but not by way of limitation, an application may be partitioned in such a way as to permit concurrent and/or parallel processing of the instructions of the application. Alternatively, the data processed by the application may be partitioned in such a way as to permit concurrent and/or parallel processing of different portions of a data set by the two or more computers. In an embodiment, virtualization software may be employed by the computer system 380 to provide the functionality of a number of servers that is not directly bound to the number of computers in the computer system 380. For example, virtualization software may provide twenty virtual servers on four physical computers. In an embodiment, the functionality disclosed above may be provided by executing the application and/or applications in a cloud computing environment. Cloud computing may comprise providing computing services via a network connection using dynamically scalable computing resources. Cloud computing may be supported, at least in part, by virtualization software. A cloud computing environment may be established by an enterprise and/or may be hired on an as-needed basis from a third party provider. Some cloud computing environments may comprise cloud computing resources owned and operated by the enterprise as well as cloud computing resources hired and/or leased from a third party provider.
In an embodiment, some or all of the functionality disclosed above may be provided as a computer program product. The computer program product may comprise one or more computer readable storage medium having computer usable program code embodied therein to implement the functionality disclosed above. The computer program product may comprise data structures, executable instructions, and other computer usable program code. The computer program product may be embodied in removable computer storage media and/or non-removable computer storage media. The removable computer readable storage medium may comprise, without limitation, a paper tape, a magnetic tape, magnetic disk, an optical disk, a solid state memory chip, for example analog magnetic tape, compact disk read only memory (CD-ROM) disks, floppy disks, jump drives, digital cards, multimedia cards, and others. The computer program product may be suitable for loading, by the computer system 380, at least portions of the contents of the computer program product to the secondary storage 384, to the ROM 386, to the RAM 388, and/or to other non-volatile memory and volatile memory of the computer system 380. The processor 382 may process the executable instructions and/or data structures in part by directly accessing the computer program product, for example by reading from a CD-ROM disk inserted into a disk drive peripheral of the computer system 380. Alternatively, the processor 382 may process the executable instructions and/or data structures by remotely accessing the computer program product, for example by downloading the executable instructions and/or data structures from a remote server through the network connectivity devices 392. The computer program product may comprise instructions that promote the loading and/or copying of data, data structures, files, and/or executable instructions to the secondary storage 384, to the ROM 386, to the RAM 388, and/or to other non-volatile memory and volatile memory of the computer system 380.
In some contexts, the secondary storage 384, the ROM 386, and the RAM 388 may be referred to as a non-transitory computer readable medium or a computer readable storage media. A dynamic RAM embodiment of the RAM 388, likewise, may be referred to as a non-transitory computer readable medium in that while the dynamic RAM receives electrical power and is operated in accordance with its design, for example during a period of time during which the computer system 380 is turned on and operational, the dynamic RAM stores information that is written to it. Similarly, the processor 382 may comprise an internal RAM, an internal ROM, a cache memory, and/or other internal non-transitory storage blocks, sections, or components that may be referred to in some contexts as non-transitory computer readable media or computer readable storage media.
The following are included as specific and non-limiting enumerated embodiments of the various concepts disclosed herein.
A first embodiment, which is a method of controlling a pumping sequence of a fracturing fleet at a wellsite while performing a fracturing job on a treatment wellbore penetrating a subterranean formation, comprising: receiving, by a modeling application executing on a computer, one or more user inputs related to the fracturing job, one or more equipment inputs comprising sensor data from one or more frac units of the fracturing fleet, one or more wellbore inputs comprising sensor data from the wellbore, or combinations thereof; predicting, by the modeling application, a fracture propagation within the subterranean formation using all or a portion of the inputs; producing, by the modeling application, a pumping sequence or an updated pumping sequence to obtain the fracture propagation, wherein the pumping sequence comprises two or more sub-stages, and wherein the modeling application employs a first pumping routine model to provide a first sub-stage of the pumping sequence and employ a second pumping routine model to provide a second sub-stage of the pumping sequence, wherein the first and second pumping routine models are different; and controlling, by a managing application, the fracturing fleet in accordance with the pumping sequence to place a fracturing fluid in the treatment well.
A second embodiment, which is the method of first embodiment, wherein the pumping sequence corresponds to a pumping time and wherein the first sub-stage is completed within a first half, alternatively a first third, alternatively a first quarter, or alternatively a first one tenth of the pumping time.
A third embodiment, which is the method of the first or second embodiment, wherein the modeling application employs a third pumping routine model to provide a last sub-stage of the pumping sequence and wherein the first, second, and third pumping routine models are different.
A fourth embodiment, which is the method of the third embodiment, wherein the last sub-stage is completed within a last half, alternatively a last third, alternatively a last quarter, or alternatively a last one tenth of the pumping time.
A fifth embodiment, which is the method of the third or fourth embodiment, wherein the first sub-stage corresponds to ramping up from zero a flow rate of the pumping sequence and the last sub-stage corresponds to a ramping down to zero of the flow rate of the pumping sequence.
A sixth embodiment, which is the method of any of the first to fifth embodiments, wherein the one or more wellbore inputs comprise sensor data gathered from sensors located in the treatment well during the fracturing job.
A seventh embodiment, which is the method of any of the first to sixth embodiments, wherein the one or more wellbore inputs comprise sensor data gathered from sensors located in one or more monitoring wellbores spaced a distance apart from the treatment wellbore.
An eighth embodiment, which is the method of seventh embodiment, wherein the treatment wellbore and one or more monitoring wellbores are lateral wellbores sharing a common vertical portion.
A ninth embodiment, which is the method of seventh embodiment, wherein the treatment wellbore and the one or more monitoring wellbores are distinct from one another and do not share any common borehole.
A tenth embodiment, which is the method of any of the first to ninth embodiments, wherein the fracturing job comprises at least two treatment wellbores and the predicting by the modeling application predicts the fracture propagation within an area of the subterranean formation located adjacent or between the two treatment wells.
An eleventh embodiment, which is the method of the tenth embodiment, wherein the fracturing fluid is placed simultaneously or sequentially into the at least two treatment wellbores.
A twelfth embodiment, which is a method of controlling a pumping sequence of a fracturing fleet at a wellsite while performing a fracturing job on a treatment wellbore penetrating a subterranean formation, comprising: receiving during the fracturing job, by a modeling application executing on a computer, one or more wellbore inputs comprising sensor data from the treatment wellbore and sensor data from one or more monitoring wellbores spaced a distance apart from the treatment wellbore; predicting, by the modeling application, a fracture propagation within the subterranean formation using all or a portion of the inputs; producing during the fracturing job, by the modeling application, an updated pumping sequence to obtain the fracture propagation; and controlling, by a managing application, the fracturing fleet in accordance with the updated pumping sequence to place a fracturing fluid in the treatment well.
A thirteenth embodiment, which is the method of the twelfth embodiment, wherein the updated pumping sequence is the same or different than an initial pumping sequence used at the beginning of the fracturing job.
A fourteenth embodiment, which is the method of the twelfth or thirteenth embodiment, wherein the pumping sequence comprises two or more sub-stages, and wherein the modeling application employs a first pumping routine model to provide a first sub-stage of the pumping sequence and employ a second pumping routine model to provide a second sub-stage of the pumping sequence, wherein the first and second pumping routine models are different.
A fifteenth embodiment, which is the method of any of the twelfth to fourteenth embodiments, wherein the pumping sequence corresponds to a pumping time and wherein the first sub-stage is completed within a first half, alternatively a first third, alternatively a first quarter, or alternatively a first one tenth of the pumping time.
A sixteenth embodiment, which is the method of the fourteenth or fifteenth embodiment, wherein the modeling application employs a third pumping routine model to provide a last sub-stage of the pumping sequence and wherein the first, second, and third pumping routine models are different.
A seventeenth embodiment, which is the method of sixteenth embodiment, wherein the last sub-stage is completed within a last half, alternatively a last third, alternatively a last quarter, or alternatively a last one tenth of the pumping time.
An eighteenth embodiment, which is the method of the sixteenth or seventeenth embodiment, wherein the first sub-stage corresponds to ramping up from zero a flow rate of the pumping sequence and the last sub-stage corresponds to a ramping down to zero of the flow rate of the pumping sequence.
A nineteenth embodiment, which is the method of any of the twelfth to eighteenth embodiments, wherein the treatment wellbore and one or more monitoring wellbores are lateral wellbores sharing a common vertical portion.
A twentieth embodiment, which is the method of any of the twelfth to eighteenth embodiments, wherein the treatment wellbore and the one or more monitoring wellbores are distinct from one another and do not share any common borehole.
A twenty-first embodiment, which is the method of any of the twelfth to twentieth embodiments, wherein the fracturing job comprises at least two treatment wellbores and the predicting by the modeling application predicts the fracture propagation within an area of the subterranean formation located adjacent or between the two treatment wells.
A twenty-second embodiment, which is the method of the twenty-first embodiment, wherein the fracturing fluid is placed simultaneously or sequentially into the at least two treatment wellbores.
While several embodiments have been provided in the present disclosure, it should be understood that the disclosed systems and methods may be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted or not implemented.
Also, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component, whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the spirit and scope disclosed herein.

Claims

What is claimed is:

1. A method of controlling a pumping sequence of a fracturing fleet at a wellsite while performing a fracturing job on a treatment wellbore penetrating a subterranean formation, comprising:

receiving, by a modeling application executing on a computer, one or more user inputs related to the fracturing job, one or more equipment inputs comprising sensor data from one or more frac units of the fracturing fleet, one or more wellbore inputs comprising sensor data from the wellbore, or combinations thereof;

predicting, by the modeling application, a fracture propagation within the subterranean formation using all or a portion of the inputs;

producing, by the modeling application, a pumping sequence to obtain the fracture propagation, wherein the pumping sequence comprises two or more sub-stages, and wherein the modeling application employs a first pumping routine model to provide a first sub-stage of the pumping sequence and employs a second pumping routine model to provide a second sub-stage of the pumping sequence, wherein the first and second pumping routine models are different; and

controlling, by a managing application, the fracturing fleet in accordance with the pumping sequence to place a fracturing fluid in the treatment well.

2. The method of claim 1, wherein the pumping sequence corresponds to a pumping time and wherein the first sub-stage is completed within a first half, alternatively a first third, alternatively a first quarter, or alternatively a first one tenth of the pumping time.

3. The method of claim 2, wherein the modeling application employs a third pumping routine model to provide a last sub-stage of the pumping sequence and wherein the first, second, and third pumping routine models are different.

4. The method of claim 3, wherein the last sub-stage is completed within a last half, alternatively a last third, alternatively a last quarter, or alternatively a last one tenth of the pumping time.

5. The method of claim 4, wherein the first sub-stage corresponds to ramping up from zero a flow rate of the pumping sequence and the last sub-stage corresponds to a ramping down to zero of the flow rate of the pumping sequence.

6. The method of claim 5, wherein the one or more wellbore inputs comprise sensor data gathered from sensors located in the treatment well during the fracturing job.

7. The method of claim 6, wherein the one or more wellbore inputs comprise sensor data gathered from sensors located in one or more monitoring wellbores spaced a distance apart from the treatment wellbore.

8. The method of claim 7, wherein the treatment wellbore and one or more monitoring wellbores are lateral wellbores sharing a common vertical portion.

9. The method of claim 7, wherein the treatment wellbore and the one or more monitoring wellbores are distinct from one another and do not share any common borehole.

10. The method of claim 1, wherein the fracturing job comprises at least two treatment wellbores and the predicting by the modeling application predicts the fracture propagation within an area of the subterranean formation located adjacent or between the two treatment wells.

11. A method of controlling a pumping sequence of a fracturing fleet at a wellsite while performing a fracturing job on a treatment wellbore penetrating a subterranean formation, comprising:

receiving during the fracturing job, by a modeling application executing on a computer, one or more wellbore inputs comprising sensor data from the treatment wellbore and sensor data from one or more monitoring wellbores spaced a distance apart from the treatment wellbore;

producing during the fracturing job, by the modeling application, an updated pumping sequence to obtain the fracture propagation; and

controlling, by a managing application, the fracturing fleet in accordance with the updated pumping sequence to place a fracturing fluid in the treatment well.

12. The method of claim 11, wherein the updated pumping sequence is the same or different than an initial pumping sequence used at the beginning of the fracturing job.

13. The method of claim 12, wherein the updated pumping sequence comprises two or more sub-stages, and wherein the modeling application employs a first pumping routine model to provide a first sub-stage of the pumping sequence and employ a second pumping routine model to provide a second sub-stage of the pumping sequence, wherein the first and second pumping routine models are different.

14. The method of claim 13, wherein the updated pumping sequence corresponds to a pumping time and wherein the first sub-stage is completed within a first half, alternatively a first third, alternatively a first quarter, or alternatively a first one tenth of the pumping time.

15. The method of claim 14, wherein the modeling application employs a third pumping routine model to provide a last sub-stage of the updated pumping sequence and wherein the first, second, and third pumping routine models are different.

16. The method of claim 15, wherein the last sub-stage is completed within a last half, alternatively a last third, alternatively a last quarter, or alternatively a last one tenth of the pumping time.

17. The method of claim 16, wherein the first sub-stage corresponds to ramping up from zero a flow rate of the updated pumping sequence and the last sub-stage corresponds to a ramping down to zero of the flow rate of the updated pumping sequence.

18. The method of claim 11, wherein the treatment wellbore and one or more monitoring wellbores are lateral wellbores sharing a common vertical portion.

19. The method of claim 11, wherein the treatment wellbore and the one or more monitoring wellbores are distinct from one another and do not share any common borehole.

20. The method of claim 11, wherein the fracturing job comprises at least two treatment wellbores and the predicting by the modeling application predicts the fracture propagation within an area of the subterranean formation located adjacent or between the two treatment wells.