THROUGH CONCEPT GENERATION

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent App. No. 63/376,226, filed on September 19, 2022, and titled "System For Automated Model Building And Scenario Evaluation Through Concept Generation," which is incorporated herein by reference in its entirety for all purposes.

BACKGROUND

[0002] Geological modeling may involve usage of a development plan/concept which can include, for example, placement data associated with wells in a reservoir, placement data associated with one or more drill centers on a surface associated with the reservoir, routing data associated with one or more pipelines connecting the reservoir to processing facilities, etc. An oil and gas operator may need to evaluate many such development plans to select an optimal solution that meets certain considerations. Determining such optimal solutions is often a challenging process because well placement operations, drill center placement activities, well design and facilities placement projects, as well as pipeline routing undertakings are all carried out by a plurality of different teams using a plurality of different tools that usually do not have a common context.

[0003] Moreover, information exchange between the plurality of different teams is often manual and very inefficient. At best, coordination between the plurality of different teams associated with development plans is particularly slow. At worst, different assumptions are sometimes made within each team comprised in the plurality of different teams making it extremely difficult and sometimes infeasible to harmonize, coordinate, or otherwise fit various design elements associated with the aforementioned different assumptions together. Consequently, this leads to inconsistent or conflicting scenarios that frustrate development projects at resource sites (e.g., an oil field, a seabed with subterranean oil formations, etc.). For example, a reservoir team may provide well targets which cannot be drilled by the drilling team because the reservoir team and the drilling team are not completely aligned, in real-time or near real-time, on the exploratory considerations or assumptions being made for the resource site in question. There is, therefore, a need to develop computational tools that can harmonize and/or provide holistic strategies across multiple development teams associated with resource site projects.

SUMMARY

[0004] The embodiments described herein include methods, systems, and computer programs for generating a plurality of development plans associated with a drilling design model, a subsea design model, and a subsurface model for a resource site.

[0005] According to one embodiment, the disclosed methods include: generating a first framework, the first framework including a structure that enables interaction with data associated with a plurality of domains of the resource site by a user; generating a second framework, the second framework including one or more modules of a signal processing engine that communicatively coordinate execution of a plurality of computing operations on the data associated with the plurality of domains of the resource site; and developing, using a first module comprised in the one or more modules, a drilling design model for the resource site, the drilling design model being characterized by at least one of: development scenario parameters that automatically configure a well construction tool, development plan description options that are used to automatically generate a list of well construction equipment, and a well construct including well property data that define a well associated with the resource site. The methods also include: executing, using the first module, a simulation operation based on the drilling design model to generate well design data (e.g., an example of a development plan), the well design data indicating at least one of: an equipment listing for the well, drilling duration data for the well, or cost data associated with developing the well; and initiating, using the computer processor and the first framework, generation of a visualization of the well design data for viewing and interaction by the user on a graphical user interface.

[0006] In another embodiment, a system and a computer program can include or execute the method described above. These and other implementations may each optionally include one or more of the following features.

[0007] In one example, a plurality of domains can comprises a plurality of specialization areas associated with developing the resource site. For example, the plurality of specialization areas may include one or more of: reservoir design operations; well configuration operations; or flow line set-up operations.

[0008] Furthermore, the first framework can provide interfaces and data structures that enable: reception of data from the plurality of domains; and displaying output data based on operations executed by at least one module of the signal processing engine.

[0009] In addition, the second framework can enable parameterizing the drilling design model by the user via an application programming interface.

[0010] According to some embodiments, the drilling design model may be generated using a skeleton development structure which comprises initial development data structures based on map-based inputs that are enhanced using the parameterizing.

[0011] In some cases, the map-based inputs include data that indicate one or more of: net hydrocarbon thickness; reservoir horizons for azimuthal well placement; and surface topology.

[0012] In another embodiment, the disclosed methods include generating a first framework, the first framework including a structure that enables interaction with data associated with a plurality of domains of the resource site by a user; generating a second framework, the second framework including one or more modules of a signal processing engine such that the one or more modules of the signal processing engine communicatively coordinate execution of a plurality of computing operations on the data associated with the plurality of domains of the resource site; receiving, using the first framework, equipment layout data associated with a subsea design operation for the resource site; and executing, using a first module comprised in the one or more modules of the signal processing engine, an associative operation that models an interconnection between one or more exploratory systems associated with the subsea design operation. The methods may further include generating, using based on the associative operation, a subsea design model for the resource site; executing, using the computer processor and the first module, a simulation operation based on the subsea design model to generate subsea design data (e.g., an example of a development plan), the subsea design data comprising: subsea equipment layout data, projected cost data associated with the subsea equipment layout data, projected schedule data indicating an implementation timeline for the subsea design layout data; and initiating, using the first framework, generation of a visualization of the subsea design data for viewing and interaction by the user on a graphical user interface.

[0013] In another embodiment, a system and a computer program can include or execute the method described above. These and other implementations may each optionally include one or more of the following features.

[0014] According to one embodiment, the plurality of domains discussed above comprises a plurality of specialization areas associated with developing the resource site. The plurality of specialization areas may include one or more of: reservoir design operations; well configuration operations; or flow line set-up operations.

[0015] The first module may comprise an application that automatically formats a layout of a development construct, structure, or model associated with the subsea design operation.

[0016] Furthermore, the interconnection of the one or more exploratory systems associated with the subsea design operation may be based on a link or digital connection which enables a two-way application programming interface (API) communication using the first framework and the second framework.

[0017] In other embodiments, the methods include generating a first framework, the first framework including a structure that enables interaction with data associated with a plurality of domains of the resource site by a user; generating a second framework, the second framework including one or more modules of a signal processing engine such that the one or more modules of the signal processing engine communicatively coordinate execution of a plurality of computing operations on the data associated with the plurality of domains of the resource site; and receiving equipment layout data and parameterization data of a reservoir associated with the resource site. The methods also include generating, using a first module comprised in the one or more modules of the signal processing engine, a subsurface model that is parameterized using a set of development scenario parameters; executing, using the first module, a simulation operation based on the subsurface model to generate subsurface production data (e.g., an example of a development plan) including a production forecast for the reservoir; and initiating, using the first framework, generation of a visualization of the production forecast for viewing and interaction by the user on a graphical user interface. [0018] In another embodiment, a system and a computer program can include or execute the method described above. These and other implementations may each optionally include one or more of the following features.

[0019] It is appreciated that the development scenario parameters discussed above include one or more of: well phasing data; or flowrate constraints data.

[0020] Furthermore, the subsurface model, according to one embodiment, is a reservoir model that is parameterized by the set of development scenario parameters; the set of development parameters comprising one or more of: phasing data indicating a production schedule for a well coupled to a reservoir associated with the reservoir model, and flowrate constraint data including well production rate data or well injection rate data associated with the well coupled to the reservoir.

[0021] In addition, the above methods further comprise: validating a parameterization operation executed on the subsurface model based on a development construct description and the development scenario parameters; and executing, using the computer processor and the first module comprised in the one or more modules of the signal processing engine, the simulation operation to generate the subsurface production data.

[0022] In some embodiments, the plurality of domains discussed above comprises a plurality of specialization areas associated with developing the resource site, the plurality of specialization areas including one or more of: reservoir design operations; well configuration operations; or flow line set-up operations.

BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The disclosure is illustrated by way of example, and not by way of limitation in the figures of the accompanying drawings in which like reference numerals are used to refer to similar elements. It is emphasized that various features may not be drawn to scale and the dimensions of various features may be arbitrarily increased or reduced for clarity of discussion. [0024] FIG. 1A shows an exemplary pipeline layout for a resource site derived from a development plan, according to some embodiments.

[0025] FIG. IB provides exemplary workflows for generating and using a development plan, according to some embodiments. [0026] FIG. 2 shows an exemplary cross-sectional view of a resource site.

[0027] FIG. 3 shows an exemplary networked system illustrating a communicative coupling of devices or systems associated with the resource site of FIG. 2.

[0028] FIGS. 4A-1 to 4B-2 provide exemplary visualizations discussed in conjunction with one or more embodiments provided in this disclosure.

[0029] FIG. 4C provides exemplary workflow associated with one or more embodiments provided in this disclosure.

[0030] FIG. 5 provides an exemplary workflow associated with one or more embodiments provided in this disclosure.

