Producing Hydrocarbons from a Subsurface Reservoir

Description

CROSS-REFERENCE TO RELATED PATENT APPLICATION

This application claims the benefit of priority to U.S. Patent Application No. 63/637,571, filed on Apr. 23, 2024, the contents of which are incorporated by reference herein.

TECHNICAL FIELD

This specification generally relates to producing hydrocarbons from a subsurface reservoir, particularly using injection wells as part of the production process.

BACKGROUND

Primary recovery methods typically only extract about 30% of oil initially present in a reservoir. In some situations, water injection or water flooding is a secondary hydrocarbon recovery technique employed before enhanced oil recovery technologies are deployed. In water injection, water is injected into a subsurface formation under high pressure and temperature conditions to extract more oil after the primary recovery phase. The injected water can maintain pressure in the reservoir and/or drive oil towards production wells. Sources of water for water injection include produced water, seawater, and aquifer water from water-bearing formations outside the oil reservoir.

SUMMARY

This specification describes an approach to producing hydrocarbons from a subsurface reservoir using injection wells as part of the production process. This approach can improve the efficiency of water injection operations for oilfields that are being pressurized at multiple locations. An injection control engine includes a reservoir model and an allocation module. Initial injection targets are set based on simulations run on the reservoir model that set injection volumes per injection location to sufficiently pressurize the reservoir to achieve desired production levels. The targets represent an injection schedule with daily rates for the upcoming scheduling horizon (e.g. 1 month). The allocation module is then used to allocate each injection volume to an injection plant. The model also performs other tasks such as varying the initial injection targets within pre-set limits. This enables reductions in the overall energy consumption by reducing the number of operating pumps and/or allocating injection to more efficient pumps. The adjusted injection targets are validated against reservoir simulations and are then used as final targets for the reservoir.

The approach disclosed in this specification can provide one or more of the following advantages. This approach can be used to schedule and allocate water injection to improve the efficiency of water injection operations for oilfields that are being pressurized at multiple locations. In particular, this approach can reduce energy consumption in surface equipment associated with water injection, which is an element in approaches to decarbonize water injection facilities. In addition, significant benefits can be attained through providing a schedule, in which injection is potentially ramped up for part of the month then reduced for the remainder of the month. This approach also imposes user specified constraints for maximum days of no injection or variations from initial targets which increase the usability of this approach for field applications.

This approach can also facilitate scheduling maintenance windows to service the injection pumps by efficiently allocating the production to other injection plants. The schedule provided also reduces fluctuations in the injection and pumping rates. This provides better controllability particularly since some wells are at remote locations and adjusting their injection rate frequently is difficult.

The details of one or more embodiments of these systems and methods are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of these systems and methods will be apparent from the description and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a schematic view illustrating hydrocarbon exploration and production activities is a subsurface formation.

FIG. 2 illustrates an oilfield with multiple injection wells and multiple production wells.

FIG. 3 is a schematic illustrating an example system used to implement processes for controlling water injection.

FIG. 4 is a flow chart illustrating a method of producing hydrocarbons from a subsurface reservoir using injection wells.

FIG. 5 illustrates an oilfield to which a prototype system was applied.

FIG. 6 illustrates hydrocarbon production operations that include both one or more field operations and one or more computational operations, which exchange information and control exploration for the production of hydrocarbons.

FIG. 7 is a block diagram illustrating an example computer system used to provide computational functionalities associated with described algorithms, methods, functions, processes, flows, and procedures according to some implementations of the present disclosure.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

This specification describes an approach to producing hydrocarbons from a subsurface reservoir using injection wells as part of the production process. This approach can improve the efficiency of water injection operations for oilfields that are being pressurized at multiple locations. An injection control engine includes a reservoir model and an allocation module. Initial injection targets are set based on simulations run on the reservoir model that set injection volumes per injection location to sufficiently pressurize the reservoir to achieve desired production levels. The targets represent an injection schedule with daily rates for the upcoming scheduling horizon (e.g. 1 month). The allocation module is then used to allocate each injection volume to an injection plant. The model also performs other tasks such as varying the initial injection targets within pre-set limits. This enables reductions in the overall energy consumption by reducing the number of operating pumps and/or allocating injection to more efficient pumps. The adjusted injection targets are validated against reservoir simulations and are then used as final targets for the reservoir.

