1. SPE 84066
Wellsite Information Transfer Standard Markup Language, WITSML, an Update M.A Kirkman, SPE, BP; M.E. Symmonds, SPE, Schlumberger; S.W. Harbinson, SPE, Landmark Graphics; J.A. Shields, SPE, Baker Hughes; M. Will, Schlumberger; A. Doniger, SPE, POSC

2. What is WITSML ?
WITSML is a collaborative effort to update the widely used American Petroleum Institute WITS standard for moving drilling data between rig and office based computer systems
Is designed for the standards of today's “always on” Internet environment while still accommodating those rigs not yet “Wired”
Public and open to all to implement
Real world use of the standard is happening NOW, and effort is going on to extend the scope of practical usage
WITSML is a collaborative industry effort to update the widely used API WITS standard for moving drilling data between contractor and operator computer systems
It is designed for the standards of today's “always on” Internet environment while still accommodating those rigs not yet “Wired”
Real world use of the standard is now happening, and effort is going on to extend the scope of practical usage
In the future, it may extend beyond the wellsite as a standard for many transfers of drilling data in ways not easily done with prior standards

3. History
Industry real time data centers in the 1980’s drove a standard, that became an API (American Petroleum Institute) recommended practice…
WITS (Wellsite Information Transfer Specification)
Designed in an era before networks and the Internet, though it stood the test of time, is now dated. Differing approaches to network implementations fragmenting interoperability
Statoil moved to develop DART (Drilling Automation Real Time) for their own needs
DART Evolved into a multi company effort to create a new standard, replacing WITS, based on evolving internet technology, with much improved functionality

4. Why is it a “Good Thing”?
Improves “Plug and play” approach to moving data between systems
For Operators, reduces costs for moving data, and improves competitiveness (Selecting vendors not driven by impact of IT changes, but on the service provided)
For Contractors, reduces need to support different systems for different operators
WITSML covers not only sequential data, but also contextual data

5. POSC special interest group open to all interested parties
Who participates?
Operators
Statoil
Shell
Norsk Hydro
ExxonMobil BP
Authorities
UK DTI
Contractors
Schlumberger
Sense Technology
SDC Geologix
NPSi
Petrolink
Paradigm
Open Spirit
Landmark
INT
IMS
Halliburton
Baker Hughes
POSC special interest group open to all interested parties

6. What is WITSML technology?
Internet standards driven / Hardware & software platform independent
XML (eXtensible Markup Language) & xsd, (XML schema definition) XML Specification of data objects
A formal and validated “Dictionary” and “Grammar”
World Wide Web-compatible / Web services
HTTP, SOAP & wsdl, XML
100% buzz word compliant
Broad coverage of drilling related data
Well, trajectory, drill string, wellbore, reports, logs, real time data
Designed to support drilling workflows, with or without network links

7. Implementations
Initial – WITSML streams added to proprietary real time systems from the major contractors. This output used to drive interfaces to operator data stores / applications plus contractor internal applications
Current – address a broader range of applications benefiting from real time data or contextual data not covered by earlier efforts
Future – should further reduce drilling IT costs and facilitate reporting automation

8. Data Objects Well * Wellbore * Rig Units * Trajectory * Target
Rig Equipment
Units *
Trajectory *
Target
Bit Record
Bottom Hole Assembly
Wellbore Geometry
Casing Scheme
Open Hole
Daily Operations
Fluids Report
Cement Job
Log *
Real Time
Mud Logging
Server capabilities
* Initial implementation in 2002

9. WITSML Documents Generic structure Data (not well) aggregation
<?xml version="1.0" encoding="UTF-8"?>
<trajectorys ... version="1.2.0">
<trajectory uidWell="W-12" uidWellbore="B-01" uidTraj="pe84e">
<nameWell>6507/7-A-42</nameWell>
<nameWellbore>A-42</nameWellbore>
<nameTraj>Plan #2</nameTraj>
<uidTrajParent>pe84d</uidTrajParent>
<nameTrajParent>Plan #1</nameTrajParent
<mdMn uom="ft">0</mdMn>
<mdMx uom="ft"> </mdMx>
<definitive>true</definitive>
<memory>true</memory>
<finalTraj>true</finalTraj>
<aziRef>Grid north</aziRef>
<trajectoryStation uidWell="W-12" ....
Generic structure
Data (not well) aggregation
Object container root
Object identity
Object details
Units of measure
Follow POSC ‘UOM’ recommendations
witsmlDict.xml for v1.2
This shows part of the original XML file for a WITSML trajectory object.
The outer container is “trajectorys”, then each trajectory has its data elements, including at the bottom, the first in a sequence of
trajectoryStation objects
This also illustrates the units labelling via the “uom” attribute.

