1 / 17

WITSML vs WITS – at the Wellsite

WITSML vs WITS – at the Wellsite. 16 th May, 2007. WITS 0 vs WITSML. A WITSML Data Stream <nameWell> TEST </nameWell> <nameWellbore> 1 </nameWellbore> <indexType> Depth </indexType> <startIndex> 7051.0 </startIndex> <endIndex> 7851.0 </endIndex>

latika
Download Presentation

WITSML vs WITS – at the Wellsite

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WITSML vs WITS –at the Wellsite 16th May, 2007

  2. WITS 0 vs WITSML A WITSML Data Stream <nameWell>TEST</nameWell> <nameWellbore>1</nameWellbore> <indexType>Depth</indexType> <startIndex>7051.0</startIndex> <endIndex>7851.0</endIndex> <indexCurve>DMEA</indexCurve> <stepIncrement>1.5</stepIncrement> <indexUnits>FT</indexUnits> <curveDescription>Measured Depth</curveDescription> </logCurveInfo> - <logCurveInfo> <mnemonic>TIME</mnemonic> <unit>S</unit> <nullValue>-999.2500</nullValue> <curveDescription>Time</curveDescription <mnemonic>ACTC</mnemonic> <unit /> <nullValue>-999.2500</nullValue> A WITS 0 Data Stream && 0201 02021 0203152 02041699 02270.973 02288871 0229484 !! && 1401 14021 14088871 1419-9.25 1420266 14211484 !! 6

  3. WITS 0 vs WITSML A WITS 0 Data Stream • && • 02085342.12 • 021020.973 • 021121 • 021288 • !! A WITSML Data Stream • <?xml version="1.0" standalone="no" ?> • - <logs xmlns="http://www.witsml.org/schemas/120" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.witsml.org/schemas/120 http://www.witsml.org/schemas/120/obj_log.xsd" version="1.2.0"> • <log uidWell="W-B6CF4BDC94954A88AFDA298DED0446F1" uidWellbore="" uidLog="L-9A8213E28ADF48B5941433F069CF5822“ • <nameWell /> <nameWellbore /> <nameLog /> • -<logHeader> • <runNumber /> • <indexType>Depth</indexType> • <startIndex>5342.12</startIndex> • <endIndex>5342.12</endIndex> • <indexCurve>DEPTMEAS</indexCurve> • <stepIncrement>0</stepIncrement> • <indexUnits>FT</indexUnits> • <logHeaderParam index="1" name="DATE" description="Log Date">11-May-2007</logHeaderParam> • -<logCurveInfo> • <mnemonic>DEPTMEAS</mnemonic> • <unit>FT</unit> • <nullValue>-999.2500</nullValue> • <

  4. Why should WITSML be used at the Wellsite? • WITS Channels are sometimes hard to identify • WITS Channels are often changed by error or at crew changes • Some Data Curve Types are not specified in the WITS specifications • Only Curve Data can usually be handled • WITSML is ‘self-describing’ and ‘human-readable’ • 95% of Petrolink problems are related to Wellsite Data gathering issues • The use of WITSML is an obvious improvement

  5. So why is WITS still used at Wellsite? • WITS works well and is easy to handle; why change something that works ? • Wellsite Data Acquisition Equipment needs to be upgraded = $$$ • Historic data can be recovered if the Communications Link is down • WITSML is still not well known and is more complex to handle in the Field • Data Standards are ‘invented’ by Operators who then expect Service Companies to implement them………what is the business driver for service companies ? • Even if WITSML is implemented by some; there will be a mix of data types…

  6. Ideal World: WITS / WITSML Wellsite Aggregation

  7. So why is WITSML not used at the Wellsiteand the Operator then connects directly? • Data Acquisition Companies wish to retain Control of their own Data • Data needs to be Quality Controlled and sometimes Edited (LWD) • Wellsite Staff are inexperienced + Editing needs to be done at the Service Company Data Centres – which are usually outside the Operator Firewall (no access to Data from outside the Operator Network) • Data Acquisition Companies may have Proprietary data and formats that they do not wish Third Parties to access (i.e. Image Tools) • WITSML Subscribe/Publish cannot be used ….. ??

  8. Why cannot WITSML Subscribe / Publish be used? • ‘Subscribe’ was originally created to receive Data from a WITSML Aggregator Publisher • ‘Publish’ is ‘always on’ and ‘Subscribe’ has no capability to retrieve Historical data if the connection is lost (VSAT satellite links dropping…) • ‘GetFromStore’ however allows WITSML Data to be Queried and recovered for Updates and Historic information……. • So – ‘GetFromStore’ is the obvious Solution…….However….

  9. ‘GetFromStore – the Solution? • Application Request for available ‘Well’, ‘Wellbore’, available Objects and Mnemonics, Intervals, Updates…… • ‘GetFromStore’ allows everyone to collect the information they need However… • Network restrictions do not allow external companies to connect from outside the corporate network • so how would Data Acquisition Companies verify their Data unless they managed the Customer Data Centre internally?... or…. • back to the days of multiple service company systems in the Operator office and ‘Desk Engineers’.... !!

  10. WITSML ‘Standards’ – a Chaotic Situation ! • In theory the WITSML Data Schema should be simple to implement: • Well…….Wellbore……..Trajectory Object .…..Log Object…… • But each Service Company is implementing in different ways… • One Company even stores all curve data and trajectory information in one object, so the standard WITSML Query will not succeed… • Another does not follow the initial authorisation procedure for server to server connections….

  11. The Reality :WITSML Office Aggregration

  12. Further Observations • WITSML is not being implemented at the Wellsite ; and it will not be implemented unless the Operators insist (i.e. include it in the Contracts) • Implementation of WITSML at the Wellsite will require a Field Support Element – a boxed solution is unlikely to be successful..... • Data Acquisition Companies (usually Mudlogger) requested to receive and manage WITS Data on the Wellsite from other Companies = Conflict of Interest as they are competitors and offer similar services • Data Acquisition Companies requested to allow their Data to pass through other Company Data Centres for WITSML conversion = Conflict of Interest and often Proprietary data is involved • Data Acquisition Companies not completely WITSML Compliant = New WITSML ‘GetFromStore’ Query Tools for each one and they change...

  13. PowerStream • Full Compliance with WITSML Specifications • WITSML 1.2 / 1.3.1.1 ‘GetFromStore’ / ‘Subscribe’ / ‘Publish’ Capability • Accepts WITS Data from any Data Acquisition Company • Wellsite WITS / WITSML Aggregators • Connect to WITSML Store of any Data Acquisition Company • Independent Company (no Conflict of Interest) providing a WITSML Solution AND the Service Element • 20 Years experience of dealing with Data Acquisition Companies

  14. WITSML Data Flow

  15. Multiple WITSML Source Presentation

  16. Link to Third-Party Applications organize - distribute - archive

  17. Link to Resolver Analysis Model organize - distribute - archive

More Related