[0031] FIG. 6 shows an exemplary instance where an input map is applied or received by the development plan generator and for which an equipment placement map and a topology map are generated.

[0032] FIG. 7 provides an exemplary workflow for generating or designing a drilling design model associated with a development plan, according to some embodiments.

[0033] FIG. 8 provides an exemplary workflow for generating a subsea design model associated with a development plan, according to some embodiments.

[0034] FIG. 9 provides an exemplary workflow for generating a subsurface model associated with a development plan, according to some embodiments.

DETAILED DESCRIPTION

[0035] Reference will now be made in detail to embodiments, examples of which are illustrated in the accompanying drawings and figures. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be apparent to one of ordinary skill in the art that the invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

[0036] The disclosed systems and methods may be accomplished using interconnected devices and systems that obtain a plurality of data associated with various parameters of interest at a resource site. The workflows/flowcharts described in this disclosure, according to some embodiments, implicate a new processing approach (e.g., hardware, special purpose processors, and specially programmed general -purpose processors) because such analyses are too complex and cannot be done by a person in the time available or at all. Thus, the described systems and methods are directed to tangible implementations or solutions to specific technological problems in exploring natural resources such as oil, gas, water well industries, and other mineral exploration operations. More specifically, the systems and methods presently disclosed may be applicable to exploring resources such as oil, natural gas, water, and Salar brines.

[0037] Attention is now directed to methods, techniques, infrastructure, and workflows for operations that may be carried out at a resource site. Some operations in the processing procedures, methods, techniques, and workflows disclosed herein may be combined while the order of some operations may be changed. Some embodiments include an iterative refinement of one or more data associated with the resource site via feedback loops executed by one or more computing device processors and/or through other control devices/mechanisms that make determinations regarding whether a given action, template, or resource data, etc., is sufficiently accurate.

[0038] The present disclosure addresses a number of problems. In one embodiment, the disclosed technology provides an orchestration framework that automates the flow of data and outcomes between domains (e.g., two or more areas of specialty associated with the exploratory efforts) to drastically reduce the time required to evaluate integrated development scenarios for a given resource site. Additionally, the present disclosure provides a novel technique that automatically generates complete and feasible development plans for developing a resource site. For instance, FIG. 1A provides an exemplary development plan generated using the disclosed techniques. In particular, the development plan of FIG. 1A includes a visualization of a geological formation that has a plurality of wells, a plurality of drill centers, and a plurality of drilling trajectories all of which are tied to pipelines 102a - 102e of the resource site.

[0039] In one embodiment, the orchestration framework coordinates the operation of a plurality of software applications associated with a development plan. Specifically, the orchestration framework may be structured to have one or more data inputs with attendant one or more application services for building the development plan. Data may be pushed from the one or more data inputs into the one or more application services to generate one or more outputs. In some implementations, the sequence of pushing a data input into a specific application service (e.g., a specific workflow) to generate a specific output comprises an atomic operation that can be chained to other atomic operations associated with the orchestration framework to create an end-to-end workflow. In combination with the orchestration framework, a feasible development plan may be automatically pushed into domain applications (e.g., applications associated with a specific domain) which can build and execute modeling operations (e.g., simulations) using domain models (e.g., models associated with a specific domain) and provide outcomes for consumption downstream. For example, well trajectory data can be passed into a drilling application (e.g., DrillPlan) which may generate detailed drill design output data (e.g., drill design visualization). The drilling application may further process the trajectory data and automatically generate an implementations schedule report (e.g., a report including a timeline for implementing the design output data) with associated estimates for evaluating the impact of one or more exploratory activities. This enables operators to move from inefficient manual silo-based models (e.g., models that often rely on offline integration for decision metrics) to optimal automatic large scale models that integrate a plurality of domain data for conducting evaluation operations associated with developing a resource site.

[0040] Moreover, a development plan comprising data associated with one or more domain-specific design and development operations may be automatically generated based on domain inputs from multiple domains comprising different areas of specialty (e.g., specializations) associated with the resource site. In one embodiment, the different areas of specialty include reservoir design operations, well configuration operations, flow line set-up operations, etc. In some cases, models may be generated for each area of specialty such that said models may be parameterized by, for example, third-parties via one or more application programming interfaces (APIs) as further discussed below.

[0041] Furthermore, the models corresponding to each area of specialty may be integrated to provide holistic analysis data associated with exploratory activities at a resource site. This can enable a cross discipline team (e.g., a team that can leverage data from one or more domains) to ensure all required constraints are implicated in the overall generated design data associated with the resource site. For example, the overall generated design data may comprise a development plan that can be used to initiate well placement operations that ensure that wells are not placed in poor preforming reservoir sections (e.g., reservoir sections whose estimated production output has low production probabilities) of the reservoir. The development plan may also be used, for example, to initiate optimal pipeline layout operations that ensure that drill centers and pipelines are not placed in unfeasible areas (e.g., environmentally protected or restricted areas, etc.) associated with reservoir. In addition, the development plan may further be used to initiate drilling operations at the resource stie that ensure that placed wells are drillable. It is appreciated that production probabilities, drill center and pipeline placement locations, and well drilling assessments, are provided as exemplary uses of the development plan.

[0042] In one embodiment, the development plan feasibly integrates or otherwise comprises or accounts for a plurality of models from a plurality of domains. This addresses the problem outlined above regarding resolving disconnects between domains to facilitate consistent design and implementation outcomes associated with a resource site as further discussed in FIG. IB.

[0043] FIG. IB shows an exemplary workflow associated with generating a development plan. According to one embodiment, the development plan generation workflow includes determining a data source at block 110 for obtaining input values that can be used to parameterize a computing or data model associated with a resource site. One or more development scenarios may be determined or evaluated, at block 112 for the data received from the determined data source under one or more uncertainty conditions (e.g., conditions defined by uncertainty parameters) associated with the data model. According to one embodiment, a concept/plan definition may be generated at block 114 for the evaluated data under the one or more uncertainty conditions. The concept/plan definition, for example, may comprise a file, a document, or a report indicating one or more wells, one or more pipelines, and/or one or more facilities associated with energy development or energy exploration activities at a resource site. The file, document, or report may serve as basis for configuring or parameterizing the data model. In some implementations, the concept/plan definition may leverage design data such as maximum number of wells for the resource site, well step out data for the resource site, deployment type (e.g., hierarchical vs daisy chain) of one or more domains associated with the resource site, etc. In one embodiment, the method includes generating a development plan by configuring or customizing the data model using the concept/plan definition. Furthermore, a forecasting process may be applied to the development plan, at block 116, to generate a production forecast based on the concept definition. [0044] According to some implementations, the development plan may also be subjected to a well activity planning process at block 122 to develop one or more well development plans for the resource site. It is appreciated that the development plan may also be subjected to an analysis process at block 124a to generate a subsea equipment list for the resource site. One or more visualizations may be generated at block 124b to indicate infrastructure (e.g., subsea infrastructure) based on the generated equipment list derived from the development plan at block 124a. As can be appreciated from FIG. IB, the development plan, which includes a computing development model for the resource site, may be subjected to a plurality of forecasting computing operations or other modeling operations (e.g., blocks 116, 118, 120, 122, 126 and 128) to generate outputs that can be ingested or used for additional analysis and/or generate visualizations (e.g., block 124b and 130) downstream. Moreover, the data ingestion cases outlined above have a plurality of description data associated with energy development such as well description data associated with one or more wells, trajectory description data associated with one or more trajectories, drill centers description data associated with one or more drill centers, and pipeline routing data associated with one or more pipelines. In some cases, the plurality of description data and/or the development plan may be formatted or otherwise structured in specific file formats (e.g., lavaScript Object Notation (JSON) file format) to ensure consistent outputs.

