1. Agenda
Introduction
Energistics Standards Panorama / History / Participants
Web Services Interoperability Standards v1.0
WITSML Version 1.x Services / Data Specifications
PRODML Version 1.x Services / Data Specifications
RESQML plan
Adjacent Technologies and External Specifications
Subjects for Subsequent Meetings
Candidates for Next Stage Deliverables
Next Steps
Adjourn

2. Wellsite Information Transfer Standard Markup Language
WITSML Summary
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

3. WITSML Headlines Scope Status Data Transfer and Web Services Standards
Focus: Drill Site to Office / Control Center
Focus: Drilling and Completion
Status
In the 9th Year (started in late 2000 by Statoil and BP)
Focus: Growing Adoption, and Use
Strong User Community (SIG) of 50+ Organizations
Semi-annual Meetings, Seminar and Exhibition
Active SIG teams; substantive change management process
Version (Q1 2007)
Version (Q4 2008)

4. WITSML Data Objects / XML Schemas
General
Well
Wellbore
Message
Operations Report
Drill Report
Real Time
Wellbore Geometry
Risk
CRS
Communication
Subscription
Server Capabilities
Change Log
Rig Instrumentation
Rig / Rig Equipment
Cement Job
Fluids Systems
Fluids Report
Surface Logging
Mud Log
Surface Logging
Mud Log
Surface Logging
Mud Log
Coring
Sidewall Core
Conventional Core
Surveying
Survey Program
Target
Trajectory
Surveying
Survey Program
Target
Trajectory
Surveying
Survey Program
Target
Trajectory
Surveying
Survey Program
Target
Trajectory
Directional Drilling Systems
Tubular
Bit Record
BHA Run
Logging While Drilling
Log  Well Log (includes Wireline)
Formation Marker
Logging While Drilling
Log  Well Log (includes Wireline)
Formation Marker
Logging While Drilling
Log  Well Log (includes Wireline)
Formation Marker
Logging While Drilling
Log  Well Log (includes Wireline)
Formation Marker
Source: BakerHughes/Paradigm

5. WITSML SIG member goals
Inter-company communications
Service Co  Service Co
Operator  Operator
Software Vendor  Software Vendor
Automatic flow of data
Send and receive with little/no manual intervention
End-user application always updated with current information
Data Retention
Vendor, Service company neutral
Version agnostic
Online, on demand
Available as needed
Cross firewalls/Cross time zones
Service Companies
Analysis Vendors
Aggregation
Information
Applications
Data mgmt
Preservation
Operators
Reporting Agencies

6. Basics Modularized Schemas. Dependent Objects.
Persistent Unique Identity.
Data base oriented methods
Soap message style
Capabilities
Query Template
Publish/Subscribe

7. Modularized Schemas
Each “object” represents a coherent set of data. For example, one report, one activity, one log.
The plural root is created by adding an “s” to the singular object.
Each “message” can contain multiple objects of the same type.
<wells … version=" ">
<well uid="w-12"> …
</well>
<well uid=“123">
</wells>
Web Services optional

8. Dependent Objects
An object can be dependent on another object for its identity. For example:
A wellbore is identified within the context of a well.
A log is identified within the context of a wellbore.
<wellbores … >
<wellbore uidWell="W-12" uid="B-001">
<nameWell>6507/7-A-42</nameWell>
<name>A-43</name> …
</wellbore>
</wellbores>
Server requires both natural and system identity. System identity optional in schema.

9. Persistent Unique Identity.
Independent objects have a Global Unique Identifier.
Dependent objects have a unique identifier that is unique within the context of its parent.
Sub-nodes have a unique identifier that is unique within the context of its nearest recurring parent node.
Every recurring node which contains elements must have uid attribute.

10. Data base oriented methods
WMLS_AddToStore - add one new object to the server
WMLS_GetFromStore – gets one or more objects from the server
WMLS_UpdateInStore - update one existing object on the server (based on uid)
WMLS_DeleteFromStore - delete one existing object (or subset) from the server (based on uid)
WMLS_GetCap - get the server’s Capabilities object

11. Soap message style
SOAP message style is “RPC” (not “literal wrapped document” style).
integer = WMLS_AddToStore(
[in] string WMLtypeIn, (name of data object)
[in] string XMLin, (string containing XML to add)
[in] string OptionsIn, (keyword-value pairs)
[in] string CapabilitiesIn, (string containing XML describing client)
[out] string SuppMsgOut (error message)
);.
One method works for many object schemas but toolsets cannot provide as much support.

12. Capabilities Client: Server:
Contact information.
Which Data Schema version is supported.
Which WS version is supported.
Server:
Which Data Schema versions are supported.
Which WS methods (for which data objects) are supported.
Which WS versions are supported.

13. Query Template
GetFromStore request (not schema compliant because of empty elements)
<wells xmlns="
<well uid=””>
<country>Mexico</country>
<nameLegal/>
</well>
</wells>
GetFromStore response (“read” schema compliant)
<well uid=”xxx”>
<nameLegal>BossWell</nameLegal>

14. Publish/Subscribe
Publish/Subscribe interface being phased out in favor of a “polling” alternative which uses a “change log” object.
If any information in an object changes then the server will capture the time of the change the change log.
The changeLog object will then be polled for any changes since a particular timestamp (i.e., the last time the client checked).
Once the client knows which objects of interest have changed then it will retrieve the whole object and look for differences.