WO2017059152A1

WO2017059152A1 - Self-organizing swarm intelligent wells

Info

Publication number: WO2017059152A1
Application number: PCT/US2016/054571
Authority: WO
Inventors: Yasin Hajizadeh
Original assignee: Schlumberger Technology Corporation; Schlumberger Canada Limited; Services Petroliers Schlumberger; Geoquest Systems B.V.
Priority date: 2015-10-02
Filing date: 2016-09-30
Publication date: 2017-04-06

Abstract

A method for performing a field operation of a field involves receiving, by a first computing unit associated with a first well in the field, first data from one or more first downhole sensors of the first well, building, using a machine learning algorithm, a first predictive model for the first well based at least on the first data, determining, by the first computing unit based on an objective function, a first input value set of the first predictive model for achieving a target result of modulating a first control device in the first well, generating, by the first computing unit, a first control signal based on the first input value set, and modulating, using the first control signal, the first control device.

Description

SELF-ORGANIZING SWARM INTELLIGENT WELLS

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent Application Serial

Number 62/236577, filed on October 02, 2015, which is incorporated herein by reference in its entirety.

BACKGROUND

[0002] In a closed-loop intelligent well workflow, a well-centric loop optimizes the production in each well by controlling individual zones. The flow control valve (FCV) adjustments are often controlled from surface, based on the data transmitted from the well. The optimization cycle in these workflows may depend on a reservoir simulation workflow to test various control combinations and resulting production profiles. Adjusting the FCV and performing reservoir simulation often involves a human operator.

SUMMARY

[0003] In general, in one aspect, embodiments of self-organizing swarm intelligent wells relate to a method for performing a field operation of a field. The method includes receiving, by a first computing unit associated with a first well in the field, first data from one or more first downhole sensors of the first well, building, using a machine learning algorithm, a first predictive model for the first well based at least on the first data, determining, by the first computing unit based on an objective function, a first input value set of the first predictive model for achieving a target result of modulating a first control device in the first well, generating, by the first computing unit, a first control signal based on the first input value set, and modulating, using the first control signal, the first control device.

[0004] Other aspects will be apparent from the following description and the appended claims.

BRIEF DESCRIPTION OF DRAWINGS

[0005] The appended drawings illustrate several embodiments of self-organizing swarm intelligent wells and are not to be considered limiting of its scope, for self-organizing swarm intelligent wells may admit to other equally effective embodiments.

[0006] FIG. 1.1 is a schematic view, partially in cross-section, of a field in which one or more embodiments of self-organizing swarm intelligent wells may be implemented.

[0007] FIG. 1.2 shows a schematic diagram of a system in accordance with one or more embodiments.

[0008] FIGS. 2.1 and 2.2 show a flowchart of an example method in accordance with one or more embodiments.

[0009] FIGS. 3.1, 3.2, 3.4, and 3.4 show an example in accordance with one or more embodiments.

[0010] FIGS. 4.1 and 4.2 show computing systems in accordance with one or more embodiments.

DETAILED DESCRIPTION

[0011] Specific embodiments will now be described in detail with reference to the accompanying figures. Like elements in the various figures are denoted by like reference numerals for consistency. [0012] In the following detailed description of embodiments, numerous specific details are set forth in order to provide a more thorough understanding. However, it will be apparent to one of ordinary skill in the art that one or more embodiments may be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description.

[0013] In general, embodiments provide a method and system for performing a field operation based on a predictive model that is generated using a machine learning algorithm. In one or more embodiments, the predictive model is a data- driven model. In particular, a computing unit associated with a well in the field receives data from one or more downhole sensors of the well. For example, the data may relate to temperature, pressure, flow rate, etc. Based at least on the data received from the one or more downhole sensors, the predictive model for the well is built using the machine learning algorithm. An input value set (e.g., including a flow control valve (FCV) control data) of the predictive model is then determined by the computing unit based on an objective function. Specifically, the input value set of the predictive model is determined for achieving a target result of modulating a control device in the well. Accordingly, a control signal is generated by the computing unit based on the input value set. The control device is then modulated using the control signal to perform the field operation.

[0014] In one or more embodiments, multiple wells in the field communicate with each other to share a portion of their downhole sensor data and field operation results. The shared data is used by the machine learning algorithm in generating the respective predictive models of the wells. Thus, data from other wells as well as data from a current well may be used to generate a predictive model of the current well. In this manner, the interactions between the wells' operations are modeled by the predictive models. [0015] One or more embodiments are directed to increasing efficiency of a computing system by configuring multiple computing units associated with individual wells as a swarm intelligence system. In particular, a swarm intelligence system is a collection of entities interacting with one another and with the environment where the entities exist. For example, the entities may be live objects, such as ants, birds, bacteria, fish, etc. that exist in the nature (i.e., environment). In another example, the entities may be computing systems of wells that exist in an oil field (i.e., environment). The interactions lead to emergence of an "intelligent" global behavior unknown to individual entities. Examples of the swarm intelligent system that occur in nature includes ant colonies, bird flocking, animal herding, bacterial growth, fish schooling, etc. By configuring the computing units to share a small portion of their data (e.g., corresponding to one parameter, two parameters, etc.) based on the swarm intelligence, the coupled computing units may achieve a higher objective that is beyond each well's capability to result in a more efficient computing system and production system. In one or more embodiments, the computing units are decentralized and located in corresponding wells. By limiting the shared data to the small portion of other computing units' data, the resource usage of each computing unit is not increased proportionally to the number of computing units (or wells) in the swarm intelligent system. In contrast, the resource usage of a central computing system capable of performing machine learning of the wells increases proportionally to the number of wells and may become impractical for a large collection of wells.

[0016] FIG. 1.1 depicts a schematic view, partially in cross section, of a field (100) in which one or more embodiments of self-organizing swarm intelligent wells may be implemented. In one or more embodiments, one or more of the modules and elements shown in FIG. 1.1 may be omitted, repeated, and/or substituted. Accordingly, embodiments of self-organizing swarm intelligent wells should not be considered limited to the specific arrangements of modules shown in FIG. 1.1.

[0017] As shown in FIG. 1.1, the field (100) includes the subterranean formation

(104), data acquisition tools (102-1), (102-2), (102-3), and (102-4), wellsite system A (114-1), wellsite system B (114-2), wellsite system C (114-3), a surface unit (112), and an exploration and production (E&P) computer system (118). The subterranean formation (104) includes several geological structures, such as a sandstone layer (106- 1), a limestone layer (106-2), a shale layer (106- 3), a sand layer (106-4), and a fault line (107). In particular, these geological structures form at least one reservoir containing fluids (e.g., hydrocarbon) as described below.

[0018] In one or more embodiments, data acquisition tools (102-1), (102-2), (102-

3), and (102-4) are positioned at various locations along the field (100) for collecting data of the subterranean formation (104) referred to as survey operations. In particular, the data acquisition tools are adapted to measure the subterranean formation (104) and detect the characteristics of the geological structures of the subterranean formation (104). For example, the data acquisition tool (102-1) includes seismic equipment and the data acquisition tools (102-2), (102-3), and (102-4) are located in the wells and include downhole sensors, such as temperature sensors, pressure sensors, flow rate sensors, acoustic sensors, pH sensors, water cut sensor, gas fraction sensors, one or more gauges, etc. Data plots (108-1), (108-2), (108-3), and (108-4) are depicted along the field (100) to demonstrate the data generated by the data acquisition tools. Specifically, the static data plot (108-1) is a seismic two-way response time. Static data plot (108- 2) is core sample data measured from a core sample of the subterranean formation (104). Static data plot (108-3) is a logging trace, referred to as a well log. Production decline curve or graph (108-4) is a dynamic data plot of the fluid flow rate over time. Other data may also be collected, such as historical data, analyst user inputs, economic information, and/or other measurement data and other parameters of interest.