FIG. 1 is a schematic view illustrating hydrocarbon exploration and production activities in a subsurface formation 100. The production activities include injecting water into the subsurface formation to maintain pressure in the subsurface formation.

The subsurface formation 100 includes a layer of impermeable cap rocks 102 at the surface. Facies underlying the impermeable cap rocks 102 include layers 104, 106, and 108. A fault line 110 extends across the layer 104 and the layer 106.

Oil and gas tend to rise through permeable reservoir rock until further upward migration is blocked, for example, by the layer of impermeable cap rock 102. Seismic surveys attempt to identify locations where interaction between layers of the subsurface formation 100 are likely to trap oil and gas by limiting this upward migration. For example, FIG. 1 shows an anticline trap 107, where the layer of impermeable cap rock 102 has an upward convex configuration, and a fault trap 109, where the fault line 110 might allow oil and gas to flow in with clay material between the walls traps the petroleum. Other traps include salt domes and stratigraphic traps.

A systemic survey is illustrated with a seismic source 112 (for example, a seismic vibrator or an explosion) generating seismic waves that propagate in the earth. Although illustrated as a single component in FIG. 1, the source or sources 112 are typically a line or an array of sources 112. The generated seismic waves include seismic body waves 114 that travel into the ground and seismic surface waves 115 travel along the ground surface and diminish as they get further from the surface. As the seismic waves 114 contact interfaces between geologic bodies or layers that have different velocities, the interface reflects some of the energy of the seismic wave and refracts part of the energy of the seismic wave. Such interfaces are sometimes referred to as horizons.

The seismic body waves 114 are received by a sensor or sensors 116. Although illustrated as a single component in FIG. 1, the sensor or sensors 116 are typically a line or an array of sensors 116 that generate an output signal in response to received seismic waves including waves reflected by the horizons in the subsurface formation 100. The sensors 116 can be geophone-receivers that produce electrical output signals transmitted as input data, for example, to a computer 118 on a seismic control truck 120. Based on the input data, the computer 118 may generate a seismic data output such as, for example, a seismic two-way response time plot.

The seismic surface waves 115 travel more slowly than seismic body waves 114. Analysis of the time it takes seismic surface waves 115 to travel from source to sensor can provide information about near surface features.

In some embodiments, a wellbore 130 that has been drilled in the subsurface formation 100 is logged in a well logging operation 128. The wellbore 130 extends downhole from a wellhead 132. The wellbore 130 is a vertical wellbore but well logging can also be performed in other wellbores, for example, slanted or horizontal wellbores. In the well logging operation 128, the wellbore 130 penetrates through three layers 102, 104, and 106 of a subsurface formation 100. A control truck 121 lowers a logging tool 134 down the wellbore 130 on a wireline 136.

The logging tool 134 is string of one or more instruments with sensors operable to measure geophysical properties of the subsurface formation 100. For example, logging tools can include resistivity logs, borehole image logs, porosity logs, density logs, or sonic logs.

As the logging tool 134 travels downhole, measurements of formations properties are recorded to generate a well log. In the illustrated operation, the data are recorded at the control truck 121 in real-time. Real-time data are recorded directly against measured cable depth. In some well-logging operations, the data is recorded at the logging tool 134 and downloaded later. In this approach, the downhole data and depth data are both recorded against time. The two data sets are then merged using the common time base to create an instrument response versus depth log.

In the well logging operation 128, the well logging is performed on a wellbore 110 that has already been drilled. In some operations, well logging is performed in the form of logging while drilling techniques. In these techniques, the sensors are integrated into the drill string and the measurements are made in real-time, during drilling rather than using sensors lowered into a well after drilling.

A control center 122 can be operatively coupled to the seismic control truck 120 and other data acquisition and wellsite systems. The control center 122 may have computer facilities for receiving, storing, processing, and analyzing data from the seismic control truck 120 and other data acquisition and wellsite systems that provide additional information about the subsurface formation. For example, the control center 122 can receive data from a computer 119 associated with a well logging unit 121.

