Autonomous oilfield production integrated control system

Abstract

A method can include receiving workflow specifications for an operational workflow performed using equipment in a field to produce hydrocarbons; configuring a dynamic reservoir simulation system according to the workflow specifications; receiving, by the dynamic reservoir simulation system, field data from the equipment; responsive to receipt of the field data, updating a model representative of one or more hydrocarbon production related physical phenomena in the field to generate an updated model of the dynamic reservoir simulation system; generating model-based results using the updated model; assessing quality of the model-based results to generate one or more quality metrics; and outputting, based at least in part on the model-based results, a control action for the operational workflow and at least one of the one or more quality metrics.

Description

AUTONOMOUS OILFIELD PRODUCTION INTEGRATED CONTROL SYSTEMRELATED APPLICATIONS

[0001] This application claims priority to and the benefit of a US Provisional Application having Serial No. 63 / 453,917, filed 22 March 2023, which is incorporated by reference herein in its entirety.BACKGROUND

[0002] A reservoir can be a subsurface formation that can be characterized at least in part by its porosity and fluid permeability. As an example, a reservoir may be part of a basin such as a sedimentary basin. A basin can be a depression (e.g., caused by plate tectonic activity, subsidence, etc.) in which sediments accumulate. As an example, where hydrocarbon source rocks occur in combination with appropriate depth and duration of burial, a petroleum system may develop within a basin, which may form a reservoir that includes hydrocarbon fluids (e.g., oil, gas, etc.).

[0003] Oilfield exploration and production efforts generally include collecting data that represents a subsurface volume of interest, and then modeling the physical characteristics of the subsurface volume based on the data. There are many sources for such data, including seismic surveys and well logs. These data permit complex models to be built, which may depict the geology of the subsurface volume, fluid migration over time in the volumes, and other aspects. Because of the high complexity of the models, and even with modern computing resources, it can take hours or even days to build and simulate conditions. Thus, changes in physical characteristics of the subsurface volume and simulating different operating conditions can present substantial delays.

[0004] Refining and rebuilding models can be performed during an exploration and well planning, where substantial resources are staked on making accurate and precise determinations of where and how to drill a well. Moreover, the pace of advancement can be slow at such stage, and thus there is both time and benefit to updating and running the models.

[0005] At the production stage, the models can be helpful in determining operating parameters (e.g., choke positions, injection rates, etc.), but the delay andexpense incurred by running the models is frequently too high. Thus, operators tend to make rough estimations for the parameters, based largely on “back-of-the- envelope” calculations using a small sampling of the total available data. Further, these techniques may rely on input and output measurements, without analysis of the factors (e.g., geology) that lead to the output from the input, or the potential for these factors to change. Thus, for example, in a waterflooding context, operators may consider combinations of injection rates and production rates from injection and production wells, respectively, in a given field, and make determinations based on those measurements. Minimal consideration is given to the geology of the field, since accounting for the geology generally calls for an accurate model, and accurately modeling the geology and simulating the fluid flow tends to be too costly and slow to be performed with sufficient frequency (e.g., daily) to keep up with the acquisition of new data.SUMMARY

[0006] A method can include receiving workflow specifications for an operational workflow performed using equipment in a field to produce hydrocarbons; configuring a dynamic reservoir simulation system according to the workflow specifications; receiving, by the dynamic reservoir simulation system, field data from the equipment; responsive to receipt of the field data, updating a model representative of one or more hydrocarbon production related physical phenomena in the field to generate an updated model of the dynamic reservoir simulation system; generating model-based results using the updated model; assessing quality of the model-based results to generate one or more quality metrics; and outputting, based at least in part on the model-based results, a control action for the operational workflow and at least one of the one or more quality metrics. A system can include a processor; a memory accessible to the processor; processor-executable instructions stored in the memory and executable by the processor to instruct the system to: receive workflow specifications for an operational workflow performed using equipment in a field to produce hydrocarbons; configure the system according to the workflow specifications; receive field data from the equipment; responsive to receipt of the field data, update a model representative of one or more hydrocarbon production related physicalphenomena in the field to generate an updated model; generate model-based results using the updated model; assess quality of the model-based results to generate one or more quality metrics; and output, based at least in part on the model-based results, a control action for the operational workflow and at least one of the one or more quality metrics. One or more computer-readable media can include computer-executable instructions executable by a system to instruct the system to: receive workflow specifications for an operational workflow performed using equipment in a field to produce hydrocarbons; configure the system according to the workflow specifications; receive field data from the equipment; responsive to receipt of the field data, update a model representative of one or more hydrocarbon production related physical phenomena in the field to generate an updated model; generate model-based results using the updated model; assess quality of the model-based results to generate one or more quality metrics; and output, based at least in part on the model-based results, a control action for the operational workflow and at least one of the one or more quality metrics.

[0007] This summary is provided to introduce a selection of concepts that are further described below in the detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in limiting the scope of the claimed subject matter.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Features and advantages of the described implementations can be more readily understood by reference to the following description taken in conjunction with the accompanying drawings.

[0009] FIG. 1 illustrates an example system that includes various framework components associated with one or more geologic environments;

[0010] FIG. 2 illustrates examples of systems;

[0011] FIG. 3 illustrates an example of a system;

[0012] FIG. 4 illustrates an example of a system;

[0013] FIG. 5 illustrates an example of a system;

[0014] FIG. 6 illustrates an example of an architecture;

[0015] FIG. 7 illustrates an example of a system;

[0016] FIG. 8 illustrates an example of a graphical user interface;

[0017] FIG. 9 illustrates an example of a graphical user interface;

[0018] FIG. 10 illustrates an example of a graphical user interface;

[0019] FIG. 11 illustrates an example of a graphical user interface;

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

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

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

[0023] FIG. 15 illustrates an example of a graphical user interface;

[0024] FIG. 16 illustrates an example of a graphical user interface;

[0025] FIG. 17 illustrates an example of a graphical user interface;

[0026] FIG. 18 illustrates an example of a graphical user interface;

[0027] FIG. 19 illustrates an example of a method and an example of a system;

[0028] FIG. 20 illustrates an example of a system;

[0029] FIG. 21 illustrates an example of a system;

[0030] FIG. 22 illustrates an example of a system;

[0031] FIG. 23 illustrates an example of a system;

[0032] FIG. 24 illustrates an example of a system; and

[0033] FIG. 25 illustrates examples of computer and network equipment.DETAILED DESCRIPTION

[0034] This description is not to be taken in a limiting sense, but rather is made merely for the purpose of describing the general principles of the implementations. The scope of the described implementations should be ascertained with reference to the issued claims.

[0035] FIG. 1 shows an example of a system 100 that includes a workspace framework 110 that can provide for instantiation of, rendering of, interactions with, etc., a graphical user interface (GUI) 120. In the example of FIG. 1 , the GU1 120 can include graphical controls for computational frameworks (e.g., applications) 121 , projects 122, visualization 123, one or more other features 124, data access 125, and data storage 126.

[0036] In the example of FIG. 1 , the workspace framework 110 may be tailored to a particular geologic environment such as an example geologic environment 150.For example, the geologic environment 150 may include layers (e.g., stratification) that include a reservoir 151 and that may be intersected by a fault 153. As an example, the geologic environment 150 may be outfitted with 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 wellsite 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. 1 shows a satellite in communication with the network 155 that may be configured for communications, noting that the satellite may additionally or alternatively include circuitry for imagery (e.g., spatial, spectral, temporal, radiometric, etc.).

[0037] FIG. 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.

[0038] In the example of FIG. 1 , the GUI 120 shows some examples of computational frameworks, including the DRILLPLAN, PETREL, TECHLOG, PETROMOD, ECLIPSE, INTERSECT, SYMMETRY and PIPESIM frameworks, SLB, Houston, Texas).

[0039] The DRILLPLAN framework provides for digital well construction planning and includes features for automation of repetitive tasks and validationworkflows, enabling improved quality drilling programs (e.g., digital drilling plans, etc.) to be produced quickly with assured coherency.

[0040] The PETREL framework can be part of the DELFI cognitive E&P environment (SLB, Houston, Texas) for utilization in geosciences and geoengineering, for example, to analyze subsurface data from exploration to production of fluid from a reservoir.

[0041] The TECHLOG framework can handle and process field and laboratory data for a variety of geologic environments (e.g., deepwater exploration, shale, etc.). The TECHLOG framework can structure wellbore data for analyses, planning, etc.

[0042] The PETROMOD framework provides petroleum systems modeling capabilities that can combine one or more of seismic, well, and geological information to model the evolution of a sedimentary basin. The PETROMOD framework can predict if, and how, a reservoir has been charged with hydrocarbons, including the source and timing of hydrocarbon generation, migration routes, quantities, and hydrocarbon type in the subsurface or at surface conditions.

[0043] The ECLIPSE framework provides a reservoir simulator (e.g., as a computational framework) with numerical solutions for fast and accurate prediction of dynamic behavior for various types of reservoirs and development schemes.

[0044] The INTERSECT framework provides a high-resolution reservoir simulator for simulation of detailed geological features and quantification of uncertainties, for example, by creating accurate production scenarios and, with the integration of precise models of the surface facilities and field operations, the INTERSECT framework can produce reliable results, which may be continuously updated by real-time data exchanges (e.g., from one or more types of data acquisition equipment in the field that can acquire data during one or more types of field operations, etc.). The INTERSECT framework can provide completion configurations for complex wells where such configurations can be built in the field, can provide detailed chemical-enhanced-oil-recovery (EOR) formulations where such formulations can be implemented in the field, can analyze application of steam injection and other thermal EOR techniques for implementation in the field, advanced production controls in terms of reservoir coupling and flexible field management, and flexibility to script customized solutions for improved modeling and field management control. TheINTERSECT framework, as with the other example frameworks, may be utilized as part of the DELFI cognitive E&P environment, for example, for rapid simulation of multiple concurrent cases. For example, a workflow may utilize one or more of the DELFI on demand reservoir simulation features.

[0045] The SYMMETRY framework provides for modeling process workflows, including integrating facilities, process units with pipelines, networks and flare, safety systems models, while ensuring consistent thermodynamics and fluid characterization across a system. The SYMMETRY framework includes components for optimizing processes in upstream, midstream and downstream sectors, maximizing profits and minimizing CAPEX. The SYMMETRY framework provides for oil pseudo-component characterization techniques. For example, a paraffin, isoparaffin, olefin, naphthene, aromatic (FIONA) based fluid characterization uses chemical family structures to enable accurate physical property estimation in one or more of blending, separation, and reactive systems to be more accurately simulated. Such an approach helps to ensure consistent thermodynamics and component tracking across a system. The SYMMETRY framework provides a simulation engine for performing various simulations of physical phenomena. Various frameworks can share compositional data, for example, consider sharing of data between the PIPESIM framework steadystate multiphase flow simulator and the SYMMETRY process framework. Compositional models can be integrated to evaluate and maintain fluid description fidelity and behavior, which can extend beyond capabilities of black-oil simulations. The SYMMETRY framework includes components that provide for assessments that align with the United Nations Sustainable Development Goals 12 and 13, that can optimize drilling CO2 footprint, and that can provide for emissions reductions. For example, the SYMMETRY framework can establish a baseline performance and evaluate different options for reducing emissions, including reduced routine flaring, alternatives to flaring, fuel gas minimization through energy management, and feedstock management (hydrogen or bio-feed blending). As to electrification, various scenarios can be modeled to, for example, select or optimize energy sources suitable for electrification of one or more processes, pieces of equipment, etc. As an example, simulations can be performed that aim to reduce energy consumption, optionally while considering energy sources (e.g., on-site from produced fluids, from solar, from wind,from geothermal, etc.). As an example, a workflow can include applying total site energy management models to support reduction in energy consumption in facilities at one or more scales, for example, from rotating equipment to various plants. The SYMMETRY framework can provide for simulations that aim to reduce fuel consumption, generate power from waste heat (e.g., energy integration), and optimizing applications of renewable power. The SYMMETRY framework provides for modeling of natural gas liquid (NGL) recovery optimization, sulfur plants, liquefied natural gas (LNG) train mixed refrigerant optimization, multisided heat exchangers, compressor train optimization, acid gas removal with amines, membrane separation, etc. Such features allow for modeling complex processes more effectively, predicting performance for proactive controls, and accelerating performance while maintaining trust in rigorous modeling. As to separators, the SYMMETRY framework can enhance separation modeling capabilities; noting that performance of a separator can be one of the largest factors in overall operational performance of an asset. Components include steady state and dynamics engines, which allow for evaluation and understanding of impacts on an overall system. Separation process analysis can aim perform more accurate rating and troubleshooting of separation using steady state and / or dynamics simulations and gain a better understanding of how transient behaviors can impact a separation process.