[0019] Further as shown in FIG. 1.1, each of the wellsite system A (114-1), wellsite system B (114-2), and wellsite system C (114-3) is associated with a rig, a wellbore, and other wellsite equipment configured to perform wellbore operations, such as logging, drilling, fracturing, production, or other applicable operations. For example, the wellsite system A (114-1) is associated with a rig (101), a wellbore (103), and drilling equipment to perform drilling operation. Similarly, the wellsite system B (114-2) and wellsite system C (114-3) are associated with respective rigs, wellbores, other wellsite equipment, such as production equipment and logging equipment to perform production operations and logging operations, respectively. Generally, survey operations and wellbore operations are referred to as field operations of the field (100). In addition, data acquisition tools and wellsite equipment are referred to as field operation equipment. In one or more embodiments, the wellbore operations extract fluids from and/or inject fluids into the subterranean formation (104). The field operations are performed as directed by a surface unit (112) and/or the E&P computer system (118). For example, the field operation equipment may be controlled by a field operation control signal that is sent from the surface unit (112) and/or the E&P computer system (118).

[0020] In one or more embodiments, the surface unit (112) and/or the E&P computer system (118) are operatively coupled to the data acquisition tools (102- 1), (102-2), (102-3), (102-4), and/or the wellsite systems. In particular, the surface unit (112) and/or the E&P computer system (118) are configured to send commands to the data acquisition tools (102-1), (102-2), (102-3), (102-4), and/or the wellsite systems and to receive data therefrom. In one or more embodiments, the surface unit (112) and/or the E&P computer system (118) may be located at the wellsite system A (114-1), wellsite system B (114-2), wellsite system C (114- 3), and/or remote locations. The surface unit (112) may be provided with computer facilities (e.g., the E&P computer system (118)) for receiving, storing, processing, and/or analyzing data from the data acquisition tools (102-1), (102- 2), (102-3), (102-4), the wellsite system A (114-1), wellsite system B (114-2), wellsite system C (114-3), and/or other parts of the field (100). The surface unit (112) and/or the E&P computer system (118) may also be provided with or have functionally for actuating mechanisms (e.g., modulating a flow control valve or other control devices) at the field (100). The surface unit (112) and/or the E&P computer system (118) may then send command signals to the field (100) in response to data received, stored, processed, and/or analyzed, for example to control and/or optimize various field operations described above. In one or more embodiments, the surface unit (112) is communicatively coupled to the E&P computer system (118). In one or more embodiments, the data received by the surface unit (112) may be sent to the E&P computer system (118) for further analysis. Generally, the E&P computer system (1 18) is configured to analyze, model, control, optimize, or perform management tasks of the aforementioned field operations based on the data received directly by the E&P computer system (118) or provided from the surface unit (112). In one or more embodiments, the E&P computer system (1 18) is provided with functionality for manipulating and analyzing the data, such as performing simulation, planning, and optimization of production operations of the wellsite system A (114-1), wellsite system B (114-2), and/or wellsite system C (114-3). In one or more embodiments, the result generated by the E&P computer system (118) may be displayed for an analyst user to view the result in a two dimensional (2D) display, three dimensional (3D) display, or other suitable displays located in the surface unit (112). Although the surface unit (112) is shown as separate from the E&P computer system (118) in FIG. 1.1, in other examples, the surface unit (112) and the E&P computer system (1 18) may also be combined. In one or more embodiments, the E&P computer system (118) may be de-centralized with portions of the E&P computer system (118) located throughout the field (100).

[0022] Although FIG. 1.1 shows a field (100) on the land, the field (100) may be an offshore field. In such a scenario, the subterranean formation may be in the sea floor. Further, field data may be gathered from the field (100) that is an offshore field using a variety of offshore techniques for gathering field data.

[0023] FIG. 1.2 shows more details of the E&P computer system (118) in which one or more embodiments of self-organizing swarm intelligent wells may be implemented. In one or more embodiments, one or more of the modules and elements shown in FIG. 1.2 may be omitted, repeated, and/or substituted. Accordingly, embodiments of self-organizing swarm intelligent wells should not be considered limited to the specific arrangements of modules shown in FIG. 1.2.

[0024] As shown in FIG. 1.2, the E&P computer system (118) includes a number of computing units, such as computing unit A (223), computing unit B (224) computing unit C (225), etc. communicating with each other. In one or more embodiments, each computing unit of the E&P computer system (1 18) is associated with a wellsite system. For example, the computing unit A (223) may be associated with the wellsite system A (114-1), the computing unit B (224) may be associated with the wellsite system B (114-2), the computing unit C (225) may be associated with the wellsite system C (114-3), etc. In one or more embodiments, at least one computing unit of the E&P computer system (118) is located in a well of the associated wellsite system. For example, the computing unit A (223) may be located in the well (e.g., a downhole location associated with the wellbore (103)) of the wellsite system A (114-1), the computing unit B (224) may be located in the well of the wellsite system B (114-2), and/or the computing unit C (225) may be located in the well of the wellsite system C (114- 3). In one or more embodiments, one or more computing units of the E&P computer system (1 18) are located in a central location (e.g., surface unit (112)) while other computing units of the E&P computer system (118) are located in respective wellsite systems or wells.

[0025] In one or more embodiments, the computing unit A (223) includes an input/output interface (226), a data analyzer (227), an optimizer (228), a field task engine (230) for performing various tasks of the field operation for the well (e.g., wellbore (103)) associated with the computing unit A (223), and a data repository (231) for storing input data, intermediate data, and resultant outputs of the computing unit A (223). In one or more embodiments, the data repository (231) may include one or more disk drive storage devices, one or more semiconductor storage devices, other suitable computer data storage devices, or combinations thereof. In one or more embodiments, content stored in the data repository (231) may be stored as a data file, a linked list, a data sequence, a database, a graphical representation, any other suitable data structure, or combinations thereof. In one or more embodiments, one or more of the computing unit B (224) computing unit C (225), etc. include similar components as the computing unit A (223) described above.

[0026] In one or more embodiments, the content stored in the data repository (231) includes a field operation result data (232), an input value set (233), a training set (234), an objective function (237), and a predictive model (238). As used herein, the field operation result data (232) refers to data representing a result of the field operation. As used herein, the field operation may include the physical survey operation and/or wellbore operation described in reference to FIG. 1.1 above. The result is an actual result or the result of physically performing the field operation in the field. In one or more embodiments, the field operation result data (232) includes production data (e.g., pressures, flow rates, etc.) or other performance indicators (e.g., a net present value (NPV) or other measure of fluid production, a measure of water flooding or gas lift in an injection operation, etc.) of the well associated with the computing unit A (223). For example, the pressure data, flow rate data, or other performance indicator may be obtained from the aforementioned downhole sensors located in the wellbore and stored in the data repository (231) as the field operation result data (232).

[0027] As used herein, the input value set (233) refers to a set of values as the input to the predictive model (238) described below. In one or more embodiments, the input value set (233) includes local sensor data (233-1), control data (233-2), and remote data (233-3). The values in the input value set (232) may be time-dependent. Specifically, the local sensor data (233-1) includes a portion of the data received from downhole sensors of the well associated with the computing unit A (223). In particular, the local sensor data (233-1) is separate from the field operation result data (232) but may influence the field operation as reflected by the field operation result data (232). For example, the local sensor data (233- 1) may include temperature data, pressure data, porosity data, permeability data, connectivity data, resistivity data, fluid density data, viscosity data, phase composition data, water pH data, etc.

[0028] As used herein, the control data refers to data used to generate a control signal for modulating or otherwise adjusting a control device. In one or more embodiments, the control data (233-2) includes a binary (e.g., one or off) state, a discrete or continuously variable positioning, or other control measure of a mechanism for a control device of the well associated with the computing unit A (223). For example, the control device may be a flow control valve (FCV), an inflow control valve (ICV), or an inflow control device (ICD) where the corresponding control data may be used to generate the FCV, ICV, or ICD control signal. [0029] As used herein, the remote data refers to data of another well separate from, or otherwise not associated with, the local computing unit. In one or more embodiments, the remote data (233-3) includes a portion of predicted or actual field operation result data (not shown), sensor data (not shown), and control data (not shown) of one or more wells that use or physically include the computing unit B (224), computing unit C (225), or other wells separate from, or otherwise not associated with, the computing unit A (223). In other words, the remote data may be similar to local data but for another computing unit or wellsite. For example, the remote data (233-3) may include a predicted and/or actual pressure, flow rate, or other performance indicators of the well associated with the computing unit B (224), computing unit C (225), or another well separate from the wellbore (103).

