Total Exploration & Production: Field Monitoring Case Study

Transcription

1 Total Exploration & Production: Field Monitoring Case Study 1 Summary TOTAL S.A. is a word-class energy producer and provider, actually part of the super majors, i.e. the worldwide independent oil companies. It has grown successfully by successive merge with first FINA in 1999 and then ELF in year Field Monitoring was initiated in 2006 and fully managed by Total E&P focusing on the use of new technologies of acquisition, data processing and interpretation to improve the output of the fields, which means maximize and better manage the reserves, extending the lifetime of the layers and increasing the rates of recovery, meaning also to maximize and better manage the production, control the costs and improve safety. Obtained benefits on first pilots can be summarized as following: improved access to timely and quality field data faster decisions creating value and reducing cost by informed alerts when issue occurs and by being more proactive better decisions from increased understanding through access and incorporation of continuous data into models (integrated asset model). The main lessons learned from the pilots are: 1. The overall technical architecture has been validated: the project has reach the objective to implement a number of various technical functions for different specialties (e.g. rotating equipment monitoring and well performance optimization) sharing the same data and built with the same components. 2. As often encountered in such projects, the change management regarding the business activities, organization, responsibilities, etc has required a large effort for training and more technical support than anticipated. 3. The central component, called the Asset Model in Total s architecture, close to a master Data management System is certainly one of the most important and required much attention. 4. The classical development cycle ( V Cycle) that has been adopted has shown some limitations. 1

2 2 What is Total Exploration & Production? Total is now one of the topmost companies in Europe as per its resources and capital. The upstream branch of Total is devoted to petroleum exploration and production business (E&P). TOTAL E&P has a worldwide presence on the five continents with operatorship (responsibility for Oil & Gas production operation) in 30 countries. TOTAL E&P challenges are to ensure its part of hydrocarbon production to supply the demand while discovering and developing new reserves to maintain sufficient capacity. 3 The Problem Field Monitoring is dedicated to real time monitoring, assistance with the diagnosis and optimization of the production on all Oil & Gas fields operated worldwide by Total. Field Monitoring helps to execute relevant analyses and helps to make better strategic decisions on the basis of single and shared information so as to better understand the events in progress. 3.1 Each entity has its own solution In most cases, each subsidiary and even each individual assets were managing their operations with a patchwork of customized real time applications (a whole host of home-made Excel or Access applications including datasheets,..) that helped to manage and support their production activities but that were possibly corrupted, erroneous, not maintainable or traceable. 3.2 Significant learning curve when staffs move between assets The workflows related to monitoring and performance improvement differ between assets, making central support difficult, and introducing a large learning curve when staff moves between assets. At both 2

3 the asset and affiliate levels, efficient communication regarding well performance is difficult because a standard view on well/production performance is not available. 3.3 Different data sources and data overload lead to confusion and incorrect reporting Many disparate well and process data sources exist within each asset. The configuration of individual data sources often differs from asset to asset making data gathering and correlation time consuming. Overlap of data leads to confusion and it can be difficult to determine which data has been validated as correct which can result in incorrect data being used for some of the recurrent operational decisions. 3.4 Determining a true optimum operating point is difficult A lot of fields are produced under a combination of multiple constraints imposed by the development schema. Implementation of these controls in an optimal manner is not so easy as this will often depend on a number of conflicting constraints and the interaction between various set-points. 4 The New Solution 4.1 Expected Benefits overview Field Monitoring was initiated in 2006 and fully managed by Total E&P focusing on the use of new technologies of acquisition, data processing and interpretation to improve the output of the fields, which means maximize and better manage the reserves, extending the lifetime of the layers and increasing the rates of recovery, meaning also to maximize and better manage the production, control the costs and improve safety. The concept is characterized by three basic key points which are: A transverse approach across specialties in order to facilitate a collaborative way of work. The integration of previously independent daily activities into an optimization loop with tools helping to take the most appropriate action The use of real time data coming from sensors in the analysis and optimization loop. This concept requires a greater cooperation between the diverse disciplines of the E&P branch, requiring a better integration, flexibility and reactivity of the tools implemented. The tools and general environment built within the framework of the Field Monitoring project allow to: Visualize in a clearer way the physical parameters of the assets Transmit directly the right information to the most appropriate people for expertise and decision Process the information in order to define and perform the corrective/optimization actions against clearer targets as soon as possible. Consequently, the expected benefits can be summarized as following: Improved access to timely and quality field data Faster decisions creating value and reducing cost by informed alerts when issue occurs and by being more proactive Better decisions from increased understanding through access and incorporation of continuous data into models (integrated asset model). 4.2 Solution scope The Field Monitoring project produces software tools that are: Integrated in an overall IT reliable architecture With a similar user experience (look and feel) for all E&P sites so as to preserve a coherent and visible global strategy Customized according to the characteristics and needs of each subsidiary/site. Every deployment in an affiliate is based on: 3