[0046] The PIPESIM simulator includes solvers that may provide simulation results such as, for example, multiphase flow results (e.g., from a reservoir to a wellhead and beyond, etc.), flowline and surface facility performance, etc. The PIPESIM simulator may be integrated, for example, with the AVOCET production operations framework (SLB, Houston Texas). 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 steam-assisted gravity drainage (SAGD), etc.). As an example, the PIPESIM simulator may be an optimizer that can optimize one or more operational scenarios at least in part via simulation of physical phenomena.

[0047] The aforementioned DELFI environment provides various features for workflows as to subsurface analysis, planning, construction and production, for example, as illustrated in the workspace framework 110. Such an environment may be referred to as a process operations environment that can include a variety offrameworks (e.g., applications, etc.). As shown in FIG. 1 , outputs from the workspace framework 1 10 can be utilized for directing, controlling, etc., one or more processes in the geologic environment 150 and, feedback 160, can be received via one or more interfaces in one or more forms (e.g., acquired data as to operational conditions, equipment conditions, environment conditions, etc.).

[0048] In the example of FIG. 1 , the visualization features 123 may be implemented via the workspace framework 110, for example, to perform tasks as associated with one or more of subsurface regions, planning operations, constructing wells and / or surface fluid networks, and producing from a reservoir.

[0049] As an example, a visualization process can implement one or more of various features that can be suitable for one or more web applications. For example, a template may involve use of the JAVASCRIPT object notation format (JSON) and / or one or more other languages / formats. As an example, a framework may include one or more converters. For example, consider a JSON to PYTHON converter and / or a PYTHON to JSON converter. Such an approach can provide for compatibility of devices, frameworks, etc., with respect to one or more sets of instructions.

[0050] As an example, visualization features can provide for visualization of various earth models, properties, etc., in one or more dimensions. As an example, visualization features can provide for rendering of information in multiple dimensions, which may optionally include multiple resolution rendering. In such an example, information being rendered may be associated with one or more frameworks and / or one or more data stores. As an example, visualization features may include one or more control features for control of equipment, which can include, for example, field equipment that can perform one or more field operations. As an example, a workflow may utilize one or more frameworks to generate information that can be utilized to control one or more types of field equipment (e.g., drilling equipment, wireline equipment, fracturing equipment, etc.).

[0051] As to a reservoir model that may be suitable for utilization by a simulator, consider acquisition of seismic data as acquired via reflection seismology, which finds use in geophysics, for example, to estimate properties of subsurface formations. As an example, reflection seismology may provide seismic data representing waves of elastic energy (e.g., as transmitted by P-waves and S-waves, in a frequency range ofapproximately 1 Hz to approximately 100 Hz). Seismic data may be processed and interpreted, for example, to understand better composition, fluid content, extent and geometry of subsurface rocks. Such interpretation results can be utilized to plan, simulate, perform, etc., one or more operations for production of fluid from a reservoir (e.g., reservoir rock, etc.).

[0052] Field acquisition equipment may be utilized to acquire seismic data, which may be in the form of traces where a trace can include values organized with respect to time and / or depth (e.g., consider 1 D, 2D, 3D or 4D seismic data). For example, consider acquisition equipment that acquires digital samples at a rate of one sample per approximately 4 ms. Given a speed of sound in a medium or media, a sample rate may be converted to an approximate distance. For example, the speed of sound in rock may be on the order of around 5 km per second. Thus, a sample time spacing of approximately 4 ms would correspond to a sample “depth” spacing of about 10 meters (e.g., assuming a path length from source to boundary and boundary to sensor). As an example, a trace may be about 4 seconds in duration; thus, for a sampling rate of one sample at about 4 ms intervals, such a trace would include about 1000 samples where latter acquired samples correspond to deeper reflection boundaries. If the 4 second trace duration of the foregoing example is divided by two (e.g., to account for reflection), for a vertically aligned source and sensor, a deepest boundary depth may be estimated to be about 10 km (e.g., assuming a speed of sound of about 5 km per second).

[0053] As an example, a model may be a simulated version of a geologic environment. As an example, a simulator may include features for simulating physical phenomena in a geologic environment based at least in part on a model or models. A simulator, such as a reservoir simulator, can simulate fluid flow in a geologic environment based at least in part on a model that can be generated via a framework that receives seismic data. A simulator can be a computerized system (e.g., a computing system) that can execute instructions using one or more processors to solve a system of equations that describe physical phenomena subject to various constraints. In such an example, the system of equations may be spatially defined (e.g., numerically discretized) according to a spatial model that that includes layers of rock, geobodies, etc., that have corresponding positions that can be based oninterpretation of seismic and / or other data. A spatial model may be a cell-based model where cells are defined by a grid (e.g., a mesh). A cell in a cell-based model can represent a physical area or volume in a geologic environment where the cell can be assigned physical properties (e.g., permeability, fluid properties, etc.) that may be germane to one or more physical phenomena (e.g., fluid volume, fluid flow, pressure, etc.). A reservoir simulation model can be a spatial model that may be cell-based.

[0054] A simulator can be utilized to simulate the exploitation of a real reservoir, for example, to examine different productions scenarios to find an optimal one before production or further production occurs. A reservoir simulator does not provide an exact replica of flow in and production from a reservoir at least in part because the description of the reservoir and the boundary conditions for the equations for flow in a porous rock are generally known with an amount of uncertainty. Certain types of physical phenomena occur at a spatial scale that can be relatively small compared to size of a field. A balance can be struck between model scale and computational resources that results in model cell sizes being of the order of meters; rather than a lesser size (e.g., a level of detail of pores). A modeling and simulation workflow for multiphase flow in porous media (e.g., reservoir rock, etc.) can include generalizing real micro-scale data from macro scale observations (e.g., seismic data and well data) and upscaling to a manageable scale and problem size. Uncertainties can exist in input data and solution procedure such that simulation results too are to some extent uncertain. A process known as history matching can involve comparing simulation results to actual field data acquired during production of fluid from a field. Information gleaned from history matching, can provide for adjustments to a model, data, etc., which can help to increase accuracy of simulation.

[0055] As an example, a simulator may utilize various types of constructs, which may be referred to as entities. Entities may include earth entities or geological objects such as wells, surfaces, reservoirs, etc. Entities can include virtual representations of actual physical entities that may be reconstructed for purposes of simulation. Entities may include entities based on data acquired via sensing, observation, etc. (e.g., consider entities based at least in part on seismic data and / or other information). As an example, 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 porosityproperty, etc.). Such properties may represent one or more measurements (e.g., acquired data), calculations, etc.

[0056] As an example, a simulator may utilize an object-based software framework, which may include entities based on pre-defined classes to facilitate modeling and simulation. As an example, an object class can encapsulate reusable code and associated data structures. Object classes can be used to instantiate object instances for use by a program, script, etc. For example, borehole classes may define objects for representing boreholes based on well data. A model of a basin, a reservoir, etc. may include one or more boreholes where a borehole may be, for example, for measurements, injection, production, etc. As an example, a borehole may be a wellbore of a well, which may be a completed well (e.g., for production of a resource from a reservoir, for injection of material, etc.).

[0057] While several simulators are illustrated in the example of FIG. 1 , one or more other simulators may be utilized, additionally or alternatively. For example, consider the VISAGE geomechanics simulator (SLB, Houston Texas). The VISAGE simulator includes finite element numerical solvers that may provide simulation results such as, for example, results as to compaction and subsidence of a geologic environment, well and completion integrity in a geologic environment, cap-rock and fault-seal integrity in a geologic environment, fracture behavior in a geologic environment, thermal recovery in a geologic environment, CO2 disposal, etc. The MANGROVE simulator (SLB, Houston, Texas) provides for optimization of stimulation design (e.g., stimulation treatment operations such as hydraulic fracturing) in a reservoir-centric environment. The MANGROVE framework can combine scientific and experimental work to predict geomechanical propagation of hydraulic fractures, reactivation of natural fractures, etc., along with production forecasts within 3D reservoir models (e.g., production from a drainage area of a reservoir where fluid moves via one or more types of fractures to a well and / or from a well). The MANGROVE framework can provide results pertaining to heterogeneous interactions between hydraulic and natural fracture networks, which may assist with optimization of the number and location of fracture treatment stages (e.g., stimulation treatment(s)), for example, to increased perforation efficiency and recovery.

[0058] 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 (e.g., with respect to one or more geologic environments, etc.). Such a framework may be considered an application (e.g., executable using one or more devices) and may be considered a data-driven application (e.g., where data is input for purposes of modeling, simulating, etc.).

[0059] As mentioned, a framework may be implemented within or in a manner operatively coupled to the DELFI cognitive exploration and production (E&P) environment (SLB, Houston, Texas), which is a secure, cognitive, cloud-based collaborative environment that integrates data and workflows with digital technologies, such as artificial intelligence and machine learning. As an example, such an environment can provide for operations that involve one or more frameworks. The DELFI environment may be referred to as the DELFI framework, which may be a framework of frameworks. As an example, the DELFI framework can include various other frameworks, which can include, for example, one or more types of models (e.g., simulation models, etc.).

[0060] As an example, data can include geochemical data. For example, consider data acquired using X-ray fluorescence (XRF) technology, Fourier transform infrared spectroscopy (FTIR) technology and / or wireline geochemical technology.

[0061] As an example, one or more probes may be deployed in a bore via a wireline or wirelines. As an example, a probe may emit energy and receive energy where such energy may be analyzed to help determine mineral composition of rock surrounding a bore. As an example, nuclear magnetic resonance may be implemented (e.g., via a wireline, downhole NMR probe, etc.), for example, to acquire data as to nuclear magnetic properties of elements in a formation (e.g., hydrogen, carbon, phosphorous, etc.).

[0062] As an example, lithology scanning technology may be employed to acquire and analyze data. For example, consider the LITHO SCANNER technology marketed by SLB (Houston, Texas). As an example, a LITHO SCANNER tool may be a gamma ray spectroscopy tool.

[0063] As an example, a tool may be positioned to acquire information in a portion of a borehole. Analysis of such information may reveal vugs, dissolution planes (e.g., dissolution along bedding planes), stress-related features, dip events, etc. As an example, a tool may acquire information that may help to characterize a fractured reservoir, optionally where fractures may be natural and / or artificial (e.g., hydraulic fractures). Such information may assist with completions, stimulation treatment, etc. As an example, information acquired by a tool may be analyzed using a framework such as the aforementioned TECHLOG framework.

[0064] As an example, a workflow may utilize one or more types of data for one or more processes (e.g., stratigraphic modeling, basin modeling, completion designs, drilling, production, injection, etc.). As an example, one or more tools may provide data that can be used in a workflow or workflows that may implement one or more frameworks (e.g., PETREL, TECHLOG, PETROMOD, ECLIPSE, SYMMETRY, etc.).

[0065] FIG. 2 shows an example of a geologic environment 210 that includes reservoirs 211 -1 and 211-2, which may be faulted by faults 212-1 and 212-2, an example of a network of equipment 230, an enlarged view of a portion of the network of equipment 230, referred to as network 240, and an example of a system 250. FIG. 2 shows some examples of offshore equipment 214 for oil and gas operations related to the reservoir 211-2 and onshore equipment 216 for oil and gas operations related to the reservoir 211-1.

[0066] In the example of FIG. 2, the various equipment 214 and 216 can include drilling equipment, wireline equipment, production equipment, etc. For example, consider the equipment 214 as including a drilling rig that can drill into a formation to reach a reservoir target where a well can be completed for production of hydrocarbons. In such an example, one or more features of the system 100 of FIG. 1 may be utilized. For example, consider utilizing a drilling or well plan framework, a drilling execution framework, etc., to plan, execute, etc., one or more drilling operations.

[0067] In FIG. 2, the network 240 can be an example of a relatively small production system network. As shown, the network 240 forms somewhat of a tree like structure where flowlines represent branches (e.g., segments) and junctions represent nodes. As shown in FIG. 2, the network 240 provides for transportation of oil and gas fluids from well locations along flowlines interconnected at junctions with final delivery at a central processing facility.

[0068] In the example of FIG. 2, various portions of the network 240 may include conduit. For example, consider a perspective view of a geologic environment that includes two conduits which may be a conduit to Mani and a conduit to Man3 in the network 240.

