November 1999

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

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

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

11. Category 1 Category 2 Category 3 mapping 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. 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 Confusing Names * 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. Add VALUE, STATUS 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. 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 Attribute PrioritisationCurve Name linked Attributes Priority Attribute Issues: Curve Type reference values (including their structure), assessment of Business Value

27. 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 Other Attributes

28. 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 Work in Progress

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)