Practical Welllog Standards A POSC Industry Collaborative Project Project Manager: Cary Purdy, POSC

1
Practical Well-log StandardsA POSC Industry
Collaborative ProjectProject Manager Cary
Purdy, POSCTechnical Project Manager Dave
Camden, Flare Consultants

• November 1999

2
Contents

• Introduction
• Objectives, background and principles
• Well-log Management Issues and Technical Overview
  of key Project Concepts
• Project Business Plan

3
Introduction

• POSC
• an international not-for-profit membership
  corporation
• provides open specifications for information
  modeling, information management, and data and
  application integration over the life cycle of
  EP assets

"POSC is a trusted source of geoscience,
engineering and IT skills for the EP industry.
We are determined to be THE place to come to for
collaborative work relating to information
sharing in EP. When people want to work together
in a open environment to solve a common EP
business problem, we want them to instinctively
think of POSC." David Archer, POSC CEO
4
Introduction

• Flare Consultants
• Formed in 1998
• An EP data management consultancy company
• Positioned between 'high-level' business
  consultants and EP service
• Cross-domain, exploration to production expertise
  
• Deliver business driven technical solutions
• Virtual team operating world-wide

5
Introduction

• Background to this project
• Long involvement in petrophysics and well-log
  data management in oil and service companies
• Builds on recent well-log management projects
• Baker Atlas improve current 'acquisition-to-datab
  ase' model
• PetroData developing standards for the
  management of well-logs in the Norwegian databank
• Guided by POSC reference data well log trace
  classes

What currently exists is a Framework on which a
complete standard can be built
6
Overall Objective

• To solve the key business problems of well-log
  data management

What does this mean?

• Address the main problem areas

• data overload

• fast-changing, complex nomenclature

• lack of accessible standards

The emphasis is on enabling the creation of a
clearly labelled well-log data set which is
accessible to a wide range of EP professionals
7
Guiding Principles

• Take a business approach
• We need practical, implementable solutions
• Many issues (classifications, business value of
  data) are subjective and there are no 'absolute'
  answers. We will need to reach a business
  compromise solution if time and cost deadlines
  are to be met.

SOLUTION BUSINESS TECHNICAL
8
Guiding Principles

• Clear objectives define standards necessary for
  the creation of an organized, clearly labeled and
  accessible well-log database
• Concentrate on the Long-Term data storage problem
  but with regard to transfer to/from Short-Term
  stores
• Make use of existing work and standards where
  possible
• Improve consistency and completeness
• Concepts should be equally applicable to both
  'Data' and 'Hard Copy' (at appropriate levels of
  granularity)

9
Project Focus

• This project is clearly focused on the data
  acquisition process. However,
• many concepts apply across various processing
  stages of well log and associated data
• work has been already been done to extend
  reference values beyond the acquisition process
• a scope extension to look at processed data could
  be considered

10
Well-Log Management Issues

• Data overload
• too many curves - users cant find the important
  data
• Complex naming
• both curve and LOG (collection of curves) names
  are complex and changing at an ever increasing
  rate
• even petrophysicists are getting confused
• others gave up years ago!
• Disparate business processes
• in the absence of clear, accessible standards,
  people continually create new, local solutions
• often there is no distinction made between
  short-term (e.g. Project databases) and the
  long-term storage (e.g. Archive/Corporate
  databases)

11
Business Value

• Data Overload
• Real Business Value is concentrated in a
  relatively small number of data curves - filtered
  views focus on high value data

Data Volume
Business Value
50,000 'Visible' Acquisition Curves
500 Useful Curves
Data Overload!
12
Confusing Names

• LOG/Tool Names
• GRAND SLAM
• DSI Vs DSST Vs SDT?
• PEX (HALS)
• HALS, HDLL, HDIL, HGNS, HNGS, HRDD, HRGD
• PROC1
• DAVE21
• 22MAY97
• COMP
• GEOL

• CURVE Names
• Sonics DT1R, DT4P, DT4S, DT5, DTCR, DTMN, DTRP,
  DTSD, DTSM, DTHC, DTHU
• Densities RHOZ, NRHB, RHOM, HNRH, HRHO, RHOB,
  HDEB, HROM
• 712, 7121, 7122
• All Sonics DT, Densities RHOB
• GR_ED_001_AJB