[0030] As used herein, the machine learning refers to a technique and an algorithm for physical machinery to learn from and make predictions of data. In one or more embodiments, the machine learning is performed by building the predictive model (238) based on the training set (234), as described below, in order to make data-driven predictions of modeled outputs (e.g., predicted result A (238-1), predicted result B (238-2), etc.). In this context, the training set (234) is a set of data used to discover potential predictive relationships between the input value set (233) and modeled outputs (e.g., predicted result A (238-1), predicted result B (238-2), etc.) of the predictive model (238). In one or more embodiments, the training set (234) corresponds to data obtained from the aforementioned downhole sensors and data used to modulate a control device of the well associated with the computing unit A (223). In particular, the data in the training set (234) is obtained from the aforementioned downhole sensors or is used to modulate the control device during a time period referred to as a training phase of the machine learning. [0031] In one or more embodiments, the training set (234) includes multiple entries (e.g., entry A (235), entry B (236), etc.) corresponding to different time points in the training phase. For example, the time points for these entries in the training phase may be periodic time points, intermittent time points, in response to user activations, or triggered by pre-determined events. Specifically, the entry A (235) includes historical local sensor data (235-1), historical control data (235- 2), historical remote data (235-3), and historical field operation result data (235- 4) that correspond to a particular time point A (not shown) in the training phase. In particular, the historical local sensor data (235-1), historical control data (235- 2), historical remote data (235-3), and historical field operation result data (235- 4) correspond to the local sensor data (233-1), control data (233-2), remote data (233-3), and field operation result data (232), respectively, at the time point A. For example, the historical local sensor data (235-1) may include temperature data, pressure data, flow rate data, porosity data, permeability data, connectivity data, resistivity data, fluid density data, viscosity data, phase composition data, water pH data, etc. of the wellbore (103) at the time point A. The historical control data (235-2) may include the data used to generate a control signal for modulating or otherwise adjusting a control device of the wellbore (103) at the time point A. The historical remote data (235-3) may include the data obtained at the time point A from another well that is separate from, or otherwise not associated with, the computing unit A (223). The historical field operation result data (235-4) may include actual production data or other performance indicators of the wellbore (103).

[0032] In one or more embodiments, the entry B (236) includes similar data items as the entry A (235) that correspond to a different time point B (not shown) in the training phase. In one or more embodiments, the training set (234) may include additional information of the well associated with the computing unit A (223) that is provided by a user or generated by a simulator to supplement the data obtained from the downhole sensors. For example, the additional information may include well information related to a location, depth, completion, etc. of the wellbore (103). In another example, the additional information may relate to certain reservoir properties, fluid properties, and/or production data that may not be available from the downhole sensors of the wellbore (103).

[0033] In one or more embodiments, the predictive model (238) is a computer model of statistical relationships between the input value set (233) and modeled outputs (e.g., predicted result A (238-1), predicted result B (238-2), etc.) of the predictive model (238). In particular, the predicted result A (238-1) represents a prediction of pressures, flow rates, or other performance indicators of the wellbore (103) that is predicted using the predictive model (238) based on a particular set of values in the input value set (233). The predicted result B (238- 1) represents the prediction based on a different set of values in the input value set (233). While the modeled output of the predictive model (238) represents a prediction of the field operation result, in contrast, the field operation result data (232) represents the actual result of the field operation for the wellbore (103). In one or more embodiments, the objective function (237) is a pre-determined measure of a predicted field operation result of the well associated with the computing unit A (223). For example, the objective function (237) may include a pressure, a flow rate, a performance indicator, or a combination thereof of the wellbore (103). In particular, the objective function (237) includes the value A (237-1), value B (237-2), etc. corresponding to the predicted result A (238-1) predicted result B (238-2), etc., respectively, that are generated by the predictive model (238).

[0034] In one or more embodiments, the input/output interface (226) is configured to obtain data from the downhole sensors of well associated with the computing unit A (223). For example, the local sensor data (233-1) and the field operation result data (232) may be obtained by the input/output interface (226) from the downhole sensors of the wellbore (103). In one or more embodiments, the input/output interface (226) is further configured to exchange data with other computing units (e.g., computing unit B (224), computing unit C (225), etc.) of the E&P computing system (118). For example, the input/output interface (226) may send a portion of the field operation result data (232) and the local sensor data (233-1) to one or more of the computing unit B (224), computing unit C

(225) , etc. In another example, the input/output interface (226) may receive the remote data (233-3) from one or more of the computing unit B (224), computing unit C (225), etc. In one or more embodiments, the input/output interface (226) obtains data from the downhole sensors and/or exchange data with other computing units intermittently, periodically, in response to a user activation, or as triggered by an event. In one or more embodiments, the input/output interface

(226) obtains data from the downhole sensors and/or exchange data with other computing units using a wireless transceiver (not shown) of the computing unit A (223). For example, the input/output interface (226) may wirelessly receive data that is streamed from the downhole sensors and/or streamed from other computing units. In one or more embodiments, the data is wirelessly received within a pre-determined time period (e.g., 1 second, 1 millisecond, etc.) subsequent to being generated by the downhole sensors or other computing units. In other words, the data is wirelessly received in real time. In one or more embodiments, the data analyzer (227) is configured to use a machine learning algorithm to build the predictive model (238) for the wellbore (103) based on the training set (234). In addition, the data analyzer (227) is configured to use the predictive model (238) to generate the predicted results (e.g., predicted result A (238-1), predicted result B (238-1), etc.) of the field operation based on the input value set (233). In one or more embodiments, the data analyzer (227) builds the predictive model (238) during the aforementioned training phase and generates the predicted results of the field operation subsequent to the training phase, which is referred to the operating phase. In one or more embodiments, the data analyzer (227) further adjusts the predictive model (238) during the operating phase, e.g., intermittently, periodically, in response to a user activation, or as triggered by an event. In one or more embodiments, the data analyzer (227) is configured to combine multiple predictive models for multiple wellbores (e.g., within a pre-determined region) to form a combined predictive model of a set of wellbores.

[0036] In one or more embodiments, the optimizer (228) is configured to determine, based on the objective function (237), a set of values for the input value set (233) as the input of the predictive model (238) for achieving a target result of the field operation. For example, the objective function (237) may be a maximized hydrocarbon production quantity of the wellbore (103) and the target result may correspond to the maximized value (e.g., value A (237-1)) of the objective function (237). In another example, the objective function (237) may be a minimized water production quantity of the wellbore (103) and the target result may correspond to the minimized value (e.g., value A (237-1)) of the objective function (237). In other words, the optimizer (228) determines a particular set of values of the input value set (233) such that the predictive model (238) generates the predicted result A (238-1). In one or more embodiments, the optimizer (228) uses one or more of a gradient based algorithm, a stochastic algorithm, a deterministic algorithm, a population based algorithm, or an evolutionary algorithm. For example, the predicted result A (238-1) may be a maximized flow rate of the wellbore (103) that results in the maximized hydrocarbon production quantity (i.e., value A (237- 1) of the objective function (237)). In another example, the predicted result A (238-1) may be a minimized water production of the wellbore (103).

[0037] In one or more embodiments, the input value set (233) is constrained by the local sensor data (233-1) and the remote data (233-3) received by the computing unit A (223). In other words, the values of the local sensor data (233-1) and the remote data (233-3) are determined based on data received from the downhole sensors and other computing units. In addition, the optimizer (228) selects appropriate values of the control data (233-2) such that the predictive model (238) generates the predicted result A (238-1) based on the combination of the selected control data (233-2) and the constrained local sensor data (233-1) and the remote data (233-3). In the context that the control data (233-2) is used to modulate a control device of the wellbore (103), the optimizer (228) determines the input value set (233) as the input of the predictive model (238) for achieving a target result of modulating the control device.

