Notes on
Mechanical Well Data Workshops

20-22 January 1997 - Maidenhead, England
4 February 1997 - Houston, TX

Contents

Meeting in Maidenhead, England - 20-22 January 1997

Meeting Notes (Maidenhead, England - 20-22 January 1997)

The initial objectives for the meeting were:

To check the data items in Epicentre against the data items identified as required by the PUMA project to support Mechanical Well data.

This lead to the following questions:

1. What exactly do we mean by Mechanical Well data? What functionality are we trying to support here?

James Wood identified the following functional requirements

1. Wellbore hydraulics (including thermal lift)
2. Well schematics (including some indication of trajectory information)
3. identification and description of equipment permanently installed in a well

The meeting was concerned that there was not sufficient information provided by the identified Puma data items to fully support this desired functionality. Jim Erdle will check the data items and identify what is missing.

2. Should we only be looking at Epicentre? What about POSC/CAESAR?

Jenny Meader gave a talk on the POSC/CAESAR model as described in Snapshot B, and explained what she knew of additions that would occur in POSC/CAESAR’s Snapshot C/D. The workshop decided that it was not within the scope of the workshop to discuss the relative merits of the two models, but that the mapping to Epicentre was the concern of the workshop.

Rolf Rolfsen gave a description of the WIME project, its aims and current status and how it might be integrated with the work of this workshop. WIME is primarily interested in drilling information and has so far attempt to produce an industry standard set of well operations (activity) codes and descriptions. Equipment as such has not been touched, but the involvement of equipment with activities has been touched on. It was felt that the WIME work was complementary to, and not overlapping with, the work of this workshop, provided good lines of communication were maintained between the two groups.

3. Are these identified data items (from Puma) a suitable benchmark for the industry as a whole? What other opportunities will there be for discussion and comment?

Jenny Meader explained that there would be a further workshop in Houston on February 4^th, that an e-mail about this to all POSC technical contacts had been sent, and that the results from the workshops would be published on POSC’s website, with a chance for members to comment on any proposals derived from the workshops. Any relatively small, uncontroversial changes POSC would endeavor to include in its v2.2 offerings; Epicentre will be frozen at the end of February to allow for testing and documentation of the changes to be completed, which limits the scope of changes that can be dealt with in v2.2.

Mapping Puma to Epicentre

The workshop then mapped the Puma data items to Epicentre, first at an "entity to entity" level, and then, as a second pass, at an attribute to attribute level. There was generally good support for the Puma data items within Epicentre, with at least 80% of the items mapping. Those items for which the workshop could not find a mapping were identified, and possible solution scenarios were discussed, but without working at a detailed level. The mapping and suggested solutions for non-mappable items is described in the document:

       HTML: Puma Mechanical Well data mapping to Epicentre (Tables 1-5)

       Excel spreadsheet: Puma Mechanical Well data mapping to Epicentre (Tables 1-5)

Action Items from the workshop (Maidenhead, England - 20-22 January 1997)

Meeting in Houston, Texas - 4^th February 1997

Introduction (Jenny Meader)

Slides from Jenny's presentation are available in:

    HTML: Presentation Slides

    Microsoft Power Point: mech_well_wkshp.ppt

The purpose of the workshops was to gather requirements, develop a proposal from results to improve Epicentre’s handling of mechanical well data and incorporate changes into the specifications as soon as possible while still allowing the POSC membership opportunities to comment on the proposed changes.

Feedback from first Workshop

Overview of Wellbore Component Facility

Are there missing subtypes? Packer is an obvious one.

How detailed do we get?

How to add extra components? Should they be added as extra subtypes or should we create general model?

The workshop agreed that any proposals need to go through real examples to test for adequacy

Issue

Didier Mondin said that the distinction between facility and equipment is difficult in practice

Schlumberger Requirements

well equipment descriptions

well tubulars

casing (shoe, float collar, casing head)
tubing (packers, tubing string, crossover)

connection information
logging tools
drill strings

dst, wireline, mwd, bha

well schematics

casing strings

completions (e.g., tubing, packers)

well activities

drilling
fracturing
cementing
dst

equipment_item and materials
describe a well using high level objects, track changes with time,

connections as needed, # of identical parts in assembly and
detail the specific items when important, positioned by
bottom(measured) depth only

hierarchy based upon common properties rather than functional descriptions
connection type

inline (top-bottom)
concentric (inside-outside)

Issues

Jim Erdle: how much detail is needed to describe something?

Jim Erdle: can we put the details in the catalog?

Gary Masters: Epicentre intent is a strong distinction between equipment and facility, with the facility describing the function, or role, and equipment providing the actual hardware that fulfills the function. Epicentre is known to lack some important behavior to fully describe this.

Didier Mondin: It is not easy to understand when to connect facilities and when to connect equipment?

Didier Mondin: It is necessary to be very clear about when we speak of facility and when we speak of equipment. More good examples are needed to illustrate the differences.

Example (simplified)

Discussion on generic versus specific modeling

