Integrated Operations SIG:Distributed Temperature Survey

Data Transfer Standard: UpdateStavanger, 18 November 2005

Paul Maton (POSC)

Overview

• Introduction• Summary of the technology• Early applications, emerging

requirements of DTS in E&P• Business drivers for DTS in E&P• SIG formation and activities • Current status and plans

DTS proprietary data format

Well/Wellbore

Backscatter to Temperature

converter Near-real TimeData

Server /RTU / …

Vendor Datastore

Vendor Applications

Proprietary Datastore

Proprietary Applications

Partner(s)

Wellsite

Operations Centreand/or Offices

WITSML standard

data format

Overview: DTS Data Diagram

Vendor Datastore

Vendor Applications

Proprietary Datastore

Proprietary Applications

Operator

Wellhead

Optical fiber carrying transmittedand backscattered light

WITSML adaptor

Laser

DTS Box

Supplier Open Standard Client

Backscatter spectrum

Stokescomponent

Temperature independent

Raman bands Wavelength

Intensity

Brillouin bands

Rayleigh componentequal to incident wavelength

Anti-Stokescomponent

Stronglytemperature

dependent

Temperature = f((I+/I-) +…)

I- I+

Deliverables

• Definition of data content requirements• Standard vocabulary and thesaurus of

vendor specific terminology to standard• Analysis of the usability of the

candidate technologies (XML, WITSML, OPC)

• To be released as part of WITSML v1.3.1– includes schema, stylesheet, sample DTS

data, and documentation

Resources

• BP / Baker initial DTS schema• Shell DTS Primer• Service company publications and data• WITSML specifications – particularly

alignment with WITSML 1.3

Issues - 1

• XML and/or OPC?– DTS Group reviewed status of OPC migration from

COM to XML– Selected XML development leveraging BP/BHI and

WITSML assets

• Reuse of WITSML assets– Leverage data objects such as Well, Wellbore and

wellLog in addition to architecture and data types

• Flexibility and Extensibility– DTS is a young and evolving technology– Standard must not constrain innovation

Issues - 2• Bandwidth constraints

– Between wellhead / control center / office– Any of three levels of bandwidth are common in the

oilfield:• Low: 9600 baud RTU connection • Low to medium: 64kB to 100MB • High: in the order of GBytes/sec

– Need to design for minimal verbosity of XML messages

• Data transmission functionalities– Batch and near real-time data access– Network integrity and quality of service monitoring– Deferred, but future implementations may use WITSML

Server capabilities

Requirements - 1• System installation data

– Well and wellbore contextual data– Fiber and ‘DTS box’ contextual data– Permanent and temporary installations– Various fiber installation patterns– Interchange of equipment

• Calibration of DTS system and data to wellbore– Determining position of DTS measurements along

fiber and in wellbore– Calibrations used to convert Stokes/Anti-Stokes

intensity ratio to temperature and apply other corrections

• OTDR (Optical Time Domain Reflectometry): – self-checking fiber and system functionality

Requirements – 2

• DTS data types– Stokes, anti-Stokes, OTDR, raw

Temperature, calibrated Temperature

– Routine ability to select all or some of the above

• Flexible DTS Message Content– Enable selection of calibration, context and

temperature types for particular purposes– Need to satisfy transfers between wellsite to

office, office to wellsite, and office to office

(DTS) Fiber configuration patterns

Single straight fiber

Single straight fiber plusindependent sensor

Partially returned fiber or ‘J’

Fully returned fiber or ‘U’

Wellhead level

DTS Data Model

dtsInstalledSystem

id, dTim, ….

instrumentBoxInformation

mfr, serial#, dTim…

dtsCalibration

(Name, value) pairs

OTDR

0..n*[Rayleigh]

fiber

mfr, serial#, …

fiberInformation

length, mD, dTim…

wellbore

nameWellbore, …

well

nameWell, field…

instrumentBox

mfr, serial#, dTim…

wellboreFiberSchematic

lAF,mD, type

wellLog

lAF, Stokes,antiStokes, tRaw, tCal

dtsIMeasurement

id, dTim, ….

DTS Features: 1

• Flexibility – allow evolution of technology– fiber and instrumentBox are independent of

E&P application– location in wellbore in terms of

lengthAlongFiber and measuredDepth with reference points such as baseTubingHangerFlange

– WITSML:WellLog used to transfer temperature and fiber self-test (OTDR) profiles

