A set of business objects has been introduced by the Data Access Layer. Their purpose is to exchange data between the application layer and the database layer.
Each data entity is created, loaded, persisted, or deleted by a service with a corresponding name.
Workspaces
Each PetroVisor workspace is implemented as a separate SQL server database. This facilitates the following common deployment scenarios:
- Cloud deployment (multi-tenancy). In this scenario, there is one physical database that contains one or more database schemas (PetroVisor workspaces). This is recommended when there is a need to minimize the number of used databases (e.g., to minimize charges for cloud deployment).
- On premise deployment. In this scenario, there is a separate database/schema per PetroVisor workspace. This is recommended when there is a need to maintain workspaces individually (e.g., to backup/restore separately).
There is no technical limitation on deployment, so it is possible to have several databases in the cloud or one database with several schemas on premises.
There are a few tables that belong to common ‘dbo’ user schemas. They contain some constants, common units, and unit conversion factors. They are valid for any workspace, and their content is intended to be read-only for PetroVisor.
A new workspace can be created automatically using the PetroVisor server configuration tool with the appropriate database server access rights. A new workspace can also be created manually using SQL scripts.
It is possible to ‘unregister’ a workspace to disable it, and to ‘register’ an existing database as a PetroVisor workspace.
Verification and automatic updating of the database schema can be executed implicitly using the PetroVisor server configuration tool. It is also done automatically during ‘login’ to a workspace using the PetroVisor client tools. Automatic updating is implemented by comparing the current database schema with a reference database schema and, if needed, generating and executing SQL scripts on the current database.
To improve performance, PetroVisor’s data access layer uses internal in-memory caching for all PetroVisor objects except production data. Static production data can be optionally cached as well, by setting a server configuration option.
Data Entities
This paragraph lists the data entities that are managed by PetroVisor and indicates their usual frequency of update. This list is primarily oriented toward external consumers of the PetroVisor API.
Data Flow
The following diagram illustrates the typical data flow through PetroVisor.
Data Flow through PetroVisor
The typical sequence of events is as follows:
- A workflow is triggered by an Activity Service, which is either scheduled automatically or manually.
- A workflow typically starts with a Data Integration Set task.
- A Data Integration Component queries the appropriate data store.
- A Data Integration Component stores the data into the database.
- The workflow progresses as data is queried, calculated, and stored during each workflow task.
- There are three types of calculation tasks:
- P# script execution
- R script execution
- Custom external dll function execution
- Old, imported data is optionally cleared from the PetroVisor database.
- The status of execution is logged and broadcasted by the Communication Hub (SignalR - based).
- When the workflow is finished, the results can be viewed in Web Dashboards.
The following drawing depicts the sequence of data processing of the same set of components as are shown in the Process View.
Data flow in comparison with the process diagram
PetroVisor Workspace Database Structure
See the main parts of the database structure and details in the following diagrams. Note that ‘TEST’ is the database schema and workspace name.
Workspace Database Structure
This diagram represents all required data-related tables. See detailed views below.
Multi-tenancy Support
PetroVisor supports multi-tenancy by allowing for a separate database schema (TEST on the diagram) for every workspace/asset. It is also possible to have only one database for all workspaces and several database schemas in it (one schema per workspace). Some tables (not marked with TEST on the diagram) are common for every workspace/asset. This case works well for cloud deployment.
For the on-premises case, it is easier to have one separate database per workspace. It is just easier to maintain (backup/restore/etc.). The schema remains the same for each database/workspace, with copies of the common tables in every database.
Signals and Related Tables
Signals and related tables
The “Signal Domain Objects” are either measurements or properties of an entity. Each signal has:
- Unique name
- Unit measurement and storage unit
- Time and container aggregation types (Sum, Avg, Min, Max, etc.)
Signal type defines the signal value:
- Time-dependent – numeric values as a time series
- Depth-dependent – numeric values as a depth series
- Static – one numeric value
- String – one string value
- String time-dependent string values as a time series
- PVT – numeric values as a series of pressures, volumes, and temperatures
The AggregationType and ContainerAggregationType fields contain enumeration values.
The following signal aggregation types are provided by default:
- Sum
- Average
- Max
- Min
- First
- Last
- Count
Entities and Related Tables
Entities and related tables
The “Entity Domain Object” is either a single physical instrument, for/from which data is gathered, or it can be a container of several entities. Each entity is assigned a unique name and entity type. Entity types have a description (e.g., Well, Section, Reservoir). Each workspace has a default predefined list of entity types. Entity types can be modified.
An Entity Set domain object is defined either as a list of existing entities, or as a P# entities formula expression (e.g., IsEntityType, IsTaggged, etc.).
Entity hierarchies are stored in serialized format in a separate Hierarchies table.
The following entity types are provided by default, but can be changed for every workspace:
- Sensor
- Perforation
- Completion
- Section
- Branch
- Well
- WellPair
- Riser
- Template
- Platform
- Block
- Area
- Field
Hierarchies in PetroVisor
The “Hierarchy Domain Object” defines optional relationships between entities.
Multiple hierarchies are possible for the same entities in different contexts, and are defined as tree-like hierarchy structures that follow these rules:
- Only one root entity
- Every entity has only one parent
- Multiple levels
- Relationships are defined as sets of pairs (Child - Parent)
DataSets and Related Tables
DataSets and related tables
In the DataSets table, SignalID refers to the Signals table, and EntityID refers to the Entities table.
Tags and Related Tables
Tags and related tables
The EntityID field in the TagEntries table refers to the Entities table. EndDate in the TagEntries table can contain NULL values, which represent ‘not closed’ tag entries.
Data Retrieval
The following “Data Retrieval Objects” are available.
Data is retrieved using Datasets and Scope. A Dataset consists of:
- Entity-Signal pair (e.g., Well 1 - produced oil)
- Unit (If omitted, the Signal storage unit is used.)
The scope is defined by time/depth limits:
- Start – End time/depth – defined as absolute dates/depths or as a P# expression
- Time/Depth increment – frequency of data (e.g., monthly, daily, etc.)
A hierarchy is optional:
- If specified, container aggregation is automatically done by the PetroVisor API.
- Container aggregation means that if an entity has no data, then use the aggregated data of children entities that are defined in the hierarchy.
Steps of PetroVisor data retrieval that are executed on-the-fly by the PetroVisor API:
- Getting data and time aggregation as defined in the Scope
- Best implemented by using the SQL Server aggregation functions to achieve maximum performance.
- The result is independent of how frequent the data is actually stored/imported.
- Container aggregation (if a hierarchy is specified)
- Implemented by PetroVisor API using C# (parallel execution, caching)
- It is enough to store the data for entities on the lowest level in the hierarchy. For higher level entities, the data is aggregated automatically.
- Different hierarchies produce different results.
- Unit conversion
- The result is independent of the unit in which the data is actually imported and stored.
Data Saving
Data Saving uses the same PetroVisor domain objects as the results of data retrieval.
A TimeNumericData domain object consists of:
- Entity
- Signal
- Unit
List of data points – each data point is a pair DateTime-Value. It uses SQL Server ‘batch/bulk’ updating for best performance.
Data saving can be invoked by using the PetroVisor API as well as a P# Saving clause.