1 / 29

Optimizing Temperature Data Reconciliation Workflow in Energy Sector

Explore the process of reconciling DTS profiles with temperature sensors for enhanced accuracy in energy assets. Learn about standardized data transfer methods and web services for seamless sensor updates. Dive into the Shell Pilot Project and industry best practices.

genei
Download Presentation

Optimizing Temperature Data Reconciliation Workflow in Energy Sector

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DTS Reconciliation Workflow Shell Pilot ProjectPRODML Work Group 2007

  2. 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

  3. 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

  4. 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

  5. Description of Webservices II • 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 PRODML WG 2007

  6. 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

  7. StatoilHydro Pilot ProjectPRODML Work Group 2007 Pilot Smart Well Zonal Allocation

  8. 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.

  9. 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

  10. StatoilHydro Pilot ProjectPRODML Work Group 2007 JV Reporting - Algeria

  11. 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)

  12. 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

  13. ConocoPhillips - OnshorePRODML Work Group 2007 Pilot Project Allocation Reporting

  14. ConocoPhillips Daily Volume Reporting PRODML Pilot Team ConocoPhillips Don Van Speybroeck, Pilot Lead Jose Rivas, Reporting Lead Thomas Vanya, Test Environment Lead AspenTech Chris Hewitt, Technical Lead Norbert Meierhoefer, Functional Lead Kongsberg Per Arild Andresen, PhD, Technical Lead P2 Energy Solutions Kiran Vajrala, Technical Lead Dave Johnson, Functional Lead Iain Saunderson, Test Environment Lead PRODML WG 2007

  15. 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

  16. BP Pilot ProjectPRODML Work Group 2007 Network Model Management PRODML WG 2007

  17. 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

  18. Definition of the Network Model 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. PRODML WG 2007

  19. 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

  20. 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

  21. 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

  22. ConocoPhillips - OffshoreWork Group 2007 Pilot Project Allocation Reporting PRODML WG 2007

  23. Pilot Team Members PRODML WG 2007

  24. 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 Introduction PRODML WG 2007

  25. 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 Objectives PRODML WG 2007

  26. Technology Providers and Products PRODML WG 2007

  27. PRODMLWG07Chevron Pilot Water Manager Oil and Gas Sales Water Management Production Management PRODML WG 2007

  28. Participating Vendors We would like to thank the vendors participating with Chevron in the WG07 pilot. Each made a significant contribution to its successful implementation PRODML WG 2007

  29. 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 Oil and Gas Sales Water Management Production Management PRODML WG 2007

More Related