Practical Well-log StandardsA POSC Industry Collaborative Project

Project Manager: Cary Purdy, POSCTechnical Project Manager: Dave Camden, Flare Consultants

November 1999

Contents

Introduction Objectives, background and principles Well-log Management Issues and Technical

Overview of key Project Concepts Project Business Plan

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 E&P assets

"POSC is a trusted source of geoscience, engineering and IT skills for the E&P industry. We are determined to be THE place to come to for collaborative work relating to information sharing in E&P. When people want to work together in a open environment to solve a common E&P business problem,

we want them to instinctively think of POSC."

David Archer, POSC CEO

Introduction

Flare Consultants Formed in 1998 An E&P data management consultancy company Positioned between 'high-level' business consultants and E&P

service Cross-domain, exploration to production expertise Deliver business driven technical solutions Virtual team operating world-wide

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-database' 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 whicha complete standard can be built

Overall Objective

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

What does this mean?

• Address the main problem areas

The emphasis is on enabling the creation of a clearlylabelled well-log data set which is accessible

to a wide range of E&P professionals

• data overload• fast-changing, complex nomenclature• lack of accessible standards

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

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)

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

Well-Log Management Issues

Data overload too many curves - users can’t 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)

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'

AcquisitionCurves

500+‘Useful’Curves

Category 1

Category 3

Category 2

mapping

Data Overload!Data Overload!

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

Clear NamesCURVE

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

Purpose: to ‘de-mystify’ proprietary and esoteric naming systems

Reference values for attributes are also defined

Curve Type AttributeExample of reference values

AC.AMP acoustic amplitudeAC.ATT acoustic attenuationAC.CAL acoustic caliperAC.DTD acoustic data density (MWD)AC.IMG acoustic imageAC.ITT acoustic integrated slownessAC.POR acoustic porosityAC.PR acoustic poisson ratioAC.SLO acoustic slownessAC.SLO.CMP acoustic compressional slownessAC.SLO.RAT acoustic slowness ratioAC.SLO.SHR acoustic shear slownessAC.SLO.STN acoustic stoneley slowness

Curve Type Curve Type Description

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)

Clear NamesCURVE ATTRIBUTES

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

Purpose: develop attributes that supply useful information

Clear NamesLOG

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

Purpose: to ‘de-mystify’ proprietary and esoteric naming systems

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 workSuccessful data/information management is greatly

facilitated by separation into long and short-term needs.This approach is implicit within this Project

Architecture - Concepts Distinction Between Long and Short Term

A clear distinction must be maintained between the short term (Project) and long-term storage environments

Add Add VALUE,VALUE,STATUSSTATUS

LONG TERMLONG TERM

ProjectProject

ArchiveArchive

SHORT TERMSHORT TERM

"Corporate""Corporate"Publish toPublish toLong-termLong-term

Load toLoad toShort-termShort-term

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

Business Issues

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

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

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

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

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

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

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

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

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

Curve Type Attribute

AC.AMP acoustic amplitudeAC.ATT acoustic attenuationAC.CAL acoustic caliperAC.DTD acoustic data density (MWD)AC.IMG acoustic imageAC.ITT acoustic integrated slownessAC.POR acoustic porosityAC.PR acoustic poisson ratioAC.SLO acoustic slownessAC.SLO.CMP acoustic compressional slownessAC.SLO.RAT acoustic slowness ratioAC.SLO.SHR acoustic shear slownessAC.SLO.STN acoustic stoneley slowness

Curve Type Curve Type Description

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)

PURPOSE: A Generic label that captures the main features of a curve

TOOL Attributes

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

PURPOSE: Allows searching for both 'technical' and generic names

* Strictly speaking, it is the tool/software plus the curve that is unique but the tool is the most identifiable component

TOOL STRING Attributes

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

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)

BUSINESS VALUE Attribute

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)

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