[0045] The disclosed technology beneficially provides a number of advantages. For example, the disclosed technology significantly reduces the time required to evaluate a given development scenario associated with a resource site based on the development plan. In particular, the present disclosure provides methods that enable real-time or near real-time development evaluations to be made, using a development plan, for a given development scenario and thereby quickly project cycle times (e.g., schedule data) for developing the resource site. Furthermore, the disclosed systems and methods enable a plurality of development plans (e.g., computing models associated with a resource site) to be quickly evaluated with fewer resources. Specifically, the disclosed technology does not rely on cumbersome and often inaccurate manual development coordination efforts associated with resource site development which are not only slow and costly but are also inefficient and resource intensive. More specifically, the present disclosure provides a platform that seamlessly and efficiently coordinates development efforts associated with the resource site, using a development plan which ensures data visibility for all stake-holders of various domains associated with the resource site by using optimized computing models, processes, and workflows. Another significant benefit provided by the technology disclosed is the elimination or significant risk reduction of cross-domain inconsistencies by using a shared or unifying infrastructure that integrates or leverages data from all domains associated with developing the resource site to generate accurate data for creating development plan outputs.

Resource Site

[0046] FIG. 2 shows an exemplary cross-sectional view of a resource site 200 which has been configured using a specific layout of various equipment based on a generated development plan using one or more workflows provided in this disclosure. While the illustrated resource site 200 represents a subterranean formation, the resource site, according to some embodiments, may be below water bodies such as oceans, seas (e.g., seabed), lakes, ponds, wetlands, rivers, etc. According to one embodiment, various measurement tools capable of sensing one or more parameters such as seismic two-way travel time, density, resistivity, production rate, etc., of a subterranean formation and/or geological formations may be provided at the resource site. As an example, wireline tools may be used to obtain measurement information related to geological attributes (e.g., geological attributes of a wellbore and/or reservoir) including geophysical and/or geochemical information associated with the resource site 200. In some embodiments, various sensors may be located at various locations around the resource site 200 to monitor and collect data for executing the process of FIG. IB.

[0047] Part, or all, of the resource site 200 may be on land, on water, or below water. In addition, while a resource site 200 is depicted, the technology described herein may be used with any combination of one or more resource sites (e.g., multiple oil fields or multiple wellsites, etc.), one or more processing facilities, etc. As can be seen in FIG. 2, the resource site 200 may have data acquisition tools 202a, 202b, 202c, and 202d positioned at various locations within the resource site 200. The subterranean structure 204 may have a plurality of geological formations 206a-206d. As shown, this structure may have several formations or layers, including a shale layer 206a, a carbonate layer 206b, a shale layer 206c, and a sand layer 206d. A fault 207 may extend through the shale layer 206a and the carbonate layer 206b. The data acquisition tools, for example, may be adapted to take measurements and detect geophysical and/or geochemical characteristics of the various formations shown.

[0048] While a specific subterranean formation with specific geological structures is depicted, it is appreciated that the oil field 200 may contain a variety of geological structures and/or formations, sometimes having extreme complexity. In some locations of a given geological structure, for example below a water line relative to the given geological structure, fluid may occupy pore spaces of the formations. Each of the measurement devices may be used to measure properties of the formations and/or other geological features. While each data acquisition tool is shown as being in specific locations in FIG. 2, it is appreciated that one or more types of measurement may be taken at one or more locations across one or more sources of the resource site 200 or other locations for comparison and/or analysis. The data collected from various sources at the resource site 200 may be processed and/or evaluated and/or used as training data, and or used to generate high resolution result sets for characterizing a resource at the resource site, and/or used for generating resource models, etc. In one embodiment, the data collected by one or more sensors at the resource site may include data associated with the number of wells of a first reservoir or second reservoir at the resource site, data associated with the number of grid cells of the first or second reservoir, data associated with the average permeability of the first or second reservoir, data associated with the production duration history (e.g., number of years of production) of the first reservoir or a second reservoir, etc.

[0049] Data acquisition tool 202a is illustrated as a measurement truck, which may comprise devices or sensors that take measurements of the subsurface through sound vibrations such as, but not limited to, seismic measurements. Drilling tool 202b may include a downhole sensor adapted to perform logging while drilling (LWD) data collection. Wireline tool 202c may include a downhole sensor deployed in a wellbore or borehole. Production tool 202d may be deployed from a production unit or Christmas tree into a completed wellbore. Examples of parameters that may be measured include weight on bit, torque on bit, subterranean pressures (e.g., underground fluid pressure), temperatures, flow rates, compositions, rotary speed, particle count, voltages, currents, and/or other parameters of operations as further discussed below.

[0050] Sensors may be positioned about the oil field 200 to collect data relating to various oil field operations, such as sensors deployed by the data acquisition tools 202. The sensors may include any type of sensors such as a metrology sensor e.g., temperature, humidity), an automation enabling sensor, an operational sensor (e.g., pressure sensor, H2S sensor, thermometer, depth, tension), an evaluation sensor, that can be used for acquiring data regarding the formation, wellbore, formation fluid/gas, wellbore fluid, gas/oil/water comprised in the formation/wellbore fluid, or any other suitable sensor. For example, the sensors may include accelerometers, flow rate sensors, pressure transducers, electromagnetic sensors, acoustic sensors, temperature sensors, chemical agent detection sensors, nuclear sensor, and/or any additional suitable sensors. In one embodiment, the data captured by the one or sensors may be used to characterize, or otherwise generate one or more parameter values for a high resolution result set used to, for example, generate a resource model. In other embodiments, test data or synthetic data may also be used in developing the resource model via one or more simulations such as those discussed in association with the flowcharts presented herein.

[0051] Evaluation sensors may be featured in downhole tools such as tools 202b-202d and may include for instance electromagnetic, acoustic, nuclear, and optic sensors. Examples of tools including evaluation sensors that can be used in the framework of the current method include electromagnetic tools including imaging sensors such as FMI™ or QuantaGeo™ (mark of Schlumberger, Houston, TX); induction sensors such as Rt Scanner™ (mark of Schlumberger, Houston, TX), multifrequency dielectric dispersion sensor such as Dielectric Scanner™ (mark of Schlumberger, Houston, TX); acoustic tools including sonic sensors, such as Sonic Scanner™ (mark of Schlumberger, Houston, TX) or ultrasonic sensors, such as pulseecho sensor as in UBI™ or PowerEcho™ (marks of Schlumberger, Houston, TX) or flexural sensors PowerFlex™ (mark of Schlumberger, Houston, TX); nuclear sensors such as Litho Scanner™ (mark of Schlumberger, Houston, TX) or nuclear magnetic resonance sensors; fluid sampling tools including fluid analysis sensors such as InSitu Fluid Analyzer ™ (mark of Schlumberger, Houston, TX); distributed sensors including fiber optic. Such evaluation sensors may be used in particular for evaluating the formation in which the well is formed (/.< ., determining petrophysical or geological properties of the formation), for verifying the integrity of the well (such as casing or cement properties) and/or analyzing the produced fluid (flow, type of fluid, etc.).

[0052] As shown, data acquisition tools 202a-202d may generate data plots or measurements 208a-208d, respectively. These data plots are depicted within the resource site 200 to demonstrate that data generated by some of the operations executed at the resource site

200.

[0053] Data plots 208a-208c are examples of static data plots that may be generated by data acquisition tools 202a-202c, respectively. However, it is herein contemplated that data plots 208a-208c may also be data plots that may be generated and updated in real time. These measurements may be analyzed to better define properties of the formation(s) and/or determine the accuracy of the measurements and/or check for and compensate for measurement errors. The plots of each of the respective measurements may be aligned and/or scaled for comparison and verification purposes. In some embodiments, base data associated with the plots may be incorporated into site planning, modeling a test at the resource site 200. The respective measurements that can be taken may be any of the above.

[0054] Other data may also be collected, such as historical data of the resource site 200 and/or sites similar to the resource site 200, user inputs, information (e.g., economic information) associated with the resource site 200 and/or sites similar to the resource site 200, and/or other measurement data and other parameters of interest. Similar measurements may also be used to measure changes in formation aspects over time.

[0055] Computer facilities such as those discussed in association with FIG. 3 may be positioned at various locations about the resource site 200 (e.g., a surface unit) and/or at remote locations. A surface unit (e.g., one or more terminals 320) may be used to communicate with the onsite tools and/or offsite operations, as well as with other surface or downhole sensors. The surface unit may be capable of sending commands to the oil field equipment/systems, and receiving data therefrom. The surface unit may also collect data generated during production operations and can produce output data, which may be stored or transmitted for further processing.

[0056] The data collected by sensors may be used alone or in combination with other data. The data may be collected in one or more databases and/or transmitted on or offsite. The data may be historical data, real time data, or combinations thereof. The real time data may be used in real time, or stored for later use. The data may also be combined with historical data or other inputs for further analysis or for modeling purposes to optimize production processes at the oil field 200. In one embodiment, the data is stored in separate databases, or combined into a single database. High-Level Networked System

