How does Datagration handle multiple data sources with the same data?

With Datagration’s unified data model, it is possible to capture multiple streams of data into the same signal. Dependent on the source, P# scripts can be used to consolidate volumes by filtering the stream or selecting the most accurate source of data to be used. The graph below shows a volume stream being consolidated over 3 different data sources. In orange is the oil volume from Aries, dark purple the Field Direct oil stream, and light purple being the Quorum oil stream. Using a combination of P# script logic, it is possible to connect the data where the previous source left off, helping to capture the historic and the most current sources of data.

Stream Consolidation

Production data may be streamed in through different sources such as Aries, Quorum, or FieldDirect. Aries may capture the date on a monthly production volume, while Quorum or Field Direct may stream in the data daily. However, with sensor noise, occasionally there may be large fluctuations in the data stream that need to be filtered. Petrovisor can pull in all streams of data and utilize logic to choose the most reliable source from the group or reduce the noise of the stream. Additionally, the flexibility of the Petrovisor system can help clients consolidate data streams as they are transitioning from one data source to another on both the production and financial side. Historic data can be streamed in from Aries on a monthly basis, but new data can continue from where the historic data leaves off through the utilization of P# logic.

Below is an example of a production volume consolidation script.

The oil volume is saved into a signal called “produced oil per time increment” which can be pulled in for visualization/ analysis. The logic above pulls in three (3) sources of data: FieldDirect, Quorum, and Aries through their respective signals. Because FieldDirect and Quorum streams in daily data, they are prioritized by the most consistently occurring data while Aries can be used to backfill. Utilizing an If Else logic, the script checks whether there is Field Direct data available, then checks Quorum, and finally Aries if the other two daily streams do not contain data. By following this type of logic, it can connect historic data with the most recently captured daily production data, giving a better overview of the asset over time. Similar scripts can be applied certain groups of assets by changing the entity set and the scope of how the data appears, whether the information should be broken down into a daily or monthly value over time.

Backfilling Streams

If a particular stream (such as Aries) is only streaming in on the first day of the month as a bulk monthly volume and null on the rest of the month, time functions can be applied to standardize the different streams being captured. Please refer to P# - Datagration Knowledge Base for the list of Time and Date functions available to convert the timeframe of data capture. Below is an example of how Aries takes precedence and as long as the Aries stream contains data on the first day of the month, PetroVisor will take that volume for the whole month. If there is no Aries volume streamed in on the first day of the month, the remaining days will be filled by the Field Direct data stream and the Quorum data stream following.

Calculating Uptime

Additional P# scripts can be added to filter through noise in the data stream in case sensors are unable capture data or fluctuate on days of no production. The amount of uptime captured can be used in additional scripts to compare well performance or tag active entities. The Uptime script below calculates the amount of time the well is on production and the logic prioritizes based on the stream Aries, then Quorum, and lastly Field Direct. If the data stream is not null and greater than 0 on a particular day, the days containing production will get accumulated over time the number of days will be saved to the “time on production” signal. This method ensures the production streams coming in are not negative which could be due to sensor issues. By using an uptime calculation, it eliminates the need of having to run additionally cleansing scripts.