Practical Uses for Epicentre

1
Practical Uses for Epicentre

• Mobil's Utilization of
• POSC Epicentre Components for
• Purchased Database Customization and
• Content Standardization

2
Mobil Use of Epicentre

• Mobil Technical Computing Strategy
  Overview/Status
• Schema customizations
• Content standards

3
Mobils Technical Computing Strategy

• Focus on Application and Implementation versus
  Invention and Development
• Standardize data management processes
• Implement common integrated environment based on
  a primary vendor architecture
• Provide integrated systems and workflows for all
  EP professionals
• Proactively use strategic alliances to pull POSC
  standards into industry practice

To provide a seamless, integrated, POSC
standards-based technical computing environment
for all EP professionals.
4
TCS Buy Not Build

• To implement the Technical Computing Strategy
  Mobil selected Landmark and GeoQuest to provide
  an integrated platform for both applications and
  the Master Data Store
• Alliance with Landmark for Integrated GG
  Applications and Project Data Store
• Alliance with GeoQuest to provide the Master Data
  Store

POSC
5
Elf
Statoil
OpenSpirit
Essence
PECC
Oilfield Systems
PRISM
Mobil
Shell
SLB
Shell Services
POSC
Chevron
Brookeswood
LGC
Cap Gemini
POSC as partner with service companies and oil
companies
Paras
Western Atlas
Shared Earth
J.Meader
6
TCS Key Components
Field Description
Field Development
Drilling Completions
Facilities Engineering
Exploration
Surveillance
Exploitation
Seis-works
Strat-works
PA / OFM

• Standard
• Applications

ZMap
eXpress
Project Data Store (PDS) Landmarks OpenWorks

• Integrated
• Environment

Master Data Store (MDS) - GeoQuests Finder

• Data
• Management

Data Management Best Practices
7
TCS Implementation Project Management
TADAMS Mgr.
TCS Leadership Team GeoQuest Mobil
Landmark (4) (9) (7)
Implementation Mgr.
Project Administration
Program Assurance
Technical Consultants J. Hollingsworth (2)
GeoQuest Program Mgr.
Site Project Leaders New Orleans Midland Houston L
iberal MOCAN - Calgary MPN - Lagos Dallas MENI
- Stavanger MNSL - Aberdeen MOI - Jakarta MEPA -
Perth MEEG - Celle
Landmark Program Mgr.
8
TCS Data Architecture
AssetDB (GeoQuest)
Enterprise (GeoQuest)
GeoShare
Recall (ZS)
Finder (GeoQuest)
Application Environments ZMAP
OpenWorks (Landmark)
PARS (PECC)
9
Customization Principles

• Minimal customizations of FINDER
• No customization of OpenWorks
• Only customize FINDER for populated data
• Global Mobil schema
• no local customizations
• temporary tables for cleanup/QC OK
• maintained by GQ
• Help GQ adopt Mobil customizations into base
  FINDER
• Single Mobil point of contact

10
Process

• Requirement to Dallas from outside
• Level 1 Proposal prepared by Dallas
• Comments
• Final level 1 note to GeoQuest (GQ)
• GQ distributes level 1 customization

11
Level 1 Proposal Prepared by Dallas

• Determine if in FINDER 8
• Determine if Level 1
• If so, Jay makes proposal
• If not, Jay forwards note
• Check Epicentre for syntax
• Check FINDER/OpenWorks GeoShare link
• Prepare/circulate draft proposal

12
Why use Epicentre?

• Completeness of the model
• abstract nature of spatial model gives
  flexibility
• use of _class and _alias entities
• Global applicability
• Consistent attribute formats through ndts
• Belief/investment in standards
• but most importantly
• Since GeoQuest is making rapid progress toward
  Epicentre compliance, the likelihood that a
  near-future release of FINDER would be similar or
  identical to our customizations is maximized

13
When would we not use Epicentre?