The computer systems 124 can be located in a different location than the control center 122. Some computer systems are provided with functionality for manipulating and analyzing the data, such as performing seismic interpretation or borehole resistivity image log interpretation to identify geological surfaces in the subsurface formation or performing simulation, planning, and optimization of production operations of the wellsite systems.

The computer systems 124 can be configured to analyze, model, control, optimize, or perform management tasks of field operations associated with development and production of resources such as oil and gas from the subsurface formation 100. For example, an injection well 123 and a production well 125 extend into layer 104 of the subsurface formation 100. A water injection plant 129 connected to the injection well 123 by conduits is used to inject water into the subsurface formation 100. Although illustrated as single components in FIG. 1, typically fields will include multiple injection wells 123, multiple production wells 125, and multiple water injection plants 129.

Based on data gathered by the exploratory field operations, the computer systems 124 can generate models such as a reservoir model for portions of the subsurface formation 100. These models can simulate the effects of production field operations (e.g., injecting water or carbon dioxide through the injection well 123 to increase the production of hydrocarbons through the production well 125). The simulations can be used to plan and, in some instances, control field operations (e.g., the operation of pumps associated with the injection well 123 and the production well 125). For example, in the illustrated oilfield, the computer systems 124 are configured to implement the previously described injection control engine to generate an injection schedule with daily rates for the upcoming scheduling horizon (e.g. 1 month). After validation, the injection schedule is used to control the multiple injection wells 123, the multiple production wells 125, and the multiple water injection plants 129 and distribute injection volumes between them.

In some embodiments, results generated by the computer systems 124 may be displayed for user viewing using local or remote monitors or other display units. One approach to analyzing seismic data is to associate the data with portions of a seismic cube representing the subsurface formation 100. The seismic cube can also display results of the analysis of the seismic data associated with the seismic survey.

FIG. 2 illustrates an oilfield with a water injection network with seven injection wells 123, four production wells 125, and three water injection plants 129a, 129b, 129c. Water entering the water injection network typically undergoes preliminary treatment at one or more treatment facilities (not shown). The specific treatment(s) required depend on the source of the water being used for injection. For example, produced water, seawater, and aquifer water will require different preliminary treatment before injection.

Each water injection plant 129a, 129b, 129c is equipped with a set of motor or gas turbine driven pumps. The pumps have varying minimum and maximum capacities and efficiencies. The water injection plant 129a receives water from the preliminary treatment facilities. The water injection plant 129a pressurizes the water for transfer to the other water injection plants 129b, 129c and also injects the water into the subsurface formation through three injection wells 123 located along an eastern flank of the reservoir from which oil is being produced. The term “flank” can be used to refer to a collection of injection wells strategically positioned around the edges of the main reservoir to maintain pressure and enhance oil recovery. The water injection plant 129b receives water from the water injection plant 129a and injects the water into the subsurface formation through two injection wells 123 located along a northern flank of the reservoir. The water injection plant 129c receives water from the water injection plant 129a and injects the water into the subsurface formation through two injection wells 123 located along a western flank of the reservoir.

Isobars on FIG. 2 illustrate pressure gradients in the reservoir. Injection of water into the reservoir through the injection wells 123 increases pressure in the reservoir around the production wells 125.

FIG. 3 is a schematic illustrating an example system 300 used to implement processes for controlling water injection into a reservoir. The system 300 includes an injection control engine 310 with a reservoir model 312 and an allocation module 314.

The reservoir model 312 is used to simulate the behavior of the oil reservoir over time. It starts with a detailed characterization of the reservoir, including geological properties, fluid properties and well configurations and their placement. The model simulates how fluids (oil, water, gas) move within the reservoir. The reservoir model 312 can be used to set water injection targets to maintain pressure given recovery targets. The reservoir model 312 can be used to set how much water needs to be injected to maintain adequate pressure which facilitates the movement of oil towards production wells. The model can be used to forecast oil production over time. This allows adjusting injection targets to meet production targets. Initial injection targets are set based on simulations run on the reservoir model 312 that set injection volumes per injection location to sufficiently pressurize the reservoir to achieve desired production levels. The targets represent an injection schedule with daily rates for the upcoming scheduling horizon (e.g. 1 month).