[0069] As shown in FIG. 2, the example system 250 includes one or more information storage devices 252, one or more computers 254, one or more networks 260 and instructions 270 (e.g., organized as one or more sets of instructions). As to the one or more computers 254, each computer may include one or more processors (e.g., or processing cores) 256 and a memory 258 for storing the instructions 270 (e.g., one or more sets of instructions), for example, executable by at least one of the one or more processors. As an example, a computer may include one or more network interfaces (e.g., wired or wireless), one or more graphics cards, a display interface (e.g., wired or wireless), etc. As an example, imagery such as surface imagery (e.g., satellite, geological, geophysical, etc.) may be stored, processed, communicated, etc. As an example, data may include SAR data, GPS data, etc. and may be stored, for example, in one or more of the storage devices 252. As an example, information that may be stored in one or more of the storage devices 252 may include information about equipment, location of equipment, orientation of equipment, fluid characteristics, etc.

[0070] As an example, the instructions 270 can include instructions (e.g., stored in the memory 258) executable by at least one of the one or more processors 256 to instruct the system 250 to perform various actions. As an example, the system 250 may be configured such that the instructions 270 provide for establishing a framework, for example, that can perform network modeling (see, e.g., the PIPESIM framework of the example of FIG. 1 , etc.). As an example, one or more methods, techniques, etc.may be performed using one or more sets of instructions, which may be, for example, the instructions 270 of FIG. 2.

[0071] FIG. 3 shows a schematic view of an example of a portion of a geologic environment 301 that can include various types of equipment. As shown in FIG. 3, the environment 301 can include a wellsite 302 and a fluid network 344. In the example of FIG. 3, the wellsite 302 includes a wellbore 306 extending into earth as completed and prepared for production of fluid from a reservoir 311 (e.g., one of the reservoirs 311-1 or 311 -2).

[0072] In the example of FIG. 3, wellbore production equipment 364 extends from a wellhead 366 of the wellsite 302 and to the reservoir 311 to draw fluid to the surface. As shown, the wellsite 302 is operatively connected to the fluid network 344 via a transport line 361. As indicated by various arrows, fluid can flow from the reservoir 311 , through the wellbore 306 and onto the fluid network 344. Fluid can then flow from the fluid network 344, for example, to one or more fluid processing facilities.

[0073] In the example of FIG. 3, sensors (S) are located, for example, to monitor various parameters during operations. The sensors (S) may measure, for example, pressure, temperature, flowrate, composition, and other parameters of the reservoir, wellbore, gathering network, process facilities and / or other portions of an operation. As an example, the sensors (S) may be operatively connected to a surface unit (e.g., to instruct the sensors to acquire data, to collect data from the sensors, etc.).

[0074] In the example of FIG. 3, a surface unit can include computer facilities, such as a memory device, a controller, one or more processors, and a display unit (e.g., for managing data, visualizing results of an analysis, etc.). As an example, data may be collected in the memory device and processed by the processor(s) (e.g., for analysis, etc.). As an example, data may be collected from the sensors (S) and / or by one or more other sources. For example, data may be supplemented by historical data collected from other operations, user inputs, etc. As an example, analyzed data may be used to in a decision-making process.

[0075] As an example, a transceiver may be provided to allow communications between a surface unit and one or more pieces of equipment in the environment 301 . For example, a controller may be used to actuate mechanisms in the environment 301 via the transceiver, optionally based on one or more decisions of a decision-makingprocess. In such a manner, equipment in the environment 301 may be selectively adjusted based at least in part on collected data. Such adjustments may be made, for example, automatically based on computer protocol, manually by an operator or both. As an example, one or more well plans may be adjusted (e.g., to select optimum operating conditions, to avoid problems, etc.).

[0076] To facilitate data analyses, one or more simulators may be implemented (e.g., optionally via the surface unit or other unit, system, etc.). As an example, data fed into one or more simulators may be historical data, real time data or combinations thereof. As an example, simulation through one or more simulators may be repeated or adjusted based on the data received.

[0077] In the example of FIG. 3, simulators can include a reservoir simulator 328, a wellbore simulator 330, a surface network simulator 332, a process simulator 334 and an economics simulator 336. As an example, the reservoir simulator 328 may be configured to solve for hydrocarbon flow rate through a reservoir and into one or more wellbores. As an example, the wellbore simulator 330 and surface network simulator 332 may be configured to solve for hydrocarbon flow rate through a wellbore and a surface gathering network of pipelines. As to the process simulator 334, it may be configured to model a processing plant where fluid containing hydrocarbons is separated into its constituent components (e.g., methane, ethane, propane, etc.), for example, and prepared for further distribution (e.g., transport via road, rail, pipe, etc.) and optionally sale. As an example, the economics simulator 336 may be configured to model costs associated with at least part of an operation. For example, consider ME RAK framework (SLB, Houston, Texas), which may provide for economic analyses.

[0078] As an example, a system can include and / or be operatively coupled to one or more of the simulators 328, 330, 332, 334 and 336 of FIG. 3. As an example, such simulators may be associated with frameworks and / or may be considered tools (see, e.g., the system 100 of FIG. 1 , etc.). Various pieces of equipment in the example geologic environment 301 of FIG. 3 may be operatively coupled to one or more systems, one or more frameworks, etc. As an example, one or more of the sensors (S) may be operatively coupled to one or more networks (e.g., wired and / or wireless) for transmission of data, which, as explained, may include data indicative of production. As shown, a sensor (S) may be utilized for acquisition of downhole dataand / or surface data, which can include data relevant to production (e.g., flow rate, temperature, pressure, composition, etc.). Such data may be utilized in a system such as, for example, the system 100 of FIG. 1 for operational decision making, etc.

[0079] While various examples of field equipment are illustrated for hydrocarbon related production operations, as explained, field equipment may be for one or more other types of operations where such field equipment can acquire data (e.g., field equipment data) that can be utilized for operation decision making and / or one or more other purposes. As to wind energy production equipment, data can include meteorological data associated with a site or sites, turbine blade data, turbine performance data, orientation control data, energy conversion data, etc. As to solar energy production equipment, data can include meteorological data associated with a site or sites, solar cell data, solar panel performance data, orientation control data, energy conversion data, etc.

[0080] As explained, field equipment data may be suitable for use with one or more frameworks, one or more workflows, etc. Uses of field equipment data can involve transfers such as, for example, inter-framework transfers where one or more types of data related issues may arise due to formatting, unit conversions, coordinate reference system (CRS) conversions, etc. Use of field equipment data can be enhanced through automated or semi-automated processes that can perform tasks such as identifying data (e.g., data types, etc.) and / or assessing quality of data.

[0081] FIG. 4 shows an example of a wellsite system 400, specifically, FIG. 4 shows the wellsite system 400 in an approximate side view and an approximate plan view along with a block diagram of a system 470.

[0082] In the example of FIG. 4, the wellsite system 400 can include a cabin 410, a rotary table 422, drawworks 424, a mast 426 (e.g., optionally carrying a top drive, etc.), mud tanks 430 (e.g., with one or more pumps, one or more shakers, etc.), one or more pump buildings 440, a boiler building 442, an HPU building 444 (e.g., with a rig fuel tank, etc.), a combination building 448 (e.g., with one or more generators, etc.), pipe tubs 462, a catwalk 464, a flare 468, etc. Such equipment can include one or more associated functions and / or one or more associated operational risks, which may be risks as to time, resources, and / or humans.

[0083] As shown in the example of FIG. 4, the wellsite system 400 can include a system 470 that includes one or more processors 472, a memory 474 operatively coupled to at least one of the one or more processors 472, instructions 476 that can be, for example, stored in the memory 474, and one or more interfaces 478. As an example, the system 470 can include one or more processor-readable media that include processor-executable instructions executable by at least one of the one or more processors 472 to cause the system 470 to control one or more aspects of the wellsite system 400. In such an example, the memory 474 can be or include the one or more processor-readable media where the processor-executable instructions can be or include instructions. As an example, a processor-readable medium can be a computer-readable storage medium that is not a signal and that is not a carrier wave.

[0084] FIG. 4 also shows a battery 480 that may be operatively coupled to the system 470, for example, to power the system 470. As an example, the battery 480 may be a back-up battery that operates when another power supply is unavailable for powering the system 470. As an example, the battery 480 may be operatively coupled to a network, which may be a cloud network. As an example, the battery 480 can include smart battery circuitry and may be operatively coupled to one or more pieces of equipment via a SMBus or other type of bus.

[0085] In the example of FIG. 4, services 490 are shown as being available, for example, via a cloud platform. Such services can include data services 492, query services 494 and drilling services 496. As an example, the services 490 may be part of a system such as the system 300 of FIG. 3.

[0086] As an example, the system 470 may be utilized to generate one or more rate of penetration drilling parameter values, which may, for example, be utilized to control one or more drilling operations.

[0087] FIG. 5 shows an example of a system 500 that can include and / or be operatively coupled to one or more frameworks, which may be hosted by an environment such as, for example, the DELFI environment. In the example of FIG. 5, the system 500 receives input 510 (e.g., remote monitoring) and can generate output 590 (e.g., remote control instructions) through use of components in various layers for data 520, services 540 and visualization and interactions 560.

[0088] As shown, the data layer 520 can include components for production data storage and model data storage; the services layer 540 can include components for automated model updates, model confidence analysis, forecasts and optimizations, recommendation management and model proxy generation and management; and the visualization and interactions layer 560 can include components for subsurface informed surveillance, subsurface drive operations advice, and automated control.

[0089] The system 500 can automate various processes that tend to be disparate and / or performed manually. For example, while an engine can generate power, to harness the power for a purpose, that engine can be fit into a vehicle. In a vehicle, that engine can be part of an interconnected machine where various components operate harmoniously to allow a driver to drive the vehicle from point A to point B. Today, a reservoir simulator may be considered one of a number of a disparate frameworks where the reservoir simulator is operated discretely and manually. For example, a reservoir engineer may be assigned a reservoir simulation task in a workflow that is performed by a team. The workflow may depend on completion of the reservoir simulation task before other members of the team can proceed with their respective tasks of the workflow. In such an example, the reservoir simulation task may be a rate limiting step, as a reservoir simulation may take days to execute; noting that multiple reservoir simulations may be required and, in some instances, issues such as a lack of convergence may arise (e.g., where an iterative reservoir simulation does not converge to a solution or a globally optimal solution).

[0090] In the system 500 of FIG. 5, a reservoir simulator may be operated in an automated manner, optionally along with one or more proxy models (e g., lighter weight computational models that can execute in less time using fewer resources than a reservoir simulator). Such an approach links the reservoir simulator to associated machinery to perform various workflows, which can make reservoir simulation more automated (e.g., optionally fully automated) and reduce demand for manual interactions.

[0091] Continuing on from the vehicle example, consider an autonomous vehicle that can update itself, call for its own maintenance, and even drive from point A to point B with minimal to no manual interactions. In the example of FIG. 5, the system 500 can similarly operate in various autonomous modes, which can, forexample, provide for automated model updates based on data received from one or more sources (e.g., one or more wells in a field, one or more wells in one or more other fields, etc.). Such an approach can provide for automated proxy model generation and assessments of both reservoir simulation models and their results and proxy models and their results. Such assessments can provide a basis for automated decision making and issuance of control instructions to field equipment and / or for issuance of notifications for human oversight and / or human intervention.

[0092] As explained, the system 500 of FIG. 5 can receive field data as part of the input 510 and generate remote control instructions as part of the output 590 where such actions can be fully automated or at least semi-automated. As explained, to further expedite control, one or more proxy models can be generated, assessed and utilized, which may be executable in considerably less time than a reservoir simulation model for a field with multiple wells.

[0093] For an oil and gas producing asset (e.g., a reservoir or reservoirs in a field), an operational surveillance team can be responsible for making decisions on a daily to weekly basis about how to operate wells and related equipment, such as pump and chokes, to meet or exceed the production targets. Most of these decisions rely on an understanding of the subsurface flow and communication between the wells. This tends to be the case regardless of type of recovery mechanism or mechanism implemented (e.g., consider enhanced oil recovery (EOR), etc.). A reservoir simulation model tends to be the best-suited tool upon which to base such decisions because it can encapsulate acquired subsurface data along with interpretations and understanding of the subsurface modelling teams. As explained, the system 500 of FIG. 5 can provide for one or more closed-loop modes of operation that provide for subsurface-driven operational decisions for a hydrocarbon asset (e.g., a reservoir or reservoirs in a field).