10. WITSML Documents Schema
<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema targetNamespace=" xmlns:witsml="
<xsd:sequence>
<xsd:complexType name="obj_trajectorys">
<xsd:element name="trajectory" type="witsml:obj_trajectory" minOccurs="0" maxOccurs="unbounded">
<xsd:element name="trajectoryStation" type="witsml:obj_trajectoryStation" minOccurs="0" maxOccurs="unbounded">
</xsd:element>
Schema
Basis for conformance / versioning
Programmatic confirmation of compliance of the data to schema
Here is an abbreviated version of the XSD (schema) document that defines the trajectory object in WITSML.
It contains the version number(120 is version 1.2.0)
There is an outermost trajectorys object containing a sequence of trajectory objects containing a sequence of trajectory station objetcs.

11. WITSML Documents
Here’s an example of the trajectory and trajectoryStation objects formatted up into a web browser report using XSLT style sheet to control the formatting and a CSS cascading style sheet to supply the colors and fonts.
WITSML trajectory data formatted with style sheets (XSLT & CSS XML files) viewed in web browser

12. User interface control Vendor independent XML
WITSML Documents
Web services enables the selecting and transfer of XML objects on remote machines
Supports queries for real time and static objects
Supports requests for objects not yet created
Here’s an example of the trajectory and trajectoryStation objects formatted up into a web browser report using XSLT style sheet to control the formatting and a CSS cascading style sheet to supply the colors and fonts.
User interface control
Vendor independent XML
Service companies
Application
Data store

13. Security Security is not part of the WITSML standard
Security is decision of implementer. Options for document transfer include:
Secure transactions (similar to online banking)
Sent as attachments or moved on floppy disk
Run unencrypted on the public internet to test interoperability
The WITSML standard is agnostic to the security model

14. Data workflows Informal, Discrete On Demand, via Web Services API
Floppy disk file transfer of XML data files
file transfer
Server
Client
Request
Response
On Demand, via Web Services API
Client-server model
SOAP Store Interface (GetFromStore method)
How it equates existing work flows – cornerstone is the schema / document format
Files – for poor comms, informal workgroups, archival
Client server / RPC / Request response – server exposes interfaces that clients can interact with
WITS0 – ‘realtime’ data feeds
Accumulate and Propagate
Receive data from providers in near real-time
Support Subscribe via SOAP
Publish via HTTP POST

15. Practical workflows Service Contractor to Service Contractor
Service / Drilling Contractor to Operator 
Application to Application
Operator to Operator 
Operator to Government
*In use today

16. 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

17. 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. .

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

19. Operator to Operator
Example: Operator Daily drilling report object to a partner
Useage: 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

20. Operator to Government
Example: Filing of statutory documents relating to the well permitting process. UK DTI, Norway’s NPD, US MMS, BLM etc.
Usage : Automate statutory reporting, reduced custom keying of data
UK PON 9 as a starting point

21. Current status
A successful implementation, focussed around LWD data, evolving from the principle of the way WITS data was used
The challenge is to deepen the usage to include the static contextual data - far easier to handle with WITSML than with WITS..
Where do we want to be?
Instigating technical changes that will make the flow of data more automated
Saving cost through removing duplication of data entry.

22. Future
Data standard owned by an oilfield standards organisation, POSC, the Petrotechnical Open Standards Consortium
Now has its own web presence
Seeking alignment with other XML efforts in our industry
Operator encouragement for broader implementations to improve existing workflows
Original companies plus others using the POSC SIG Model
New versions driven by the POSC WITSML Special Interest Group (SIG)
Releases staggered to match pace of use, minor eg and major eg 1.3

23. What made WITSML a success?
A small core group of Operators and Contractors defined the vision and built a limited implementation to achieve a simple initial goal
A steering committee provided financial support for professional documentation of the work done by a dedicated technical group
“Volunteerism” was then formalised by transferring custodianship to a standards body (POSC), as the standard was opened up to input from any interested party
A small core group of Operators and Contractors defined the vision and implemented a limited implementation to achieve a simple goal, while keeping the needs of a broader standard in mind
A steering committee provided financial support for professional documentation of the work done by a dedicated technical group, with kick off funding to establish support within the contractors
The “Volunteerism” was then formalised by transferring custodianship to a standards body (POSC), as the standard was opened up to input from any interested party

24. Further Information Full details of object schemas
Web Sites: &
Full details of object schemas
Catalogs and definitions
Examples
Sample style sheets
Documentation
Contacts for participating companies