[0038] In one or more embodiments, the optimizer (228) adjusts the input value set

(233), or more particularly the control data (233-2), in response to updated values of the local sensor data (233-1) and the remote data (233-3). For example, one or more of the local sensor data (233-1) and the remote data (233-3) may be streamed from the downhole sensors and/or other computing units (e.g., computing unit B (224), computing unit C (225), etc.) in real time. As a result, the optimizer (228) may adjust the control data (233-2) in real time as a response to the streamed data. In one or more embodiments, the optimizer (228) determines the set of values for the input value set (233) using the method described in reference to FIG. 2.2 below.

[0039] In one or more embodiments, the computing unit A (223) includes the field task engine (230) that is configured to generate a control signal based on the control data (233-2) to modulate a control device of the wellbore (103). For example, the control device may be a piece of drilling equipment, an actuator, a fluid valve, or other electrical and/or mechanical devices located in or otherwise associated with the wellbore (103). Using the field task engine (230) of the computing unit A (223) and similar field task engines of other computing units (e.g., computing unit B (224), computing unit C (225), etc.), the field operation equipment depicted in FIG. 1.1 above may be controlled by the E&P computer system (118). In this manner, the E&P computer system (118) may control drilling equipment, actuators, fluid valves, or other electrical and/or mechanical devices disposed about the field (100) as depicted in FIG. 1.1 above.

[0040] One or more computing units (e.g., computing unit A (223), computing unit

B (224) computing unit C (225), etc.) of the E&P computer system (118) may include a system computer, such as shown in FIGS. 4.1 and 4.2 below, which may be implemented as a server or any conventional computing system. However, those skilled in the art, having benefit of this disclosure, will appreciate that implementations of various technologies described herein may be practiced in other computer system configurations, including hypertext transfer protocol (HTTP) servers, hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network personal computers, minicomputers, mainframe computers, and the like.

[0041] While specific components are depicted and/or described for use in the units and/or modules of the E&P computer system (118), a variety of components with various functions may be used to provide the formatting, processing, utility and coordination functions for the E&P computer system (118). The components may have combined functionalities and may be implemented as software, hardware, firmware, or combinations thereof.

[0042] FIGS. 2.1 and 2.2 depict an example method in accordance with one or more embodiments. For example, the method depicted in FIGS. 2.1 and 2.2 may be practiced using the E&P computer system (118) described in reference to FIGS. 1.1 and 1.2 above. In one or more embodiments, one or more of the elements shown in FIGS. 2.1 and 2.2 may be omitted, repeated, and/or performed in a different order. Accordingly, embodiments of self-organizing swarm intelligent wells should not be considered limited to the specific arrangements of elements shown in FIGS. 2.1 and 2.2.

[0043] Initially, in Block 201 of FIG. 2.1, first data from one or more first downhole sensors of a first well is receiving by a first computing unit associated with the first well. For example, the first data may include reservoir property data, fluid property data, and production data of the first well. In addition, second data is received by the first computing unit from a second computing unit associated with a second well. In one or more embodiments, the second data is referred to as remote data for the first computing unit. In one or more embodiments, the second data is a small portion (e.g., one data item, two data items, less than 5 data items, etc.) of the reservoir property data, fluid property data, and production data of the second well. For example, the small portion of the reservoir property data, fluid property data, and production data of the second well may be selected by the second computing unit for sending to, or otherwise sharing with the first computing unit.

[0044] In one or more embodiments, the first data is received by the first computing unit intermittently, periodically, in response to a user activation, or as triggered by an event. Further, the second data is received by the first computing unit intermittently, periodically, in response to a user activation, or as triggered by an event. In one or more embodiments, the first computing unit and the second computing unit correspond to the computing unit A (223) and the computing unit B (224), respectively, depicted in FIG. 1.2 above.

[0045] In Block 202, a first predictive model for the first well is built based at least on the first data and the second data. In one or more embodiments, the first data and the second data that are received and accumulated during a training phase are used to form a training set. Based on the training set, the first predictive model is built using a machine learning algorithm. For example, the first data accumulated during the training phase is analyzed to determine a statistical dependence of the production data of the first well based on the reservoir and fluid properties of the first well. Accordingly, the statistical dependence is included in the first predictive model. In another example, the second data accumulated during the training phase is also analyzed to determine an additional statistical dependence of the production data of the first well based on the second data. Accordingly, the additional statistical dependence is also included in the first predictive model. In one or more embodiments, the predictive model is used to predict a result of the field operation in the operating phase subsequent to the training phase. In this context, data received and used in the training phase is referred to as historical values of the data. In particular, the historical values of the data are used in the training set to adjust the predictive model using the machine learning algorithm. In contrast, data received and used in the operating phase is referred to as updated and/or further updated values of the data. In Block 203, an input value set (e.g., control data, such as FCV control data) of the first predictive model is determined by the first computing unit for achieving a target result of the field operation. In one or more embodiments, the target result is evaluated based on an objective function. In one or more embodiments, the input value set is constrained by the local sensor data and the remote data. In other words, the first predictive model is inversed to determine the control data (e.g., FCV control data) as constrained by the local sensor data and the remote data. Specifically, the local sensor data and the remote data in the input value set are assigned updated values of the first data and the second data, respectively, that are available at the time of determining the input value set. Separately, the remaining portion of the input value set is determined based on the objective function to achieve the target result. In particular, the remaining portion includes control data (e.g., FCV control data) that is used to modulate a first control device of the first well. As the updated values of the local sensor data and the updated values of the remote data are streamed from the downhole sensors and remote wells in real time, the control data (e.g., FCV control data) in the input value set is adjusted in response. Adjusting the control data (e.g., FCV control data) in the input value set in real time is performed at least according to a loop from Block 204 through Block 209. Additional details of the Block 203 are depicted in FIG. 2.2 below.

[0047] In Block 204, the first control device (e.g., FCV) is modulated by the first computing unit based on the input value set, or more particularly the control data (e.g., FCV control data). In one or more embodiments, a first control signal is generated by the first computing unit based on the input value set. For example, the first computing unit may use an analog-to-digital converter to convert a digital value of the first control signal to an analog level of the first control signal. Accordingly, the first control signal is applied to the first control device to modulate the first control device. For example, the first control signal may be applied to a control input of a valve to modulate the flow rate of fluids flowing through the valve. According to the loop from Block 204 through Block 209, the flow rate may be adjusted, e.g., using the FCV control signal, in real time in response to the local sensor data and the remote data being streamed from the downhole sensors and remote wells.

[0048] In Block 205, third data representing the result of modulating the first control device is transmitted by the first computing unit to the second computing unit. In one or more embodiments, the first computing unit and the second computing unit exchange data to build/adjust their respective predictive models. Similar to the first computing device building/adjusting the first predictive model based on the second data from the second computing unit, the third data may be used by the second computing device to build and/or adjust a second predictive model of the second well. In one or more embodiments, the third data is transmitted by the first computing unit to the second computing unit intermittently, periodically, in response to a user activation, or as triggered by an event.

[0049] In Block 206, a second control device of the second well is modulated by the second computing device based on the third data and the second predictive model. In one or more embodiments, as discussed above, the second predictive model is built/adjusted by the second computing unit based at least on the third data. The second predictive model is then used to generate a second control signal that is used to modulate the second control device. Similar to the first control device in the first well, the second control device may be adjusted in real time according to the loop from Block 204 through Block 209.

[0050] In Block 207, a determination is made as to whether the field operation is completed. If the determination is positive, i.e., the field operation is completed, the method ends. If the determination is negative, i.e., the field operation has not been completed, the method proceeds to Block 208.

[0051] In Block 208, a further updated value of the second data {i.e., remote data for the first computing unit), representing the result of modulating the second control device in Block 206, is transmitted by the second computing unit to the first computing unit. In one or more embodiments, updates of the second data are transmitted by the second computing unit to the first computing unit intermittently, periodically, in response to a user activation, or as triggered by an event.

