Practical Well-log Standards A POSC Industry Collaborative Project

Practical Well-log Standards A POSC Industry Collaborative Project Manager: Cary Purdy, POSC Technical Project Manager: Dave Camden, Flare Consultants November 1999

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

Introduction l POSC l l 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 l Flare Consultants l l l 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 l Background to this project l Long involvement in petrophysics and well-log data management in oil and service companies l Builds on recent well-log management projects: l Baker Atlas: improve current 'acquisition-to-database' model l Petro. Data: developing standards for the management of welllogs in the Norwegian databank l 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 l 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 l Take a business approach l We need practical, implementable solutions l 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 l Clear objectives: define standards necessary for the creation of an organized, clearly labeled and accessible well-log database l Concentrate on the Long-Term data storage problem but with regard to transfer to/from Short-Term stores l Make use of existing work and standards where possible l l Improve consistency and completeness Concepts should be equally applicable to both 'Data' and 'Hard Copy' (at appropriate levels of granularity)

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

Well-Log Management Issues l Data overload l l too many curves - users can’t find the important data Complex naming l both curve and ‘LOG’ (collection of curves) names are complex and changing at an ever increasing rate l l l even petrophysicists are getting confused others gave up years ago! Disparate business processes l in the absence of clear, accessible standards, people continually create new, local solutions l 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 l Data Overload l Real “Business Value” is concentrated in a relatively small number of data curves - filtered views focus on high value data Data Volume Category 1 C 50, 000+ 'Visible' Acquisition Curves Business Value ry o eg at 2 Data Overload! Category 3 mapping 500+ ‘Useful’ Curves

Confusing Names l LOG*/Tool Names l l l l l GRAND SLAM DSI Vs DSST Vs SDT? PEX (HALS) HALS, HDLL, HDIL, HGNS, HNGS, HRDD, HRGD PROC 1 DAVE 21 22 MAY 97 COMP GEOL l CURVE Names l l l Sonics: DT 1 R, DT 4 P, DT 4 S, DT 5, 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 l CURVES l l 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 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 Names CURVE ATTRIBUTES Purpose: develop attributes that supply useful information l CURVES l Other Attributes: l l l Name, Type, Description, Unit Type, Unit, Vertical Resolution, Tool Type, Tool Type Description, 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 l LOG: for acquisition data l l 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 l standard names for key composite and CPI data sets

Clear Business Process l Attempting to follow standard procedures at all levels of detail is impractical l 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 l Distinction Between Long and Short Term l 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) l The Long/Short-Term split will help people to be more organised l The same naming principles apply to both types of stores but l The Long-Term stores should be fully compliant - they hold the company, long-term data l The Short-Term Project stores will always have additional, ‘personal’ data sets that may not follow a standard convention

Business Issues

Deliverables l A set of attributes plus reference values l 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) l Other attributes which hold key information associated with data creation processes (mostly acquisition) l All attributes are listed with reference values (this is the current Master Attribute List, or MAL) l Delivery will be through the POSC release mechanism

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

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

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

Phased Deliverables l Phased deliverables with Project Milestones every 6 weeks l l l 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 l Priority Attributes l MCL l l l l CURVE TYPE CURVE DESCRIPTION TOOL NAME (Technical) TOOL DESCRIPTION TOOL TYPE (Generic) TOOL TYPE DESCRIPTION BUSINESS VALUE l Secondary l MCL l l l PROCESS STAGE USAGE UNIT TYPE Priority Attribute Issues: Curve Type reference values (including their structure), assessment of Business Value

Other Attributes l ACQUISITION l l l GENERIC TOOL STRING DESCRIPTION OPERATION MODE GENERAL l l STATUS PROCESS STAGE l A naming convention l Service Co Tool Names l Service Co Full Description l OH. WIRE, MWD etc l FINAL, PLANNING l ACQ. RAW, CMP, CPI

Work in Progress l GENERAL l l l CREATOR CERTAINTY QUALITY INDICATORS (by USAGE) l l Analyst, Engineer HIGH, LOW l l l QC STATUS QC LEVEL. USAGE l LOGGING DIRECTION LOGGING PASS l l UNCHECKED, PART, FULL HIGH. FE, LOW. ALL UP, STATION, REAM MAN, REPEAT, PASS 1

Appendix A Attribute Details l This section presents the purpose and some implementation details for the following attributes: l CURVE TYPE l TOOL Attributes l TOOL STRING Attributes l CURVE BUSINESS VALUE

Curve Type Attribute PURPOSE: A Generic label that captures the main features of a curve 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)

TOOL Attributes PURPOSE: Allows searching for both 'technical' and generic names l TOOL NAME l l TOOL DESCRIPTION l l service company official description TOOL TYPE l l 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 l 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) l TOOL STRING NAME l l l TOOL STRING DESCRIPTION l l 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 l l 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 l BUSINESS VALUE l l l 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)