[0094] As an example, a system can include components for automated production update in subsurface models; continuous assessment of forecast reliability with a model confidence advisor; operational optimization with fit-for-purpose optimizers; physics-based and / or machine learning-based smart proxy models for workflow acceleration; and decision advisor dashboards to translate subsurface insights into actions.

[0095] As to some implementation examples, consider one or more of an oilfield operations team that receives advice on how to operate wells in terms of how much to inject and how much to produce from individual wells; an oilfield operations team that receives advice on wells which are good candidates for workovers; and an oilfield operations team that receives advice on new data that can be acquired (e.g., well tests, formation logs, production logs) to improve the quality of decisions.

[0096] In the system 500, decisions may be recommended with consideration to field operating objectives and field constraints, such as, for example: annual target oil and / or gas production rates and volumes; equipment constraints such as fluid handling capacities and safe operating limits; and economic constraints such as budget available for workovers and data acquisition. As explained the system 500 can provide for automated updates of one or more subsurface models (e.g., reservoir simulation models, proxy models, etc.) with real-time data.

[0097] As to some examples of input, consider one or more of oil field measured data; real-time, high-frequency measurements streamed from sensors in the field to cloud-based production data storage; production and / or injection rates; well pressures; uptime fractions; sporadic measurements maintained in one or more production data stores; pressure transient tests; downhole production / injection logging; well workover data maintained in production data store; change of well equipment (tubing, pumps, valves / chokes); hydraulic fracturing, acid stimulation; new perforations; water / gas shutoff; and one or more dynamic reservoir simulation models stored in a dynamic model data store.

[0098] As an example, the system 500 can provide one or more graphical user interfaces (GUIs) that can allow for setup of one or more workflows in one or more operational modes. As an example, a user can setup an updater process through a web page as a GUI; define a source of production data; define a source of dynamic reservoir model data; define a schedule at which a process or processes are to be executed; call for implementation of a scheduler that triggers one or more processes in one or more containers in a cloud platform (e.g., AZURE, GOOGLE, AWS, etc.). In such an approach, an updater can automatically retrieve new data (e.g., compared to previous execution) from the production data source at the right aggregation level, for example, using particular APIs and / or one or more other access technologies and / ortechniques. In such an approach, the updater can retrieve the dynamic simulation model from a model data store, for example, using one or more APIs, where the updater incorporates the new data into the dynamic simulation model. In such an example, the updater can execute an updated dynamic simulation model, for example, using a restart mechanism such that an updated portion or portions of a simulation timeline may be executed (e.g., to expedite delivery of pertinent results). In such an example, the updater can operate to push the updated dynamic simulation model and its results back to a model data store to create a new revision / version of the dynamic simulation model; noting that such an approach may be applied to and / or otherwise involve one or more proxy model related actions. For example, consider triggering an update to a proxy model based on an update to a dynamic simulation model.

[0099] As an example, the system 500 can update and call for utilization of one or more of various models that may individually and / or collectively be a digital twin of one or more parts of an asset. For example, a reservoir model can be a dynamic reservoir model that changes dynamically with respect to changes in the field such that it remains a viable digital twin of a reservoir or reservoirs in the field. In such an approach, assurances can be provided that the most current dynamic reservoir model (e.g., a dynamic reservoir simulation model) is the current best digital representation of the field. As explained, the system 500 can provide for assessments such as history matching assessments where field data, for example, as to production, are compared to model-based results for production (e.g., whether the results are for a reservoir simulation model, one or more proxy models, etc.). As explained, a dynamic reservoir simulation model can be maintained by the system 500 where that model is an up-to- date virtual twin of a hydrocarbon field.

[0100] As an example, the system 500 can ingest production data from one or more sources (e.g., consider the AVOCET framework, the TECH LOG framework, etc.) via co-located off-the-cloud agents into a cloud pub-sub messaging system that send the data to a production data foundation (PDF) system into its cloud infrastructure. As an example, a model update process can commence by calling a digital reservoir engineering (RE) job API that provides relevant parameters. In such an example, a Job worker invoked by such a job API can trigger creation of an engine ecosystem(EESy) ARGO workflow that in turns orchestrate the process of the update using the model update engine.

[0101] In the foregoing example, an ARGO workflow can be implemented using an open-source container-native workflow engine for orchestrating parallel jobs on Kubernetes. For example, an ARGO workflow can be implemented as a Kubernetes CRD (Custom Resource Definition). In such an example, workflows can be defined where each step in the workflow is a container. As an example, one or more multi- step workflows can be modelled as a sequence of tasks or otherwise capture dependencies between tasks using a directed acyclic graph (DAG).

[0102] In the foregoing example, given the parameters provided by the job worker, the model update engine can fetch appropriate simulation case from one or more sources (e.g., Reservoir Engineering Data Services - REDS), retrieve the production data by calling one or more PDF APIs and update parts of the input data deck for the given simulation, such as an observed data file (e.g., OBSH). In such an approach, with the input data deck updated, the workflow can run the simulation, push the simulation back to REDS and advertise the status of the process back to the job worker which will store it on a cloud storage location. Once the process is completed, the original simulation case can be updated with the latest data from production.

[0103] As to subsurface model confidence analysis (e.g., model assessment), consider features of the system 500 that can instruct a process to periodically run to check on a dynamic reservoir simulation model, for example, to evaluate one or more of the following: how reliable the forecasts of the model are for individual wells; what regions of the model need improvement; and what new data can be acquired and the estimated value of the data. As to input, consider access to a dynamic reservoir simulation model stored in a dynamic model data store (REDS). In such an example, the system 500 can provide instructions to render a GUI where a user can setup the model confidence analysis process (e.g., consider access via a web page). In such an example, the user can define a source of dynamic reservoir model data and, for example, select one or more checks that are relevant and to be executed. In such an example, the user may define a schedule at which the process is to be executed or, for example, a default schedule may be implemented; noting that a schedule may be a dynamic schedule (e.g., optionally state based, etc.). As an example, a schedulercan trigger a process in a container on the cloud where the process retrieves a specified dynamic simulation model from the specified model data store, for example, using one or more APIs. The process may also access other sources of oilfield measured data in order to compare them with the model, for example, a seismic data store, a well log data store, and / or a production data store (PDF). In such an example, the process can execute the defined one or more checks and generate one or more quality metrics. In such an example, the quality metrics may be pushed back to the model data store (e.g., using one or more APIs) and linked to the reservoir simulation model (e.g., a digital twin of a particular field). As an example, one or more quality metrics may be processed to generate advice on model improvement and data acquisition where such advice can be published to a recommendation management system (e.g., for human interaction and / or automated action).

[0104] As an example, the system 500 may provide for performing various quality checks (e.g., assessments). For example, consider a volume consistency or material balance that determines whether injected and produced volumes calculated by the model match with the measured volumes; a history match quality that quantifies a mismatch between the model calculated and measured quantities over time; and history match modifications that determine whether the modifications made to the model to achieve the match are reasonable from a geological and engineering standpoint, for example, using one or more automated intelligent domain rules. The system is extensible, for example, in allowing new quality checks to be implemented through a low-code mechanism.

[0105] As to output, the system 500 may output one or more quality metrics for rendering to one or more GUIs that can be displayed to one or more users (e.g., via a web-based dashboard). For example, consider one or more of metrics defined on entities such as wells and completions; metrics defined as a 3D distribution of model quality on the subsurface reservoir (e.g., to highlight one or more areas of a reservoir with higher uncertainty); and recommendations on model improvement and data acquisition.

[0106] As an example, a model confidence analysis process can commence by calling a digital RE job API that provides relevant parameters. In such an example, a job worker can be invoked by a job API that triggers the creation of an EESy ARGOworkflow that in turns orchestrates the process of the update using the model confidence engine. In such an example, given the parameters provided by the Job worker, the model confidence engine can fetch appropriate simulation cases from REDS, calculate confidence, send the simulation case back to REDS with the confidence artifacts and advertise the status of the process back to the job worker, which can store it on a cloud storage location.

[0107] As to automated generation of production forecast and optimized recommendations, the system 500 can be a virtual field management system that can capture the operating logic and constraints of a real-world hydrocarbon field. In such an example, a process can be scheduled or executed on-demand that: generates production and injection forecasts based on a dynamic reservoir simulation model; generates optimum settings to best operate the wells and other equipment on the field to maximize hydrocarbon production and minimize costs using fit-for-purpose optimizers; and converts the optimization outputs into implementable recommendations using domain-driven rule-based system.

[0108] As to input, consider access to a dynamic reservoir simulation model stored in a dynamic model data store (REDS), along with equipment and resource constraints that can limit operating capacity of wells and other equipment and optionally an operating philosophy of the oilfield that can define one or more desired objectives.

[0109] As an example, a process can include rendering a GUI that allows a user to setup a forecast process, define the source of the dynamic reservoir model data, define the field constraints and objectives, and define the schedule at which the process has to be executed. In such an example, the scheduler can trigger the process in a container on the cloud where the process retrieves the dynamic simulation model from the model data store (e.g., using one or more APIs). In such an example, the process can modify the dynamic simulation model according to the user defined constraints and objectives. The process can then execute the dynamic reservoir simulation model in a forecast mode, for example, using a restart mechanism such that the execution starts from a previously saved state representing the end of history period.

[0110] As an example, one or more optimizers may be executed at runtime, for example, depending on the user defined objectives such that one or more recommendations can be generated. As an example, one or more multiple fit-for- purpose optimizers can be implemented for injection production balancing and allocation, such as for a waterflooded oilfield, to balance sweep, pressure maintenance, and reduce water recycling. In such an example, the recommendations generated can propose a schedule for settings (e.g., rates, wellhead or bottomhole pressures, surface or subsurface pump or valve settings) at which wells, or downhole flow-control devices should be operated. As an example, one or more optimizers can provide for downhole flow control device optimization for wells which are fitted with controllable downhole devices. In such an example, the recommendations generated can propose a schedule for the downhole valve settings such that the well performance is optimized. As an example, one or more optimizers can provide for artificial lift optimization where, for example, a process pushes a forecast model and its results back to a model data store and where the process publishes one or more recommendations generated to a recommendation management system.

[0111] As to implementation of a model forecast analysis process, it can commence by calling a digital RE job API that provides relevant parameters. In such an example, a job worker can be invoked by the job API that triggers the creation of an EESy ARGO workflow that in turns orchestrates the process of the update using a model forecast engine. In such an approach, given the parameters provided by the job worker, the model forecast engine can fetch an appropriate simulation case from the REDS and prepare the simulation files to comply with the desired type of forecast calculation. In such an example, with the simulation files updated, the workflow can run the simulation, push the simulation results back to the REDS and advertise the status of the process back to the job worker, which can store it on a cloud storage location.

[0112] As an example, a recommendation management system can include: a cloud-based repository of automatically generated recommendations where each recommendation can be qualified with details including expected outcome, risk, costs, and priority; an approval mechanism where a recommendation can progress through a hierarchy of authorization with defined user roles; features to send an approvedrecommendations to a field remote control system (e.g., consider an AGORA field gateway computational system); and a feedback mechanism where implementation of a recommendation is monitored, and actual outcomes are recorded for evaluating the success of the recommendation against the estimated outcome.

[0113] As an example, a system may include and / or be operatively coupled to one or more gateways (e.g., gateway devices, gateway systems, etc.) such as, for example, an AGORA gateway (e.g., consider one or more processors, memory, etc., which may be deployed as a “box” that can be locally powered and that can communicate locally with other equipment via one or more interfaces). As an example, one or more pieces of equipment may include computational resources that can be akin to those of an AGORA gateway or more or less than those of an AGORA gateway. As an example, an AGORA gateway may be a network device.

[0114] As an example, a gateway can include one or more features of an AGORA gateway (e.g., v.202, v.402, etc.) and / or another gateway. For example, consider an INTEL ATOM E3930 or E3950 Dual Core with DRAM and an eMMC and / or SSD. Such a gateway may include a trusted platform module (TPM), which can provide for secure and measured boot support (e.g., via hashes, etc.). A gateway may include one or more interfaces (e.g., Ethernet, RS485 / 422, RS232, etc.). As to power, a gateway may consume less than about 100 W (e.g., consider less than 10 W or less than 20 W). As an example, a gateway may include an operating system (e.g., consider LINUX DEBIAN LTS). As an example, a gateway may include a cellular interface (e.g., 4G LTE with Global Modem I GPS, etc.). As an example, a gateway may include a WIFI interface (e.g., 802.11 a / b / g / n). As an example, a gateway may be operable using AC 100-240 V, 50 / 60 Hz or 24 VDC. As to dimensions, consider a gateway that has a protective box with dimensions of approximately 10 in x 8 in x 4 in.