[0052] In Block 209, the input value set of the first predictive model is adjusted by the first computing unit using the further updated value of the second data {i.e., remote data). In particular, in Block 203, the remote data {i.e., second data) in the input value set of the first predictive model is assigned the updated value available at the time of determining the input value set. In one or more embodiments, the input value set of the first predictive model is adjusted by using the further updated value of the second data to substitute the previously assigned updated value. In response to updating the first input value set, the method returns to Block 204 where the first control signal is adjusted based on the updating of the first input value set.

[0053] FIG. 2.2 shows additional details of Block 203 where the input value set (e.g., FCV control data) of the first predictive model is determined, as constrained by the updated values of the first data (e.g., downhole sensor data) and the second data (e.g., remote data), for achieving the target result (e.g., target flow rate as an output of the predictive model) of the field operation. In other words, FIG. 2.2 describes a flowchart of inversing the first predictive model to determine the control data (e.g., FCV control data) as constrained by the local sensor data and the remote data.

[0054] Initially in Block 211, a trial input value set of the first predictive model is selected. In one or more embodiments, a portion of the trial input value set are assigned updated values of the first data and the second data, respectively, that are available at the time of determining the input value set. Separately and in addition, the remaining portion (i.e., control data, such as FCV control data) of the trial input value set is selected.

[0055] In Block 212, a value of the objective function is determined using the trial input value set as input to the first predictive model. Specifically, the modeled output of the predictive model is generated based on the trial input value set. Accordingly, the value of the objective function is determined based on the modeled output of the predictive model.

[0056] In Block 213, a determination is made as to whether a pre-determined criterion for the objective function is satisfied based on the trial input value set. For example, the criterion may specify that the objective function is to be maximized or minimized. In a further example, the criterion may specify a maximum iteration count through the loop of Block 211, Block 212, and Block 213. If the determination is negative, i.e., the criterion is not satisfied {e.g., the modeled output of the predictive model does not produce a maximized value or a minimized value for the objective function, or the number of iterations exceeds the maximum iteration count), the method returns to Block 211 to select a different trial input value set. If the determination is positive, i.e., the criterion is satisfied {e.g., the objective function has a maximized value), the method proceeds to Block 214.

[0057] In Block 214, the selected trial input value set is used as the input value set of the first predictive model. In addition, the value of the objective function based on the selected trail input value set is used as the target result of the field operation.

[0058] FIGS. 3.1, 3.2, 3.4, and 3.4 show an example in accordance with one or more embodiments. In one or more embodiments, the example shown in these figures may be practiced using the E&P computer system shown in FIGS. 1.1 and 1.2 and the method described in reference to FIGS. 2.1 and 2.2 above. The following example is for explanatory purposes and not intended to limit the scope of the claims.

[0059] FIG. 3.1 illustrates an example of a system (301) that includes various management components (110) to manage various aspects of a geologic environment (150) {e.g., an environment that includes a sedimentary basin, a reservoir (151), one or more faults (153-1), one or more geobodies (153-2), etc.). For example, the management components (110) may allow for direct or indirect management of sensing, drilling, injecting, extracting, etc., with respect to the geologic environment (150). In turn, further information about the geologic environment (150) may become available as feedback 160 {e.g., optionally as input to one or more of the management components (110)). In one or more embodiments, the system (301) and the geologic environment (150) correspond to the field (100) depicted in FIG. 1.1 above.

[0060] In the example of FIG. 3.1, the management components (110) include a seismic data component (113), an additional information component (114) (e.g., well/logging data), a processing component (1 16), a simulation component (120), an attribute component (130), an analysis/visualization component (142) and a workflow component (144). In operation, seismic data and other information provided per the components (113) and (114) may be input to the simulation component (120).

[0061] In an example embodiment, the simulation component (120) may rely on entities (122). Entities (122) may include earth entities or geological objects such as wells, surfaces, bodies, reservoirs, etc. In the system (301), the entities (122) can include virtual representations of actual physical entities that are reconstructed for purposes of simulation. The entities (122) may include entities based on data acquired via sensing, observation, etc. (e.g., the seismic data (113) and other information (114)). An entity may be characterized by one or more properties (e.g., a geometrical pillar grid entity of an earth model may be characterized by a porosity property). Such properties may represent one or more measurements (e.g., acquired data), calculations, etc.

[0062] In an example embodiment, the simulation component (120) may operate in conjunction with a software framework such as an object-based framework. In such a framework, entities may include entities based on pre-defined classes to facilitate modeling and simulation. A commercially available example of an object-based framework is the MICROSOFT^® .NET^® framework (Redmond, Washington), which provides a set of extensible object classes. In the .NET^® framework, an object class encapsulates a module of reusable code and associated data structures. Object classes can be used to instantiate object instances for use in by a program, script, etc. For example, borehole classes may define objects for representing boreholes based on well data.

[0063] In the example of FIG. 3.1, the simulation component (120) may process information to conform to one or more attributes specified by the attribute component (130), which may include a library of attributes. Such processing may occur prior to input to the simulation component (120) (e.g., consider the processing component (116)). As an example, the simulation component (120) may perform operations on input information based on one or more attributes specified by the attribute component (130). In an example embodiment, the simulation component (120) may construct one or more models of the geologic environment (150), which may be relied on to simulate behavior of the geologic environment (150) (e.g., responsive to one or more acts, whether natural or artificial). In the example of FIG. 3.1, the analysis/visualization component (142) may allow for interaction with a model or model-based results (e.g., simulation results, etc.). As an example, output from the simulation component (120) may be input to one or more other workflows, as indicated by a workflow component (144).

[0064] As an example, the simulation component (120) may include one or more features of a simulator such as a reservoir simulator. As an example, a simulation component, a simulator, etc. may include features to implement one or more meshless techniques (e.g., to solve one or more equations, etc.). As an example, a reservoir or reservoirs may be simulated with respect to one or more enhanced recovery techniques (e.g., consider a thermal process such as SAGD, etc.).

[0065] In an example embodiment, the management components (110) may include features of a commercially available framework such as the PETREL^® seismic to simulation software framework (Schlumberger Limited, Houston, Texas). The PETREL^® framework provides components that allow for optimization of exploration and development operations. The PETREL^® framework includes seismic to simulation software components that can output information for use in increasing reservoir performance, for example, by improving asset team productivity. Through use of such a framework, various professionals (e.g., geophysicists, geologists, and reservoir engineers) can develop collaborative workflows and integrate operations to streamline processes. Such a framework may be considered an application and may be considered a data-driven application (e.g., where data is input for purposes of modeling, simulating, etc.).

[0066] In an example embodiment, various aspects of the management components (110) may include add-ons or plug-ins that operate according to specifications of a framework environment. For example, a commercially available framework environment marketed as the OCEAN^® framework environment (Schlumberger Limited, Houston, Texas) allows for integration of add-ons (or plug-ins) into a PETREL^® framework workflow. The OCEAN^® framework environment leverages .NET^® tools (Microsoft Corporation, Redmond, Washington) and offers stable, user-friendly interfaces for efficient development. In an example embodiment, various components may be implemented as add-ons (or plug-ins) that conform to and operate according to specifications of a framework environment (e.g., according to application programming interface (API) specifications, etc.).

[0067] FIG. 3.1 also shows an example of a framework (170) that includes a model simulation layer (180) along with a framework services layer (190), a framework core layer (195) and a modules layer (175). In particular, the model simulation layer (180) may include a framework for model building and visualization.

[0068] As an example, a framework may include features for implementing one or more mesh generation techniques. For example, a framework may include an input component for receipt of information from interpretation of seismic data, one or more attributes based at least in part on seismic data, log data, image data, etc. Such a framework may include a mesh generation component that processes input information, optionally in conjunction with other information, to generate a mesh.

[0069] In the example of FIG. 3.1, the model simulation layer (180) may provide domain objects (182), act as a data source (184), provide for rendering (186), and provide for various user interfaces (188). Rendering (186) may provide a graphical environment in which applications can display their data while the user interfaces (188) may provide a common look and feel for application user interface components.

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