4 a single Core Framework which allows to be compliant with the Field Monitoring environment (IT architecture and common modules). It does encompass the Exchange and Building Foundations. a part known as Template (Building Foundations) which is the same for each domain such as Well Performance Monitoring (WPM), Plant Performance Monitoring (PPM) and Reservoir Monitoring (RM). a part known as Extension which aims at developing in a variety of forms (versions) each template. For instance WPM can be customized for wells activated by gas lift (GL), electro submersible pumps (ESP) or subsea wells ((SS). A Customization part which is for modeling and configuration tasks aiming at adapting the tool to a dedicated site. Identical tools for all E&P sites, customized for each subsidiary Field Monitoring Architecture can be understood as a collection of useful components arranged in layers. Communication between components is simplified by means of standard data formats, common data definitions, and standard communication protocols Références, date, lieu The Core Framework (Foundations) plus the Templates plus the Extensions represented most of the overall effort development so that it minimizes the effort to make during the deployment phase in each affiliate. 4.3 The Core Framework Core Framework components Partial standardization of tools thanks to a Core framework The Core framework gathers A merge of all common requirements Graphical User Interface (GUI) Alarming module Asset Model and Management (Asset Objects) KPI generation mechanism IT Architecture A set of services Project documentation Support Maintenance Training On site assistance Knowledge transfer, Références, date, lieu The Core Frameworks includes both Exchange and Building Foundations. The Core Framework encompasses the following components. 4

5 Graphical User Interface including specifications for a consistent GUI across all applications, such as Dashboards, Synoptics, Graphs, Trends, Reports including main principles for the creation of the Reports Alarming/Notification including the main principles about data pre-processing and alarm management such as Conditions, Priorities, Status, Acknowledgement, Alarm history, KPI s and EBOD s generation mechanisms. EBOD means Equivalent Barrel of Oil per Day representing the number of barrels lost due to the gap between the operational point and the optimum operating point of the well. Asset Modeling describing the business object data and their relationships including master data. Each equipment/asset is modelised as an object. A Physical Graph shows physical connection between assets, a Tree view shows hierarchical connections between assets, a Versioning with new versions created after each change. IT Architecture describing the IT implementation, principles and rules for the Field Monitoring solution. Flexibility for settings describing the system initialization and configuration that Field Monitoring tools have to respect IT Architecture The IT architecture is, first of all, a set of principles for developing business applications and for integrating them with the existing (legacy) systems. It promotes collaborative work thanks to: Access and use of intraday / real time data as part of short term analysis: Facilitate the repeatability of periodic production data analysis tasks via integrated workflows Ease information sharing Key elements of the strategy are as follows: Separate functionalities into discrete components and services (functional blocks) around common requirements (the Core Framework) Re-use some components and services for a variety of applications Make connections among components and services using common (not applicationspecific) technologies Develop a data model (asset model) that supports the use of common data formats, common data types, and well-managed data resources Gathering all data & information into an end-user business logic representation Rely on open industry standards at all levels Therefore the core architecture complies with the following guidelines : Provide a manageable platform for collaboration and development of web based applications Provide an integration and orchestration platform layer A real time component collects and performs trending on real time data XML messaging between non proprietary interfaces must be used in priority. Functional Architecture Four layers are implemented: Data, Application, Integration and Orchestration, Visualization 5

6 Functional Architecture Layers 17 - Références, date, lieu The data layer is composed of : a Persistence block covering the storage of the entities used by the application, being real time data coming directly from various measuring devices (pressure, temperature,..) ( Historian DB ) or databases needed by the application (configuration items, events,..). a Domain block which covers the detailed description of business entities and attached information used by the application ( Asset Model Management ) various existing business databases ( External Data Sources ). The application layer including the Alarming module, the Calculation and Validation module and the Business applications. This level is composed of commercially available components plus dedicated packages for integration and/or special functions. Microsoft.Net platform is used as the common framework for development. The Integration and Orchestration layer (Exchange Foundation) automating and orchestrating the data flows between the applications, composed of : an Enterprise Application Integration tool (EAI), implemented on Microsoft Biztalk a data integration tool Extract, Transform, Load (ETL), implemented on Microsoft SQL Server Integration Services an Application calls (encapsulation services) consumed by the EAI. a Process design tool encapsulated in the EAI a Process execution tool which will message a human Actor if input is required a Business Rule Engine (not yet implemented) A Business Activity Monitoring providing a complete overview of the system to the IT administrator. (not yet implemented) The Visualization Layer (Building Foundations) enabling collaboration through the exposition of dashboards, performance indicators and reports. Microsoft Office Sharepoint Server is used as the container of this layer. Webparts are coming either from specific providers (eg for real time data trending views and process synoptic) or developed by the project itself. 6

7 Common Functionalities and Visualization 7 - WPM-SS Communication Kit Solution Architecture 5 The Project 5.1 Phases Phase of the project Phase 1 Phase 2 Phase 3 Phase of the rollout Phase 4 Phase 5 Phase 6 Description Core Framework Templates and Extensions Pilot sites Description Declension Template and/or Extension Declension Template and/or Extension pilot site Roll-out of a site Thanks to the industrialization process and to the accumulated experience, a reduction of cycle time of the phases during the roll-out is expected. 7

8 5.2 Approach The diagram which follows represents a cycle of life said in "V" particularly adapted to the development of applications and where the list of the key deliverable is mentioned. 5.3 Issues and Lessons learned The first 2 pilots deployment have been held in March and June 2009, the first one in the Argentinean affiliate in Buenos Aires, the other in the Angola affiliate, involving user both in the main office in Luanda and on the offshore floating production unit. The main lessons learned from that pilots are: 1. The overall technical architecture has been validated : the project has reach the objective to implement a number of various technical functions for different specialties (e.g. rotating equipment monitoring and well performance optimization) sharing the same data and built with the same components. 2. As often encountered in such projects, the change management regarding the business activities, organization, responsibilities, etc has required a large effort for training and more technical support than anticipated. 3. The central component, called the Asset Model in Total s architecture, close to a master Data management System is certainly one of the most important and required much attention. 4. The classical development cycle ( V Cycle) that has been adopted has shown some limitations. A kind of tunnel effect has led to a situation where a number of delivered components where not fully acceptable by the end user and required some re-work. A prototype of the Solution at an early stage of the process would have helped on a better appropriation and acceptance by the end user. Also this development cycle has delayed the appropriation of the tools by the support teams, both business and IT, with a learning curve starting a bit too late. 5.4 Project Figures and Facts The project was initiated in late 2006 and was planned as a 24 months activity. 8

9 The pre-project work and call for tender has required some time and the actual development has started by the end of Final delivery of the system, anticipated in December 2009 had to be postponed by a few months. Installations of the 2 pilots in the affiliates and site acceptance phases have been run in March and June 2009, leading to an actual overall activity of 30 months. The internal project team was composed of up to 6 persons (business and IT), with more workload within the preliminary and acceptance + deployment phases. Most of the development and integration have been conducted by a contracted third party. 5.5 Transformation Tools The architecture is relying on a number of business components integrating each of them some tooling to manage the evolution of the system required by changes in the asset configuration and/or adding new functions. Osisoft-PI (Plant Information System) is the most important of them. Some rules and procedures have been defined to ensure a proper coordination of the transformation actions required on all those components. Microsoft.Net platform plus middleware components (MOSS 2007 and Biztalk) are used as the common framework for development. UML has been leveraged to develop the models. 6 Value this paragraph has been added since last version and will be further completed. The Solution has enabled a far more relevant monitoring thanks to the simulation tools which provide, every 3 minutes for certain measures or every hours for others, comparisons between the real measures and the expected results. Thanks to the Solution architecture, future extensions such as those developed in the next paragraph can be more rapidly developed and implemented. 7 Future Extensions End of 2009 and the first semester of 2010 have been devoted to finalize the system, ensure its usability and run a feedback analysis regarding the deployment of the 2 first pilots. The organizational changes on the business side have attracted most of the workload in that phase. The first two pilots cover for each subsidiary one module (WPM for one and PPM for the other), and next deployments will expand the scope to other modules. At this time further benefits of the solution architecture should be observed with faster deployments and much shorter learning curves. Two complementary extensions to the Field Monitoring System are presently on the workbench: 9

10 1. Adding a new module (extension of the asset model, new functions and a new business component) for another specialty domain : the pipeline corrosion monitoring 2. Leveraging the heart of the system by adding some simple but useful capabilities for browsing and navigating through the asset data model and associated data. A support Organization and Transformation model will be set up for the future evolutions of the Solution relying upon: 1. A Methodology pole to manage the Asset Model and the Workflows evolutions 2. A Technical pole to implement and deploy new functionalities. 10