Shell Pilot Project PRODML Work Group 2007

29
Shell Pilot Project PRODML Work Group 2007 DTS Reconciliation Workflow

description

DTS Reconciliation Workflow. Shell Pilot Project PRODML Work Group 2007. Overview. DTS (Distributed Temperature Sensing) gives a continuous temperature profile along a well One way to improve accuracy is to reconcile the DTS profile to a single point-source temperature sensor - PowerPoint PPT Presentation

Transcript of Shell Pilot Project PRODML Work Group 2007

Page 1: Shell Pilot Project PRODML Work Group 2007

Shell Pilot Project PRODML Work Group 2007

DTS Reconciliation Workflow

Page 2: Shell Pilot Project PRODML Work Group 2007

Overview

• DTS (Distributed Temperature Sensing) gives a continuous temperature profile along a well

• One way to improve accuracy is to reconcile the DTS profile to a single point-source temperature sensor

• Energy company assets can have DTS and PT sensors from multiple vendors

• A standardised method to transfer raw and calibrated DTS logs To/From a DTS database as well as point temperature readings - typically from a well-agnostic process historian is beneficial.

• In case there is a need to change the DTS or PT sensors, this can be done seamlessly without affecting the subsequent process flows.

PRODML WG 2007

Page 3: Shell Pilot Project PRODML Work Group 2007

Shell DTS Pilot

• The Shell DTS Pilot components• Shell DTS Database

• Repository for raw and reconciled DTS logs• Weatherford DTS Viewer / Manager

• Carries out reconciliation and curve shifting• OSIsoft Historian

• Master source for all point temperature data

• Data transferred to DTS database and historian continuously, asynchronously from the DTS-PT reconciliation loop

• Network model provides:• Information required to match DTS trace to point temperature source• Position of the point-source temperature in well relative to a depth datum• Not physically implemented but required functionality was hard-coded into

each web service

PRODML WG 2007

Page 4: Shell Pilot Project PRODML Work Group 2007

Description of Webservices

• Shell Web Service• In order to interface with the Shell DTS Data Server, two

web services have been developed:• One for requesting and returning DTS traces that

are stored in the Shell DTS Data Server. • Another for storing reconciled DTS traces in the

Shell DTS Data Server.

• The initial and terminal messages that start and end the entire communication protocol are handled directly by the Shell DTS Data Server.

PRODML WG 2007

Page 5: Shell Pilot Project PRODML Work Group 2007

• Weatherford• The Weatherford contribution to the Shell pilot project is on

two front: 1. A Web Service (Weatherford DTS Manager) was

developed that supports GetDataAsyncInitiate web method. This Web Service is responsible for getting the

temperature data from different Web Services, perform reconciliation of data and store the new DTS trace data in Shell database.

2. A visualization tool (DTSPlus) was provided for plotting the DTS trace before and after reconciliation. The visualization tool also supports configuring the

network model information

Description of Webservices II

PRODML WG 2007

Page 6: Shell Pilot Project PRODML Work Group 2007

Description of Webservices III

• OSISoft webservice• The OSIsoft contribution to the Shell pilot project is an update to the

GetDataSync web method for the productVolume schema. Implementation is identical to the PRODML 1.0 specification, but includes the specification of a port element within the parameterSet element so that sensor depth down wellbore can be properly represented. Retrieval of actual temperature at depth is consistent with the representation of the data in PRODML 1.0.

• Infosys Orchestration• The Infosys contribution is to track all the web services and to handle any

exceptions or errors that may occur, such as if a web service response does not come, thereby triggering an alert and a log entry for re-conciliation.

PRODML WG 2007

Page 7: Shell Pilot Project PRODML Work Group 2007

PRODML WG 2007

StatoilHydro Pilot ProjectPRODML Work Group 2007 Pilot

Smart Well Zonal Allocation

Page 8: Shell Pilot Project PRODML Work Group 2007

PRODML WG 2007

The Problem To run smart wells at its optimum level it must be

possible to determine the zonal reservoir pressure at any time and compare those with the theoretical expected pressure calculated from your well and network models. A comparison of the theoretical value with the actual calculated value is a key performance indicator if the well/reservoir behaved as expected. If not the system needs to be recalibrated.