Generic modeling is more flexible, allows for things that were not thought of when the model was originally designed (allows for "organic" growth?). However generic models can be more difficult to understand and interpret, and the burden of interoperability is put much more at the application level. In a generic model, the business rules (expected properties for an object, constraints applied to the data) are held as standard data (instances) within the schema structure, and so are not available to tools that are designed to operate at a schema level.

Issue:

Business rules need to be shared for interoperability - how do we do this?

Basic Problems:

1. well component facility connection/composition is missing
2. well component facility "subtypes" are missing
3. combining facility and PFNU behavior in a wellbore leads to inconsistency

Proposal:

workgroup participants to submit (in a delimited text file) and
combine lists of well facilities (or equipment), merge and publish
on web

Different options to be tried - proposed by Robert

1. Remove all existing subtypes of wellbore_component_facility and model general behavior (connections/components etc.)This would have pty_equipment_facility. Didier Mondin expressed his dislike of this concept.

2. Add more specific subtypes and add specific behavior

   Take examples and work through both approaches to see strengths and weaknesses of both. Didier requests to also include PFNU in investigations.

3. (proposed by Gary) add general composition & connection behavior on well component facility (either by adding it to its supertype, Facility, or by changing its supertype to general_facility), but keep the subtypes and their individual specific properties.

Discussion

Didier Mondin asked about the status of POSC/CAESAR and WIME.

Jenny Meader said that POSC was continuing to work with POSC/CAESAR and many of the POSC/CAESAR "class library" instances would be loaded into Epicentre as standard data for v2.2. The issue of the differences in modeling style had not yet been resolved, but both POSC and POSC/CAESAR would work to achieve an acceptable solution on this. ICS’s work for the ETAP project was a very interesting example of a practical approach to implementing POSC/CAESAR's model.

WIME are working on standardizing activity codes and definitions within the drilling discipline. They have recently issued a RFT, which could be viewed on POSC’s website. Didier Mondin commented that there were not enough activity subtypes in Epicentre and the coverage was patchy, which POSC acknowledged. Schlumberger is currently doing lots of work in this area. Dan Schenck asked that POSC be allowed to share this work - Didier Mondin agreed to check on this.

Schlumberger has an activity hierarchy based on shared characteristics - they find this is the only effective way to build hierarchies - He asserted that functional hierarchies don't work. Schlumberger have single parent, one off hierarchy, which has to be very clear-cut and sometimes results in some strange classifications.

Jim Erdle expressed concerned about the length of time that the proposed process would take and asked why the work done in the previous workshop could not be accepted and built on. IBM (and others) cannot wait for months before a solution is proposed. He suggested fixing the composition/ connection\problem with wellbore_component_facility. Add packer (and other subtypes), with the specific properties that were needed. Dan Schenck supported this and agreed that POSC would try the proposal 3, which had most support from this workshop and fits closely with the proposed solutions suggested by the first workshop.

Dan and Jenny agreed that as much of this work as was possible would be done for v2.2.

It was agreed that there is a need to be able to express relative positions of facilities/equipment within the strings (facilities).

Dan Schenck asked if it was necessary to have a further meeting to come to closure on this, with participants from both Europe and North America. The meeting agreed. Robert suggested attaching it to one or other of the POSC March meetings.

Didier Mondin asked that publicly available data, such as tubing tables, engineer's handbook, be included as standard instance data.

Engineering handbook data can be divided into two kinds:

- industry standard characteristics (API)
- manufacturer specific characteristics

Didier Mondin suggested that all API RP's should be in and stated that this would be very beneficial to both POSC and the industry and would be well.

Peter Chok expressed concern about the amount of administration required to handle many different manufacturers catalog data. The suggestion was made that perhaps POSC could set up a standard loading format for this type of data so that manufacturers could provide the data, pre-loaded into a format that can be easily loaded into a POSC data store.

Action items from the meeting:

1. e-mail Robert's well facility list text file to participants of the two workshops for comment/additions etc.
2. The list of wellbore component facilities will be merged and published on POSC's website for comment
3. Didier/Peter to provide, by the middle of February, "real" examples of a "casing plan" and a drilling scenario that include LWD equipment in the BHA to test the changes.
4. The plan of action for this to be written up and posted on POSC's website
5. POSC to work on proposal based on adding general construction/connection behavior to wellbore_component_facility, adding the subtypes discovered through the process described in action items 1 &2, with specific attributes as required. The specific construction/connection behavior currently present on some subtypes of wellbore_component_facility will be removed, as this will be redundant to the general behavior.
6. POSC to arrange a closure meeting on this, at which the proposed solution will be presented and discussed, on a date next to the POSC March Houston meetings, scheduled for the week beginning 3rd March 1997.
7. POSC to investigate providing loading standards and tools for catalogs of vendor data.

Copyright © 1994-1997 Petrotechnical Open Software Corporation. All rights reserved.
POSC ® and the POSC logo ® are registered trademarks and Epicentre™ is a trademark of Petrotechnical Open Software Corporation.