Evolution

1
Evolution
2
WITSML Life Cycle Timeline
Years
2000-2001
2002-2003
2004-2005
2006-2007
2008-2009
2010-2011
Version 1.0
Version 1.1
Version 1.2
Version 1.3.0
Version 1.3.1
Version 1.3.1.1
Version x.x?
Version x.x.1
Version y.y
3
The Evolution of WITSML Standards - 1

• Version 1.0 (2001) first prototype
  specifications
• Public Seminar in Austin, Texas
• Version 1.1 (2002) - Minor schema changes. Added
  server capabilities support
• Public Seminar in Stavanger, Norway
• Version 1.2 (2003) First version used widely
• Public Seminars twice per year
• Follow 2 to 3 days of technical working meetings
• Vendor Exhibition added in 2004
• Version 1.3.0 (2005) - Tightening of constraints
  in data schema and web services specifications.
  Decoupled API from data schema.

4
The Evolution of WITSML Standards - 2

• Version 1.3.1 (2006) Minor cleanup,
  clarification, etc. Added XML version-to-version
  conversion script
• Version 1.3.1.1 (2007) - Bug fixes for data
  schema.
• Version 1.4.0 (2008)
• Data schema documentation minor clarifications
  and backward compatible additions to data schema.
  
• More Web Services minor clarifications.
• Documented behavior for indicating changes.
• Documented behavior for Store interface used for
  real-time data.
• Public Seminar and Vendor Exhibition
• May in Houston, Texas
• November in Dubai, UAE

5
WITSML Open Issues List
6
WITSML Strategic Challenges

• Grow from Early Adopter Use to Full Deployment
• Widen the footprint of WITSML data types in use.
• Engage Completion Contractors.
• Refine ability to automate transfers.
• Address workovers, maintenance, and services.
• Address more analytical, decision-making
  processes.
• Support use by PRODML.
• Address bi-directional data transfers, e.g. well
  paths

7
WITSML Measuring Progress

• Are we delivering the objective for the WITSML
  Standards?
• Enable decisions using Real Time data
• Proven, deployed solutions delivering real-time
  data for decision-making
• Simplify data interaction and data reuse
• 90 of data transferred is related to four WITSML
  data objects
• Limited use of Operational Information
• Reduce complexity
• Incorporation of new data has moved from days to
  hours and minutes
• Initiation of new data use still issue
• Some data errors still exist
• Reduce cost
• Time savings
• 5 minute intervals on loading are now considered
  Normal or Maximum
• Technology Improvements
• Application use of real-time data increasing
• More accuracy
• Adoption and Use rate indicates value

8
Use
9
Simplicity and Integration

• Simplicity
• Achieved through
• Consistent data element and structure definitions
  and semantics
• Consistent interfaces among cooperating software
  components

• Integration
• Achieved through the ability to
• Compare and
• Combine
• Data from multiple diverse sources.

10
Drilling Data Architecture (without WITSML)
11
Drilling Data Architecture (with WITSML)
12
WITSML Transfer End-Points

• Service Contractor to Service Contractor
• Service / Drilling Contractor to Operator 
• Application to Application
• Operator to Operator 
• Operator to Government

13
Service Contractor to Service Contractor

• Example Sharing a BHA description at the rig
  between different service vendors
• Usage Reduce inefficient duplicate entry of
  data. Improve quality of stored data

14
Drilling / Service Contractor to Operator

• Example Automation of transfer of electronic
  report data from drilling contractor.
• Example Geological data from Mud Logging company
  into wellsite composite log application
• Usage Avoid costly re-keying of data received
  in paper form. Ensures all gathered data is
  stored in company repositories.

15
Application to Application

• Example Migrating data from one proprietary
  format to another, using the WITSML API as the
  data mapping tool.
• Usage Wellbore hardware configuration viewer,
  input to simulation models or 3D visualisation
  displays

16
Operator to Operator

• Example Operator Daily drilling report object to
  a partner
• Usage Current partner reports do not allow
  loading of data into company database. Access to
  data allows viewing in a format users are
  comfortable with, and retaining the data for
  benchmarking

17
Operator to Government

• Example Filing of statutory documents relating
  to the well permitting process. UK DTI, Norways
  NPD, US MMS, BLM etc.
• Usage Automate statutory reporting, reduced
  custom keying of data

18
What would success look like?
Service Companies

• Goals stated in Real Time/WITSML usage study1
• Access to the information I need to make
  time-critical decisions, regardless of who I am
  currently working with (as a Service Company)
• Save me 15 minutes a day, by not having to type
  in some data that is already in electronic format
  somewhere else
• Allow me to understand what is happening, at
  anytime, for any (drilling) operations, anywhere
• The ability to use drilling data from any
  technology provider within our (internal)
  processes for decision making
• Neutral way of encapsulating information so that
  it is available regardless of vendor, provider or
  version of their various technology

Information
Operators
1 Marketing Analysis of Real Time Workflow
initiatives. Landmark/Halliburton 2004
19
WITSML Examples of Use

• Operating Company A
• 300 wells affected by WITSML
• Impact in all regions of drilling activity
• 2 month study in 2006
• 29 wells in WITSML
• 250000 ft drilled using WITSML

• Operating Company B
• 87 wells affected by WITSML
• 51 in first ¾ of 2006 alone
• Typically 10-15 actively running (WITSML) at any
  time
• Typical operations
• 5 minute update intervals
• Operations Support

Source WITSML (October 2006) Public Forum
presentations
20
InterACT Scalability - Getting data to where its
needed..
Client ODC
Wellsite data acquisition, aggregation and display
Web based viewers
InterACT interfaces- WITSML API WITSML
Streaming WITSML Data Exchange
Rig Sensors
Downhole Tools
Schlumberger Secure Center
Schlumberger OSC