[0115] As an example, a recommendation management system of the system 500 may be operable in a manner that is independent of one or more recommendation generating systems and their internal working and can communicate with them through one or more APIs.

[0116] As an example, a decision dashboard can be a cloud-based dashboard that displays reservoir model-driven surveillance analysis results that helps understand the current performance of the oilfield. For example, consider one or moreof subsurface views extracted from a reservoir model that help understand the current state of the subsurface; real-time production data analytics based on data from the production data store; subsurface model quality metrics generated by the Subsurface model confidence analysis process; recommendations from the recommendation management system (e.g., optionally providing for enabling one or more approval mechanisms for the recommendations).

[0117] As an example, a dashboard can be written on a PYTHON-based framework such as, for example, the DASH PLOTLY framework. DASH is a relatively low-code framework for rapidly building data apps and written on top of Plotly.js (“js” is JAVASCRIPT) and React.js. DASH can provide for building and deploying data apps with customized user interfaces where DASH can abstract away various technologies and protocols to build a full-stack web app with interactive data visualization.

[0118] As an example, a dashboard can interface with various backend services, for example, via a backend-for-frontend (BFF or BE-for-FE). As an example, given a configuration, a dashboard backend component or components can fetch data from the REDS and prepare structures to be presented visually by the front-end. As an example, via a dashboard, a user may trigger one or more automated processes such as, for example, one or more of model update, model confidence and model forecast.

[0119] As an example, the system 500 can provide for multi-fidelity reservoir representations. For example, the system 500 can provide flexibility to represent behavior of a field including the subsurface, wells and surface equipment through several techniques and / or technologies. For example, consider one or more of a numerical reservoir simulation model (RSM), a data-driven proxy of the RSM that executes in a fraction of its time, and one or more reduced-order and / or reduced- physics versions of a full RSM. As an example, the system 500 can include and / or be operatively coupled to one or more machine learning frameworks (e.g., consider the TENSORFLOW framework, Google, Mountain View, California).

[0120] As an example, a system such as the system 500 may account for various types of equipment such as, for example, one or more of the types of equipment shown in the examples of FIG. 1 , FIG. 2, FIG. 3 and FIG. 4. Fielddevelopment planning, execution, etc., are complex processes that can involve evaluating multiple scenarios for a field and selecting the best scenario based on assessing trade-offs among multiple factors. As explained, the example system 500 of FIG. 5 can provide for reductions in one or more of cost, time, and scope, which ultimately can increase efficiency of field operations. As an example, a systems approach may be implemented, which may involve a life-cycle analysis, cradle-to- grave and / or cradle-to-cradle assessment.

[0121] FIG. 6 shows an example of an architecture 600 that may be utilized for implementation of one or more portions of the system 500 of FIG. 5. As shown, the architecture 600 can include a workflow execution environment (e.g., consider a DELFI reservoir engineering environment or dynamic reservoir engineering (DRE) cluster) that interacts with an EESy that includes components for a model update engine, a model confidence engine, and a model forecast engine, where an INTERSECT framework engine is also included as an example of a reservoir simulation framework. Various features of the DRE cluster can provide for triggering of engines (the jobs service), handling of simulation model data and results (reservoir engineering data services), and storage of results, where output may be directed to a cloud storage. The engines within EESy may, directly and / or indirectly, retrieve data from and push data to the cloud storage, including the production data storage (e.g., using PDF). In FIG. 6, the DRE cluster is shown as including a backend-to-frontend (BE-to-FE) component, such that a dashboard can interface with various backend services, for example, via a BFF, a BE-to-FE, etc.

[0122] As mentioned, the system 500 may be applied to one or more field scenarios, which can include, for example, EOR. For example, consider an EOR process that includes injection of surfactant to a downhole region of the Earth using equipment such as, for example, one or more pumps. As an example, a surfactant can include a chemical that forms a surfactant in a subterranean environment, for example, due to one or more chemical interactions and / or reactions that may occur in a subterranean environment. As an example, a surfactant can be a polymer that becomes a surface active agent responsive to exposure to an alkaline environment. For example, EOR can include injection of polymer as a surfactant where the polymer becomes a surface active agent downhole in a downhole alkaline environment.

[0123] As an example, a reservoir simulation model may include a number of cells (e.g., grid cells) that may exceed one million cells (e.g., consider a model with 100,000,000 cells or more) such a model may take considerable time and computational resources to output a solution that characterizes a reservoir. As such, a simulation can represent an amount of time and resources expended where a solution is desired to be accurate. Where a simulation can be of greater accuracy, confidence may be increased in a solution that characterizes a reservoir, particularly where decisions are to be made as to injection, production, equipment development, drilling, etc. However, as explained, at times one or more proxy models may be implemented because execution of a full reservoir simulation model of a field may take considerable time and be rate limiting. Through use of one or more proxy models, particularly with associated quality metrics (e.g., confidence, etc.), decisions (e.g., as to control actions, etc.) may be made in a lesser amount of time, which may, in turn, result in more optimal field control and / or lesser non-productive time (NPT) and / or waste (e.g., consider waste of water, waste of separation resources, waste of energy, waste of gas in artificial lift, etc.).

[0124] As an example, a dynamic reservoir simulation can include modeling water injection as may be associated with surfactant flooding as a chemical EOR operation. Such an approach may involve one or more cells of a grid cell model of a reservoir transitioning into, for example, a three-phase region of a ternary phase diagram. As an example, a salinity gradient may exist as part of a physical reality that can drive a transition. As an example, a reservoir simulator can be improved by inclusion of operational instructions for decision making as to physical phenomena that can occur in a reservoir being subjected to one or more EOR operations. For example, where a front or fronts exist, a simulator can include dynamic gridding where, for example, a region in advance of a front is dynamically gridded via grid refinement. In such an example, the nature of the front may be taken into account, for example, the types of phases that may exist at the region may be taken into account (e.g., where a more complex region is expected phase-wise, the gridding may be refined and / or a time-step decreased).

[0125] As an example, a controller can be instructed to control one or more field operations based on saturations, which may be matched to real-time for operations inthe field. In such an example, a controller can instruct a pump to adjust a pump flow rate of fluid, which may include one or more chemicals, in a manner to alter saturations in the subterranean region. As an example, a simulator may be updated responsive to such an adjustment, automatically and / or via user input. In such a workflow, the simulator can determine values for a past, present and / or future time. In such an example, one or more values may be utilized to issue one or more additional control instructions.

[0126] FIG. 7 shows an example of a system 700 that includes various types of equipment for performing various types of field operations. The system 700 may be operatively coupled to the system 500, which includes a simulator and that can output information to a display or displays for rendering one or more GUIs. As an example, the system 700 may be controllable and controlled by such a computing system, autonomously and / or semi-autonomously, optionally via various GUI inputs.

[0127] In the system 700, various pieces of equipment are shown, which can include electronic equipment such as sensors, actuators, controllers, transmitters, receivers, etc. As an example, a computing system can be operatively coupled to one or more pieces of equipment via wire and / or wireless communication circuitry. As an example, a computing system can include a simulator as a specially programmed computerized framework that can calculate various values for purposes of controlling one or more pieces of field equipment. For example, a simulator can calculate a flow rate, an emulsion type, an emulsion formation time, an emulsion formation region, an interfacial tension, a composition of fluid, etc. Such types of values can be utilized in controlling an injection process that injects chemicals into a subterranean formation that includes a reservoir with oil. As an example, one or more methods can improve recovery of oil from a reservoir by utilizing a simulator that can simulate underground conditions. As an example, such a method may make a tertiary recovery process (e.g., an EOR process) more effective as to amount of oil recovered, rate of oil recovery, amount of oil in produced fluid(s), and / or amount of water and / or chemical utilized.

[0128] The system 700 of FIG. 7 can be utilized for purposes of chemical flooding to add a material (chemical) to water being injected into a reservoir to increase the oil recovery by one or more of (1) increasing the water viscosity (e g., polymerand / or surfactant floods), (2) decreasing the relative permeability to water (crosslinked polymer and / or surfactant floods), or (3) increasing the relative permeability to oil and decreasing residual oil saturation (Sor) by decreasing the interfacial tension between the oil and water phases (e.g., microemulsion and / or alkaline floods).

[0129] FIG. 7 shows an example of a method that includes driving fluid in a subterranean region via injection of water and one or more chemicals via a well or wells 710, using water as a buffer to protect one or more chemicals 720, controlling chemical solution mobility 730 (e.g., via a pump or pumps, etc.), exposing one or more chemicals to an alkaline environment where one or more of the chemicals can form a surface active agent in situ to reduce interfacial tension (I FT) 740, and recovering additional oil via reduction in IFT via a production well 750. Such a method can include, for example, a preflush operation that may help to condition a reservoir prior to injection of one or more chemicals 750.

[0130] As shown, the production well in the system 700 of FIG. 7 can include associated equipment such as a sucker pump and the injection wells can include associated equipment such as injection pumps. Various surface equipment shown in the system 700 of FIG. 7 can include control equipment, surface processing equipment, collection equipment, computing equipment, reservoir simulator(s), etc.

[0131] In FIG. 7, some examples of equipment are labeled, including a well head assembly 752 of an injection well, an injection pump 754 operatively coupled to the well head assembly 752 of the injection well to inject fluid (e.g., water and / or water and chemicals) into the injection well where fluid may be held in one or more tanks as part of surface equipment 790 to supply the injection pump 754 and where computerized control equipment 780 can be operatively coupled to one or more of such surface equipment 790, well head assembly 752 and injection pump 754 to control one or more operations that can include one or more EOR operations.

[0132] Also shown in FIG. 7 are a well head assembly 772 for a production well and a production pump 774 that is operatively coupled to the well head assembly 772 to produce fluid(s) from the reservoir as may be subjected to one or more operations, which can include one or more EOR operations. The computerized control equipment 780 (e.g., as housed in a building, etc.) can be operatively coupled to various equipment including, for example, the well head assembly 772 and the productionpump 774. As an example, the computerized control equipment 780 can include one or more simulators and / or be operatively coupled to one or more simulators that can simulate conditions in the reservoir as to one or more of oil, water, emulsion, microemulsion, etc. The computerized control equipment 780 can issue one or more control signals to one or more pieces of equipment using results from a simulator that operates according to a method or methods (e.g., consider one or more of the processes described with respect to the system 500 of FIG. 5).

[0133] As an example, the computerized control equipment 780 can be local and / or remote and can include instructions executable to render one or more GUIs, which may provide for manual, semi-automated, and / or automated control of one or more pieces of equipment in the system 700. For example, saturations can be determined for various regions of the reservoir where injection and / or production may be controlled using one or more of those saturations (e.g., in a region or regions). For example, an injection rate of the injection pump 754 may be adjusted, a production rate of the production pump 774 may be adjusted (e.g., based on effectiveness of an EOR operation according to a simulator, etc.), a valve in the well head assembly 752 may be adjusted, a valve in the well head assembly 772 may be adjusted, an amount of water and / or amount of chemical flowing from a tank or tanks of surface equipment 790 may be adjusted (e.g., via one or more valves, one or more pumps, etc.), for example, to increase and / or decrease water and / or chemical injected into the reservoir via one or more injection wells. As an example, injection wells may be controlled differently according to regional results from a simulator. Such a simulator-based approach to control can improve one or more EOR operations for the reservoir shown in the example of FIG. 7. As an example, an improvement can be from a system that operates with less error and / or more rapidly to thereby allow for control that approaches real-time control for performing one or more EOR operations.

[0134] As an example, the computerized control equipment 780 can include one or more processors, memory that store instructions executable by a processor, and one or more interfaces, which can include interfaces for transmission of information and / or receipt of information from one or more pieces of equipment in the system 700, which may include one or more sensors, one or more actuators, etc. As an example, the computerized control equipment 780 can be a controller that issues controlinformation via one or more interfaces to one or more pieces of equipment in the system 700. As an example, a controller may aim to expedite recovery of oil, make recovery more efficient, make surface processing more efficient, etc.

