WIME into Epicentre

Version Information

Modified by JCB on 10SEP1999:
- Add section on motivation for changes.
- Restructured topics to improve clarity

Introduction

In December of 1998, WIME (Well Information Mapping in Epicentre, a consortium of oil industry companies led by Statoil) released the first version of their requirements for well construction and maintenance information. The intent of the group was that POSC would change the Epicentre information model and associated standard reference data to reflect the requirements developed by their team of software developers, drilling and completion engineers. While concerns of WIME are broad in scope, the primary focus of this first release has been the representation of well activities. For more information on WIME, please see the WIME web site maintained by Nigel Goodwin of Essence Associates.

Motivation for Changes

The impact of the WIME requirements on Epicentre were interpreted by Nigel Goodwin and Jim Brannigan during a two day meeting in POSC's Richmond offices during early December of 1998 (see Community Discussion of Changes, below). The concepts in WIME that need to be captured in Epicentre were:

There exists aggregate activities that contain unit activities. See Jobs and Normal Composition, below
An activity can be one and only one WIME activity type. See "Unique Classification", below.
Activities have Objectives. See "Objectives, Productivity and Efficiency", below.
Activities may be classified as either Optimum or Non-Optimum. See "Objectives, Productivity and Efficiency", below.
Activities may be classified as Productive or Non-Productive. See "Objectives, Productivity and Efficiency", below.
An Activity Type may have an Alias. That is, it may be referred to by an alternate name, such as its WIME activity number. See "Standard Values for activity_class_alias", below.
An inheritance hierarchy exists between activity types. See "WIME Activity Type Hierarchy", below.
Some activity types are abstract. That is, the exist to help organize other activity types and are not meant to characterize a particular instance of an activity. See "Abstract Activities" for details.

Mapping of WIME concepts to existing Epicentre Concepts

The WIME concept of activity type is best mapped to the Epicentre concept of activity class (i.e., entity activity_class. Therefore, the WIME activity types are captured as standard instances of activity_class (see "Adding WIME Activity Types").

Most of the existing WIME activity types conform to the definition of the abstract Epicentre entity, wellbore_activity. There is, therefore, some pressure to rationalize existing sub-types of wellbore_activity in light of the WIME activity types (e.g., the elimination of existing Epicentre sub-types of wellbore_activity). Also problematic is the fact that there is no mechanism to enforce that a sub-type of activity is classified (via the attribute activity_classification) in a manner conforming to its entity definition. In order to allow this to occur, the standard instances of activity_class were augmented with entries corresponding to all existing sub-types of activity. These new instance classified (e.g., "Epicentre Well Facility Activity") to distinguish them from the WIME activity types (classified as "WIME 1.0"). Existing standard instances of activity_class were modified to conform to this pattern. For more details, see "Activity Class Classification System". Finally, note that it was felt that mapping existing Epicentre sub-types of activity to WIME activity types (or vice versa) was a low priority, and would be imprecise at best.

Standard Values for activity_class_alias

The WIME activity types were assigned unique numbers. Since the system was evolving, this allowed the wording of the activity name to be changed.

In order to preserve investment in early implementations, a standard instance population was prepared for activity_class_alias that associates the WIME Activity ID with its associated standard instance in activity_class (see, "WIME Activity ID Standard Instances" for more details).

WIME Activity Type Hierarchy

The Epicenter entity activity_class_classification was felt to be sufficient for the time being to represent the WIME activity type hierarchy. (see "WIME Type Hierarchy" for details). The inheritance of normal parts is implied only, that is, the standard instances for activity_normal_composition only show normal parts at the highest point in the hierarchy.

This is true also for "global" parts that can be part of any activity. This is represented by placing them as part of "Activity Type" the abstract root of the WIME activity type hierarchy (see, "Jobs and Normal Composition", for more details.

Unique Classification

The WIME specification requires that an activity be of only a single WIME activity type. In Epicentre terms, this would mean either that the activity_class attribute of activity be added to the unique rule, or that a new entity be created to associate activity with activity_class.

Recall that activity_classification, the existing association between activity_class and activity has a many-to-one relationship to both entities. In order to minimize impact on any existing application, the second approach was followed (See Unique Activity Classification for more details).

Objectives, Productivity and Efficiency

The WIME specification declare that there are objectives for activities (the so-called "objective classes") and performance classes. These concepts were missing from Epicentre. The concept of an objective was most closely aligned with the entity guideline_or_privilege. The performance class was interpreted to be a two components, efficiency and productivity.

The concept of efficiency relates to whether the activity conforms to an ideal of a "technical limit", that is termed henceforth as "optimum". Note that this is irrespective of whether or not the activity met any stated goal or objective.

However, the concept of productivity was more complex. It was felt that a particular activity may be productive in relation to one goal, while not productive towards another. Therefore, it was felt that productivity would be an attribute of an association between and activity and an objective (see "Objectives, Productivity and Efficiency" for more details).

In should also be noted that the concept of objective seems strongly tied to the concept of aggregate activities. In fact, many of the WIME aggregate activities are without a definition, save that implied by their name, and the enumeration of their normal parts. The higher level normal objectives for aggregate activities represent a milestone of sorts, that when reached indicate the end state of the aggregate activity.

Jobs and Normal Composition

An "aggregate activity", in WIME parlance, is an activity that can contain other activities (which may also be aggregates,and so on). These are distinguished by names ending in the word "job". As mentioned above, many of the aggregates are best defined by what "parts" they can contain.

In order to reflect WIME's activity composition hierarchy, it is proposed that a new entity be added to Epicentre, along with associated standard instance values. For more information, see "Activity Normal Composition"

Staged Changes

In order to fully comply with the needs expressed by WIME, the Epicentre team at POSC believes significant changes need to be made in the Epicentre data model. The Epicentre information model has a managed change process. Therefore, substantial changes to the model need review, and are done during specified periods. In order to be more responsive, POSC has been experimenting with releasing minor, interim changes to the model. In particular, it is felt that new reference data can be released with little harm and much benefit. Minor changes, such as adding optional attributes should also be possible. In keeping with this direction, a staged approach to addressing the needs of WIME is proposed. All of the following are specific to the definition of well activities.

Stage 1: Create mapping from WIME repository to existing entities in Epicentre. Add to standard reference data population.
Stage 2: Modify existing standard reference data where required.
Stage 3: Add optional attributes to existing entities where required. Add reference data to modified entities if required.
Stage 4: Add new entities required where they do not conflict with existing entities. Add required reference data to new entities.
Stage 5: Add non-optional attributes, delete or replace attributes and entities. Add reference data to new entities if required.

The final stage will be dependent on the success of earlier stages and would be part of a major release (that is, 2.3 or 3.0). However, these extensions might be pursued by others more quickly at the risk of deviation between what is proposed here and the eventual Epicentre model.

Community Discussion of Changes

This work developed from discussions with WIME members, the WIME project coordinator (Nigel Goodwin, Essence Associates) and others. The summary on the second day of the December 1998 meeting of Nigel Goodwin and Jim Brannigan is the best statement available from WIME regarding their needs vis a vis Epicentre.

Please follow the links above to get details on the proposals.

Colored Horizontal Rule

Last modified by James C. Brannigan on: Tuesday, 14-Sep-1999 16:20:12 CDT. Send questions and comments to webmaster@posc.org