[0071] In the example of FIG. 3.1, data may be stored in one or more data sources (or data stores, generally physical data storage devices), which may be at the same or different physical sites and accessible via one or more networks. The model simulation layer (180) may be configured to model projects. As such, a particular project may be stored where stored project information may include inputs, models, results and cases. Thus, upon completion of a modeling session, a user may store a project. At a later time, the project can be accessed and restored using the model simulation layer (180), which can recreate instances of the relevant domain objects. [0072] In the example of FIG. 3.1, the geologic environment (150) may include layers (e.g., stratification) that include a reservoir (151) and one or more other features such as the fault (153-1), the geobody (153-2), etc. As an example, the geologic environment (150) may be outfitted with any of a variety of sensors, detectors, actuators, etc. For example, equipment (152) may include communication circuitry to receive and to transmit information with respect to one or more networks (155). Such information may include information associated with downhole equipment (154), which may be equipment to acquire information, to assist with resource recovery, etc. Other equipment (156) may be located remote from a well site and include sensing, detecting, emitting or other circuitry. Such equipment may include storage and communication circuitry to store and to communicate data, instructions, etc. As an example, one or more satellites may be provided for purposes of communications, data acquisition, etc. For example, FIG. 3.1 shows a satellite in communication with the network (155) that may be configured for communications, noting that the satellite may additionally or instead include circuitry for imagery (e.g., spatial, spectral, temporal, radiometric, etc.).

[0073] FIG. 3.1 also shows the geologic environment (150) as optionally including equipment (157) and (158) associated with a well that includes a substantially horizontal portion that may intersect with one or more fractures (159). For example, consider a well in a shale formation that may include natural fractures, artificial fractures (e.g., hydraulic fractures) or a combination of natural and artificial fractures. As an example, a well may be drilled for a reservoir that is laterally extensive. In such an example, lateral variations in properties, stresses, etc. may exist where an assessment of such variations may assist with planning, operations, etc. to develop a laterally extensive reservoir (e.g., via fracturing, injecting, extracting, etc.). As an example, the equipment (157) and/or (158) may include components, a system, systems, etc. for fracturing, seismic sensing, analysis of seismic data, assessment of one or more fractures, etc.

[0074] As mentioned, the system (301) may be used to perform one or more workflows. A workflow may be a process that includes a number of worksteps. A workstep may operate on data, for example, to create new data, to update existing data, etc. As an example, a may operate on one or more inputs and create one or more results, for example, based on one or more algorithms. As an example, a system may include a workflow editor for creation, editing, executing, etc. of a workflow. In such an example, the workflow editor may provide for selection of one or more pre-defined worksteps, one or more customized worksteps, etc. As an example, a workflow may be a workflow implementable in the PETREL^® software, for example, that operates on seismic data, seismic attribute(s), etc. As an example, a workflow may be a process implementable in the OCEAN^® framework. As an example, a workflow may include one or more worksteps that access a module such as a plug-in (e.g., external executable code, etc.).

[0075] The system (301) may be used for closed-loop management of a smart well.

For example, the system (301) may provide a method that includes considering the interaction between the wells, e.g., without calling for surface action and dependency on a reservoir simulation model. In an embodiment, the method may include obtaining a model based on the swarm intelligence concept. In this concept, intelligent wells communicate with each other to achieve higher goals that are beyond each well's individual capability. They also form a memory of their actions, so that they can operate individually in situations where communication is damaged or lost.

[0076] In an embodiment, the system (301) includes an intelligent well, along with a downhole computing unit, a drive to store sensor data, a wireless transmitter, one or more flow control valves (FCVs) and sensors for measuring fluid properties/rates. The computing unit may be configured to perform data analysis and run optimization routines. In some embodiments, the computing unit may not perform reservoir simulation, which may reduce the processing demands on the computing unit.

[0077] In the system (301), a link may not exist between wells and a central SCADA (Supervisory Control and Data Acquisition) system. This may reduce the risk of losing a well-to-surface connection (both for transmitting data from well to central operation unit and transmitting control action back from the unit to the well). In addition, the method may not rely on a reservoir simulation model. Instead, the method may include running optimization algorithms on a data-driven model (either locally on each well, or globally on a combined first predictive model for the wells/group of wells), which may reduce reaction time.

[0078] FIG. 3.2 illustrates a schematic view of an intelligent well system (200), according to an embodiment. As shown, the system (200) may include at least one well (202), which may extend at least partially downward from the surface 204 into a subterranean formation (the well may also be deviated, horizontal, etc.). One or more downhole systems (215), e.g., strings, completions, etc., may be deployed into the well (202). For example, the downhole system (215) may include a computing unit (219), a hard disk (210), a transmitter (e.g., wireless) (221), one or more FCVs (e.g., FCV (216), FCV (217)), and at least one sensor (218) to measure flow rate and/or any other condition in the well (202). The computing unit (217) may include a data analysis module (222) and an optimization module (220). For example, the computing unit (219), data analysis module (222), and optimization module (220) may correspond to the computing unit A (223), data analyzer (227), and optimizer (228) depicted in FIG. 1.2 above. [0079] The well (202) may be in communication with one or more other wells of the well system (200). FIG. 3.3 illustrates an aerial view of an oilfield including the well (202) (i.e., well A) in addition to several other wells, which are indicated with letters B, C, E, and D. As shown, well A may communicate with its neighbors, wells C and B. Well C may communicate further with well E, and well D may not be in communication with this group of wells.

[0080] FIG. 3.4 illustrates a flowchart of a method for controlling an intelligent well system, such as the well system (200) described above, using swarm intelligence, according to an embodiment. The method shown in FIG. 3.4 may be executable by one or more computing units, which may, in some embodiments, be located within, above, near, or otherwise be maintained in association with a well. The computing unit may receive data from sensors communicable therewith, as at Block 302. The sensor data may represent flow rates and/or other conditions in the well. In some embodiments, the computing unit may also receive data from other wells, e.g., via wireless transmission, as at Block 304.

[0081] The computing unit may then build a first predictive model core using supervised, semi-supervised, or unsupervised machine learning algorithms, as at Block 306. The model may be updated by receiving new data, e.g., streaming the data in real-time, as at Block 308. An algorithm may be applied to the first predictive modeling core to modulate the FCVs, as at Block 310. Each well may function independently or in communication with others, honoring individual/group constraints. Results of each action on production or other performance indicators may then be transmitted to nearby wells and may be used by the computing systems associated therewith to update their respective models, as at Block 312. In this context, each well may contribute to the global swarm and combined actions of these wells result in better production performance. [0082] Embodiments of self-organizing swarm intelligent wells may be implemented on a computing system. Any combination of mobile, desktop, server, router, switch, embedded device, or other types of hardware may be used. For example, as shown in FIG. 4.1, the computing system (400) may include one or more computer processors (402), non-persistent storage (404) (e.g., volatile memory, such as random access memory (RAM), cache memory), persistent storage (406) (e.g., a hard disk, an optical drive such as a compact disk (CD) drive or digital versatile disk (DVD) drive, a flash memory, etc.), a communication interface (412) (e.g., Bluetooth interface, infrared interface, network interface, optical interface, etc.), and numerous other elements and functionalities.

[0083] The computer processor(s) (402) may be an integrated circuit for processing instructions. For example, the computer processor(s) may be one or more cores or micro-cores of a processor. The computing system (400) may also include one or more input devices (410), such as a touchscreen, keyboard, mouse, microphone, touchpad, electronic pen, or any other type of input device.

[0084] The communication interface (412) may include an integrated circuit for connecting the computing system (400) to a network (not shown) (e.g., a local area network (LAN), a wide area network (WAN) such as the Internet, mobile network, or any other type of network) and/or to another device, such as another computing device.

[0085] Further, the computing system (400) may include one or more output devices (408), such as a screen (e.g., a liquid crystal display (LCD), a plasma display, touchscreen, cathode ray tube (CRT) monitor, projector, or other display device), a printer, external storage, or any other output device. One or more of the output devices may be the same or different from the input device(s). The input and output device(s) may be locally or remotely connected to the computer processor(s) (402), non-persistent storage (404), and persistent storage (406). Many different types of computing systems exist, and the aforementioned input and output device(s) may take other forms.