LOG refers to a collection of curves for
example from a logging acquisition or
interpretation process
13
Clear NamesCURVE
Purpose to de-mystify proprietary and
esoteric naming systems

• CURVES
• Keep original Mnemonic as CURVE NAME
• TYPE a generic classification which helps user
  understand purpose and can be used to drive
  processing
• DESCRIPTION a text description of the curve
• Use AGREED STANDARDS for naming key CURVE
  attributes (TYPE, CLASS, TOOL, etc..)

Reference values for attributes are also defined
14
Curve Type AttributeExample of reference values
Curve Type Description
Curve Type

• Multiple-component Attribute Reference values
• Separator improves readability
• Hierarchical structure - can set to level of
  detail required
• Structure facilitates searching
• Can be treated as a single value (easy to use in
  existing systems)

15
Clear NamesCURVE ATTRIBUTES
Purpose develop attributes that supply useful
information

• CURVES
• Other Attributes
• Name, Type, Description, Unit Type, Unit,
  Vertical Resolution, Tool, Tool Type, Tool Type
  Description, Tool String, Tool String Description
• Source, Status, Process Stage
• View/load Control Business Value, (Load
  Category), Usage

16
Clear NamesLOG
Purpose to de-mystify proprietary and
esoteric naming systems

• LOG for acquisition data
• Keep full technical/marketing name (information
  only)
