1. Shell Pilot Project PRODML Work Group 2007 DTS Reconciliation Workflow

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

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 Project PRODML Work Group 2007 Pilot Smart Well Zonal Allocation

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

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

10. PRODML WG 2007 The Workflow The integrated asset model will consume historical production and injection data to calculate production and injections targets (forecast). Those targets will be used to in the consolidator to compare the targets to the actually achieved values The measured temperature and pressure at each zone (downhole sensor data available via data historian) will be used to calculate zonal and total rates and to calculate the reservoir pressure per zone The reservoir pressure and rates can be used in an advanced process controller to calculate the optimum choke setting on how to operate the well within the targets and the constraints.

11. PRODML WG 2007 StatoilHydro Pilot Project PRODML Work Group 2007 JV Reporting - Algeria

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

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

14. PRODML WG 2007 ConocoPhillips - Onshore PRODML Work Group 2007 Pilot Project Allocation Reporting

15. 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 ConocoPhillips Daily Volume Reporting PRODML Pilot Team PRODML WG 2007

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

17. BP Pilot Project PRODML Work Group 2007 Network Model Management PRODML WG 2007

18. BP Network Model Team Joe PalatkaBP Jim BettencourtBP (SAIC) Ray VerhoeffOSIsoft Per Arild AndersonKongsberg Intellifield Duncan OrdMatrikon Laurence OrmerodWeatherford Jason ClarkeWeatherford PRODML WG 2007

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

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

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

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

23. ConocoPhillips - Offshore Work Group 2007 Pilot Project Allocation Reporting PRODML WG 2007

24. Pilot Team Members NameCompanyTitle Russell BorgmanConocoPhillipsCOP Program Manager Wayne ManuelConocoPhillips Supervisor – Upstream Global Solutions, Operations & Drilling Lars GaasebyConocoPhillipsData Services Supervisor Thomas VanyaConocoPhillipsIntegrator Specialist Jordan AmisAccentureCOP Project Manager Michel ChartonPetexPetroleum Experts Limited Project Manager Chaminda PeriesHalliburtonProduct Architect Ray VerhoeffOSIsoftVice President of Research Gary MastersEnergisticsProdML Project Architect Bryan BeckerEnergisticsProdML Project Manager PRODML WG 2007

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

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

27. Technology Providers and Products NameCompanyProduct Michel ChartonPetexGAP IPM v7 Beta Chaminda PeriesHalliburtonLandmark Decision Space Asset Observer v2.0 Alpha Ray VerhoeffOSIsoftPI Enterprise Server v3.4 PRODML WG 2007

28. PRODML WG07 Chevron Pilot Water Manager Water Management Production Management Oil and Gas Sales PRODML WG 2007

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

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