Page 9: Shell Pilot Project PRODML Work Group 2007

PRODML WG 2007

The Team IP21 by Aspentech is the data historian EnergyComponents by TietoEnator is the

production database Prosper by Petroleum Experts is a Well modelling

application DECIDE! By Schlumberger is the orchestrator of

automated workflows and data consolidation Avocet Production Surveillance by Schlumberger is

the visualization tool Avocet - Integrated Asset Modeller (IAM) by

Schlumberger is the optimizer and forecaster

Page 10: Shell Pilot Project PRODML Work Group 2007

PRODML WG 2007

StatoilHydro Pilot ProjectPRODML Work Group 2007

JV Reporting - Algeria

Page 11: Shell Pilot Project PRODML Work Group 2007

PRODML WG 2007

The context StatoilHydro partner in 2 Algerian fields (InSalah, InAmenas)

operated by BP. Field is operated as joint venture between BP and StatoilHydro.

Sonatrach is the goverment equivalent requiring different types of reports each day

Currently the network infrastructure is almost non-existing, ftp the only viable connection variant

Today reports are faxed to Sonatrach – the different reports covers different views of the same data

Data is shipped in a wide range of different formats

Involved software Energy Components (TietoEnator) and Production Monitoring and Reporting (TietoEnator)

Page 12: Shell Pilot Project PRODML Work Group 2007

PRODML WG 2007

The business benefits Data is structured in a computer readable form – making it possible

to load, publish to different formats, make subsets of data e.g. only extract gas composition for a given pipeline

Data is transfered in a more optimal manner to the different parties involved

Data is timely distributed without needed human intervention Data can be published to different production systems utilising the

same format e.g. well tests are required for a lot of different applications

The data stream is just published once to multiple sources Data can be more easily shared between involved parties – no need

to manual punching of excel spreadsheets, txt – files and so on The different reports are based on the same datastream and one file Joint venture partners gain access to data in a more timely and

structured manner

Page 13: Shell Pilot Project PRODML Work Group 2007

PRODML WG 2007

ConocoPhillips - OnshorePRODML Work Group 2007 Pilot Project

Allocation Reporting

Page 14: Shell Pilot Project PRODML Work Group 2007

ConocoPhillipsDon Van Speybroeck, Pilot LeadJose Rivas, Reporting LeadThomas Vanya, Test Environment Lead

AspenTechChris Hewitt, Technical LeadNorbert Meierhoefer, Functional Lead

KongsbergPer Arild Andresen, PhD, Technical Lead

P2 Energy SolutionsKiran Vajrala, Technical LeadDave Johnson, Functional LeadIain Saunderson, Test Environment Lead

ConocoPhillips Daily Volume Reporting PRODML Pilot Team

PRODML WG 2007

Page 15: Shell Pilot Project PRODML Work Group 2007

ConocoPhillips Daily Volume Reporting

PRODML Pilot Problem Statement

• Rebuilding and remapping software application interfaces to produce daily production reports should not be so complicated.

• Software applications and database systems in the Upstream Production environment have different data requirements for collection, analysis, and reporting functions.

• The systems data flow and analysis requirements change in size and functionality as the assets grow and evolve.

  • Continuous data mapping and custom interface development efforts

between applications and systems can be eliminated through the adoption of industry standard network and volume models defined in PRODML.

PRODML WG 2007

Page 16: Shell Pilot Project PRODML Work Group 2007

BP Pilot ProjectPRODML Work Group 2007

Network Model Management

PRODML WG 2007

Page 17: Shell Pilot Project PRODML Work Group 2007

BP Network Model Team

• Joe Palatka BP

• Jim Bettencourt BP (SAIC)

• Ray Verhoeff OSIsoft

• Per Arild Anderson Kongsberg Intellifield

• Duncan Ord Matrikon

• Laurence Ormerod Weatherford

• Jason Clarke Weatherford

PRODML WG 2007

Page 18: Shell Pilot Project PRODML Work Group 2007

A description of the processing units in an oil field, the product flow connections between them and the property measurement points that exist. This includes active units, planned units and historic units that are not currently active.