[0135] As an example, a system can help to control a process via one or more actions, which may include preceding chemical injection with a preflush to buffer the chemicals from reactions with the in-situ water and following the chemical injection with the injection of a polymer solution to maintain a favorable mobility ratio for the flood. As an example, a system may account for chemicals that are surface active and that, due to such properties, interact with one or more types of rock (e.g., reservoir rock). For example, a chemical can have an affinity for one or more types of minerals found in reservoirs, causing adsorption of chemicals from solution onto the rock in various quantities. As an example, a system can estimate subsurface conditions and can control one or more pieces of equipment, optionally in real-time and optionally with feedback data as acquired by one or more sensors that are subsurface and / or one or more sensors associated with producing fluid and / or processing fluid (e.g., consider determinations as to water fraction, oil fraction, state of chemicals, microemulsions, etc.).

[0136] FIG. 8, FIG. 9, FIG. 10, FIG. 11 , FIG. 12, FIG. 13, FIG. 14, FIG. 15, FIG. 16, FIG. 17 and FIG. 18 show examples of GUIs 800, 900, 1000, 1100, 1200, 1300, 1400, 1500, 1600, 1700 and 1800, respectively, for various workflows implemented by a system such as, for example, the system 700 of FIG. 7, with respect to waterflooding operations in a field with wells.

[0137] FIG. 8 shows the example GUI 800 as including a field map panel with well locations, injector to producer well allocation factors depicted by straight lines with line width corresponding to the magnitude of the allocation factor, and production bubbles. Additional panels show model-driven surveillance analysis including comparison of the various injection patterns with respect to critical metrics such as oil production rate, remaining mobile oil volume, and voidage replacement ratio with respect to water injection rate.

[0138] FIG. 9 shows the example GUI 900 as including a field map panel with physical parameter data (e.g., porosity) extracted from the simulation model and additional panels for model-driven surveillance analysis.

[0139] FIG. 10 shows the example GUI 1000 as including various panels for graphs of oil and water production, water injection rate, water cut, etc., with respect to time for a selected well.

[0140] FIG. 11 shows the example GUI 1100 as including a table and a graph where the table includes confidence indicators for various wells with respect to water injection rate, oil production rate and water production rate, for example, the water injection rates can be recommendations for the wells, where the graph shows current and optimized water injection rates for the wells.

[0141] FIG. 12 shows the example GUI 1200 as including various panels for graphs of before and after comparisons with respect to the recommendations.

[0142] FIG. 13 shows the example GUI 1300 as including various panels for a field map and a graph of reservoir fluid allocation for various wells.

[0143] FIG. 14 shows the example GUI 1400 as including various panels for graphs of oil and water production, water injection rate, water cut, etc., with respect to time for a selected injection pattern which includes a specified injection well and producers under its influence.

[0144] FIG. 15 shows the example GUI 1500 as including various panels for a table and various graphs where the table includes injection rate information for a selected well and where the graphs provide before and after comparisons for optimization.

[0145] FIG. 16 shows the example GUI 1600 as including various panels for a selected well where metrics are provided for pattern voidage replacement ratio, injection efficiency, pattern injection leakage, linked producers, water injection rate and water cut. As shown, a map can be rendered to show the selected well with respect to other wells and where one or more recommended actions can be rendered such as to increase water injection rate by a particular amount, which can be rendered along with a confidence indicator (e.g., medium confidence). Additionally, information is rendered for model confidence, which can include volume consistency as to water injected, history match quality as to water injected and BHFP, and history match modifications in a composite manner where, for example, colors, graphics, etc., may be utilized to rapidly convey information.

[0146] FIG. 17 shows the example GUI 1700 as including various panels for a selected well where forecasted outcomes are presented for oil, water and gas, along with history match quality for oil, water, gas and BHFP. As shown, the history match quality is lower for water. Additionally, a graphic is rendered that can provide information as to reservoir fluid pathways with respect to a selected well and one or more other wells, using streamline representation.

[0147] FIG. 18 shows the example GUI 1800 as including various panels for model confidence, which includes metrics for a composite, produced volume consistency, history match quality, and history match (HM) modifications. The field map panel shows a distribution of model confidence to indicate which parts of the reservoir are more uncertain and would merit additional data acquisition and / or modeling work.

[0148] As an example, a system may account for one or more emission factors. For example, consider using thermodynamic properties where mass flowrate of CO2 and methane can be estimated. As an example, mass flowrate of methane can be multiplied by global warming potential (e.g., from basis of design) and then the CO2 equivalent per day or per annum can be reported as fugitive emissions in the emissions tap. As an example, an optimization may provide for emissions optimization for one or more field operations (e.g., operational workflows).

[0149] As an example, a system can be implemented at least in part using a cloud platform. As explained, a system can leverage one or more computational frameworks, which may be accessible or hosted using a framework environment (e.g., DELFI environment). As an example, a system may utilize an application programming interface (API) structure such as an open API structure to facilitate interactions.

[0150] FIG. 19 shows an example of a method 1900 and an example of a system 1990. In the example of FIG. 19, the method can include a reception block 1910 for receiving workflow specifications for an operational workflow performed using equipment in a field to produce hydrocarbons; a configuration block 1920 for configuring a dynamic reservoir simulation system according to the workflow specifications; a reception block 1930 for receiving, by the dynamic reservoir simulation system, field data from the equipment; an update block 1940 for, responsiveto receipt of the field data, updating a model representative of one or more hydrocarbon production related physical phenomena in the field to generate an updated model of the dynamic reservoir simulation system; a generation block 1950 for generating model-based results using the updated model; an assessment block 1960 for assessing quality of the model-based results to generate one or more quality metrics; and an output block 1970 for outputting, based at least in part on the modelbased results, a control action for the operational workflow and at least one of the one or more quality metrics.

[0151] In the example of FIG. 19, the system 1990 includes one or more information storage devices 1991 , one or more computers 1992, one or more networks 1995 and instructions 1996. As to the one or more computers 1992, each computer may include one or more processors (e.g., or processing cores) 1993 and a memory 1994 for storing the instructions 1996, for example, executable by at least one of the one or more processors. As an example, a computer may include one or more network interfaces (e.g., wired or wireless), one or more graphics cards, a display interface (e.g., wired or wireless), etc.

[0152] The method 1900 is shown along with various computer-readable media blocks 1911 , 1921 , 1931 , 1941 , 1951 , 1961 and 1971 (e.g., CRM blocks). Such blocks may be utilized to perform one or more actions of the method 1900. For example, consider the system 1990 of FIG. 19 and the instructions 1996, which may include instructions of one or more of the CRM blocks 1911 , 1921 , 1931 , 1941 , 1951 , 1961 and 1971.

[0153] FIG. 20, FIG. 21 , FIG. 22 and FIG. 23 show an example of a system 2000 and examples of system portions 2100, 2200 and 2300 of the system 2000. As shown the system 2000 can include various loops for integrated control of field operations. For example, the system 2000 can include various components that can provide for recommendation generation, operational insights, a recommendation system, remote operations, etc., which can be utilized for control of one or more field operations. As an example, the system 2000 may include one or more features that provide for human interactions. For example, the system 2000 may operate using one or more instances of a human-in-the-loop (HITL). In such an example, the system 2000 may operate in an automatic mode as to various processes and may provide forone or more opportunities for human interaction, which may be, for example, to assess a process, assess a recommendation, to approve an action, etc. The system 2000 may operate in an automatic and / or semi-automatic manner. As an example, the system 2000 may provide for generation of notifications, which may call for human interaction (e.g., via one or more GUIs, etc.).

[0154] FIG. 21 shows the system portion 2100, which may be a system by itself. As shown, the system portion 2100 includes various production related components, including a production data source component, a production update filter and a production engine update component, which can interact with a reservoir model selection component. As shown, the reservoir model selection component can provide for various actions such as interactions with components such as a full-fidelity 3D reservoir model, a reservoir model proxy (e.g., proxy model(s)), a reduced physicsbased model (e.g., optionally with front tracking of one or more fluid fronts), a reduce order model, an inter-well numerical simulation model (INSIM) and / or capacitance resistance model (CapRM) component and one or more other reservoir representations. As shown, a proxy model generator can generate a proxy model using one or more features of the full-fidelity 3D reservoir model where a proxy quality analysis component can perform a quality analysis (QA) on a proxy model or proxy models. As explained, one or more proxy models can help to expedite one or more workflows for control of field operations (e.g., integrated control of actions related to an asset).

[0155] As to a CapRM, it can be derived from a material balance equation and a linear productivity prediction model, reflecting connectivity between injection and production wells via their rate fluctuations. For example, based on the similarity between the hydraulic system and power system, CapRM can use weights and time constants to quantify the connectivity (capacitance effect) and signal lags (resistance effect) of each injector-producer pair. Variants of CapRM exist and may be used. For example, combined with the Y-function method, a Buckley-Leverett-based waterflood analysis model, CapRM can further strengthen the robustness. As to INSIM, comparatively, it may be another category of physical methodologies, developed with the material balance equation and Buckley-Leverett theory. By simplifying the waterflooding reservoir into a series of volume flow units, INSIM can accelerate thesimulation process and characterize the permeability channels of injector-producer pairs. Based on INSIM, several improved versions have been proposed, such as INSIM-FT-3D, simulating the waterflood in three dimensions and considering the gravity effect, and INSIM-FPT replacing the reservoir properties by history matching results.

[0156] FIG. 22 shows the system portion 2200, which may be a system by itself. As shown, the system portion 2200 includes a model confidence analysis component that can output various model confidence measures (e.g., indicators, metrics, etc.). Such output may be utilized in one or more risking / de-risking processes, which may involve use of components such as a decision risk reduction component, a decision risk estimation component, a proactive model improvement advisor, a data acquisition advisor, a field test recommender, a field services catalog (e.g., database), a costbenefit analysis of acquisition component (e.g., for acquisition of additional field data, field tests, etc.), and a manual and / or automated model improvement component.

[0157] FIG. 23 shows the system portion 2300, which may be a system by itself. As shown, the system portion 2300 includes various field related components such as, for example, a field objectives component, a field operating philosophy component and field constraints (e.g., capacity / resources) component. Such components may inform a production forecast generator that can provide output to one or more other components such as, for example, an optimizer selector and the recommendation generator. As shown, the optimizer selector can provide for selection of one or more aspects of a field to optimize. For example, consider an infill advisor for determining whether one or more infill wells (e.g., injector and / or producer) can help to optimize production, a workflow advisor for outputting one or more workflows that can help to optimize production, a downhole device optimizer (e.g., for one or more types of downhole equipment that may related to injection and / or production), an artificial lift optimizer that may provide guidance as to one or more existing artificial lift operations in the field and / or one or more new artificial lift operations for the field, an injectionproduction rate allocator that may provide metrics for control of equipment to provide a desired or more optimal allocation of fluids amongst wells in a field, and an emissions reduction component that may provide for assessments of emissions related to one or more field operations, optionally by optimizing field operations to reduce emissionsand / or to meet one or more emissions targets. Such an emissions reduction component may account for flaring of hydrocarbons, operation of fuel combustion engines, capture of gas, artificial lift technologies, etc. As an example, an emissions reduction component may be informed by weather data such that decisions can be made responsive to weather changes, forecasts, etc. For example, if wind power is available, emissions may be reduced by using more wind power. As another example, if solar power is available, emissions may be reduced by using more solar power. In various instances, if carbon sequestration (e.g., CO2 and / or methane sequestration) are a concern for a field, an emissions reduction component may provide output that can more effectively handle carbon, whether carbon generation and / or carbon sequestration. As an example, a field may include one or more reservoirs where a reservoir or a portion thereof may be suitable for one or more types of operations such as storage of material (e.g., water, greenhouse gas, etc.).

[0158] Various components in the examples of FIG. 20, FIG. 21 , FIG. 22 and FIG. 23 may be implemented to perform one or more workflows for autonomous and / or semi-autonomous integrated control for a field (e.g., an asset). As an example, the system 2000 can be an autonomous oilfield production integrated control system. As explained, such a system can provide for one or more types of control, which can include model control, workflow control, data acquisition control, testing control, operational equipment control, etc.

