ADR: Creation of a Reservoir Management DDMS
RESERVOIR MANAGEMENT DDMS
ADR: Creation of Reservoir Management DDMS
Creation of the Reservoir Management DDMS to support storage and analysis of reservoir management & monitoring data.
Status
-
Proposed -
Trialing -
Under review -
Approved -
Retired
Context & Scope
Reservoir data are to be tracked in order to optimize the flow of reservoir engineers. The DDMS here is dedicated to host data which will allow other parts to consume and evaluate the behavior of the reservoirs.
Personas that typically use reservoir data can include:
- Reservoir Engineers
- Reservoir Modelers
- Flow Assurance Engineers
- Data Managers
- ...
Typically, the lifecycle of reservoir management data follows this general flow:
a) putting together a plan to collect reservoir data,
b) working with vendors to collect data,
c) data can be contextualized and
e) placed in a database, as shown in Figure 1 below.
Figure 1. Example of RM Business Process Flow
To analyze reservoir behavior effectively, engineers initiate the process by gathering data from diverse sources and consolidating them into a centralized repository.
Furthermore, the initial stage of this data management process should be preserved to support downstream applications and facilitate the utilization of machine learning algorithms.
The Reservoir Management datasets exhibit intricate interconnections among key entities such as Reservoirs, Sectors, and Segments. To address this complexity, we propose the adoption of an Entity-Relational database, as depicted in Figure 2 below, to fulfill this critical need.
To effectively analyze and manage reservoir data across a variety of storage systems, it is imperative to establish uniform data definitions, a standardized data structure, and common abstractions, such as APIs. Without these essential components, the process of analyzing this dataset becomes exceptionally challenging, necessitating significant manual effort to format and prepare the data for analysis.
Figure 2. Solution architecture
The scope of the DDMS would be associated with the following data types :
- Rerservoir/Sector/Segment estimated volume
- Rerservoir/Sector/Segment models
- Rerservoir/Sector/Segment fluid synthesis
- Rerservoir/Sector/Segment geological labels
- Rerservoir/Sector/Segment HydroCarbon properties
- Rerservoir/Sector/Segment studies
And the following types which might be tackled by the production DDMS :
- Reservoir/Sector/Segment production/injection data
Decision
Enhance the OSDU Platform to provide a standard optimized method to store and consume Reservoir Management data.
And in doing so, creating a new DDMS in lieu of enhancing an existing DDMS.
The initial release of this DDMS aims to satisfy these use cases:
- Provide optimized bulk content storage:
- Enable data consumers to store bulk data in a way that is consistent and easy to access
- DDMS supporting this by having endpoints for bulk data ingestion/storage to well-defined reservoir management DDMS data models
- Support query, filter, and deliver bulk data within one dataset:
- Enable data consumers to find reservoirs that have a specific management attribute (E.g., in place volume values > 1000 Gal) for a specific country...
- DDMS supporting this by:
- Supporting query by any catalog data/metadata (e.g. geocontexts, dates, reservoir types, technical assurance, etc.) or DDMS bulk data
- Supporting filtering for value ranges and other criteria (e.g., depths, volumes, pressures, temperatures, etc.)
- Enable trace bulk data back to OSDU Catalog records:
- Enable data consumers to find the original data source after working with bulk data
- DDMS supporting this by having endpoints that allow search against the Core Search service, for WKSs relevant to Reservoir Management data, linked to DDMS Datasets
Rationale
A DDMS does not exist today that provides optimized storage and consumption of Reservoir Management data. This particular data set does not neatly fit into an existing DDMS (e.g., wellbore, reservoir, seismic, production, etc. ). It has a close affinity to the Reservoir Data Domain and therefore Reservoir DDMS, since the data is always associated with a reservoir, we might consider merging the work with the Reservoir DDMS. However the current Reservoir DDMS does not cover Segments and Sectors.
For that reason and using best practices of domain driven design but also behavioral driven design, it was decided to create a new DDMS that can support an array of optimized storage and consumption specific to the Reservoir Management data domain.
Note, the Data Definition Data Domain teams are currently aligning OSDU Data Definitions by Data Domains.
The decision to leverage domain driven design is in line with this effort.
Current proposal can be found here.
Consequences
Reservoir Management DDMS would be added as an experimental feature of the platform. The initial MVP would provide capabilities to store and consume the data types overviewed above. This would be both the metadata records associated with those data types (e.g. models, estimated volumes, etc.) and the content. For the metadata records, we will utilize the core Storage Service, and not store separate instances. However, validation will occur before storing the JSON to the core storage service. Content will initially be stored in a ER database such as PostgreSQL and will utilize the core dataset service for storage/management of source files.
The initial donation will only include an Azure implementation. The consequence is that we'll need to work with the other CSPs post-donation on the creation of the other layers.
No content parsers will be provided as part of the donation. This is due to both lack of an industry standard of reservoir management content and the commercial nature of the products in this space.
When to revisit
Future considerations to revisit this DDMS when:
- DDMS architecture fundamentally shifts approach away from being domain-driven
- OSDU community aligns to refactor scope of this DDMS with another DDMS (Reservoir DDMS, Production DDMS)
Tradeoff Analysis - Input to decision
Alternatives and implications
The main alternative considered was to add reservoir endpoints to the Reservoir DDMS, but as it has been stated above, not all datasets fit at the moment.
As a consideration toward duplication of code, relying on common libraries such as the osdu-api (clients to the core services) is seen as an overcome.
Another consideration is the separation of concerns and the micro services oriented architecture at the heart of the OSDU platform. We believe that we are more aligned to such architecture and have a dedicated service focusing solely on Reservoir Management.
Examples of benefits would be over the integration and maintenance of the service.
Decision criteria and tradeoffs
The team evaluated ties to other domains covered by existing DDMSs, and we did not find a good match. Following the domain driven design approach by creating this as a separate DDMS allows it to evolve to meet the needs of the consumers of Reservoir Management and the unique needs that domain would have.
We expect this will evolve quite a bit as we expand the service to accommodate more analytics use cases that span multiple data types.
The benefit of allowing it to independently evolve would outweigh the potential code duplication elimination that would come from shoehorning this domain into any other DDMS.
Architecturally, the DDMS has been designed to conform with the 11 OSDU DDMS Key Principles and design best practices:
- https://community.opengroup.org/osdu/documentation/-/wikis/OSDU-(C)/Design-and-Implementation/Domain-&-Data-Management-Services
- https://community.opengroup.org/osdu/documentation/-/wikis/OSDU-(C)/Reference-Architecture/Functional-Architecture/Data
- https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/home
Specific to this DDMS, these considerations were factored into the design and architecture:
- Behavioral Driven Design endpoints
- Domain-driven API
- Contextual boundaries
- Microservices-based
- Modular
- Vendor & technology agnostic
- Balanced between analytic performance and cloud resource cost
- Flexible component composition for specific use cases and requirements
Decision timeline
A prototype currently under development by Total Energies and Capgemini.