The allocation module 314 is then used to allocate each injection volume to an injection plant 129. The model also performs other tasks such as varying the initial injection targets within pre-set limits. This enables reductions in the overall energy consumption by reducing the number of operating pumps and/or allocating injection to more efficient pumps. The adjusted injection targets are validated against reservoir simulations and are then used as final targets for the reservoir.

In the prototype system 300, the allocation module 314 used Mixed Integer Linear (or Nonlinear) Programming (MILP/MINLP) to control pumps associated with the injection wells 123 and the water injection plants 129 to minimize the overall energy consumption of the network. The allocation module is configured to allow users to implement constraints reflecting the configuration of the injection wells 123 and the water injection plants 129 in the water injection network. This approach results in a schedule with limited changes in the pumping and injection rates through the month. The usability of the models and the applicability of the results is increased by avoiding frequent adjustments of the injection flowrate for each well or flank. It is also possible to shutdown injection for a given maximum number of days. It is also mandatory to meet month end total targets within a given compliance limit, which can be separately specified for each flank.

For example, the prototype system 300 defined nine constraints. Constraints 1 and 2 control the total supply of each water injection plant falls between the aggregated minimum and maximum limits of operating pumps for that specific plant. Constraints 3 and 4 limited the total injection to each flank between the minimum and maximum allowed rates. Constraint 5 set the injection to a given flank to 0 when there is user-defined shutdown event at a given period t. Constraint 6 balances the supply from each water injection plant with the rate from its pumps. Constraint 7 limits the number of shutdown days to those defined by the user. Constraint 8 requires the model meet the month end injection target within a user-defined minimum compliance. Constraint 9 requires the water supplied by a given plant is equal the water rate of the connected receiving plants.

The allocation module includes an optimization model configured with an objective function which controls water injection at oil and gas fields to minimize the overall power consumption of the water injection operation while complying with operational constraints. A prototype of the system implemented with the objective function represented by Eq. 1.

Min ⁢ ∑ t ∑ p z t , p pumps × Cost p WIP - ∑ t ∑ f y t , f inject + ∑ t ∑ f x t , f DIR + ∑ t ∑ p x t , p DPR Eq . 1

in which sets t, p and f refer to time periods, WIPs and flanks, respectively. Variables x, y and z refer to continuous, binary and integer variables, respectively. The first term in Eq. (1) calculates the total cost of used pumps at each WIP, where z^pumps is the number of running pumps at the WIP and Cost^WIP is the cost of using a pump, which is assumed to be the same for all pumps at the same WIP to reduce the problem size. The second term penalizes the model for setting zero injection rate at a given day to avoid unnecessary shut down of injection, where y^inject is a binary variable which is activated when there is zero injection. The third and fourth terms minimize fluctuations in injection and pumping rates, respectively, where x^DIR is a variable that is constrained to equal or exceed daily variations in injection rates and x^DPR is defined to equal or exceed daily variations in pumping rates as will be illustrated in the constraints.

Mathematically speaking, the objective function minimizes the summation of four terms. The first term calculates the total cost of used pumps at each water injection plant. The second term penalizes the model for setting zero injection rate at a given day to avoid unnecessary shut down of injection. The third and fourth terms minimize fluctuations in injection and pumping rates, respectively. The optimization problem is then solved to the optimum values of all the variables. The pump rates are then assigned to each pump's control logic through a distributed control system. The injection rates are then applied by throttling the control valves at each injection well. Each water injection plant is connected to a set of flanks. The wells can be modeled explicitly or their assigned production targets can be grouped into their respective flanks.

FIG. 4 is a flow chart illustrating a method 400 of producing hydrocarbons from a subsurface reservoir using injection wells. The method 400 can include receiving reservoir parameters, initial pressures, and target pressures (step 410). In some implementations, the method uses a previously implemented reservoir model which already incorporates reservoir parameters, initial pressures, and target pressures.

The reservoir model incorporating reservoir parameters and initial pressures is run to identify initial injection targets to achieve target pressures (step 412). Based on initial injection targets, an injection schedule that minimizes the overall power consumption of pumps associated with the plurality of injection wells is developed using an allocation module incorporating operational constraints of the pumps (step 414). The allocation module can be implemented with mixed integer programming.