[0159] FIG. 24 shows an example of a system 2400 that includes one or more field digital twins such as, for example, a virtual asset model and a virtual field manager. The system 2400 may include various components that may form a recommendation confidence improvement sub-system, a recommendation confidence assessment sub-system, and a recommendation generation and management subsystem, along with, for example, a sub-system for the one or more digital twins. As shown, field operation data may provide for feeding a decision quality improvement component that can provide for updating of historical data (e.g., response to control of field equipment via a remote control component, etc.), model improvement via a model improvement advisor, data acquisition via a data acquisition advisor, etc. As an example, improvements may be utilized to improve a virtual asset model, which may be a digital twin of field assets (e.g., machine learning model, physics-based model,hybrid model, etc.). In such an example, characteristics of the model may be fed to a model confidence estimator that can generate quality assessment (QA) metrics for the model, which may be utilized in one or more decision making processes. As shown, the model confidence estimator may be fed with historical simulated production data as may be generated by the virtual field manager (e.g., a field digital twin component), which may also generate production forecasts that may be fed to a field recommendation generator, which may also operate based at least in part on output of the recommendation confidence estimator. As shown, a recommendation management system may operate based field recommendations, data acquisition advice, past actions, etc., to generate control signals (e.g., commands, instructions, etc.) suitable for control of one or more field operations, which may be via a remote control component. As shown, actions (e.g., control actions) may give rise to field responses that generate additional field operational data where such data may inform the recommendation confidence estimator. The system 2400 may be a dynamic system whereby continuous improvements may be made with respect to time in the ability of the system 2400 to generate control signals to control one or more field operations. As shown, various quality metrics (e.g., QA metrics, etc.) may be generated that may be output along with one or more control actions (e.g., control signals). As an example, the system 2400 may operate to, based at least in part on model-based results, output a control action for an operational workflow and at least one of one or more quality metrics. In such an approach, model-based results may be utilized for control where such control may be informed as to quality thereof (e.g., recommendation quality, etc.).

[0160] As explained, a system may be a dynamic system that may improve over time such that, for example, one or more quality metrics may improve such that control actions improve, which may provide for increased automation of one or more field operations. For example, if quality metrics are acceptable, a level of automation may be increased for performance of one or more field operations. In general, automation at higher levels demands confidence. As explained, confidence may be addressed via generation of quality metrics. For example, in the system 2400, interactions may occur between the recommendation confidence estimator and the field recommendation generator such that a recommendation may be accompanied by aconfidence indicator, which may be a quality metric and / or based at least in part on one or more quality metrics. As explained, where confidence is deemed to be too low (e.g., by comparison to a threshold, etc.), a recommendation may be deemed of low confidence and subject to review and / or discarded (e.g., not translated into a field control signal for control action, etc.). As explained, field responses to past actions may provide information that may help to more accurate estimate confidence in a recommendation. For example, if a past action (e.g., per a past recommendation, etc.) resulted in a desirable field response, then that may act to increase confidence as to a recommended action. As an example, as a system gains experience through past actions and associated responses, the system may increase its ability to generate acceptable recommendations with more accurate levels of confidence.

[0161] As an example, a system may provide for increasing a level of automation where quality metrics improve in a manner that increases confidence in system output (e.g., as to control action). Similarly, where quality metrics do not provide for confidence in increasing automation level, an automation level may be maintained or decreased (e.g., as to include human intervention, etc.).

[0162] As shown, the system 2400 may operate based on confidence in more than one model, which may include a virtual asset model and a virtual field manager model. As explained, production forecasts may be received by the field recommendation generator, where such production forecasts may be informed by one or more outputs of a virtual asset model. In such an example, history matching may be utilized to assess the production forecasts, which may provide for estimating model confidence, which may be confidence as to more than one model.

[0163] As an example, where an aim is to increase production, if a production forecast is unacceptable in increasing production, this concern together with an estimation as to confidence may be utilized by a field recommendation generator to determine whether or not a recommendation as to a possible action is warranted. For example, if a possible action is of relatively high confidence as to a relatively small increase in forecast production, it may be warranted to take such an action, as opposed to a scenario where the confidence is relatively low. As such, the system 2400 may provide for generation of recommendations as to control actions in a manner that accounts for prospective increases in production, where, for example, an aim isto increase production; noting that the system 2400 may provide for assessing scenarios where an aim may be to maintain or decrease production (e.g., due to one or more bottlenecks downstream, etc.).

[0164] As an example, each control action generated by a system may be accompanied by one or more corresponding quality metrics such that individual control actions may be assessed as to quality, which may provide for determinations as to level of automation as to control of field equipment, etc. As explained, a system may provide for improvement of itself via a quality metric-based approach.

[0165] As an example, field operations may pertain to one or more of well performance, network performance, production forecasting, interventions, etc. For example, as to well performance, consider well-level lift performance, flow assurance risk (e.g., sand production, erosion, corrosion, scale, wax, hydrates, liquid loading, slugging, etc.), etc. As an example, flow assurance risk may relate to network performance, which may also address field-wide lift optimization, surface debottlenecking, choke valve optimization, compliance, etc. As to production forecasting, consider workflows involving production targets and compliance tracking, downtime and loss management (e.g., of resources, time, etc.), constraints management, etc. As to interventions, consider one or more of interventions concerning water shutoff, stimulation (e.g., treatments, etc.), reperforation, behind- casing opportunities to improve operations, idle well reactivation, etc.

[0166] As an example, a system such as, for example, the system 2400 may provide for improving various types of field operations. Such a system may include one or more features of the system 2000 and / or one or more other systems described herein.

[0167] As an example, one or more machine learning techniques may be utilized to enhance process operations, a process operations environment, a communications framework, etc. As explained, various types of information can be generated via operations where such information may be utilized for training one or more types of machine learning models to generate one or more trained machine learning models, which may be deployed within one or more frameworks, environments, etc.

[0168] As to types of machine learning models, consider one or more of a support vector machine (SVM) model, a k-nearest neighbors (KNN) model, an ensemble classifier model, a neural network (NN) model, etc. As an example, a machine learning model can be a deep learning model (e.g., deep Boltzmann machine, deep belief network, convolutional neural network, stacked auto-encoder, etc.), an ensemble model (e.g., random forest, gradient boosting machine, bootstrapped aggregation, AdaBoost, stacked generalization, gradient boosted regression tree, etc.), a neural network model (e.g., radial basis function network, perceptron, back-propagation, Hopfield network, etc.), a regularization model (e.g., ridge regression, least absolute shrinkage and selection operator, elastic net, least angle regression), a rule system model (e.g., cubist, one rule, zero rule, repeated incremental pruning to produce error reduction), a regression model (e.g., linear regression, ordinary least squares regression, stepwise regression, multivariate adaptive regression splines, locally estimated scatterplot smoothing, logistic regression, etc.), a Bayesian model (e.g., naive Bayes, average on-dependence estimators, Bayesian belief network, Gaussian naive Bayes, multinomial naive Bayes, Bayesian network), a decision tree model (e.g., classification and regression tree, iterative dichotomiser 3, C4.5, C5.0, chi-squared automatic interaction detection, decision stump, conditional decision tree, M5), a dimensionality reduction model (e.g., principal component analysis, partial least squares regression, Sammon mapping, multidimensional scaling, projection pursuit, principal component regression, partial least squares discriminant analysis, mixture discriminant analysis, quadratic discriminant analysis, regularized discriminant analysis, flexible discriminant analysis, linear discriminant analysis, etc.), an instance model (e.g., k-nearest neighbor, learning vector quantization, self-organizing map, locally weighted learning, etc.), a clustering model (e.g., k-means, k-medians, expectation maximization, hierarchical clustering, etc.), etc.

[0169] As an example, a machine model may be built using a computational framework with a library, a toolbox, etc., such as, for example, those of the MATLAB framework (Math Works, Inc., Natick, Massachusetts). The MATLAB framework includes a toolbox that provides supervised and unsupervised machine learning algorithms, including support vector machines (SVMs), boosted and bagged decisiontrees, k-nearest neighbor (KNN), k-means, k-medoids, hierarchical clustering, Gaussian mixture models, and hidden Markov models. Another MATLAB framework toolbox is the Deep Learning Toolbox (DLT), which provides a framework for designing and implementing deep neural networks with algorithms, pretrained models, and apps. The DLT provides convolutional neural networks (ConvNets, CNNs) and long shortterm memory (LSTM) networks to perform classification and regression on image, time-series, and text data. The DLT includes features to build network architectures such as generative adversarial networks (GANs) and Siamese networks using custom training loops, shared weights, and automatic differentiation. The DLT provides for model exchange various other frameworks.

[0170] As an example, the TENSORFLOW framework (Google LLC, Mountain View, CA) may be implemented, which is an open-source software library for dataflow programming that includes a symbolic math library, which can be implemented for machine learning applications that can include neural networks. As an example, the CAFFE framework may be implemented, which is a DL framework developed by Berkeley Al Research (BAIR) (University of California, Berkeley, California). As another example, consider the SCIKIT platform (e.g., scikit-leam), which utilizes the PYTHON programming language. As an example, a framework such as the APOLLO Al framework may be utilized (APOLLO. Al GmbH, Germany). As an example, a framework such as the PYTORCH framework may be utilized (Facebook Al Research Lab (FAIR), Facebook, Inc., Menlo Park, California).

[0171] As an example, a training method can include various actions that can operate on a dataset to train a ML model. As an example, a dataset can be split into training data and test data where test data can provide for evaluation. A method can include cross-validation of parameters and best parameters, which can be provided for model training.

[0172] The TENSORFLOW framework can run on multiple CPUs and GPUs (with optional CUDA (NVIDIA Corp., Santa Clara, California) and SYCL (The Khronos Group Inc., Beaverton, Oregon) extensions for general-purpose computing on graphics processing units (GPUs)). TENSORFLOW is available on 64-bit LINUX, MACOS (Apple Inc., Cupertino, California), WINDOWS (Microsoft Corp., Redmond,Washington), and mobile computing platforms including ANDROID (Google LLC, Mountain View, California) and IOS (Apple Inc.) operating system-based platforms.

[0173] TENSORFLOW computations can be expressed as stateful dataflow graphs; noting that the name TENSORFLOW derives from the operations that such neural networks perform on multidimensional data arrays. Such arrays can be referred to as "tensors".

[0174] As an example, a device may utilize TENSORFLOW LITE (TFL) or another type of lightweight framework. TFL is a set of tools that enables on-device machine learning where models may run on mobile, embedded, and loT devices. TFL is optimized for on-device machine learning, by addressing latency (no round-trip to a server), privacy (no personal data leaves the device), connectivity (Internet connectivity is demanded), size (reduced model and binary size) and power consumption (e.g., efficient inference and a lack of network connections). The TFL framework provides multiple platform support, covering ANDROID and iOS devices, embedded LINUX, and microcontrollers. The TFL framework provides diverse language support, which includes JAVA, SWIFT, Objective-C, C++, and PYTHON. High performance, with hardware acceleration and model optimization. The TFL framework provides for machine learning tasks that may include, for example, image classification, object detection, pose estimation, question answering, text classification, etc., on multiple platforms.

[0175] As an example, a dynamic reservoir simulation system can be an autonomous and / or semi-autonomous integrated control system for a field (e.g., an asset) and / or be a part of an autonomous and / or semi-autonomous integrated control system for a field (e.g., operatively coupled to, etc.). Reservoir simulation can include simulation of subsurface and / or surface flows. For example, consider use of one or more types of frameworks such as one or more of the INTERSECT framework and the PIPESIM framework in an integrated control system. As explained, one or more types of frameworks, models, etc., can be implemented within a control system to improve control of one or more field operations, which, in turn, can provide for asset optimization (e.g., optimization of a field that includes one or more reservoirs and one or more wells). As explained, optimization can occur on multiple levels and can bebased on field data such that control actions can be output to equipment in an effort to optimize an asset with respect to constraints and objectives.

[0176] As an example, a method can include receiving workflow specifications for an operational workflow performed using equipment in a field to produce hydrocarbons; configuring a dynamic reservoir simulation system according to the workflow specifications; receiving, by the dynamic reservoir simulation system, field data from the equipment; responsive to receipt of the field data, updating a model representative of one or more hydrocarbon production related physical phenomena in the field to generate an updated model of the dynamic reservoir simulation system; generating model-based results using the updated model; assessing quality of the model-based results to generate one or more quality metrics; and outputting, based at least in part on the model-based results, a control action for the operational workflow and at least one of the one or more quality metrics.

[0177] In such an example, the model can be or include a dynamic reservoir simulation model and where the generating implements a reservoir simulator using the dynamic reservoir simulation model. In such an example, assessing quality can include comparing the model-based results to measured field data and subjecting the model to geologic and engineering assessments using domain-derived rules.

[0178] As an example, a model can be a proxy model of a reservoir simulation model and where a method can include generating model-based results by implementing the proxy model. In such an example, assessing quality can include comparing the model-based results of the proxy model to previously generated modelbased results of the reservoir simulation model.

