Data within geoscience repositories are often important constituents of business decisions. For example, a business decision may depend on volume of recoverable oil, which inherently relies on physical data and potentially simulation results (e.g., from simulation of a geologic environment). In such an example, business decision making may be performed, at least in part, on paper. Further, documentation of business process decisions may rely on storing papers in a file, for example, with printouts of some relevant simulation results and possibly some physical data. Such practices do not readily provide for uniform decision making or reassessments of business decisions (or business decision making processes). As described herein, various techniques can optionally enhance decision making and analysis of decisions and decision making processes.
One or more computer-readable media including computer-executable instructions to instruct a computing system to access a template, instantiate the template for a realization of a data-driven application, perform an analysis defined by the template where the analysis relies on linking to at least some data relied on by the data-driven application and output information based at least in part on the analysis. Various other apparatuses, systems, methods, etc., are also disclosed.
This summary is provided to introduce a selection of concepts that are further described below in the detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in limiting the scope of the claimed subject matter.
Features and advantages of the described implementations can be more readily understood by reference to the following description taken in conjunction with the accompanying drawings.
The following description includes the best mode presently contemplated for practicing the described implementations. This description is not to be taken in a limiting sense, but rather is made merely for the purpose of describing the general principles of the implementations. The scope of the described implementations should be ascertained with reference to the issued claims.
In the example of
As described herein, the simulation component 120 may rely on entities 122. Entities 122 may be earth entities such as wells, surfaces, reservoirs, etc. In the system 100, the entities 122 are typically virtual representations of actual physical entities that are reconstructed for purposes of simulation. The entities 122 may be based on data acquired via sensing, observation, etc. (e.g., the seismic data 112 and other information 114).
As described herein, the simulation component 120 may rely on a software framework such as an object-based framework. In such a framework, entities may be based on pre-defined classes to facilitate modeling and simulation. A commercially available example of an object-based framework is the MICROSOFT® .NET™ framework (Redmond, Wash.), which provides a set of extensible object classes. In the .NET™ framework, an object class encapsulates a module of reusable code and associated data structures. Object classes can be used to instantiate object instances for use in by a program, script, etc. For example, borehole classes may define objects for representing boreholes based on well data.
In the example of
As described herein, the management components 110 may include features of a commercially available simulation framework such as the PETREL® seismic to simulation software framework (Schlumberger Limited, Houston, Tex.). The PETREL® framework provides components that allow for optimization of exploration and development operations. The PETREL® framework includes seismic to simulation software components that can output information for use in increasing reservoir performance, for example, by improving asset team productivity. Through use of such a framework, various professionals (e.g., geophysicists, geologists, and reservoir engineers) can develop collaborative workflows and integrate operations to streamline processes. Such a framework may be considered an application and may be considered a data-driven application (e.g., where data is input for purposes of simulating a geologic environment).
As described herein, the management components 110 may include features for geology and geological modeling to generate high-resolution geological models of reservoir structure and stratigraphy (e.g., classification and estimation, facies modeling, well correlation, surface imaging, structural and fault analysis, well path design, data analysis, fracture modeling, workflow editing, uncertainty and optimization modeling, petrophysical modeling, etc.). Particular features may allow for performance of rapid 2D and 3D seismic interpretation, optionally for integration with geological and engineering tools (e.g., classification and estimation, well path design, seismic interpretation, seismic attribute analysis, seismic sampling, seismic volume rendering, geobody extraction, domain conversion, etc.). As to reservoir engineering, for a generated model, one or more features may allow for simulation workflow to perform streamline simulation, reduce uncertainty and assist in future well planning (e.g., uncertainty analysis and optimization workflow, well path design, advanced gridding and upscaling, history match analysis, etc.). The management components 110 may include features for drilling workflows including well path design, drilling visualization, and real-time model updates (e.g., via real-time data links).
As described herein, various aspects of the management components 110 may be add-ons or plug-ins that operate according to specifications of a framework environment. For example, a commercially available framework environment marketed as the OCEAN® framework environment (Schlumberger Limited) allows for seamless integration of add-ons (or plug-ins) into a PETREL® framework workflow. The OCEAN® framework environment leverages .NET® tools (Microsoft Corporation, Redmond, Wash.) and offers stable, user-friendly interfaces for efficient development. As described herein, various components may be implemented as add-ons (or plug-ins) that conform to and operate according to specifications of a framework environment (e.g., according to application programming, interface (API) specifications, etc.). Various technologies described herein may be optionally implemented as components in an attribute library.
In the field of seismic analysis, aspects of a geologic environment may be defined as attributes. In general, seismic attributes help to condition conventional amplitude seismic data for improved structural interpretation tasks, such as determining the exact location of lithological terminations and helping isolate hidden seismic stratigraphic features of a geologic environment. An attribute generation process (e.g., in the PETREL® framework or other framework) may rely on a library of various seismic attributes (e.g., for display and use with seismic interpretation and reservoir characterization workflows).
In the example of
The model simulation layer 240 may provide domain objects 242, act as a data source 247, provide for rendering 248 and various user interfaces 249. Rendering 248 may provide a graphical environment in which applications can display their data while the user interfaces 249 may provide a common look and feel for all application user interface components.
In the example of
In the example of
In Scenario B (template-based), a user operates equipment 315 in the system 310 to call for instantiation of a template X 352 by an instance of Project 1360 (e.g., a realization of a data-driven application). The instantiated template X 354 can call for rendering of a graphical user interface (GUI) while Project 1 is running (e.g., per the model simulation layer 240 of
As shown in the example of
In general, a project built using PETREL® software contains so-called data elements that represent earth entities (e.g., a well, a surface, a reservoir, etc.). Earth entities can be characterized by properties (e.g., logs along a well bore, height fields across a surface, porosity distributions in a reservoir, etc.). Earth entities in a data-driven application such as the PETREL® application may be based on domain objects (e.g., consider the entity objects 244 and the property objects 246 of
At time T2, a user at equipment 417 performs a template-based business analysis for Project 1 as defined by the template X 452. As the data for Project 1 has already been tagged at time T1 as being associated with the template X 452, the user may optionally perform the analysis in an alternative manner 465 that does not require a running instance of Project 1460. Further, as indicated in the example of
While the examples of
As described herein, information associated with implementation of a business analysis, a field analysis, etc., may be used as feedback to improve data, data management, business decision making, field decision making, etc. (see, e.g., feedback block 160 of
As described herein, a domain specific language (DSL) may be used for expressing a process such as a business analysis process that may include determining a probable success or failure. A DSL may be dedicated to a particular problem domain, a particular problem representation technique, a particular solution technique, etc. DSLs are generally implemented either by interpretation or code generation. Interpretation can include reading in the DSL script and executing it at run time. Code-generation can include parsing DSL script and generating code (e.g., in a high level language, such as Java or C). A software process being used generally requires some modification to account for design, implementation, integration, debugging, and maintenance of a DSL. As described herein, a simulation component (e.g., the simulation component 120 of
Below is an example of some DSL script for an analysis template:
As described herein, a process (e.g., business, field, etc.) can be documented as a template for association with a simulation application. As mentioned, data relied on by the application can be associated with one or more templates. The association between data and a template can result in the data being tagged with one or more tags defined by the template. As such data is typically associated with an earth entity of a project, tagging may optionally be considered as tagging the earth entity. As described herein, tagging may tag geometry data, property value data, or other data. Tagging enables search mechanisms to report data associated with a processes or parts of a process.
In the context of a geoscience repository (e.g., data store), a business analysis is conventionally performed separately (i.e., not in direct association with a realization of simulation of a geologic environment). As described herein, by performing a business analysis within the context of a geoscience repository allows for directly linking data to the analysis and tagging data by the analysis where the tagging can be performed in a manner consistent across multiple repositories (e.g., realizations of different geologic environments) to enable search tools to provide a consistent view over multiple repositories tailored to the business analysis.
As mentioned, implementation of an analysis can provide for an audit trail associated with a geoscience repository in a manner that also enables a consistent methodology of geoscience analysis across an organization or group of users.
The method 510 is shown in
As described herein, a method can include accessing a template, instantiating the template for a realization of a data-driven application, performing an analysis defined by the template where the analysis relies on linking to at least some data relied on by the data-driven application and outputting information based at least in part on the analysis. As described herein, one or more computer-readable media can include instructions to instruct a computing system to access a template, instantiate the template for a realization of a data-driven application, perform an analysis defined by the template where the analysis relies on linking to at least some data relied on by the data-driven application and output information based at least in part on the analysis.
In the example of
As different organizations are likely to require a different combination of factors depending on their respective business model and the geography and geology of a project being assessed, the process is presented as a template that can be created and customized by a client organization. Again, as mentioned, such a template can be expressed via a DSL.
As indicated in
The tagging then enables data to be viewed in relationship with the process. For example, a GUI may show all data in a geoscience repository connected to an entity. Tagging can also enable the business process to control the display style of an entity when visualized in the geoscience application (see, e.g., the property objects 246 with display parameters of
In the example of
A DSL template expression component 820 may be configured for receiving user input to enter or select statements of a DSL where the statements collectively form a template that can be instantiated, for example, by an application such as a geoscience application.
A template-driven entity tagging component 830 may be configured for tagging entities associated with an application such as a geoscience application. For example, a template may be instantiated by a realization of a geologic environment by a geoscience application where a GUI is rendered to a display that allows for display of entities of the geoscience application (e.g., entities as instantiated by the realization). In such a manner, a process (e.g., a business process or field process) may perform an analysis using information associated with the entities.
An entity tag management component 840 may be configured for managing entity tags. For example, a business process may tag various entities associated with a realization of a geologic environment by a geoscience application. In such an example, the entities may be agnostic to the particular geologic environment realized. The entities may be managed based on status (e.g., tagged or not tagged). Management may include updates to tags for various projects responsive to changes in underlying data or decisions.
An entity-based process audit component 850 may be configured for auditing processes. For example, a business process may rely on one or more entities of a geoscience application where during the process tagging of the entities occurs. If the business process results in a business decision, that decision may be audited at a later time by examining the tagged entities (e.g., and associated data).
An enterprise tag analysis component 860 may be configured to analyze tags or tagged entities across an enterprise (e.g., including partners, contractors, suppliers, etc.). Where application entities are tagged as part of a business process, decision making based on such business processes may be analyzed across an enterprise, for example, to determine key information or trends in decision making (e.g., in view of new information, training, etc.). Decisions that were deemed adequate at one point in time may be analyzed to determine if they are still adequate at a later point in time. Tagged entities may be examined to determine what is leading to a changed result.
A GUI front-end component 870 may be configured to implement a process (e.g., business process or field process) that relies on one or more entities associated with simulation software for simulating a physical environment. For example, a GUI may present a business process in conjunction with earth entities associated with simulation software whereby a user may selectively activate a graphic control to select one or more of the entities to thereby access data for use in the business process. The GUI component 870 may be configured to access a library of entities to allow for automatic population of selection options for a business process. In a particular approach, the GUI component 870 may be instantiated via consumption of a template expressed in a DSL (e.g., where the DSL is specific to a process such as a business process and an application such as a geoscience application).
The components 800 include a component 880, which may include one or more features of the components 810 to 870 and optionally other features.
In the example of
As described herein, a method can include selecting an entity of a geoscience application, tagging the entity as being associated with a business process, accessing information associated with the tagged entity; and calculating a metric defined by the business process based at least in part on information. As described herein, one or more computer-readable media can include computer-executable instructions to instruct a computing system to select an entity of a geoscience application, tag the entity as being associated with a business process, access information associated with the tagged entity; and calculate a metric defined by the business process based at least in part on information. In the foregoing example, an entity may be based on one or more domain objects (e.g., entity objects and property objects).
As described herein, a template may be instantiated for a realization of a process, which then will give a link to data associated with an application. A template may define a business process. As described herein, a system may be configured to run a business process that aims to determine one or more metrics as to, for example, a chance of success. Such a system may be configured to run the process over time to see if a chance of success has changed (for better or worse). While various examples refer to “chance of success”, a business process may provide output germane to decisions other than chance of success (or failure).
As described herein, a system may provide for auditing one or more processes based on information extracted during a process run (e.g., business process run X at time t, it is known what entities were relied on and what the underlying data was for the geoscience package at time t per database information, object management, etc.). An audit may provide some confidence of what someone decided and why. For example, for a person that found a 53% chance of success and production of 70 million barrels, if actual production differs when drilled, an update as to underlying business process may occur (e.g., optionally via a modification of a template).
As described herein, where tagging occurs, tagged data may be of interest to managers, scientists and business people. Further, tags may be used in various types of feedback loops. As to managers, data managers may need to store properly tagged data. As to scientists, they may need to know what data is being relied on by business people. As to business people, they may need to know when data is updated and that it has integrity.
As described herein, a system may be configured to allow a user to define a template via a domain specific language, to instantiate the template in a geoscience package to link to data in a manner that involves tagging data relied on by a geoscience package (e.g., to provide for associations with underlying physical data). Such a system may optionally be configured to run a template-defined process over time to see if output changes over time. In various examples, a system may run automatically in response to a trigger. For example, new data or revised data being stored at a storage location may cause a trigger to call for access to one or more business process templates and instantiation of those templates using the new or revised data. Where an outcome differs, an email or other communication may be sent to a user associated with a prior business process run to notify that user that circumstance have changed in a manner whereby the outcome of the business process differs. In such an example, a user may be able to set one or more parameters as to what type of difference would be sufficient for issuing a notification (e.g., +10%, −10% or +/−10%).
As described herein, one or more computer-readable media may include computer-executable instructions to instruct a computing system to output information for controlling a process. For example, such instructions may provide for output to sensing process, an injection process, drilling process, an extraction process, etc.
As described herein, components may be distributed, such as in the network system 910. The network system 910 includes components 922-1, 922-2, 922-3, . . . 922-N. For example, the components 922-1 may include the processor(s) 902 while the component(s) 922-3 may include memory accessible by the processor(s) 902. Further, the component(s) 902-2 may include an I/O device for display and optionally interaction with a method. The network may be or include the Internet, an intranet, a cellular network, a satellite network, etc.
Although various methods, devices, systems, etc., have been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as examples of forms of implementing the claimed methods, devices, systems, etc.
This application claims the benefit of U.S. Provisional Application having Ser. No. 61/345,258 entitled “Business Process Realization Linking,” filed May 17, 2010, which is incorporated by reference herein.
Number | Date | Country | |
---|---|---|---|
61345258 | May 2010 | US |