• Where it is currently missing an area
• e.g., log evaluation
• Where implementation of the model would require
  implementation of unreasonably many tables in
  ORACLE
• checkshot surveys
• Where I don't understand it and don't have time
  to have it explained to me, we would do something
  temporary
• cores

14
Comments

• Very small distribution ( 5 people)
• Only requester and Dallas data folks
• Reply within 5 working days

15
Example - Leases

• We require lease data not held in FINDER
• We did the following
• Extracted parts of 9 normal entities and 8 ref_
  entities from the logical model, along with their
  data types
• Specified these in an ORACLE-compatible way
• we used natural keys wherever possible
• identifiers occasionally need to be shortened
• Hooked them into the existing FINDER data model
  (e.g., stratigraphy is needed for mineral_zone)
• GQ is currently preparing the scripts
• This area is currently out for comment

16
Issues with the results

• Customized values won't GeoShare or be understood
  by certain applications
• Use of VIEWs to hide complexity from end
  users/ODBC
• Are VIEWs customizations?
• Loaders from standard data sources (e.g., TDG)
  must be written

17
Global Data Standards - Why

• Fundamental for data transfers
• OpenWorks 5 Data Integrity
• Joining of multiple databases (Enterprise/OpenExpl
  orer)
• Good data management practice
• data cleanup
• loading rules

18
Standards Principles

• Global rules established for some attributes
• Standard content defined for a few
• Single point of contact
• POSC content where possible

19
Global Standards Process

• Requirements to Dallas
• Proposal from Dallas
• Comments
• Final note to sites
• GQ distributes for FINDER, PDS unclear
• Needs to be decided project by project
• May be difficult to update work in progress

20
Comments

• Large distribution ( 125 people)
• Sites should reply within 5 working days
• Lack of reply means acceptance

21
How does Epicentre help?

• Epicentre organizes codes in logical ways not
  well thought out in other databases
• well statuses, well classes
• POSC gathers together other industry standards
  for us
• ISO-3166
• POSC has worked with industry to seek out
  globally usable standards
• interest designations, material classes, CAESAR
  classes
• Most of all, it's an industry standard

22
Standards Categories

• Local
• CT - coordinates rules only, as appropriate
• All content supplied locally - PROJECT scope
• Examples UWI, Well name, Field name
• Open
• CT - coordinates rules and seed content
• Content can be supplied locally - PROJECT scope
• Examples Geologic Provinces, State/Province
• Global
• CT - coordinates definition of all content
• Local content not allowed - CODES scope
• Examples Elevation references, country names

23
Examples - Easy (?)

• UWI, well_name
• no standard - just formats
• well_class
• determine the intent of the attribute
• see if POSC has the Lahee classes
• copy them into FINDER/OW

24
Examples - Harder

• well statuses
• usage different POSC to Geoshare to FINDER/OW
• status components in more than one POSC entity
• plot symbols
• none in Epicentre (I could find, anyway)
• ease of customization led to many different PDS
  sets
• defensiveness sets in
• "We do business diferently here, and ours are
  different"
• "We have an agreed set with our partners that we
  have to use"
• "Our regulatory agency requires us to use this
  set"

25
The argument winner is

• "FINDER, OpenWorks, GeoShare, PA/OFM,
  drafting and other applications will all be
  integrated to this standard.
• You can change them however you like, but
  you'll need to justify the time and to develop
  your own standards, and to reapply at each
  release across all environments, find someone to
  develop and maintain them, and make users wait to
  use the new toys until you're finished."

26
Standards Issues

• Standards from OpenWorks
• pick qualifier codes to strat_exception_codes
• How to implement at PDS create time
• How to implement in place in PDS
• Upgrade to OpenWorks 5/FINDER 8.5/GDM 10

27
How has POSC helped us

• Develop Epicentre
• Developing standard codes
• original EP codes
• new codes from WIME, CAESAR, etc.
• Website/CD for delivery mechanism
• Telephone support
• Jenny, John, Cary, Gary, Robert