[0057] FIG. 3 shows a high-level networked system diagram illustrating a communicative coupling of devices or systems associated with the resource site 200. The system shown in the figure may include a set of processors 302a, 302b, and 302c for executing one or more processes discussed herein. The set of processors 302 may be electrically coupled to one or more servers (e.g., computing systems) including memory 306a, 306b, and 306c that may store for example, program data, databases, and other forms of data. Each server of the one or more servers may also include one or more communication devices 308a, 308b, and 308c. The set of servers may provide a cloud-computing platform 310. In one embodiment, the set of servers includes different computing devices that are situated in different locations and may be scalable based on the needs and workflows associated with the oil field 200. The communication devices of each server may enable the servers to communicate with each other through a local or global network such as an Internet network. In some embodiments, the servers may be arranged as a town 312, which may provide a private or local cloud service for users. A town may be advantageous in remote locations with poor connectivity. Additionally, a town may be beneficial in scenarios with large networks where security may be of concern. A town in such large network embodiments can facilitate implementation of a private network within such large networks. The town may interface with other towns or a larger cloud network, which may also communicate over public communication links. Note that cloud-computing platform 310 may include a private network and/or portions of public networks. In some cases, a cloud-computing platform 310 may include remote storage and/or other application processing capabilities.

[0058] The system of FIG. 3 may also include one or more user terminals 314a and 314b each including at least a processor to execute programs, a memory (e.g., 316a and 316b) for storing data, a communication device and one or more user interfaces and devices that enable the user to receive, view, and transmit information. In one embodiment, the user terminals 314a and 314b is a computing system having interfaces and devices including keyboards, touchscreens, display screens, speakers, microphones, a mouse, styluses, etc. The user terminals 314 may be communicatively coupled to the one or more servers of the cloud- computing platform 310. The user terminals 314 may be client terminals or expert terminals, enabling collaboration between clients and experts through the system of FIG. 3.

[0059] The system of FIG. 3 may also include at least one or more oil fields 200 having, for example, a set of terminals 320, each including at least a processor, a memory, and a communication device for communicating with other devices communicatively coupled to the cloud-computing platform 310. The resource site 200 may also have one or more sensors (e.g., one or more sensors described in association with FIG. 2) or sensor interfaces 322a and 322b communicatively coupled to the set of terminals 320 and/or directly coupled to the cloudcomputing platform 310. In some embodiments, data collected by the one or more sensors/sensor interfaces 322a and 322b may be processed to generate a one or more resource models (e.g., reservoir models) or one or more resolved data sets used to generate the resource model which may be displayed on a user interface associated with the set of terminals 320, and/or displayed on user interfaces associated with the set of servers of the cloud computing platform 310, and/or displayed on user interfaces of the user terminals 314. Furthermore, various equipment/devices discussed in association with the resource site 200 may also be communicatively coupled to the set of terminals 320 and or communicatively coupled directly to the cloud-computing platform 310. The equipment and sensors may also include one or more communication device(s) that may communicate with the set of terminals 320 to receive orders/instructions locally and/or remotely from the resource site 200 and also send statuses/updates to other terminals such as the user terminals 314.

[0060] The system of FIG. 3 may also include one or more client servers 324 including a processor, memory and communication device. For communication purposes, the client servers 324 may be communicatively coupled to the cloud-computing platform 310, and/or to the user terminals 314a and 314b, and/or to the set of terminals 320 at the resource site 200 and/or to sensors at the oil field, and/or to other equipment at the resource site 200.

[0061] A processor, as discussed with reference to the system of FIG. 3, may include a microprocessor, a graphical processing unit (GPU), a microcontroller, a processor module or subsystem, a programmable integrated circuit, a programmable gate array, or another control or computing device.

[0062] The memory/storage media discussed above in association with FIG. 3 can be implemented as one or more computer-readable or machine-readable storage media that are non-transitory. In some embodiments, storage media may be distributed within and/or across multiple internal and/or external enclosures of a computing system and/or additional computing systems. 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), BluRays or any other type of optical media; or other types of storage devices. “Non-transitory” computer readable medium refers to the medium itself (i.e., tangible, not a signal) and not data storage persistency (e.g., RAM vs. ROM).

[0063] Note that instructions can be provided on one computer-readable or machine- readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes and/or non-transitory storage means. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). The storage medium or media can be located either in a computer system running the machine- readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution.

[0064] It is appreciated that the described system of FIG. 3 is an example that may have more or fewer components than shown, may combine additional components, and/or may have a different configuration or arrangement of the components. The various components shown may be implemented in hardware, software, or a combination of both, hardware and software, including one or more signal processing and/or application specific integrated circuits.

[0065] Further, the steps in the flowcharts described below may be implemented by running one or more functional modules in an information processing apparatus such as general-purpose processors or application specific chips, such as ASICs, FPGAs, PLDs, GPUs or other appropriate devices associated with the system of FIG. 3. For example, the flowchart of FIG. IB as well as the flowcharts below may be executed using a signal processing engine stored in memory 306a, 306b, or 306c such that the signal processing engine includes instructions that are executed by the one or more processors such as processors 302a, 302b, or 302c as the case may be. The various modules of FIG. 3, combinations of these modules, and/or their combination with general hardware are included within the scope of protection of the disclosure. While one or more computing processors (e.g., processors 302a, 302b, or 302c) may be described as executing steps associated with one or more of the flowcharts described in this disclosure, the one or more computing device processors may be associated with the cloudbased computing platform 310 and may be located at one location or distributed across multiple locations. In one embodiment, the one or more computing device processors may also be associated with other systems of FIG. 3 other than the cloud-computing platform 310.

[0066] In some embodiments, a computing system is provided that includes at least one processor, at least one memory, and one or more programs stored in the at least one memory, such that the programs comprise instructions, which when executed by the at least one processor, are configured to perform any method disclosed herein.

[0067] In some embodiments, a computer readable storage medium is provided, which has stored therein one or more programs, the one or more programs including instructions, which when executed by a processor, cause the processor to perform any method disclosed herein. In some embodiments, a computing system is provided that includes at least one processor, at least one memory, and one or more programs stored in the at least one memory for performing any method disclosed herein. In some embodiments, an information processing apparatus for use in a computing system is provided for performing any method disclosed herein.

Embodiments

[0068] One or more embodiments of this disclosure may include the following elements:

• a first framework for capturing development scenarios and uncertainties to be evaluated;

• a second framework for generating development plans and orchestrating data and workflows to evaluate scenarios and generate outcomes (output data);

• a workflow for populating and evaluating a detailed drilling design operation;

• a workflow for populating and evaluating a detailed subsea design operation; and

• a workflow for populating and evaluating a subsurface simulation forecasting operation. These and other aspects are further discussed below.

