Practical Well-log Standards
A POSC Industry Collaborative Project
Project Manager: Cary Purdy, POSC
Technical 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 welllogs 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
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 E&P professionals
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


Complex naming


too many curves - users can’t find the important data
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'
Acquisition
Curves
Category 1
Data Overload!
Category 3
mapping
500+
‘Useful’
Curves
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 Names
CURVE
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
Curve Type Attribute
Example of reference values
Curve Type
AC.AMP
AC.ATT
AC.CAL
AC.DTD
AC.IMG
AC.ITT
AC.POR
AC.PR
AC.SLO
AC.SLO.CMP
AC.SLO.RAT
AC.SLO.SHR
AC.SLO.STN
Curve Type Description
acoustic amplitude
acoustic attenuation
acoustic caliper
acoustic data density (MWD)
acoustic image
acoustic integrated slowness
acoustic porosity
acoustic poisson ratio
acoustic slowness
acoustic compressional slowness
acoustic slowness ratio
acoustic shear slowness
acoustic stoneley slowness
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 Names
CURVE 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
Clear Names
LOG
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
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
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
"Corporate"
Add VALUE,
STATUS
SHORT TERM
Publish to
Long-term
Project
Archive
Load to
Short-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 subcontract 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 Prioritisation
Curve 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)


Analyst, Engineer
HIGH, LOW

QC STATUS


QC LEVEL.USAGE

LOGGING DIRECTION
LOGGING PASS


UNCHECKED, PART,
FULL
HIGH.FE, LOW.ALL
UP, STATION, REAM
MAN, REPEAT, PASS1
Appendix A
Attribute 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
PURPOSE: A Generic label that captures the main features of a curve
Curve Type
AC.AMP
AC.ATT
AC.CAL
AC.DTD
AC.IMG
AC.ITT
AC.POR
AC.PR
AC.SLO
AC.SLO.CMP
AC.SLO.RAT
AC.SLO.SHR
AC.SLO.STN
Curve Type Description
acoustic amplitude
acoustic attenuation
acoustic caliper
acoustic data density (MWD)
acoustic image
acoustic integrated slowness
acoustic porosity
acoustic poisson ratio
acoustic slowness
acoustic compressional slowness
acoustic slowness ratio
acoustic shear slowness
acoustic stoneley slowness
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)
TOOL Attributes
PURPOSE: Allows searching for both 'technical' and generic names

TOOL NAME




TOOL DESCRIPTION


service company official description
TOOL TYPE


Curve level attribute
combination of TOOL* plus curve name (mnemonic) is
unique
name is service company name (including series, if
known)
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
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



TOOL STRING DESCRIPTION


Log level attribute
create by concatenation of 'official' service company
tool names
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
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)