[0179] As an example, model-based results can include forecast results for hydrocarbon production and fluid injection responsive to implementation of one or more control actions.

[0180] As an example, a dynamic reservoir simulation system can include one or more of an automated model update service, a model confidence analysis service, a forecast service, an optimization service, a model proxy generation service, a model management service, and a recommendation service.

[0181] As an example, a dynamic reservoir simulation system can include services that operate according to the workflow specifications to generate model-based results and one or more control actions. In such an example, outputting can include generating instructions to render a graphical user interface to present the control action, where the graphical user interface includes at least one graphical control actuatable for issuance of one or more control actions to equipment in a field.

[0182] As an example, a dynamic reservoir simulation system can instantiate, according to workflow specifications, a dynamic reservoir engineering cluster interoperable with an engine ecosystem that is operatively coupled to a reservoir simulation framework. In such an example, the engine ecosystem can include one or more of a model update engine, a model confidence engine and a model forecast engine. As an example, a dynamic reservoir engineering cluster can include components for rendering of a dashboard for the operational workflow, where the dashboard interfaces with one or more backend services. In such an example, the one or more backend services can respond to one or more application programming interface calls to perform one or more of accessing data and generating structures for visualization via the dashboard as a frontend.

[0183] As an example, a dashboard can include at least one graphical control actuatable to trigger one or more automated processes. In such an example, the one or more automated processes can include one or more of a model update processing using a model update engine hosted by an engine ecosystem, a model confidence engine hosted by an engine ecosystem and a model forecast engine hosted by an engine ecosystem.

[0184] As an example, an operational workflow can be or include an enhanced oil recovery workflow. As an example, an enhanced oil recovery workflow can include water injection to enhance hydrocarbon production.

[0185] As an example, a dynamic reservoir simulation system can be located remote from a field where equipment in the field includes at least one gateway system that is operatively coupled to the dynamic reservoir simulation via one or more networks.

[0186] As an example, a system can include a processor; a memory accessible to the processor; processor-executable instructions stored in the memory and executable by the processor to instruct the system to: receive workflow specifications for an operational workflow performed using equipment in a field to producehydrocarbons; configure the system according to the workflow specifications; receive field data from the equipment; responsive to receipt of the field data, update a model representative of one or more hydrocarbon production related physical phenomena in the field to generate an updated model; generate model-based results using the updated model; assess quality of the model-based results to generate one or more quality metrics; and output, based at least in part on the model-based results, a control action for the operational workflow and at least one of the one or more quality metrics.

[0187] As an example, one or more computer-readable media can include computer-executable instructions executable by a system to instruct the system to: receive workflow specifications for an operational workflow performed using equipment in a field to produce hydrocarbons; configure the system according to the workflow specifications; receive field data from the equipment; responsive to receipt of the field data, update a model representative of one or more hydrocarbon production related physical phenomena in the field to generate an updated model; generate model-based results using the updated model; assess quality of the model-based results to generate one or more quality metrics; and output, based at least in part on the model-based results, a control action for the operational workflow and at least one of the one or more quality metrics.

[0188] As an example, a computer program product can include one or more computer-readable storage media that can include processor-executable instructions to instruct a computing system to perform one or more methods and / or one or more portions of a method.

[0189] In some embodiments, a method or methods may be executed by a computing system. FIG. 25 shows an example of a system 2500 that can include one or more computing systems 2501-1 , 2501-2, 2501-3 and 2501-4, which may be operatively coupled via one or more networks 2509, which may include wired and / or wireless networks. As shown, the system 2500 may include one or more other components 2508.

[0190] As an example, a system can include an individual computer system or an arrangement of distributed computer systems. In the example of FIG. 25, the computer system 2501-1 can include one or more modules 2502, which may be or include processor-executable instructions, for example, executable to perform varioustasks (e.g., receiving information, requesting information, processing information, simulation, outputting information, etc.).

[0191] As an example, a module may be executed independently, or in coordination with, one or more processors 2504, which is (or are) operatively coupled to one or more storage media 2506 (e.g., via wire, wirelessly, etc.). As an example, one or more of the one or more processors 2504 can be operatively coupled to at least one of one or more network interface 2507. In such an example, the computer system 2501-1 can transmit and / or receive information, for example, via the one or more networks 2509 (e.g., consider one or more of the Internet, a private network, a cellular network, a satellite network, etc.). As shown, one or more other components 2508 can be included.

[0192] As an example, the computer system 2501-1 may receive from and / or transmit information to one or more other devices, which may be or include, for example, one or more of the computer systems 2501-2, etc. A device may be located in a physical location that differs from that of the computer system 2501 -1. As an example, a location may be, for example, a processing facility location, a data center location (e.g., serverfarm, etc.), a rig location, a wellsite location, a downhole location, etc.

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

[0194] As an example, the storage media 2506 may be implemented as one or more computer-readable or machine-readable storage media. As an example, storage may be distributed within and / or across multiple internal and / or external enclosures of a computing system and / or additional computing systems.

[0195] As an example, a storage medium or storage media may include one or more different forms of memory including semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and flash memories, magnetic disks such as fixed, floppy and removable disks, other magnetic media including tape,optical media such as compact disks (CDs) or digital video disks (DVDs), BLUERAY disks, or other types of optical storage, or other types of storage devices.

[0196] As an example, a storage medium or media may be located in a machine running machine-readable instructions, or located at a remote site from which machine-readable instructions may be downloaded over a network for execution.

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

[0198] As an example, a system may include a processing apparatus that may be or include a general-purpose processors or application specific chips (e.g., or chipsets), such as ASICs, FPGAs, PLDs, or other appropriate devices.

[0199] As an example, a device may be a mobile device that includes one or more network interfaces for communication of information. For example, a mobile device may include a wireless network interface (e.g., operable via IEEE 802.11 , ETSI GSM, BLUETOOTH, satellite, etc.). As an example, a mobile device may include components such as a main processor, a memory, a display, display graphics circuitry (e.g., optionally including touch and gesture circuitry), a SIM slot, audio / video circuitry, motion processing circuitry (e.g., accelerometer, gyroscope), wireless LAN circuitry, smart card circuitry, transmitter circuitry, GPS circuitry, and a battery. As an example, a mobile device may be configured as a cell phone, a tablet, etc. As an example, a method may be implemented (e.g., wholly or in part) using a mobile device. As an example, a system may include one or more mobile devices.

[0200] As an example, a system may be a distributed environment, for example, a so-called “cloud” environment where various devices, components, etc. interact for purposes of data storage, communications, computing, etc. As an example, a device or a system may include one or more components for communication of information via one or more of the Internet (e.g., where communication occurs via one or more Internet protocols), a cellular network, a satellite network, etc. As an example, a method may be implemented in a distributed environment (e.g., wholly or in part as a cloud-based service).

[0201] As an example, information may be input from a display (e.g., consider a touchscreen), output to a display or both. As an example, information may be output to a projector, a laser device, a printer, etc. such that the information may be viewed. As an example, information may be output stereographically or holographically. As to a printer, consider 2D or a 3D printer. As an example, a 3D printer may include one or more substances that can be output to construct a 3D object. For example, data may be provided to a 3D printer to construct a 3D representation of a subterranean formation. As an example, layers may be constructed in 3D (e.g., horizons, etc.), geobodies constructed in 3D, etc. As an example, holes, fractures, etc., may be constructed in 3D (e.g., as positive structures, as negative structures, etc ).

[0202] Although only a few example embodiments have been described in detail above, those skilled in the art will readily appreciate that many modifications are possible in the example embodiments. Accordingly, all such modifications are intended to be included within the scope of this disclosure as defined in the following claims. In the claims, means-plus-function clauses are intended to cover the structures described herein as performing the recited function and not only structural equivalents, but also equivalent structures. Thus, although a nail and a screw may not be structural equivalents in that a nail employs a cylindrical surface to secure wooden parts together, whereas a screw employs a helical surface, in the environment of fastening wooden parts, a nail and a screw may be equivalent structures.

Claims

CLAIMSWhat is claimed is:

1. A method comprising: receiving workflow specifications for an operational workflow performed using equipment in a field to produce hydrocarbons; configuring a dynamic reservoir simulation system according to the workflow specifications; receiving, by the dynamic reservoir simulation system, field data from the equipment; responsive to receipt of the field data, updating a model representative of one or more hydrocarbon production related physical phenomena in the field to generate an updated model of the dynamic reservoir simulation system; generating model-based results using the updated model; assessing quality of the model-based results to generate one or more quality metrics; and outputting, based at least in part on the model-based results, a control action for the operational workflow and at least one of the one or more quality metrics.

2. The method of claim 1 , wherein the model comprises a dynamic reservoir simulation model and wherein the generating implements a reservoir simulator using the dynamic reservoir simulation model.

3. The method of claim 2, wherein the assessing quality comprises comparing the model-based results to measured field data and subjecting the model to geologic and engineering assessments using domain-derived rules.

4. The method of claim 1 , wherein the model comprises a proxy model of a reservoir simulation model and wherein the generating implements the proxy model.

5. The method of claim 4, wherein the assessing quality comprises comparing the model-based results of the proxy model to previously generated model-based results of the reservoir simulation model.

6. The method of claim 1 , wherein the model-based results comprise forecast results for hydrocarbon production and fluid injection responsive to implementation of the control action.

7. The method of claim 1 , wherein the dynamic reservoir simulation system comprises one or more of an automated model update service, a model confidence analysis service, a forecast service, an optimization service, a model proxy generation service, a model management service, and a recommendation service.

8. The method of claim 1 , wherein the dynamic reservoir simulation system comprises services that operate according to the workflow specifications to generate the modelbased results and the control action.

9. The method of claim 8, wherein the outputting comprises generating instructions to render a graphical user interface to present the control action, wherein the graphical user interface comprises at least one graphical control actuatable for issuance of the control action to the equipment in the field.

10. The method of claim 1 , wherein the dynamic reservoir simulation system instantiates, according to the workflow specifications, a dynamic reservoir engineering cluster interoperable with an engine ecosystem that is operatively coupled to a reservoir simulation framework.11 . The method of claim 10, wherein the engine ecosystem comprises one or more of a model update engine, a model confidence engine and a model forecast engine.

12. The method of claim 10, wherein the dynamic reservoir engineering cluster comprises components for rendering of a dashboard for the operational workflow, wherein the dashboard interfaces with one or more backend services.

13. The method of claim 12, wherein the one or more backend services respond to one or more application programming interface calls to perform one or more of accessing data and generating structures for visualization via the dashboard as a frontend.

14. The method of claim 12, wherein the dashboard comprises at least one graphical control actuatable to trigger one or more automated processes.

15. The method of claim 14, wherein the one or more automated processes comprise one or more of a model update processing using a model update engine hosted by an engine ecosystem, a model confidence engine hosted by an engine ecosystem and a model forecast engine hosted by an engine ecosystem.

16. The method of claim 1 , wherein the operational workflow comprises an enhanced oil recovery workflow.

17. The method of claim 16, wherein the enhanced oil recovery workflow comprises water injection to enhance hydrocarbon production.

18. The method of claim 1 , wherein the dynamic reservoir simulation system is located remote from the field and wherein the equipment comprises at least one gateway system that is operatively coupled to the dynamic reservoir simulation via one or more networks.

19. A system comprising: a processor; a memory accessible to the processor;processor-executable instructions stored in the memory and executable by the processor to instruct the system to: receive workflow specifications for an operational workflow performed using equipment in a field to produce hydrocarbons; configure the system according to the workflow specifications; receive field data from the equipment; responsive to receipt of the field data, update a model representative of one or more hydrocarbon production related physical phenomena in the field to generate an updated model; generate model-based results using the updated model; assess quality of the model-based results to generate one or more quality metrics; and output, based at least in part on the model-based results, a control action for the operational workflow and at least one of the one or more quality metrics.

20. One or more computer-readable media comprising computer-executable instructions executable by a system to instruct the system to: receive workflow specifications for an operational workflow performed using equipment in a field to produce hydrocarbons; configure the system according to the workflow specifications; receive field data from the equipment; responsive to receipt of the field data, update a model representative of one or more hydrocarbon production related physical phenomena in the field to generate an updated model; generate model-based results using the updated model; assess quality of the model-based results to generate one or more quality metrics; and output, based at least in part on the model-based results, a control action for the operational workflow and at least one of the one or more quality metrics.

Images