First Framework for Capturing Development Scenarios and Uncertainties [0069] The first framework, according to one embodiment, enables data reception, and/or data coordination from a plurality of domains associated with a resource site. In particular, the first framework can provide data reception mechanisms for receiving one or more development scenario data associated with a plurality of domains of a resource site. For example, the first framework may be tied to data sources that provide input data for a plurality of development scenarios associated with a development plan. For example, the data sources may include: domain data including well domain data and reservoir domain data associated with the resource site; and domain data indicating facility count and cost data associated with developing a resource from the resource. According to one embodiment, the data sources include data derived from one or more of: evaluation data indicating technical and/or economic analysis information associated exploratory operations and/or extractive operations for a resource at the resource site; evaluation data indicating technical and/or economic analysis information associated with moving or transporting or conveying a resource from the resource site; and evaluation data indicating technical and/or economic analysis information associated with processing and/or refining a resource from the resource site. For each development scenario comprised in the plurality of development scenarios, the input data may be captured and used to execute the necessary atomic operations associated with end-to-end workflows of the first framework or a second framework discussed. At this stage, one or more scenarios associated with executing development operations at the resource site may be defined or otherwise characterized together with corresponding uncertainties to generate a development plan. In one embodiment, the one or more scenarios represent and/or assess options data for implementing one or more operations (e.g., resource development operations) associated with the resource site. The one or more options data include, for example, number of wells, equipment layout structure for a subsea resource site, equipment layout structure for a surface resource site, quantitative and/or qualitative parameter data for equipment layout structures associated with the surface or subsurface resource sites, etc. An exemplary definition or characterization of scenarios include quantitatively and/or qualitatively specifying domain parameters such as well number, flow center number, pipeline length amount and trajectory, etc. as indicated in FIGS. 4A-1 to 4A-2. In particular, FIGS. 4A-1 to 4A-2 comprise an interface including a plurality of display elements on a graphical interface for receiving one or more inputs. The one or more inputs, for example, can specify domain parameters and creating data objects associated with capturing development scenarios and uncertainties and incorporating same to generate a development plan for a given resource site. For example, the plurality of display elements may include a first set 401 of display elements 402a-402b that are configured to include forms for entering and/or receiving quantitative and and/or qualitative data for one or more parameters associated with a given development scenarios together with relevant uncertainties required to parameterize the development plan. The plurality of display elements may also include a second set 403 of display elements 404a-404b that summarize the one or more parameters of a development plan being parameterized together with associated uncertainties. In particular, the second set 403 of display elements can visually provide a summary set up structure or configuration for all decisions associated with a given development plan. The plurality of display elements may further include a third set 405 of display elements 406a-406b that indicate a summary for a selected decision associated with the second set 403 of display elements. According to some embodiments, the various display elements of FIGS. 4A-1 to 4A-2 facilitate the generation of outcome and/or uncertainty data for each characterized scenario associated with a development plan. The outcome and/or uncertainty data may indicate, for example, a production amount (e.g., hydrocarbon production amount) or production characterization property of the resource site based on a defined scenario a resource site based on the development plan.

[0070] According to some embodiments, data inputs such as development consideration data with associated options data may be captured based on user objectives. This development consideration data and options data may be used to generate development scenarios that can be visualized in a scenario table as shown in the FIGS. 4B-1 to 4B-2. Specifically, FIG. 4B-1 to 4B-2 comprise a first set of display elements 407 that provide a tabular framing 408a and/or mapping 408b of specific scenarios to development considerations and options data used to characterize the development plan. In addition, a second set 409 of display elements may comprise outcome data 410a or a tabular indication 410b of the scenario-outcome mappings associated with testing and/or simulating the development plan.

[0071] In one embodiment, uncertainty data may be associated with or linked to specific data source(s) from which development scenarios are derived. For example, the specific data sources can comprise sources that provide cost information associated with one or more development scenarios, sources that provide staffing information associated with the one or more development scenarios, sources that provide development execution operations timeline information associated with the one or more development scenarios, etc. It is appreciated that information from one or more sources may include sensitivity data that characterize said sources to have high, medium, or low sensitivities for one or more computing or data models (e.g., developmental plans) associated with the first framework. According to one embodiment, the first framework may facilitate associating, linking, or mapping the one or more data sources including the uncertainty data with one or more development scenarios. The first framework additionally or optionally can enable selection and review of sample data used as input data for each model realization (e.g., a parameterized development plan) executed as part of a given development scenario evaluation.

Second Framework for Generating Development Plans and Orchestrating Data and Workflows

[0072] The second framework may comprise an orchestration framework that may enable data to flow between two or more automated workflows. In particular, the second framework may facilitate data interactions and/or data coordination and/or data integrations from a plurality of domains associated with the resource site. For example, the orchestration framework may facilitate data flow: between a workflow for populating and evaluating a detailed drilling design operation and a workflow for populating and evaluating a detailed subsea design operation; or between a workflow for populating and evaluating a detailed drilling design operation and a workflow for populating and evaluating a subsurface simulation forecasting operation.

[0073] In one embodiment, the orchestration framework may be comprised in a planning evaluation services component of a signal processing engine executing the various operations presented in this disclosure. Any combination of inputs, workflows and/or outcomes (e.g., output data) can be configured by the orchestration framework via one or more APIs. For example, FIG. 4C shows exemplary instances where various input data 420, 422, 424, 426, 428, and 430 are coordinated or otherwise configured to have various services 434, 436, 438, and 440 via a first services engine 432 of the orchestration framework. The various services 434, 436, 438, and 440 may, according to one embodiment, serve as inputs to a second services engine 442 of the orchestration framework. In the illustrated example, the second services engine 442 may analyze, combine, or otherwise synthesize the inputs 434, 436, 438, and 40 to generate a field layout service in the form of a report, and/or a visualization, and/or an equipment layout information for placing and/or configuring one or more equipment at a resource site. The specific set of services depicted in FIG. 4C may be part of a development plan generator module comprised in the signal processing engine/module mentioned above. The development plan generator module may generate data indicative of a complete field layout outlined in, for example, FIG. 1A.

[0074] According to one embodiment, the second framework comprises a development file generator or a development plan generator that is flexible and is extendible through one or more open application programming interfaces (APIs) to build large automated workflows based on user preferences and/or user parameterizations. In particular, FIG. 5 shows an exemplary relationship between a development plan/file generator 502 comprised in the second framework relative to one or more workflows 504 as well as analysis data associated with said workflows 506 and impact data 508.

[0075] The workflows, for example, may comprise: a first workflow for processing facilities associated with the resource site; a second workflow for executing subsea planning operations associated with the resource site; a third workflow for executing well planning operations associated with the resource site; and a fourth workflow for executing other subsurface operations associated with the resource site; a workflow for populating and evaluating a detailed drilling design operation; a workflow for populating and evaluating a detailed subsea design operation; and a workflow for populating and evaluating a subsurface simulation forecasting operation. It is appreciated that the one or more APIs may be accessed by the second framework via the development plan/file generator. After executing the necessary workflow comprised in the one or more workflows, a development plan may be generated based on the analysis data and/or impact data.

[0076] As outlined above, each development scenario may have a corresponding development plan (e.g., a development file) that may be generated. The development plan may comprise physical equipment data such: as data associated with placement of wells in the reservoir; data associated with placement of drill centers; data associated with the well trajectories; and data associated with subsea pipelines. The development plan may also include: data indicating attendant activities for the aforementioned data, schedule or timeline data for a given development scenario; and costs data for implementing the development scenario.

[0077] The foregoing structure of the first framework and/or second framework enables automatically generating “skeleton” development plans/structure which comprise fundamental/initial development data structures based on inputs (e.g., map-based inputs) that can be further enhanced or otherwise enriched based on user param eterizations. It is appreciated that a skeleton development plan is not a “final” development plan but rather serves as a starting point from which further domain-specific refinements may be applied to build an enhanced or complete development plan such as those of FIGS. 1A and which may include data indicating required equipment for a given development scenario, cost for said development scenario, and schedule or timeline for said development scenario.

[0078] According to one embodiment, input map(s) or map-based inputs including data indicating net hydrocarbon thickness, reservoir horizons for azimuthal well placement, surface topology (e.g., bathymetric map) may be received as inputs to the development plan generator. For example, FIG. 6 shows an exemplary instance where an input map 602 is applied or otherwise received by the development plan generator and for which an equipment placement map 604 is generated as well as a topology map 606. The equipment placement map may indicate optimal locations to place equipment such as: sensors; valves; drill rigs; equipment associated with a well or a reservoir; equipment associated with facilities including drill center facilities, gathering center facilities (e.g., one or more pipelines fluidly coupled to gather, transport, or convey fluid resources associated with the resource site); and processing facilities (e.g., facilities that refine or process a gathered resource from the resource site). In addition, the topology map may enable the placement, positioning, or arrangement of one or more wells or other structures or equipment in specific locations at the resource site in order to optimally access, for example, a reservoir at the resource site. It is appreciated that the map properties for the input map(s) may be formatted to remove well placement areas in geological structures such as faults.

[0079] Those with skill in the art will recognize that input maps, such as those shown in FIG. 6, are among the varying sources of information to be analyzed through the development plan generator. The maps and other input types can be formed by varying processes, including Agile Reservoir Modeling techniques such as those found in PCT Application PCT/US2021/062737, Processing Subsurface Data with Uncertainty for Modelling and Field Planning, which is incorporated by reference in its entirety. Example disclosed methods in this PCT application include using concurrent ensemble model generation techniques that automatically build subsurface models from wellbore, seismic, and other data types. Moreover, additional inputs to the field development planning workflows disclosed herein can include subsurface models built from multiple domains through various means, including, e.g., subsurface framework model building techniques such as those found in U.S. Provisional Patent App. Serial Nos. 63/376,115 and 63/376,133, both filed 19 September 2022, and which are incorporated by reference in their entireties.