This model can be dynamically shared between applications that require knowledge of the network topology in order to add value.

Standards-based sharing of the network model allows for accurate propagation of the topology and for dynamic maintenance. This provides a common understanding of the system configuration and scope.

Definition of the Network Model

PRODML WG 2007

Page 19: Shell Pilot Project PRODML Work Group 2007

Pilot Goals

• Increase the speed of data propagation through out the field management system

• Increase the integrity of the analysis and optimization in the operation of fields by enabling automated propagation of the current Network Product Flow Model

PRODML WG 2007

Page 20: Shell Pilot Project PRODML Work Group 2007

Pilot Objectives

• Define an Authorities Source in the system for the Network Model

• Create an active Network Product Flow Model and make it available for propagation to other applications in the system

• Change the network model in the Authoritative Source and expose it for propagation to other applications in the system

PRODML WG 2007

Page 21: Shell Pilot Project PRODML Work Group 2007

Conclusion

• The BP Network Product Flow Model Demonstrated :

− Automated availability and dynamic propagation of the model to users/applications on the system

− Automated updating of application with the latest configuration

− The ability to get historic active models in a dynamic and automated manner

PRODML WG 2007

Page 22: Shell Pilot Project PRODML Work Group 2007

PRODML WG 2007

ConocoPhillips - OffshoreWork Group 2007 Pilot Project

Allocation Reporting

PRODML WG 2007

Page 23: Shell Pilot Project PRODML Work Group 2007

Pilot Team Members

Name Company Title

Russell Borgman ConocoPhillips COP Program Manager

Wayne Manuel ConocoPhillipsSupervisor – Upstream Global Solutions, Operations & Drilling

Lars Gaaseby ConocoPhillips Data Services Supervisor

Thomas Vanya ConocoPhillips Integrator Specialist

Jordan Amis Accenture COP Project Manager

Michel Charton Petex Petroleum Experts Limited Project Manager

Chaminda Peries Halliburton Product Architect

Ray Verhoeff OSIsoft Vice President of Research

Gary Masters Energistics ProdML Project Architect

Bryan Becker Energistics ProdML Project Manager

PRODML WG 2007

Page 24: Shell Pilot Project PRODML Work Group 2007

Introduction

• COP Case for Change:– The process of optimizing production in a large offshore

gas producing asset in the North Sea is manually intensive and slow to react to changes in the producing system

– Major impediments to improving the process include:• The lack of a capability to access an accurate and dynamic

model of asset configuration data for use by various engineering applications

• The inability to feed real time data to the engineering applications without hard coding system interfaces

PRODML WG 2007

Page 25: Shell Pilot Project PRODML Work Group 2007

Objectives

• The PRODML COPPR pilot would demonstrate how PRODML enables the capabilities to:– Create a dynamically updateable network model and

make changes available for allocation reporting– Facilitate the access of real time data from the

appropriate source system– Capture changes in the asset configuration network

model for an audit trail, including rationale behind changes

– Utilize a network model to support field operations

PRODML WG 2007

Page 26: Shell Pilot Project PRODML Work Group 2007

Technology Providers and Products

Name Company Product

Michel Charton Petex GAP IPM v7 Beta

Chaminda Peries Halliburton Landmark Decision Space Asset Observer v2.0 Alpha

Ray Verhoeff OSIsoft PI Enterprise Server v3.4

PRODML WG 2007

Page 27: Shell Pilot Project PRODML Work Group 2007

PRODMLWG07Chevron Pilot

Water Manager

Water ManagementProduction Management

Oil and GasSales

PRODML WG 2007

Page 28: Shell Pilot Project PRODML Work Group 2007

Participating Vendors

We would like to thank the vendors participating with Chevron in the WG07 pilot. Each made a significantcontribution to its successful implementation

PRODML WG 2007

Page 29: Shell Pilot Project PRODML Work Group 2007

Design Basis

Contribute to Understanding PRODML Vendor / Internal Capability Legacy System Integration

Contribute to Key Work Process IOR – Building Blocks Brownfield IOR – Water Management

Predict Throughput React to Facility Changes Optimize Pipeline Network Visualize System

Water ManagementProduction Management

Oil and GasSales

PRODML WG 2007