[0086] Software instructions in the form of computer readable program code to perform embodiments may be stored, in whole or in part, temporarily or permanently, on a non-transitory computer readable medium such as a CD, DVD, storage device, a diskette, a tape, flash memory, physical memory, or any other computer readable storage medium. Specifically, the software instructions may correspond to computer readable program code that, when executed by a processor(s), is configured to perform one or more embodiments.

[0087] The computing system (400) in FIG. 4.1 may be connected to or be a part of a network. For example, as shown in FIG. 4.2, the network (420) may include multiple nodes (e.g., node X (422), node Y (424)). Each node may correspond to a computing system, such as the computing system shown in FIG. 4.1, or a group of nodes combined may correspond to the computing system shown in FIG. 4.1. By way of an example, embodiments may be implemented on a node of a distributed system that is connected to other nodes. By way of another example, embodiments may be implemented on a distributed computing system having multiple nodes, where each portion of an embodiment may be located on a different node within the distributed computing system. Further, one or more elements of the aforementioned computing system (400) may be located at a remote location and connected to the other elements over a network.

[0088] Although not shown in FIG. 4.2, the node may correspond to a blade in a server chassis that is connected to other nodes via a backplane. By way of another example, the node may correspond to a server in a data center. By way of another example, the node may correspond to a computer processor or micro- core of a computer processor with shared memory and/or resources. [0089] The nodes (e.g., node X (422), node Y (424)) in the network (420) may be configured to provide services for a client device (426). For example, the nodes may be part of a cloud computing system. The nodes may include functionality to receive requests from the client device (426) and transmit responses to the client device (426). The client device (426) may be a computing system, such as the computing system shown in FIG. 4.1. Further, the client device (426) may include and/or perform the entirety or a portion of one or more embodiments.

[0090] The computing system or group of computing systems described in FIG.

4.1 and 4.2 may include functionality to perform a variety of operations disclosed herein. For example, the computing system(s) may perform communication between processes on the same or different system. A variety of mechanisms, employing some form of active or passive communication, may facilitate the exchange of data between processes on the same device. Examples representative of these inter-process communications include, but are not limited to, the implementation of a file, a signal, a socket, a message queue, a pipeline, a semaphore, shared memory, message passing, and a memory-mapped file. Further details pertaining to a couple of these non-limiting examples are provided below.

[0091] Based on the client-server networking model, sockets may serve as interfaces or communication channel end-points enabling bidirectional data transfer between processes on the same device. Foremost, following the client- server networking model, a server process (e.g., a process that provides data) may create a first socket object. Next, the server process binds the first socket object, thereby associating the first socket object with a unique name and/or address. After creating and binding the first socket object, the server process then waits and listens for incoming connection requests from one or more client processes (e.g., processes that seek data). At this point, when a client process wishes to obtain data from a server process, the client process starts by creating a second socket object. The client process then proceeds to generate a connection request that includes at least the second socket object and the unique name and/or address associated with the first socket object. The client process then transmits the connection request to the server process. Depending on availability, the server process may accept the connection request, establishing a communication channel with the client process, or the server process, busy in handling other operations, may queue the connection request in a buffer until server process is ready. An established connection informs the client process that communications may commence. In response, the client process may generate a data request specifying the data that the client process wishes to obtain. The data request is subsequently transmitted to the server process. Upon receiving the data request, the server process analyzes the request and gathers the requested data. Finally, the server process then generates a reply including at least the requested data and transmits the reply to the client process. The data may be transferred, more commonly, as datagrams or a stream of characters (e.g., bytes).

Shared memory refers to the allocation of virtual memory space in order to substantiate a mechanism for which data may be communicated and/or accessed by multiple processes. In implementing shared memory, an initializing process first creates a shareable segment in persistent or non-persistent storage. Post creation, the initializing process then mounts the shareable segment, subsequently mapping the shareable segment into the address space associated with the initializing process. Following the mounting, the initializing process proceeds to identify and grant access permission to one or more authorized processes that may also write and read data to and from the shareable segment. Changes made to the data in the shareable segment by one process may immediately affect other processes, which are also linked to the shareable segment. Further, when one of the authorized processes accesses the shareable segment, the shareable segment maps to the address space of that authorized process. Often, no more than one authorized process may mount the shareable segment, other than the initializing process, at any given time.

[0093] Other techniques may be used to share data, such as the various data described in the present application, between processes without departing from the scope of self-organizing swarm intelligent wells. The processes may be part of the same or different application and may execute on the same or different computing system.

[0094] Rather than or in addition to sharing data between processes, the computing system performing one or more embodiments may include functionality to receive data from a user. For example, in one or more embodiments, a user may submit data via a graphical user interface (GUI) on the user device. Data may be submitted via the graphical user interface by a user selecting one or more graphical user interface widgets or inserting text and other data into graphical user interface widgets using a touchpad, a keyboard, a mouse, or any other input device. In response to selecting a particular item, information regarding the particular item may be obtained from persistent or non-persistent storage by the computer processor. Upon selection of the item by the user, the contents of the obtained data regarding the particular item may be displayed on the user device in response to the user's selection.

[0095] By way of another example, a request to obtain data regarding the particular item may be sent to a server operatively connected to the user device through a network. For example, the user may select a uniform resource locator (URL) link within a web client of the user device, thereby initiating a Hypertext Transfer Protocol (HTTP) or other protocol request being sent to the network host associated with the URL. In response to the request, the server may extract the data regarding the particular selected item and send the data to the device that initiated the request. Once the user device has received the data regarding the particular item, the contents of the received data regarding the particular item may be displayed on the user device in response to the user's selection. Further to the above example, the data received from the server after selecting the URL link may provide a web page in Hyper Text Markup Language (HTML) that may be rendered by the web client and displayed on the user device.

[0096] Once data is obtained, such as by using techniques described above or from storage, the computing system, in performing one or more embodiments, may extract one or more data items from the obtained data. For example, the extraction may be performed as follows by the computing system in FIG. 4.1. First, the organizing pattern (e.g., grammar, schema, layout) of the data is determined, which may be based on one or more of the following: position (e.g., bit or column position, Nth token in a data stream, etc.), attribute (where the attribute is associated with one or more values), or a hierarchical/tree structure (consisting of layers of nodes at different levels of detail— such as in nested packet headers or nested document sections). Then, the raw, unprocessed stream of data symbols is parsed, in the context of the organizing pattern, into a stream (or layered structure) of tokens (where each token may have an associated token "type").

[0097] Next, extraction criteria are used to extract one or more data items from the token stream or structure, where the extraction criteria are processed according to the organizing pattern to extract one or more tokens (or nodes from a layered structure). For position-based data, the token(s) at the position(s) identified by the extraction criteria are extracted. For attribute/value-based data, the token(s) and/or node(s) associated with the attribute(s) satisfying the extraction criteria are extracted. For hierarchical/layered data, the token(s) associated with the node(s) matching the extraction criteria are extracted. The extraction criteria may be as simple as an identifier string or may be a query presented to a structured data repository (where the data repository may be organized according to a database schema or data format, such as XML).

[0098] The extracted data may be used for further processing by the computing system. For example, the computing system of FIG. 4.1, while performing one or more embodiments, may perform data comparison. Data comparison may be used to compare two or more data values (e.g., A, B). For example, one or more embodiments may determine whether A > B, A = B, A != B, A < B, etc. The comparison may be performed by submitting A, B, and an opcode specifying an operation related to the comparison into an arithmetic logic unit (ALU) (i.e., circuitry that performs arithmetic and/or bitwise logical operations on the two data values). The ALU outputs the numerical result of the operation and/or one or more status flags related to the numerical result. For example, the status flags may indicate whether the numerical result is a positive number, a negative number, zero, etc. By selecting the proper opcode and then reading the numerical results and/or status flags, the comparison may be executed. For example, in order to determine if A > B, B may be subtracted from A (i.e., A - B), and the status flags may be read to determine if the result is positive (i.e., if A > B, then A - B > 0). In one or more embodiments, B may be considered a threshold, and A is deemed to satisfy the threshold if A = B or if A > B, as determined using the ALU. In one or more embodiments, A and B may be vectors, and comparing A with B involves comparing the first element of vector A with the first element of vector B, the second element of vector A with the second element of vector B, etc. In one or more embodiments, if A and B are strings, the binary values of the strings may be compared.

