Permanent Downhole Gauges (PDG) are a remarkable source of information of both long term production data and the capture of occasional build-ups that may be described as ‘free well tests’. Data are acquired at high frequency and over a long duration. The down side is the large number of data points gathered, which can amount to hundreds of millions per sensor which is far beyond the processing capability of today’s fastest PC. There are a number of challenges: storing and accessing the raw data, filtering, transferring this to the relevant analysis module and finally sharing both filtered data and analyses.

Diamant Master is a client/server solution for reservoir surveillance that addresses these issues in a shared environment. It permanently mirrors raw data from any data historian, reduces the number of points with wavelet-based filtration, stores and shares the filtered data and also exports this to third party databases. Derived data can be created and updated by user controlled mathematical operations on existing data. Boolean alarms can be created and used over a network. Diamant Master also stores technical objects and maintains the data with enterprise-wide consistency avoiding the need for repetitious data handling and speeding the workflow. Diamant Master is administered, and can be partially operated by, a WEB client. It is fully controlled by the Diamant module in Ecrin.

New in v4.12 exclusive algorithms automatically identify, isolate and send multiple shut-ins for analysis. Automatic rate allocation at build-up inception honoring actual production history has been added, further reducing tedious engineer workload by pinpointing a daily rate to the moment a build-up begins.

PDGs acquire pressure data at high frequency and over a long duration. A typical data set will include two types of information; each spike is an unscheduled shut-in that may be treated as a ‘free’ well test for PTA. In addition the long term global producing pressure response, ignoring these spikes, can be used in association with the well production to perform Production Analysis and/or history matching. The data is there and it is already paid for. It is ‘simply’ a matter of getting at and interpreting the data. Nice idea, one not so little problem; the available data is vast and growing. For one single gauge there are typically 3 to 300 million data points. This will bring even the fastest of today’s PCs to a grinding halt. But we need both shortterm high frequency data for PTA and long-term low frequency data for PA.

To perform a transient or production analysis we typically need 100,000 data points. The trouble is it is a different 100,000 from the same dataset. To obtain both, Diamant Master (DM) uses a wavelet algorithm. Wavelets may be described as a ‘smart’ filter with a threshold. For each point the local noise is estimated for different frequencies. If the local noise is above threshold, as occurs for pressure breaks when the well is shut in, this ‘noise’ is considered significant and it is kept. In this case, the wavelets act as a high pass filter. Conversely, if the noise level is below threshold, this is considered as noise and it is filtered out. In this case the wavelets act as a low pass filter. As a result, producing pressures will be filtered out and reduced to a few points per day, while all early shut-in data will be preserved. For the engineer, it is the software equivalent of running a pencil through a noisy data cloud but marking, and closely following, the data whenever the engineer ‘sees’ a shut-in.

Diamant Master is an ongoing process installed on a dedicated machine running Windows Server™. Engineers, subject to privileges, operate DM from Diamant in Ecrin or a WEB based subset. All operations are performed and shared on the DM server which remains persistently linked to the original data source(s) from which it sequentially imports the raw, unfiltered data. Users can navigate the input database and indicate which tag(s) should be imported. Data is mirrored from the raw database to a local, fast access format. At the start of deployment DM will remain in an infinite loop in order to retrieve the legacy data. Once DM has updated a given gauge it will regularly contact the new data and load on a timer set by the DM administrator. For each mirrored data set, users with the right privilege may create one or several filtered channels using the wavelet filter.

Once the filter is defined DM will, in the background and as soon as sufficient new points have been mirrored, update. The filtered data is stored in the local DM database to be subsequently sent to Ecrin analysis modules on a single drag-and-drop. This data may also be exported to a third party database. It is possible for the Ecrin users to return to any part of the data and request a reload with a different, or no filter. DM stores KAPPA technical objects and files in a hierarchic and intuitive structure to be shared by Ecrin interpretation modules.

The beauty of standards is that there are so many to choose from. So it is in the Oil Industry; there is no standard way to store PDG data. There are many providers, and each has their own data model. It is common for Operators to have several providers and hence different data models will co-exist. Most databases have low-level access (ODBC, OLEDB, OPC, etc), but this is, at best, cumbersome for end users. Each solution would require a specific adaptor to navigate and access the data. KAPPA has implemented a unique API; the External DataBase Interface (EDBI) that permits the connection to customized adaptors. In most cases the adaptor is written by KAPPA. Each adaptor is delivered as a DLL that includes the data access and the user interface to navigate the database. It acts as a plug-in. At the first connection, Ecrin will automatically download the DM plug-in and the user will navigate without further installation. External EDBI adaptors export the filtered data to specific client databases.

