240 likes | 245 Views
WITSML is a collaborative effort to update the widely used American Petroleum Institute WITS standard for moving drilling data between rig and office computer systems. It improves interoperability, reduces costs, and accommodates the "always on" internet environment.
E N D
SPE 84066 Wellsite Information Transfer Standard Markup Language, WITSML, an UpdateM.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
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
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
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
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 Who participates? POSC special interest group open to all interested parties
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
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
Well * Wellbore * Rig 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 Data Objects • * Initial implementation in 2002
WITSML Documents <?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">14089.3</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
WITSML Documents <?xml version="1.0" encoding="UTF-8" ?> <xsd:schema targetNamespace="http://www.witsml.org/schemas/120" xmlns:witsml="http://www.witsml.org/schemas/120"> <xsd:sequence> <xsd:complexType name="obj_trajectorys"> <xsd:sequence> <xsd:element name="trajectory" type="witsml:obj_trajectory" minOccurs="0" maxOccurs="unbounded"> <xsd:sequence> <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
WITSML Documents • WITSML trajectory data formatted with style sheets (XSLT & CSS XML files) viewed in web browser
User interface control Service companies Vendor independent XML Application Data store 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
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 Email attachments or moved on floppy disk • Run unencrypted on the public internet to test interoperability • The WITSML standard is agnostic to the security model
Server Client • On Demand, via Web Services API • Client-server model • SOAP Store Interface (GetFromStore method) Request Response • Accumulate and Propagate • Receive data from providers in near real-time • Support Subscribe via SOAP • Publish via HTTP POST Data workflows • Informal, Discrete • Floppy disk file transfer of XML data files • E-Mail file transfer
Practical workflows • Service Contractor to Service Contractor • Service / DrillingContractor to Operator • Application to Application • Operator to Operator • Operator to Government *In use today
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
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..
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 Visualisationdisplays
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
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
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.
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 1.2.1 and major eg 1.3
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
Further Information • Web Sites: www.witsml.org&www.posc.org • Full details of object schemas • Catalogs and definitions • Examples • Sample style sheets • Documentation • Contacts for participating companies