[0080] According to some embodiments, data being processed to generate the development plan includes a model that is parameterized using a plurality of parameters: number of producers (e.g., wells that produce fluid) or injectors (wells that receive fluid or into which fluid is injected); maximum horizontal length; quantities such as maximum well total depth, Dog Leg Severity (DLS) limit, maximum number of nodes (e.g. drill centers, processing centers where produced fluids — oil/gas/water — may be treated, etc.); number of connections per node (e.g. slots per drill center); approximate costs for “nodes” and connections (e.g. cost for drilling, cost for pipelines, etc.). It is appreciated that the DLS limit is a measure of the change of direction of a well path over a defined length. A user may execute, via one or more systems, control operations using the DLS limit data such as determining an upper DLS limit, bounding well drilling operations based on the upper DLS limit, and terminating the well drilling operations at the upper DLS limit.

[0081] In one embodiment, the development plan generator may determine (e.g., calculate during a simulation, forecast during a simulation, or project during a simulation) one or more locations of the reservoir well targets based on the parameterization. A set of predefined reservoir well targets (e.g., reservoir section) may be provided which have been obtained by other operations associated with the foregoing workflows. For example, the development plan generator may automatically generate drill center data, trajectory data and pipeline data with well placement data being automatically generated by another workflow. In some implementations, an outline for the development plan may be generated which includes: reservoir well target placement information, trajectories information, drill centers and pipelines information, and process center tie in-point information. It is appreciated that a development plan or development file may indicate multiple pipelines through which the reservoir fluid is flowing. The multiple pipelines may be connected or coupled to a processing or treatment facility or to a tie-in point (e.g., instances where the multiple pipelines for a development plan are connected to an existing pipeline). According to some implementations, the multiple pipelines may be connected to the treatment facility during execution of greenfield development operations where no infrastructure is available. In other implementations, the multiple pipelines may be connected to the tie-in point during execution of brownfield operations where a new development plan is “plugged” into an existing infrastructure.

[0082] In one implementation, the skeleton development plan may be used as initial inputs to the development plan generator which would be subsequently updated based on user considerations. The development plan may be accessible via an orchestration framework through one or more APIs associated with a user portal (e.g., DELFI portal) that documents and enables a user to execute one or more workflows associated with the development plan generator and thereby inform other consuming applications (e.g. Subsea Planner, DrillPlan or any third-party applications) using the generated data from the development plan generator and/or data from one or more workflows associated with the development plan generator. According to one implementation, a user (e.g., a third-party) may couple or otherwise interface one or more workflows and/or one or more models using one or more APIs to the development plan generator such that the one or more workflows and/or one or more models may be similar to, or different from the workflows provided in FIG. 5 of this disclosure.

Workflow for Populating and Evaluating a Detailed Drilling Design Operation

[0083] One purpose of the well construction integration workflows is to automate the process of creating an equipment list and cost analysis data for wells included in a given development scenario. The automated process may include one or more of: automating and/or enhancing the process of injecting well trajectory data into a drill planning tool (e.g., DrillPlan) to generate data indicating one or more of a full equipment list required for well construction costing; orchestrating or parameterizing, using the generated data indicating a full equipment list, the configuration of the well construction tool with appropriate settings (e.g. wellbore diameter, completion type, total depth etc.) thereby creating an equipment list required for well construction costing; extracting data indicating the full equipment list with corresponding cost data and furnish said extracted data for consumption by other parts of the workflow (e.g., costing and schedule workflows) to generate the development plan.

[0084] According to one embodiment, the workflow for populating and evaluating a detailed drilling design operation may comprise using a drilling design model that may be parameterized based on one or more of the following:

For each development scenario to be evaluated, the following data may be used to characterize the drilling design model:

(i) development scenario parameters: these may be provided to allow the well construction tool to be automatically configured according to scenario specifications (e.g., wellbore specifications data, completion parameters, etc.). In one embodiment, the development scenario parameters may be supplemented by a configuration file that maps a plurality of parameters to well construction tool settings.

(ii) development plan description options: these may be provided to the well construction tool to allow the relevant development plan's entities to be extracted for the purpose of building the well construction equipment list (e.g., wellhead locations, well sections, trajectories, etc.). According to some implementations, the development plan includes data indicating physical entities belonging to multiple domains. For the well construction domain, the entities may include wellhead location and for the facility domain, the entities may include pipelines, gathering stations, processing facilities, etc.

(iii) well construct (e.g., well construction model): this may initially be a simple model that can be captured using, for example, a spreadsheet with well properties data that define the well but can progress to more complex models (e.g., multi-dimensional models associated with a computational tool such as DrillPlan).

[0085] The drilling design model may be executed (e.g., in a simulation) to generate a plurality of outputs based on one or more development scenarios associated with this workflow. In some embodiments, the following outputs may be made available for consumption by other parts of the systems or workflows disclosed. For example, the drilling design model, after parameterization and execution may be used to generate data (well design data) indicating a wells equipment list, data indicating a drilling duration, data indicating costs describing the wells to be include in the development scenario in question, etc. [0086] In some embodiments, the well construction model may be configured using a reference object comprising a plurality of parameters from a user. A mapping operation may be executed that relates the development scenario parameters (e.g., using the reference object) to the configuration instructions associated with the drilling design model and which may be passed to the well construction tool. An orchestration or coordination operation may be executed to facilitate flow of data from the development plan description and the configuration instructions to the well construction tool at this stage.

[0087] In one embodiment, a pre-processing stage that converts the well construction model or other models or other conceptual wells may be implemented to format said models or conceptual wells for further processing by other complex computational tools (e.g., DrillPlan) associated with the workflow for populating and evaluating a detailed drilling design operation. In exemplary embodiments, the well construction tool may execute operations that generate the wells equipment list based on the orchestration framework discussed above. In some embodiments, the cost data corresponding to the equipment list may also be generated. The system may then generate data indicating the wells equipment list and the cost data which may be visualized or ingested by another workflow provided by this disclosure.

[0088] According to one embodiment, a method for executing automated model generation and scenario evaluation operations at a resource site comprises generating a first framework, such that the first framework includes a structure that enables interaction with data associated with a plurality of domains of the resource site by a user. The method further includes generating a second framework, such that the second framework includes one or more modules of a signal processing engine that communicatively coordinate execution of a plurality of computing operations on the data associated with the plurality of domains of the resource site. According to some implementations, the method includes developing, using a first module comprised in the one or more modules, a drilling design model for the resource site. The drilling design model may be characterized by at least one of: development scenario parameters that automatically configure a well construction tool; development plan description options that are used to automatically generate a list of well construction equipment; and a well construct that includes well property data that define a well associated with the resource site. The method may further execute, using the computer processor and the first module, a simulation operation based on the drilling design model to generate well design data. The well design data may indicate at least one of: an equipment listing for the well; drilling duration data for the well; or cost data associated with developing the well. Moreover, the method may initiate, using the computer processor and the first framework, generation of a visualization of the well design data for viewing and interaction by the user on a graphical user interface.

[0089] These and other implementations may each optionally include one or more of the following features. The plurality of domains comprise a plurality of specialization areas associated with developing the resource site including one or more of: reservoir design operations; well configuration operations; or flow line set-up operations. The first framework, according to some implementations provides interfaces and data structures that enable reception of data from the plurality of domains and displaying output data based on operations executed by at least one module of the signal processing engine. The second framework, in some cases, enables parameterizing the drilling design model by a user via an application programming interface. Furthermore, the drilling design model may be generated using a skeleton development structure which comprise initial development data structures based on map-based inputs that are enhanced using the parameterizing. The map-based inputs may include data that indicates one or more of: net hydrocarbon thickness, reservoir horizons for azimuthal well placement, surface topology.

Workflow for Populating and Evaluating a Detailed Subsea Design Operation

