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
1
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
2
WITSML Headlines
• Scope
– Data Transfer and Web Services Standards
– Focus: Drill Site to Office / Control Center
– Focus: Drilling and Completion
• Status
–
–
–
–
–
–
–
3
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 1.3.1.1 (Q1 2007)
Version 1.4.0 (Q4 2008)
WITSML Data Objects / XML
Schemas
General
•Well
•Wellbore
•Message
•Operations Report
•Drill Report
•Real Time
•Wellbore Geometry
•Risk
•CRS
Surface Logging
•Mud Log
Surveying
•Survey Program
•Target
•Trajectory
Logging While
Drilling
•Log  Well Log
(includes Wireline)
•Formation Marker
4
Communication
•Subscription
•Server Capabilities
•Change Log
Rig Instrumentation
•Rig / Rig Equipment
•Cement Job
Fluids Systems
•Fluids Report
Coring
•Sidewall Core
•Conventional Core
Directional Drilling
Systems
•Tubular
•Bit Record
•BHA Run
Source: BakerHughes/Paradigm
WITSML SIG member goals
•
– Service Co  Service Co
– Operator  Operator
– Software Vendor  Software Vendor
Automatic flow of data
•
Data Retention
– Send and receive with little/no manual
intervention
– End-user application always updated with
current information
Analysis
Vendors
Aggregation
Applications
– Vendor, Service company neutral
– Version agnostic
Data mgmt
Online, on demand
– Available as needed
– Cross firewalls/Cross time zones
Service
Companies
Information
•
•
5
Inter-company communications
Preservation
Operators
Reporting
Agencies
Basics
• Modularized Schemas.
• Dependent Objects.
• Persistent Unique Identity.
• Data base oriented methods
• Soap message style
• Capabilities
• Query Template
• Publish/Subscribe
6
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="1.4.0.0">
<well uid="w-12">
…
</well>
<well uid=“123">
…
</well>
</wells>
• Web Services optional
7
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.
8
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.
9
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
10
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.
11
Capabilities
• Client:
– Contact information.
– Which Data Schema version is supported.
– Which WS version is supported.
• Server:
– Contact information.
– Which Data Schema versions are supported.
– Which WS methods (for which data objects) are
supported.
– Which WS versions are supported.
12
Query Template
• GetFromStore request (not schema compliant
because of empty elements)
<wells xmlns="http://www.witsml.org/schemas/131">
<well uid=””>
<country>Mexico</country>
<nameLegal/>
</well>
</wells>
• GetFromStore response (“read” schema
compliant)
<wells xmlns="http://www.witsml.org/schemas/131">
<well uid=”xxx”>
<country>Mexico</country>
<nameLegal>BossWell</nameLegal>
</well>
</wells>
13
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.
14