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

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

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

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

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

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"> </wells> Web Services optional

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.

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.

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

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.

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.

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) <well uid=”xxx”> <nameLegal>BossWell</nameLegal>

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.