Typically, each well of the plurality of injection wells is associated with a water injection plant and the allocation module is configured to incorporate constraints reflecting the configuration of the plurality of injection wells and the water injection plants. In some cases, the constraints control a total supply of each water injection plant to fall between the aggregated minimum and maximum limits of operating pumps for that specific water injection plant. In some cases, the constraints limit total injection to each flank of the reservoir to between minimum and maximum allowed rates. In some cases, the constraints balance supply from each water injection plant with the rate from its pumps. In some cases, the constraints require the water supplied by a water injection plant is equal the water rate of connected receiving water injection plant.

The injection schedule can include daily injection rates for the plurality of wells for an upcoming scheduling horizon (e.g., a month). In some applications, the injection schedule includes a daily injection rate for each well of the plurality of injection wells. In some applications, the injection schedule includes a daily injection rate for groups of wells of the plurality of injection wells.

After the injection schedule is developed and verified, the pumps are controlled to implement the injection schedule (step 416). Hydrocarbons can be produced through production wells associated with the plurality of injection wells (step 418) contemporaneously with injection of water through the injection wells.

FIG. 5 illustrates an oilfield to which a prototype system was applied to generate the daily scheduling of a water injection network 500 in the Ghawar oilfield. This network comprises a multitude of nodes, where seawater first undergoes a series of preliminary treatments. The treated seawater is then pumped through an extensive network of plants, which either further pressurize the water for transfer to other plants or directly inject it underground through remote wells, which are located along piping flanks.

The starting point of the water injection network 500 is the Qurayyah Seawater Plant 510, located on the Arabian Gulf. The facility is capable of processing some 14 million barrels of seawater daily. The treated water leaves Qurayyah south bound to the ‘Uthmaniyah Water Supply Plant (UWSP) 512 and north to the A in Dar Water Injection Plant (ADWIP) 514. From UWSP, water is pumped to a network of water injection plants (WIPs) 516. Each WIP 516 directs water to a number of remote injection wells located along flanks.

Four ‘Uthmaniyah WIPs 516 sustain pressure in the Ghawar's North section, while the Hawiyah WIP 516 (HAWIP) injects to wells that are connected directly to it and additional ones further south at HRDH. In the North, water is pumped to the Sulfate Removal Facility 518 (SRF) and ADWIP. At ADWIP water is directed to remote injection wells and is also sent to Khurais Central Processing Facility 520 (KhCPF), which is responsible for injecting water at the Khurais field.

Each WIP 516 is equipped with a set of motor or gas turbine driven pumps with varying minimum and maximum capacities as presented in Table 1. Each WIP 516 is connected to a set of flanks. In the test application, wells were not modelled explicitly. Rather their assigned production targets were grouped into their respective flanks. Two flanks are shared between UWIP-1 and UWIP-3. One Flank is shared between UWIP-4 and HAWIP and one flank is shared between UWIP-5 and HA WIP. The constraints of this application provided a model which minimizes the overall energy consumption of the network while providing a schedule with minimal disruptions both in the pumping and injection rates. This implementation allowed for injection to be shutdown for a given maximum number of days. If not shutdown, each flank is constrained to operate between given minimum and maximum rates while meeting month end total targets within a given compliance limit, which can be separately specified for each flank. This implementation assumes that if pumps are used, a fixed base cost is incurred. The fixed base cost varies per pump, but is not a function of the flowrate.

Running the prototype system provided a schedule with daily injection rates at each flank, efficient pump operational parameters, and supply strategies for swing flanks. The model accommodates user-defined constraints, ensuring month-end compliance targets are met. By introducing penalty terms in the objective function, the model minimizes daily operational variations, producing a practical and operationally acceptable schedule.

Employing techniques to enhance computational efficiency, the model reduces CPU times from hours for reservoir model-based approaches to an average of 340 seconds. The schedule provided by running the prototype system reduced energy consumption for the water injection network by up to 7% compared to the current schedule.