At initialization, and as a one off process, DM proceeds with a quick data scan of one point in every ten thousand to offer a preview of the data and help in spotting anomalies and gross errors. A selection on the data window can be made and outliers immediately discarded. Within the load window an initial sample of a fixed size, typically around 100,000 points or one week of data is extracted. In an interactive and iterative process, the engineer will adjust the wavelet setting, to get to the point where the required data signature sensitivity is retained and superfluous data filtered. Post-filtration, based on a maximum Δt and Δp, is then used to reduce the number of points to the final de-noised signal. Upon user acceptance the filtration is performed using overlapping increments of the size of the initial sample.

These are user defined and permit mathematical operations on data channels with a comprehensive formulae package. The outcome may be another data set or a Boolean function of time that may be used to create an alarm. The outcome of the alarm is to display, in the Diamant window, the execution of an alarm E-mail, or the call of a user defined DLL.

We believe this to be a very important breakthrough. Until recently all algorithms (including those involving wavelets) failed miserably to automatically identify shut-ins, especially when data sets were showing both soft and hard shut-ins. In v4.12, an exclusive algorithm locates, without user intervention, all transients within a selected time period, with a rate of success that makes it a considerable time saver for the engineer. Years of PDG data can be scanned in seconds, the transients identified and made available to the user for simultaneous or discrete analysis in Saphir (PTA). This was the last missing link to allow full automation of the data processing.

If a well is shut-in half way through the day 2000 BOPD flowing for 12 hours is still 2000 BPOD, not 1000 BOPD. When there is a build up it is therefore a question of allocating this more sparse data correctly to the period before the well was shut-in. This was a tedious manual process that involved the user creating a derived Boolean channel to indentify flowing and shut-in periods based on the build-up. This has been fully automated in v4.12.

Filtered data can be transferred from DM by drag-drop to an analysis module. Shut-ins are analyzed and compared using the PTA module (Saphir) while producing pressures will be history matched or used in diagnostic plots using the PA module (Topaze) or even through to the full field history match in Rubis. DM maintains a persistent link to the original data source. For each gauge, regularly or on user request, the process reconnects to the data source and then loads and filters incremental data using the filter as set for the particular gauge. It is also possible to change the filter setting, for new data or retroactively, or to partially re-populate a data segment over, for example, an identified build-up with different or no filtration.

With the transients identified and daily rates correctly allocated and cleaned, shut-in data can be sent, en masse or individually, to a PTA (Saphir) document automatically created by Ecrin. The result can be the latest shut-ins or a cloud of transients from previous years, that may be analysed together, as a selected group or discretely. Years worth of shut-ins are gathered from DM with rates synchronised and presented in Saphir in seconds.

The diagram below shows the different components of the DM process. These operate continuously and independently. The interface between the KAPPA storage database, the Ecrin clients, the WEB clients and the other DM processes are controlled by the DM Server (DMS). It protects data locked by a user against possible interference from other users. When an Ecrin user decides to mirror PDG data or to create new filtered data, the DMS will store the new instructions in the KAPPA database. The DM Mirroring Process (DMMP) and the DM Filtering Process (DMFP) are independent. The DM Calculation Process (DMCP) creates and permanently updates tags derived from other tags. The DMCP also sets alarms.

Diamant is the best way to handle data, technical objects and files when using KAPPA applications. However these can also be accessed from an Internet browser by connecting to the DM server IP address or its name in the domain. The engineer can view the status of the different processes, access the data tables and technical objects and recover the filtered data in ExcelTM format without using Ecrin. An ActiveX control can also be loaded to navigate the data structure in the same browser environment as Diamant.

For very small workgroups, the Diamant module in Ecrin has a subset of the Diamant Master PDG capabilities. The database connection (EDBI), and therefore the ability to access filtered data from various sources is the same. Mirroring is allowed but incremental loads are triggered by the user. The filtration process is identical but data are stored in a local Diamant file. Direct sharing is not possible, however filtered data may be exported to files. It is not necessary to purchase Diamant in order to operate Diamant Master.