Overview of WITSML and usage in BP Nick Whiteley, Wells Technology, BP WITSML lndustry Workshop Calgary, AB Canada September 29, 2011
Wellsite Information Transfer Standard Markup Language The right-time seamless flow of well-site data between operators and service companies to speed and enhance decision-making An Open Information Transfer Standard for the Oilfield http://www.energistics.org/witsml-standard
WITSML SIG: Member Companies Accenture AspenTech Atman Consulting Baker Hughes BJ Services BP Chevron US DOI Digital Oilfield Sol. DrillScan Dynamic Graphics ExxonMobil Geolog SPA Geoservices Halliburton HRH Limited IBM IDS Institut Francais du Petrole INT Kongsberg LIOS Technology Mahindra Satyam Merrick Systems Microsoft Moblize National Oilwell Varco Oil Teams S.R.L. ONGC OpenSpirit Paradigm Pason Peloton Perfomix Petris Technology Petrolink Pioneer Natural Res. Roxar RPS Group Saudi Aramco Schlumberger SDC Geologix SMT Shell Smith (now Schlumberger) Statoil TCS Total Weatherford Wellstorm Woodside Energy
Usage Modes Service Contractor to Service Contractor e.g. log data between LWD and Mudlogging service providers Service / Drilling Contractor to Operator very common usage e.g. LWD curves to petrophysical, PP/FG, T&D and other application Application to Application e.g. ExxonMobil & Chevron handling of Completions data through life of well (in progress) Operator to Operator Yet to be exploited e.g. sharing data with partners Operator to Government e.g. Statoil/BP (NPD report), Pioneer (Stim Job Report) Primary current workflows / use cases: 1. Transfer of real-time data from service company to operator applications (e.g. 3d Visualization/geosteering, PP/FG, petrophysical, T&D Analysis etc.) 2. Aggregation of multiple data sources into a common platform for visualization enhanced and common situational awareness 3. Transfer of report data. E.g. daily operations summary to regulatory body, fracture/stimulation job report from service company to operator
Supported Data Objects in Version 1.4.1 Cement Job Frac / Stimulation Fluids Drilling Operations Reporting Log Mudlog Formation Marker Core Risk Subsurface Well & Wellbore CRS Rig / Rig Equipment Tubular / string Wellbore Geometry BHA Run Survey Program Target Trajectory & Tool Error Contextual Message Attachment Change log Object Group General 5 Source: BakerHughes/Paradigm
Benefits to BP and History in BP BENEFITS WITSML and the BP Common Architecture are important enablers for other BP D&C projects including the BP Well Advisor software Integrate real-time data together with BP s know-how, policies and guidelines into the way Drilling & Completions works, transform the safety and integrity of our operations, while improving drilling performance and well reliability Data can be sourced from more than one service provider, manipulated to provide information from data, and viewed in integrated displays, supporting enhanced decisions Enables the deployment of hybrid solutions for real-time drilling data handling with applications and services chosen for capability rather than for compatibility Reduces costs for moving data, and improves competitiveness (Selecting vendors not driven by impact of IT changes, but on the service provided) More robust solution providing increased availability and reliability to support critical decisions both inside and outside of normal working hours. HISTORY 2003/2004 first use of WITSML in BP to transfer data from service providers to subsurface applications 2007 Aggregation of multiple vendors data into a single common platform in Tangguh (Indonesia) 2008 First use of a BP managed rig based data aggregator in support of a GoM Exploration Well. 2009 Every North-Sea rig has real-time data aggregated and displayed in HQ using WITSML. First use in BP to aggregate coiled tubing data and wired drillpipe data (LWD and along string measurements) 2010 Creation of a smart agent to detect data issues. Leads to a significant improvement in uptime and quality 2011 Angola go live with most extensive rigsite aggregation to date: LWD, SLS, Cement, Drilling Control System, Well Test, E-line 2011 GoM CORE opens to provide remote well control monitoring. Data systems are WITSML based Today Application in North Sea, GoM, Angola, Brazil, Oman, Alaska (pilot), Azerbaijan (pilot). Plans for Egypt, Jordan, Iraq 6
Example: Automated Petrophysical Model Updates BEFORE During reservoir drilling operations the Petrophysical community was manually loading several LAS log and trajectory files into the application to perform petrophysical analysis LAS files would normally only be available every 2-5 hrs Files did not have consistent data sampling rates had missing data and directional surveys supplied separately Old workflow of manually loading and updating models was a five-step process The imported data The data imported via the routine along with the automated interpretation NOW Petrophysicist defines a subscription to the real time WITSML well data depository Data (logs and trajectory) is automatically loaded periodically into petrophysical application Petrophysics group wrote a routine to automate field specific petrophyiscal analysis The old manual workflow of 5 steps has been reduced to 1 step saving an average of 45 minutes per data load, per LAS file on average a saving of 4 hours per 24 hours New workflow has enabled faster discussions between Petrophysics and other subsurface disciplines 7
Strategy & Deployment STRATEGY All electronic data collected on the rig from down-hole and rig sensors will be aggregated into a central data repository. Contracts will reflect these requirements All data will be managed and stored internally by BP. If this data is aggregated offshore then the offshore WITSML data aggregator will be replicated to an onshore store hosted in a BP office or managed data centre. Typically, this onshore store will contain data from many rigs. It will provide data access to onshore personnel and to any other authorised personnel with permitted access to the BP Wide Area Network (WAN). Data aggregation will use WITSML as far as possible but other data formats, including WITS and OPC, will be supported to enable interfacing to other rig systems. DEPLOYMENT We derive maximum value by not just deploying the WITSML standard but by deploying it in a consistent way The Common Architecture design is vendor neutral. It is a framework which may be populated quite deliberately with components from different vendors. There will be regional and financial circumstances that will favour different suppliers in different drilling operations. BP has selected a preferred WITSML aggregator There are two variants of the Common Architecture model but both options result in the all of the data collected during the operations being aggregated in the office WITSML store : Rig site aggregation Office aggregation 8
WITSML Roadmap 2011(1.4.1) stimjob object Error model Support for plugand-play 2014 Focus on support for automation & reducing barriers to entry Tiered usage (high end/low end) Major release - not backward compatible 2017 More automation New use/new data
Just released! V1.4.1 New & Improved API Specification Clarified behaviours Improved interoperability Completely revised API document Data Schema specifications ADDED: stimjob, drillreport, toolerrormodel, attachment, objectgroup REMOVED: trajectorystation, realtime, welllog, dtsinstalledsystem, dtsmeasurement CHANGED: mudlog to clarify lithology, log to allow more efficient querying Supporting documentation and tools stimjob usage guide XSLT Transform 1.3.1.1 to 1.4.1 Lithology usage guide (coming soon) More to come
2014 Major Release Goals: Reduce overhead for operators and service/technology companies to implement and use these standards to meet operational goals Enable companies to focus on product differentiators rather than the movement of data from A to B Reduce barriers to entry for all, including smaller organizations Business case for these goals: Add value to entire market (onshore as well as offshore) Lower cost (tiered approach, deployment barriers ) Reduce personnel involvement and over-head