[0090] The module and/or data integrations discussed above in association with the workflows in this disclosure enable the automatic generation of development plans that can serve as inputs to a subsea planner module comprised in the signal processing engine. In one embodiment, the subsea planner module comprises an application that executes the workflow for populating and evaluating a detailed subsea design operation. In one embodiment, the subsea planner module may automatically expand and/or refine or otherwise format a layout of the development plan(s)/construct(s) to generate a detailed equipment list, cost data, and schedule data. The user may interact with one or more visualizations (e.g., design data) associated with the subsea planner module to generate, for example, an equipment list for subsea development operations. The equipment list and/or cost data and/or schedule data may be made available to the orchestration framework for inclusion in the integrated evaluation platform as part of the development plan (e.g., equipment data, cost data, schedule data, etc.). [0091] This workflow may comprise an associative operation facilitated by a computational tool (e.g., Subsea Planner development plan) or a module comprised in the signal processing engine that digitally models (e.g., using a subsea design model) an interconnection of exploratory systems on the seabed with a development scenario associated with the orchestration framework. Modeling such an interconnection of exploratory systems, according to some embodiments, may be based on a link which enables a two-way API communication between the orchestration framework and the computational tool. The second workflow, according to one embodiment, may include generating a subsea design model for the resource site which may be used in a simulation operation to generate subsea design data based on one or more development scenarios associated with this workflow. The second workflow may also comprise an import operation that imports a skeleton development plan to provide an informational structure for generating the interconnection of exploration systems on the seabed. The workflow may further comprise automatically populating one or more geo-located well heads and facility locations associated with the development scenario into the computational tool (e.g., Subsea Planner). In addition, the workflow may comprise automatically populating geo-located pipelines based on the development scenario. In one embodiment, the models within the computational tool (e.g., Subsea Planner) may be adjusted or otherwise optimized or parameterized to generate, in real-time or near real-time, an enriched model for the subsea equipment layout data (e.g., add equipment, pipeline material/IDs, etc.) together with attendant projected cost data and schedule data (e.g., projected implementation timeline information) for generating said layout. The workflow may also include exporting the enriched model (e.g., enriched development plan together with attendant cost data and schedule data) for ingestion by other modules (e.g., orchestration framework), systems, or workflows as the case may be.

[0092] According to some embodiments, a method for executing automated model generation and scenario evaluation operations at a resource site comprises generating a first framework such that the first framework includes a structure that enables interaction with data associated with a plurality of domains of the resource site by a user. The method may also comprise generating a second framework such that the second framework includes one or more modules of a signal processing engine that communicatively coordinate execution of a plurality of computing operations on the data associated with the plurality of domains of the resource site. The method may further include receiving, using the first framework, equipment layout data associated with a subsea design operation for the resource site. In some embodiments, the method comprises executing, using a first module comprised in the one or more modules of the signal processing engine, an associative operation that models an interconnection between one or more exploratory systems associated with the subsea design operation. The method may further include generating, based on the associative operation, a subsea design model for the resource site. In one embodiment, the method comprises executing, using the first module, a simulation operation based on the subsea design model to generate subsea design data, such that the subsea design data comprises: subsea equipment layout data, projected cost data associated with the subsea equipment layout data, and projected schedule data indicating an implementation timeline for the subsea design layout data. The method may also include initiating, using the first framework, generation of a visualization of the subsea design data for viewing and interaction by the user on a graphical user interface.

[0093] These and other implementations may each optionally include one or more of the following features. The plurality of domains may comprise a plurality of specialization areas associated with developing the resource site, such that the plurality of specialization areas includes one or more of: reservoir design operations, well configuration operations, or flow line set-up operations. The first module may comprise an application that automatically formats a layout of a development construct or model associated with the subsea design operation. Furthermore, the interconnection of the one or more exploratory systems associated with the subsea design operation is based on a link which enables a two-way application programming interface communication using the first framework and the second framework.

Workflow for Populating and Evaluating a Subsurface Simulation Forecasting Operation [0094] A workflow for populating and evaluating a subsurface simulation forecasting operation is now discussed. According to some embodiments, this workflow enables executing simulation operations that generate outputs used to automate the generation of production forecast data based on a simulation model associated with the development plan. The production forecast data may be used as input for a subsequent step to evaluate or determine economic data for a development scenario. In one embodiment, the auto-generated development plan referred to above provides input to the simulation model. The wells and layout structure may be used to automatically parameterize the simulation model along with additional information related to the development scenario (e.g., flowrate constraints, well phasing, etc.). According to some implementations, the workflow comprises providing a development plan description (e.g., equipment layout data) including, for example, wells, layout, etc. for use in conjunction with the reservoir model (e.g., parameterization data of the reservoir) to generate the simulation model (e.g., subsurface model). The workflow further comprises providing a reference object that is used to generate the development scenario parameters which serve as configuration parameters that control or otherwise regulate the process of populating the wells in the reservoir model. In one embodiment, these parameters (e.g., configuration parameters) include specific settings such as well phasing data, flowrate constraints data, etc., that are used to configure the simulation model. The phasing data, for example, can include data/information that enables the calculation or computing of one or more production schedules for one or more wells coupled to a reservoir at the resource site. The flowrate constraint data may include, for example, well production rate data and/or well injection rate data used to parameterize, constrain, or control the simulation model. The workflow may further comprise executing one or more orchestration operations that populate, structure, or place the provided wells into specific sections of the sub-surface model using at least the configuration parameters. In one embodiment, the workflow automatically configures and executes the simulation model in a simulation based on the orchestration operation and the parameterizations discussed above to generate subsurface production data. In particular, the executed simulation, according to some embodiments, is based on one or more development scenarios associated with this workflow. This may comprise: providing the development scenario parameters which describe the relevant configurations (e.g. facility constraint configurations, etc.) and are used for parameterizing the simulation model; providing a mapping which relates the development scenario parameters to a set of simulation instructions which configure the simulation model, including, for example, adjusting the model in accordance with the development plan description (e.g., turning on required wells) and dynamically configuring flow rate constraints (e.g. production water handling limit, Gas compression constraints, etc.) associated with the design plan. In one embodiment, the workflow comprises validating the configuring/parameterization operation executed on the simulation model to reflect the development plan description and development scenario parameters and executing a simulation to generate the production forecast data. In one embodiment, the production forecast data may be included in a visualization that is displayed on a graphical user interface.

[0095] According to some embodiments, a method for executing automated model generation and scenario evaluation operations at a resource site comprises generating a first framework such that the first framework includes a structure that enables interaction with data associated with a plurality of domains of the resource site. The method may also include generating a second framework such that the second framework includes one or more modules of a signal processing engine that communicatively coordinate execution of a plurality of computing operations on the data associated with the plurality of domains of the resource site. In some embodiments, the method comprises receiving equipment layout data and parameterization data of a reservoir associated with the resource site. The method may also include generating, using a first module comprised in the one or more modules of the signal processing engine, a subsurface model that is parameterized using a set of development scenario parameters. The method may further comprise executing, using the first module, a simulation operation based on the subsurface model to generate subsurface production data including a production forecast for the reservoir. The method may also include initiating, using the first framework, generation of a visualization of the production forecast for viewing and interaction by a user on a graphical user interface.

[0096] These and other implementations may each optionally include one or more of the following features. The development scenario parameters include one or more of well phasing data, or flowrate constraints data. Furthermore, the method may further comprise: validating, using the computer processor, a parameterization operation executed on the subsurface model based on a development construct description and the development scenario parameters; and executing, using the computer processor and the first module comprised in the one or more modules of the signal processing engine, the simulation operation to generate the subsurface production data. Furthermore, the plurality of domains may comprise a plurality of specialization areas associated with developing the resource site. The plurality of specialization areas include one or more of: reservoir design operations, well configuration operations, or flow line set-up operations.

Exemplary Workflows [0097] FIGS. 7-9 provide exemplary workflows 700, 800, and 900 for methods, systems, and computer programs associated with automated model generation and scenario evaluation operations at a resource site. It is appreciated that a signal processing engine stored in a memory device may cause a computer processor to execute the various processing stages of FIGS. 7-9. For example, the disclosed techniques may be implemented as a signal processing engine within a geological software tool such that the signal processing engine enables the modeling of geological structures in the subsurface of a resource site based on the processes outlined herein.

[0098] FIG. 7 provides an exemplary workflow 700 for generating or designing a drilling design model associated with a development plan according to some embodiments.