DTS Features: 2

• Re-using WITSML schemas and architecture – Well, wellbore objects– Log with flexible table structure– Many data types, and elements– Composite schema to enable use

independently of WITSML server

• Adding DTS specific sub-schemas and elements

DTS Features: 3

• Documentation Package– Addresses 3 audiences:

• Petroleum Engineers and Geoscientist end-users, Data Managers, Software Engineers

– XML Schemas and Style sheets– Sample XML– Shell DTS Primer

fiber.xml<?xml version="1.0" encoding="UTF-8"?><!-- Standalone description of a fiber Note that this is an example only, and may not actually exist --><fiber id="fiberExample1" xmlns="http://www.witsml.org/dts" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.witsml.org/dts ../obj_dts.xsd">

<name>Example Fiber One</name><type>50/125 multimode</type><coating>gold</coating><jacket>hytrel</jacket><diameter uom="um">900</diameter><refractiveIndex>1.4976</refractiveIndex><oneWayLoss uom="dB/km">.18</oneWayLoss><spoolNumberTag>12345AA4</spoolNumberTag><spoolLength uom="m">10000</spoolLength><manufacturingDate>1965-03-08</manufacturingDate><manufacturer>Corning</manufacturer>

</fiber>

Current Plans

• Publication as integrated part of WITSML v1.3.1

• First non-drilling member of WITSML family of standards

• Promote and support implementation(s) in 2005 - 2006

• Use feedback from implementations to iterate on specification as needed in 2006

POSC DTS Standards in Shell

Martijn HooimeijerLinda Dodge

Why Shell Contributes

• Fits into Shell Data Architecture Standards

• Data handling and processing independent of DTS hardware vendors allows global standards, reduces interfaces

• Standard interfaces facilitate usage of best in class visualisation, interpretation and monitoring tools

POSC DTS Standards in Shell

What Shell has contributed

• Shell DTS Primer (a foundational document for the WITSML DTS definition)

• Integration expertise • DTS Expertise• Stimulating vendors to implement and

comply with WITSML DTS

POSC DTS Standards in Shell

Office Domain

Distributed Data DB

XML ?

XML (?)

ClientSoftware

Envisioned DTS Architecture

POSC DTS Standards in Shell

Process Control Domain

Storage requiredfor 72 hours

Data to be sent inPOSC DTS ML Exchange format.

TemporaryStorage

DTSHardware

XML / OPC

•Transfer raw data: (unscaled) Stokes / anti-Stokes data • Transfer temperature traces• Transfer other distributed data• Flexible header that may include parameters relating to Light box, Fiber, and Well details.• Transfer installation / hardware configuration (either as an “extended” header of regular message, or as separate message, with preference for the prior).

Shell’s plans

• A DTS data handling architecture has been designed around the WITSML DTS, including Oracle DTS Database

• First application using WITSML DTS due to be up and running in Q4 this year: will probably generate change requests

• Continue working with all our DTS vendors to have their devices export WITSML DTS

POSC DTS Standards in Shell

dts summary• Initiated external collaboration amongst DTS service

providers and operator community to establish industry standard data format.

• Active participation in integrated operations SIG to develop data specification requirements based on experience from prototype xml schema developed by BP.

• Proven the application of DTS data transmission via xml through a BP developed schema prototype. This prototype was implemented as an interim solution prior to the release of the industry standard format.

• We are committed to the development and application an industry standard that will be held by POSC .

BP: dts summary

• Initiated external collaboration amongst DTS service providers and operator community to establish industry standard data format.

• Active participation in integrated operations SIG to develop data specification requirements based on experience from prototype xml schema developed by BP.

• Proven the application of DTS data transmission via xml through a BP developed schema prototype. This prototype was implemented as an interim solution prior to the release of the industry standard format.

• We are committed to the development and application an industry standard that will be held by POSC .

Conclusions• Business case exists for DTS data transfer

standard: with benefits to Operators, Service Companies and DTS system manufacturers

• Clear, focussed objectives and community of interest established

• Requirements, Issues and Resources collected, analysed, draft schemas and documentation reviewed by DTS Workgroup, WITSML technical team and Industry

• Publication as first non-drilling extension of WITSML family of standards anticipated by end ’05.

• Operational implementation(s) planned and proceding

More information from

Paul Maton maton@posc.orgTel: +44 1932 828794