FIG. 6 illustrates hydrocarbon production operations 600 that include both one or more field operations 610 and one or more computational operations 612, which exchange information and control exploration for the production of hydrocarbons. In some implementations, outputs of techniques of the present disclosure can be performed before, during, or in combination with the hydrocarbon production operations 600, specifically, for example, either as field operations 610 or computational operations 612, or both.

Examples of field operations 610 include forming/drilling a wellbore, hydraulic fracturing, producing through the wellbore, injecting fluids (such as water) through the wellbore, to name a few. In some implementations, methods of the present disclosure can trigger or control the field operations 610. For example, the methods of the present disclosure can generate data from hardware/software including sensors and physical data gathering equipment (e.g., seismic sensors, well logging tools, flow meters, and temperature and pressure sensors). The methods of the present disclosure can include transmitting the data from the hardware/software to the field operations 610 and responsively triggering the field operations 610 including, for example, generating plans and signals that provide feedback to and control physical components of the field operations 610. Alternatively or in addition, the field operations 610 can trigger the methods of the present disclosure. For example, implementing physical components (including, for example, hardware, such as sensors) deployed in the field operations 610 can generate plans and signals that can be provided as input or feedback (or both) to the methods of the present disclosure.

Examples of computational operations 612 include one or more computer systems 620 that include one or more processors and computer-readable media (e.g., non-transitory computer-readable media) operatively coupled to the one or more processors to execute computer operations to perform the methods of the present disclosure. The computational operations 612 can be implemented using one or more databases 618, which store data received from the field operations 610 and/or generated internally within the computational operations 612 (e.g., by implementing the methods of the present disclosure) or both. For example, the one or more computer systems 620 process inputs from the field operations 610 to assess conditions in the physical world, the outputs of which are stored in the databases 618. For example, seismic sensors of the field operations 610 can be used to perform a seismic survey to map subsurface features, such as facies and faults. In performing a seismic survey, seismic sources (e.g., seismic vibrators or explosions) generate seismic waves that propagate in the earth and seismic receivers (e.g., geophones) measure reflections generated as the seismic waves interact with boundaries between layers of a subsurface formation. The source and received signals are provided to the computational operations 612 where they are stored in the databases 618 and analyzed by the one or more computer systems 620.

In some implementations, one or more outputs 622 generated by the one or more computer systems 620 can be provided as feedback/input to the field operations 610 (either as direct input or stored in the databases 618). The field operations 610 can use the feedback/input to control physical components used to perform the field operations 610 in the real world.

For example, the computational operations 612 can process the seismic data to generate three-dimensional (3D) maps of the subsurface formation. The computational operations 612 can use these 3D maps to provide plans for locating and drilling exploratory wells. In some operations, the exploratory wells are drilled using logging-while-drilling (LWD) techniques which incorporate logging tools into the drill string. LWD techniques can enable the computational operations 612 to process new information about the formation and control the drilling to adjust to the observed conditions in real-time.

The one or more computer systems 620 can update the 3D maps of the subsurface formation as information from one exploration well is received and the computational operations 612 can adjust the location of the next exploration well based on the updated 3D maps. Similarly, the data received from production operations can be used by the computational operations 612 to control components of the production operations. For example, production well and pipeline data can be analyzed to predict slugging in pipelines leading to a refinery and the computational operations 612 can control machine operated valves upstream of the refinery to reduce the likelihood of plant disruptions that run the risk of taking the plant offline.

In some implementations of the computational operations 612, customized user interfaces can present intermediate or final results of the above-described processes to a user. Information can be presented in one or more textual, tabular, or graphical formats, such as through a dashboard. The information can be presented at one or more on-site locations (such as at an oil well or other facility), on the Internet (such as on a webpage), on a mobile application (or app), or at a central processing facility.

The presented information can include feedback, such as changes in parameters or processing inputs, that the user can select to improve a production environment, such as in the exploration, production, and/or testing of petrochemical processes or facilities. For example, the feedback can include parameters that, when selected by the user, can cause a change to, or an improvement in, drilling parameters (including drill bit speed and direction) or overall production of a gas or oil well. The feedback, when implemented by the user, can improve the speed and accuracy of calculations, streamline processes, improve models, and solve problems related to efficiency, performance, safety, reliability, costs, downtime, and the need for human interaction.