• Generic Tool String Name from component tool
  types (this is main LOG NAME that is
  understandable to all and will be time-invariant
  (searchable)
• Specific Tool String Name created by
  concatenating component tool names (information
  and searchable)
• other process stages
• standard names for key composite and CPI data sets

17
Clear Business Process

• Attempting to follow standard procedures at all
  levels of detail is impractical
• the work involved may not bring enough value to
  the business
• users won't do it!
• The key is to apply standards where they are
  effective
• for shared, long-term data and information
• for short-term individual or project-type work

Successful data/information management is greatly
facilitated by separation into long and
short-term needs. This approach is implicit
within this Project
18
Architecture - Concepts

• Distinction Between Long and Short Term
• A clear distinction must be maintained between
  the short term (Project) and long-term storage
  environments

LONG TERM
Publish to Long-term
"Corporate"
Project
SHORT TERM
Load to Short-term
Archive
19
Data Architecture(Long and Short-Term Databases)

• The Long/Short-Term split will help people to be
  more organised
• The same naming principles apply to both types of
  stores but
• The Long-Term stores should be fully compliant -
  they hold the company, long-term data
• The Short-Term Project stores will always have
  additional, personal data sets that may not
  follow a standard convention

20
Business Issues
21
Deliverables

• A set of attributes plus reference values
• Curve Level attributes which are 'pre-defined' on
  the basis of a unique Tool/Curve combination
  (this is the current Master Curve List, or MCL)
• Other attributes which hold key information
  associated with data creation processes (mostly
  acquisition)
• All attributes are listed with reference values
  (this is the current Master Attribute List, or
  MAL)
• Delivery will be through the POSC release
  mechanism

22
Business Model

• Bring current Well-log Standards Framework up to
  a 'Commercial Grade' through the POSC project
  mechanism
• POSC would manage the project as a multi-client
  sponsored initiative
• Flare would manage technical aspects of the
  project under sub-contract to POSC
• Deliverables distributed through POSC as a part
  of the general POSC Standards
• Sponsors influence the development
• Early deliverables available to sponsors
• Maintain and update through POSC

23
Business Benefits

• Reduced costs or increased efficiency
• significantly lower costs to maintain 'load
  lists' (assume some customisation still required)
• less time wasted in identifying data for experts
  and non-experts
• faster data preparation and acceptance for
  exchange/sale
• trades, asset/licence swaps and disposals,
  mergers
• Increased Effectiveness
• clear data organisation and naming will improve
  use and maximise value-add potential
• Sponsorship Benefits
• sponsors are involved in steering priorities and
  provide business and technical input
• sponsors receive early deliverables

24
Implementation Plan

• Hold Workshops in early November 1999 with the
  following objectives
• Agree high-level technical proposal
• Agree method of scope definition
• proposal is by service company and tool (both
  wireline and MWD)
• Agree on prioritisation mechanism
• split into milestones tool groups of 6 to 7
  (significant) tools
• Agree Business Model
• Present sponsorship proposal (outline costs,
  timeframes and deliverables)
• (Attendees would come from oil companies and
  major service providers)
• Obtain sponsorship and begin building commercial
  grade solution

25
Phased Deliverables

• Phased deliverables with Project Milestones every
  6 weeks
• Difficult to plan total resource requirements for
  complete project
• propose phased approach with milestone
  deliverables
• Phase 1 to deliver 20 tools
• suggest 6 to 7 tools per milestone with
  deliverables every 6 weeks
• subsequent funding provisional on successful
  delivery of current phase

26
Attribute PrioritisationCurve Name linked
Attributes

• Priority Attributes
• MCL
• CURVE TYPE
• CURVE DESCRIPTION
• TOOL NAME (Technical)
• TOOL DESCRIPTION
• TOOL TYPE (Generic)
• TOOL TYPE DESCRIPTION
• BUSINESS VALUE

• Secondary
• MCL
• PROCESS STAGE
• USAGE
• UNIT TYPE

Priority Attribute Issues Curve Type reference
values (including their structure), assessment of
Business Value
27
Other Attributes

• ACQUISITION
• GENERIC TOOL STRING
• TOOL STRING
• TOOL STRING DESCRIPTION
• OPERATION MODE
• GENERAL
• STATUS
• PROCESS STAGE

• A naming convention
• Service Co Tool Names
• Service Co Full Description
• OH.WIRE, MWD etc
• FINAL, PLANNING
• ACQ.RAW, CMP, CPI

28
Work in Progress

• GENERAL
• CREATOR
• CERTAINTY
• QUALITY INDICATORS (by USAGE)
• QC STATUS
• QC LEVEL.USAGE
• LOGGING DIRECTION
• LOGGING PASS

• Analyst, Engineer
• HIGH, LOW
• UNCHECKED, PART, FULL
• HIGH.FE, LOW.ALL
• UP, STATION, REAM
• MAN, REPEAT, PASS1

29
Appendix AAttribute Details

• This section presents the purpose and some
  implementation details for the following
  attributes
• CURVE TYPE
• TOOL Attributes
• TOOL STRING Attributes
• CURVE BUSINESS VALUE

30
Curve Type Attribute
PURPOSE A Generic label that captures the main
features of a curve
Curve Type Description
Curve Type

• Multiple-component Attribute Reference values
• The separator character improves readability
• Hierarchical structure - can set to level of
  detail required
• Structure facilitates searching
• Can be treated as a single value (easy to use in
  existing systems)

31
TOOL Attributes
PURPOSE Allows searching for both 'technical'
and generic names

• TOOL NAME
• Curve level attribute
• combination of TOOL plus curve name (mnemonic)
  is unique
• name is service company name (including series,
  if known)
• TOOL DESCRIPTION
• service company official description
• TOOL TYPE
• a generic categorisation which captures the main
  features of the tool (reference values are given
  for all tools)
• TOOL TYPE DESCRIPTION
• full text description of the TOOL TYPE

Strictly speaking, it is the tool/software
plus the curve that is unique but the tool is the
most identifiable component
32
TOOL STRING Attributes

• PURPOSE Allows searching for both 'technical'
  and generic names
• caters for expert and infrequent users
• keeps full technical information
• generic name is not time dependent (unlike
  technical or marketing names)

• TOOL STRING NAME
• Log level attribute
• create by concatenation of 'official' service
  company tool names
• TOOL STRING DESCRIPTION
• full text description of the tool string, usually
  the text that appears on the well-log print
  header
• GENERIC TOOL STRING
• propose to make this the main (highly visible)
  NAME of the Log
• create by concatenation of the TOOL TYPEs

33
BUSINESS VALUE Attribute

• PURPOSE Provides indication of general business
  value of a CURVE
• Used for filtering curve views to show only
  high-value curves
• Could be used to determine which curves service
  companies deliver to clients

• BUSINESS VALUE
• Intention is to assess a curve's 'general
  business value'
• Study of oil companies' 'load lists' for
  corporate databases shows that there is general
  agreement as to which curves are high-value (we
  are just looking for the best-fit assessment here
  - that is, keep it simple for now)
• Future extensions of this business value concept
  could include more targeted usages (for example,
  identifying a set of curves suitable for a
  particular processing)