Integrated Operations SIG: Distributed Temperature Survey

1
Integrated Operations SIGDistributed
Temperature Survey

• Data Transfer Standard UpdateStavanger, 18
  November 2005Paul Maton (POSC)

2
Overview

• Introduction
• Summary of the technology
• Early applications, emerging requirements of DTS
  in EP
• Business drivers for DTS in EP
• SIG formation and activities
• Current status and plans

3
Overview DTS Data Diagram
Supplier
Open Standard
Client
Operations Centreand/or Offices
Wellhead
WITSML standarddata format
DTS proprietary data format
Vendor Applications
Proprietary Applications
Laser
Vendor Datastore
Proprietary Datastore
Backscatter to Temperature converter
Partner(s)
WITSML adaptor
Proprietary Applications
Vendor Applications
DTS Box
Wellsite
Vendor Datastore
Proprietary Datastore
Optical fiber carrying transmittedand
backscattered light
Well/Wellbore
Operator
4
Backscatter spectrum
Temperature f((I/I-) )
Rayleigh componentequal to incident wavelength
Intensity
Stokescomponent Temperature independent
Anti-Stokescomponent Stronglytemperature
dependent
Brillouin bands
I-
I
Wavelength
Raman bands
5
Why establish a standard?

• Manufacturers
• Enabler for greater industry use of DTS
• Possible applicability in other industries
• Service companies
• Avoids the requirement for customization for each
  client
• Enabler for greater industry use of DTS
• Operators
• Consistent access to data from different service
  companies
• Earlier availability of DTS data

6
June 04 Proposal

• Collaborative design and development of DTS data
  transmission and exchange standard between DTS
  manufactures and suppliers and operators
• Leverage WITSML architecture, infrastructure
  (API) and process (SIG)
• Evolution and maintenance of public domain
  standard through POSC
• Transfer funtionality, applications, and storage
  of information are out of scope

7
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

8
DTS Group formation

• BP sponsor Richmond meeting (March 04)
• Attendees BP, Shell, Baker Hughes, Halliburton,
  POSC, Polarmetrix, Schlumberger, Sensornet, Wood
  Group
• POSC publish project proposal (June 04)
• Participation established (Sept 04)
• Active BP, Shell, Halliburton, Schlumberger,
  Sensornet
• Funding (17) and monitoring (3) POSC members of
  IntOPS SIG

9
DTS Group Activities

• Teleconferences (4)
• Reviewed scope, raised issues (IP, data content,
  flexibility, XML or OPC?, etc.), enumerated
  reference information, etc
• Workgroups at Shell, London (2)
• Refined and reviewed requirements, scoping,
  issues, received submissions, reviewed initial
  draft specification
• On-going work by POSC staff
• Documenting and analysing requirements
• Revised XML schemas internal review

10
Resources

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

11
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

12
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

13
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

14
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

15
(DTS) Fiber configuration patterns
Wellhead level
Single straight fiber
Single straight fiber plusindependent sensor
Partially returned fiber or J
Fully returned fiber or U
16
DTS Data Model
wellbore
well
nameWellbore,
nameWell, field
wellboreFiberSchematic
dtsCalibration
(Name, value) pairs
lAF,mD, type
fiber
mfr, serial,
17
DTS Features 1

• Flexibility allow evolution of technology
• fiber and instrumentBox are independent of EP
  application
• location in wellbore in terms of lengthAlongFiber
  and measuredDepth with reference points such as
  baseTubingHangerFlange
• WITSMLWellLog used to transfer temperature and
  fiber self-test (OTDR) profiles

18
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

19
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

20
fiber.xml
lt?xml version"1.0" encoding"UTF-8"?gt lt!--
Standalone description of a fiber Note that
this is an example only, and may not actually
exist --gt ltfiber id"fiberExample1"
xmlns"http//www.witsml.org/dts"
xmlnsxsi"http//www.w3.org/2001/XMLSchema-instan
ce" xsischemaLocation"http//www.witsml.org/d
ts ../obj_dts.xsd"gt ltnamegtExample Fiber
Onelt/namegt lttypegt50/125 multimodelt/typegt ltcoatin
ggtgoldlt/coatinggt ltjacketgthytrellt/jacketgt ltdiamet
er uom"um"gt900lt/diametergt ltrefractiveIndexgt1.497
6lt/refractiveIndexgt ltoneWayLoss
uom"dB/km"gt.18lt/oneWayLossgt ltspoolNumberTaggt1234
5AA4lt/spoolNumberTaggt ltspoolLength
uom"m"gt10000lt/spoolLengthgt ltmanufacturingDategt19
65-03-08lt/manufacturingDategt ltmanufacturergtCornin
glt/manufacturergt lt/fibergt
21
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

22
POSC DTS Standards in Shell

• Martijn Hooimeijer
• Linda Dodge

23
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
24
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
25
Envisioned DTS Architecture
Process Control Domain Storage required for 72
hours Data to be sent in POSC DTS ML Exchange
format.
DTS Hardware

• 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).

Temporary Storage
XML / OPC
Office Domain
XML ? XML (?)
Distributed Data DB
Client Software
POSC DTS Standards in Shell
26
Shells 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
27
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 .

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

29
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

30
More information from

• Paul Maton maton_at_posc.org
• Tel [phone]