[0099] At block 702, a signal processing engine may generate a first framework. The first framework, for example, may include a structure that enables interaction with data associated with a plurality of domains of the resource site by a user.

[00100] The signal processing engine may also generate, at block 704, a second framework such that the second framework includes one or more modules of a signal processing engine that communicatively coordinate execution of a plurality of computing operations on the data associated with the plurality of domains of the resource site.

[00101] At block 706, the signal processing engine may develop, using a first module comprised in the one or more modules, a drilling design model for the resource site. The drilling design model, according to some embodiments, may be characterized by at least one of: development scenario parameters that automatically configure a well construction tool; development plan description options that are used to automatically generate a list of well construction equipment; and a well construct including well property data that define a well associated with the resource site.

[00102] The signal processing engine may also be used to execute, at block 708, using the first module, a simulation operation based on the drilling design model to generate well design data (e.g., an example of a development plan). The well design data, for example, may indicate at least one of: an equipment listing for the well; drilling duration data for the well; or cost data associated with developing the well. According to one embodiment, the signal processing engine may be used to initiate, using the first framework, generation of a visualization of the well design data for viewing and interaction by the user on a graphical user interface.

[00103] These and other implementations may each optionally include one or more of the following features. The plurality of domains can comprises a plurality of specialization areas associated with developing the resource site. For example, the plurality of specialization areas may include one or more of: reservoir design operations; well configuration operations; or flow line set-up operations.

[00104] Furthermore, the first framework can provide interfaces and data structures that enable: reception of data from the plurality of domains; and displaying output data based on operations executed by at least one module of the signal processing engine.

[00105] In addition, the second framework can enable parameterizing the drilling design model by the user via an application programming interface.

[00106] According to some embodiments, the drilling design model may be generated using a skeleton development structure which comprises initial development data structures based on map-based inputs that are enhanced using the parameterizing.

[00107] In some cases, the map-based inputs include data that indicate one or more of: net hydrocarbon thickness; reservoir horizons for azimuthal well placement; and surface topology.

[00108] FIG. 8 provides an exemplary workflow 800 for generating a subsea design model associated with a development plan according to some embodiments.

[00109] At block 802, a signal processing engine may generate a first framework such that the first framework includes a structure that enables data interaction with data associated with a plurality of domains of the resource site by a user.

[00110] The signal processing engine may also be used to generate, at block 804, a second framework. The second framework, according to one embodiment includes one or more modules of a signal processing engine that communicatively coordinate execution of a plurality of computing operations on the data associated with the plurality of domains of the resource site.

[00111] At block 806, the signal processing engine may be used to receive, using the first framework, equipment layout data associated with a subsea design operation for the resource site. [00112] Turning to block 808, the signal processing engine may be used to execute, using a first module comprised in the one or more modules of the signal processing engine, an associative operation that models, establishes, or coordinates an interconnection between one or more exploratory systems associated with the subsea design operation.

[00113] At block 810, the signal processing engine may be used to generate based on the associative operation, a subsea design model for the resource site.

[00114] The signal processing engine may be further used, at block 812, execute using the first module, a simulation operation based on the subsea design model to generate subsea design data (e g., an example of a development plan), the subsea design data comprising: subsea equipment layout data; projected cost data associated with the subsea equipment layout data; projected schedule data indicating an implementation timeline for the subsea design layout data. [00115] In addition, the signal processing engine may be used, at block 814, to initiate, using the first framework, generation of a visualization of the subsea design data for viewing and interaction by the user on a graphical user interface.

[00116] According to one embodiment, the plurality of domains discussed in conjunction with FIG. 8 comprises a plurality of specialization areas associated with developing the resource site. The plurality of specialization areas may include one or more of: reservoir design operations; well configuration operations; or flow line set-up operations.

[00117] The first module may comprise an application that automatically formats a layout of a development construct, structure, or model associated with the subsea design operation.

[00118] Furthermore, the interconnection of the one or more exploratory systems associated with the subsea design operation may be based on a link or digital connection which enables a two-way application programming interface (API) communication using the first framework and the second framework.

[00119] FIG. 9 provides an exemplary workflow 900 for generating a subsurface model associated with a development plan according to some embodiments.

[00120] At block 902, a signal processing engine may generate a first framework such that the first framework includes a structure that enables interaction with data associated with a plurality of domains of the resource site by a user. [00121] The signal processing engine can also be used to generate, at block 904, a second framework that includes one or more modules of a signal processing engine which can be used to communicatively coordinate execution of a plurality of computing operations on the data associated with the plurality of domains of the resource site.

[00122] At block 906, the signal processing engine may be used to receive equipment layout data and parameterization data of a reservoir associated with the resource site.

[00123] Furthermore, the signal processing engine may be used to generate, at block 908 using a first module comprised in the one or more modules of the signal processing engine, a subsurface model that is parameterized using a set of development scenario parameters.

[00124] At block 910, the signal processing engine may be used to execute, using the first module, a simulation operation based on the subsurface model to generate subsurface production data (an example of a development plan) including a production forecast for the reservoir.

[00125] At block 912, the signal processing engine may be used to initiate, using the first framework, generation of a visualization of the production forecast for viewing and interaction by the user on a graphical user interface.

[00126] According to one embodiment, the development scenario parameters discussed in association with FIG. 9 include one or more of: well phasing data; or flowrate constraints data.

[00127] In addition, the flowchart 900 of FIG. 9 may further comprise: validating a parameterization operation executed on the subsurface model based on a development construct description and the development scenario parameters; and executing, using the computer processor and the first module comprised in the one or more modules of the signal processing engine, the simulation operation to generate the subsurface production data.

[00128] In some embodiments, the plurality of domains discussed in association with FIG. 9 comprises a plurality of specialization areas associated with developing the resource site, the plurality of specialization areas including one or more of: reservoir design operations; well configuration operations; or flow line set-up operations.

[00129] According to one embodiment, the subsurface model is a reservoir model that is parameterized by the set of development scenario parameters. In such cases, the set of development scenario parameters discussed in association with FIG. 9 can comprise phasing data indicating a production schedule for a well coupled to a reservoir associated with the reservoir model. Furthermore, the set of development scenario parameters discussed in association with FIG. 9 can also include flowrate constraint data including well production rate data or well injection rate data associated with the well coupled to the reservoir.

[00130] The various systems and methods discussed facilitate the generation of visualizations that inform the optimal execution of resource development operations. These visualizations may be based on the development plans and may include automatically generated equipment configuration maps or layouts for resource sites that provides an optimal arrangement of necessary exploratory equipment. The visualization may also include data associated with costs for such configuration maps as well as data associated with estimated timing (e.g., schedule data) for implementing the configuration maps, etc. In some embodiments, the term optimal and its variants (e g., efficient, optimally, etc.) may simply indicate improving, rather than the ultimate form of 'perfection' or the like.

[00131] While any discussion of or citation to related art in this disclosure may or may not include some prior art references, there is no concession or acquiescence to the position that any given reference is prior art or analogous prior art.

[00132] The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the disclosed subject-matter to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to explain the principles of the disclosed subject-matter and its practical applications, to thereby enable others skilled in the art to use the disclosed technology and various embodiments with various modifications as are suited to the particular use contemplated.

[00133] It will also be understood that, although the terms first, second, etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used to distinguish one element from another. For example, a first object or step could be termed a second object or step, and, similarly, a second object or step could be termed a first object or step, without departing from the scope of the technology disclosed. The first object or step, and the second object or step, are both objects or steps, respectively, but they are not to be considered the same object or step. [00134] The terminology used in the description herein is for the purpose of describing particular embodiments and is not intended to be limiting. As used in the description of the invention and the appended claims, the singular forms “a,” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and/or” as used herein refers to and encompasses any possible combination of one or more of the associated listed items. It will be further understood that the terms “includes,” “including,” “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

[00135] As used herein, the term “if’ may be construed to mean “when” or “upon” or “in response to determining” or “in response to detecting,” depending on the context.

[00136] Those with skill in the art will appreciate that while some terms in this disclosure may refer to absolutes, e.g., all source receiver traces, each of a plurality of objects, etc., the methods and techniques disclosed herein may also be performed on fewer than all of a given thing, e.g., performed on one or more components and/or performed on one or more source receiver traces. Accordingly, in instances in the disclosure where an absolute is used, the disclosure may also be interpreted to be referring to a subset.