In some implementations, the feedback can be implemented in real-time, such as to provide an immediate or near-immediate change in operations or in a model. The term real-time (or similar terms as understood by one of ordinary skill in the art) means that an action and a response are temporally proximate such that an individual perceives the action and the response occurring substantially simultaneously. For example, the time difference for a response to display (or for an initiation of a display) of data following the individual's action to access the data can be less than 1 millisecond (ms), less than 1 second(s), or less than 5 s. While the requested data need not be displayed (or initiated for display) instantaneously, it is displayed (or initiated for display) without any intentional delay, taking into account processing limitations of a described computing system and time required to, for example, gather, accurately measure, analyze, process, store, or transmit the data.

Events can include readings or measurements captured by downhole equipment such as sensors, pumps, bottom hole assemblies, or other equipment. The readings or measurements can be analyzed at the surface, such as by using applications that can include modeling applications and machine learning. The analysis can be used to generate changes to settings of downhole equipment, such as drilling equipment. In some implementations, values of parameters or other variables that are determined can be used automatically (such as through using rules) to implement changes in oil or gas well exploration, production/drilling, or testing. For example, outputs of the present disclosure can be used as inputs to other equipment and/or systems at a facility. This can be especially useful for systems or various pieces of equipment that are located several meters or several miles apart, or are located in different countries or other jurisdictions.

FIG. 7 is a block diagram of an example data processing system 600 used to provide computational functionalities associated with described algorithms, methods, functions, processes, flows, and procedures described in the present disclosure. For example, the data processing system 700 can be configured for control of injection pumps to reduce operational costs while meeting operational constraints. The data processing device 702 can include input devices such as keypads, keyboards, and touch screens that can accept user information. Also, the data processing device 702 can include output devices that can convey information associated with the operation of the data processing device 702. The information can include digital data, visual data, audio information, or a combination of information. The information can be presented in a graphical user interface (UI) (or GUI).

The data processing device 702 can serve in a role as a client, a network component, a server, a database, a persistency, or components of a computer system for performing the subject matter described in the present disclosure. The illustrated data processing device 702 is communicably coupled with a network 724. In some implementations, one or more components of the data processing device 702 can be configured to operate within different environments, including cloud-computing-based environments, local environments, global environments, and combinations of environments.

The data processing device 702 can receive requests over network 724 from a client application (for example, executing on another data processing device 702). The data processing device 702 can respond to the received requests by processing the received requests using software applications. Requests can also be sent to the data processing device 702 from internal users (for example, from a command console), external (or third) parties, automated applications, entities, individuals, systems, and computers.

Each of the components of the data processing device 702 can communicate using a system bus 704. In some implementations, any or all of the components of the data processing device 702, including hardware or software components, can interface with each other or the interface 706 (or a combination of both), over the system bus 704. Interfaces can use an application programming interface (API) 714, a service layer 716, or a combination of the API 714 and service layer 716. The API 714 can include specifications for routines, data structures, and object classes. The API 714 can be either computer-language independent or dependent. The API 714 can refer to a complete interface, a single function, or a set of APIs.

The service layer 716 can provide software services to the data processing device 702 and other components (whether illustrated or not) that are communicably coupled to the data processing device 702. The functionality of the data processing device 702 can be accessible for all service consumers using this service layer. Software services, such as those provided by the service layer 716, can provide reusable, defined functionalities through a defined interface. For example, the interface can be software written in JAVA, C++, or a language providing data in extensible markup language (XML) format. While illustrated as an integrated component of the data processing device 702, in alternative implementations, the A PI 714 or the service layer 716 can be stand-alone components in relation to other components of the data processing device 702 and other components communicably coupled to the data processing device 702. Moreover, any or all parts of the API 714 or the service layer 716 can be implemented as child or sub-modules of another software module, enterprise application, or hardware module without departing from the scope of the present disclosure.