[0099] The computing system in FIG. 4.1 may implement and/or be connected to a data repository. For example, one type of data repository is a database. A database is a collection of information configured for ease of data retrieval, modification, re-organization, and deletion. Database Management System (DBMS) is a software application that provides an interface for users to define, create, query, update, or administer databases.

[00100] The user, or software application, may submit a statement or query into the DBMS. Then the DBMS interprets the statement. The statement may be a select statement to request information, update statement, create statement, delete statement, etc. Moreover, the statement may include parameters that specify data, or data container (database, table, record, column, view, etc.), identifier(s), conditions (comparison operators), functions (e.g. join, full join, count, average, etc.), sort (e.g. ascending, descending), or others. The DBMS may execute the statement. For example, the DBMS may access a memory buffer, a reference or index a file for read, write, deletion, or any combination thereof, for responding to the statement. The DBMS may load the data from persistent or non-persistent storage and perform computations to respond to the query. The DBMS may return the result(s) to the user or software application.

[00101] The computing system of FIG. 4.1 may include functionality to present raw and/or processed data, such as results of comparisons and other processing. For example, presenting data may be accomplished through various presenting methods. Specifically, data may be presented through a user interface provided by a computing device. The user interface may include a GUI that displays information on a display device, such as a computer monitor or a touchscreen on a handheld computer device. The GUI may include various GUI widgets that organize what data is shown as well as how data is presented to a user. Furthermore, the GUI may present data directly to the user, e.g., data presented as actual data values through text, or rendered by the computing device into a visual representation of the data, such as through visualizing a data model.

[00102] For example, a GUI may first obtain a notification from a software application requesting that a particular data object be presented within the GUI. Next, the GUI may determine a data object type associated with the particular data object, e.g., by obtaining data from a data attribute within the data object that identifies the data object type. Then, the GUI may determine any rules designated for displaying that data object type, e.g., rules specified by a software framework for a data object class or according to any local parameters defined by the GUI for presenting that data object type. Finally, the GUI may obtain data values from the particular data object and render a visual representation of the data values within a display device according to the designated rules for that data object type.

[00103] Data may also be presented through various audio methods. In particular, data may be rendered into an audio format and presented as sound through one or more speakers operably connected to a computing device.

[00104] Data may also be presented to a user through haptic methods. For example, haptic methods may include vibrations or other physical signals generated by the computing system. For example, data may be presented to a user using a vibration generated by a handheld computer device with a predefined duration and intensity of the vibration to communicate the data.

[00105] The above description of functions presents a few examples of functions performed by the computing system of FIG. 4.1 and the nodes and/or client device in FIG. 4.2. Other functions may also be performed using one or more embodiments of self-organizing swarm intelligent wells.

[00106] While one or more embodiments have been described with respect to a limited number of embodiments, those skilled in the art, having benefit of this disclosure, will appreciate that other embodiments may be devised which do not depart from the scope as disclosed herein. Accordingly, the scope should be limited by no more than the attached claims.

Claims

CLAIMS What is claimed is:

1. A method for performing a field operation of a field, comprising:

receiving, by a first computing unit associated with a first well in the field, first data from one or more first downhole sensors of the first well; building, using a machine learning algorithm, a first predictive model for the first well based at least on the first data;

determining, by the first computing unit based on an objective function, a first input value set of the first predictive model for achieving a target result of modulating a first control device in the first well;

generating, by the first computing unit, a first control signal based on the first input value set; and

modulating, using the first control signal, the first control device.

2. The method of claim 1, further comprising:

receiving, by the first computing unit, second data from a second computing unit associated with a second well in the field,

wherein the building the first predictive model for the first well is further based on the second data.

3. The method of claim 2, further comprising:

receiving a first updated value of the first data from the one or more first downhole sensors of the first well; and

receiving a second updated value of the second data from the second computing unit,

wherein the first input value set is constrained by the first updated value of the first data and the second updated value of the second data.

The method of claim 3, further comprising:

transmitting, by the first computing unit to the second computing unit, third data representing a first result of the modulating the first control device; modulating, by the second computing unit based on the third data and a second predictive model, a second control device in the second well;

transmitting, by the second computing unit to the first computing unit, a further updated value of the second data representing a second result of the modulating the second control device;

adjusting, by using the further updated value to substitute the second updated value of the second data, the first input value set to generated an adjusted first input value set; and

adjusting the first control signal based on the adjusted first input value set.

The method of claim 4, wherein the modulating the second control device comprises: determining, by the second computing unit and constrained by the third data, a second input value set of the second predictive model;

generating a second control signal based on the second input value set; and applying the second control signal to the second control device.

The method of claim 4, wherein the determining the first input value set comprises: selecting, during an iterative process, a trial input value set of the first predictive model, wherein the first updated value of the first data and the second updated value of the second data correspond to a portion of the trial input value set;

determining, during the iterative process, a value of the objective function using the first predictive model based on the trial input value set; and

in response to determining that a pre-determined criterion of the iterative process is satisfied based on the trial input value set, using the trial input value set as the first input value set and using the value of the objective function as the target result.

7. The method of claim 4, further comprising:

identifying one or more production indicators of the field operation corresponding to at least one selected from a group consisting of the objective function, the target result, and the second data.

8. A system for performing a field operation of a field, comprising:

one or more first downhole sensors and a first control device of a first well in the field; and

a first computing unit associated with the first well and comprising a data analysis module, an optimization module, and an optimization module, wherein the data analysis module is configured to:

receive first data from the one or more first downhole sensors of the first well;

build, using a machine learning algorithm, a first predictive model for the first well based at least on the first data; and

determine, by the first computing unit based on an objective function, a first input value set of the first predictive model for achieving a target result of modulating a first control device in the first well,

wherein the optimization module is configured to:

determine, based on an objective function, a first input value set of the first predictive model for achieving a target result of modulating the first control device, and

wherein the field task engine is configured to:

generate a first control signal based on the first input value set; and modulate, using the first control signal, the first control device.

9. The system of claim 8, further comprising:

a second computing unit associated with a second well in the field and configured to send second data to the first computing unit,

10. The system of claim 9, wherein the optimization module is further configured to: receive a first updated value of the first data from the one or more first downhole sensors of the first well; and

receive a second updated value of the second data from the second computing unit, wherein the first input value set is constrained by the first updated value of the first data and the second updated value of the second data.

11. The system of claim 10, further comprising:

a second control device in the second well,

wherein the second computing unit is further configured to:

receive, from the first computing unit, third data representing a first result of the modulating the first control device;

modulate, based on the third data and a second predictive model, the second control device in the second well; and

transmit, to the first computing unit, a further updated value of the second data representing a second result of the modulating the second control device,

wherein the optimization module is further configured to:

adjust, by using the further updated value to substitute the second updated value of the second data, the first input value set to generated an adjusted first input value set, and

wherein the data analysis module is further configured to:

adjust the first control signal based on the adjusted first input value set.

12. The system of claim 11, wherein the modulating the second control device comprises: determine, constrained by the third data, a second input value set of the second predictive model;

generate a second control signal based on the second input value set; and apply the second control signal to the second control device.

13. The system of claim 11, wherein the determining the first input value set comprises: select, during an iterative process, a trial input value set of the first predictive model, wherein the first updated value of the first data and the second updated value of the second data correspond to a portion of the trial input value set;

determine, during the iterative process, a value of the objective function using the first predictive model based on the trial input value set; and

in response to determining that a pre-determined criterion of the iterative process is satisfied based on the trial input value set, use the trial input value set as the first input value set and use the value of the objective function as the target result.

14. The system of claim 9, wherein the first computing unit comprises a wireless signal receiver configured to:

wirelessly receive the first data that is streamed from the one or more first downhole sensors in real time; and

wirelessly receive the second data that is streamed from the second well in real time.

15. A computer readable medium storing instructions to carry out the method according to any of claims 1-7.