The data processing device 702 includes an interface 706. Although illustrated as a single interface 706 in FIG. 6, two or more interfaces 706 can be used according to implementations of the data processing device 702 and the described functionality. The interface 706 can be used by the data processing device 702 for communicating with other systems that are connected to the network 724 (whether illustrated or not) in a distributed environment. Generally, the interface 706 can include, or be implemented using, logic encoded in software or hardware (or a combination of software and hardware) operable to communicate with the network 724. More specifically, the interface 706 can include software supporting one or more communication protocols associated with communications. As such, the network 724 or the interface's hardware can be operable to communicate physical signals within and outside of the illustrated data processing device 702.

The data processing device 702 includes a processor 708. Although illustrated as a single processor 708 in FIG. 6, two or more processors 708 can be used according to implementations of the data processing device 702 and the described functionality. Generally, the processor 708 can execute instructions and can manipulate data to perform the operations of the data processing device 702, including operations using algorithms, methods, functions, processes, flows, and procedures as described in the present disclosure.

The data processing device 702 also includes a database 720 that can hold data (such as reservoir parameter data including pressure, equipment connectivity data, and operational parameter data 722) for the data processing device 702 and other components connected to the network 724 (whether illustrated or not). For example, database 720 can be in-memory or a database storing data consistent with the present disclosure. In some implementations, database 720 can be a combination of two or more different database types (for example, hybrid in-memory and conventional databases) according to implementations of the data processing device 702 and the described functionality. While database 720 is illustrated as an internal component of the data processing device 702, in alternative implementations, database 720 can be external to the data processing device 702.

The data processing device 702 also includes a memory 710 that can hold data for the data processing device 702 or a combination of components connected to the network 724 (whether illustrated or not). In some implementations, memory 710 can be a combination of two or more different types of memory (for example, a combination of semiconductor and magnetic storage) according to implementations of the data processing device 702 and the described functionality. While memory 710 is illustrated as an internal component of the data processing device 702, in alternative implementations, memory 710 can be external to the data processing device 702.

The application 712 can be an algorithmic software engine providing functionality according to implementations of the data processing device 702 and the described functionality. For example, application 712 can serve as one or more components, modules, or applications.

The data processing device 702 can also include a power supply 718. The power supply 718 can include a rechargeable or non-rechargeable battery that can be configured to be either user-or non-user-replaceable.

There can be any number of computers 702 associated with, or external to, a computer system including the data processing device 702, with each data processing device 702 communicating over network 724. Further, the terms “client,” “user,” and other appropriate terminology can be used interchangeably, as appropriate, without departing from the scope of the present disclosure. Moreover, the present disclosure contemplates that many users can use one data processing device 702 and one user can use multiple computers 702.

Implementations of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, in tangibly embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Software implementations of the described subject matter can be implemented as one or more computer programs. Each computer program can include one or more modules of computer program instructions encoded on a tangible, non-transitory, computer-readable computer-storage medium for execution by, or to control the operation of, data processing apparatus. Alternatively, or additionally, the program instructions can be encoded in/on an artificially generated propagated signal. The example, the signal can be a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. The computer-storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of computer-storage mediums.

The terms “data processing apparatus,” “computer,” and “electronic computer device” (or equivalent as understood by one of ordinary skill in the art) refer to data processing hardware. For example, a data processing apparatus can encompass all kinds of apparatus, devices, and machines for processing data, including by way of example, a programmable processor, a computer, or multiple processors or computers. The apparatus can also include special purpose logic circuitry including, for example, a central processing unit (CPU), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC). In some implementations, the data processing apparatus or special purpose logic circuitry (or a combination of the data processing apparatus or special purpose logic circuitry) can be hardware-or software-based (or a combination of both hardware-and software-based).

The methods, processes, or logic flows described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform functions by operating on input data and generating output. The methods, processes, or logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, for example, a CPU, an FPGA, or an ASIC.

Computer readable media (transitory or non-transitory, as appropriate) suitable for storing computer program instructions and data can include all forms of permanent/non-permanent and volatile/non-volatile memory, media, and memory devices. Computer readable media can include, for example, semiconductor memory devices such as random-access memory (RAM), read only memory (ROM), phase change memory (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices. Computer readable media can also include, for example, magnetic devices such as tape, cartridges, cassettes, and internal/removable disks.

A number of embodiments of the systems and methods have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of this specification. Accordingly, other embodiments are within the scope of the following claims.