5.2 CGM PIP IV
This Work Plan describes the proposal for changes in the following POSC specifications and supporting material:
This is to support the POSC Mission Statement:
" The mission of POSC is to benefit the E&P Industry by establishing, maintaining and promoting specifications to be used as standards for the sharing of information throughout the asset life cycle. "
POSC has used the following as input in drafting this document:
The purpose of the work defined in this Work Plan is to add value to the POSC specifications and make them easier to use and more effective. Changes are restricted to the current scope of the model as well as current architecture and modeling style. Additionally, changes are limited to those that can be designed and tested by POSC and its members by the end of May 1997.
The following criteria have been used to determine if a requested change falls within the accepted scope of this work plan:
Notice of this Work Plan has been sent to all POSC Business and Technical contacts. It is posted on the POSC website in the public area.
It will be presented to the POSC membership as part of the MIG SIG to be held both in the USA in Houston on November 20th 1996 and in Behoust, France, on 11th December 1996.
There is a majordomo group called
next-release@posc.org
which will be one forum in which issues on the content of the release and the
proposed schedule can be discussed.
This Work Plan is provisional and is subject to change as a result of feedback received from POSC members.
Feedback on both the content of the proposed work, and the proposed schedule will be welcomed by POSC.
The closure date for feedback on this Work Plan is 15th January 1997.
The Work Plan will be withdrawn for serious considerations if there are strong objections to the plan from a number of POSC members. If the Work Plan is largely acceptable to the membership, which will be a judgement made by POSC on the feedback received, then a revised Work Plan containing any minor adjustments made as a result of feedback will be published by 31st January 1997.
Data Store preferred value - this is to enable applications that can only cope with one value of something that is versionable in Epicentre. Applications are usually designed this way for reasons of performance and simplicity.
The preferred value is a single preferred value of an Epicentre property for an object it describes. If a Well, for example, has a set of possible Pty_location_2d properties, then one and only one could be selected as the "preferred value" and this preference would be at the level of a data store.
Discovery, Chevron, Schlumberger
There are several possible solutions, and the impact on the Epicentre data model is dependent on which solution is chosen. See the Preferred Values discussion paper (member password required) on the possible solutions at the POSC Web site.
All the solutions considered involve the addition of optional attributes and can be considered compatible with the previous versions of Epicentre.
The number of additional optional attributes in the Epicentre logical model ranges from one to several thousand, depending on the solution chosen.
The number of additional nullable columns in the sample relational implementation ranges from less than one hundred to several hundred, depending on the projection strategy chosen.
These additional optional attributes could be ignored by those Epicentre users who have no requirement for this feature. Those users who wish to make use of this feature would need to determine some procedure for the selection of the preferred values and the loading of this information into Epicentre, and procedures and mechanisms will need to be established to ensure the data integrity of the preferred values.
The previous versions of the production model could not be implemented in relational technology to perform at a speed acceptable to the SAVE community for the purposes of reservoir simulation (reservoir simulators currently use flat files). A proposed model has been tested and accepted by the SAVE community.
SAVE
This requires the introduction of a new data type. The work to support this data type by the Projection Tool and the Compatibility Layer has already been done. The properties of the fluid flows and the related entities have been re-modeled. New flow stream properties aggregate the properties previously modeled individually.
Anyone with a POSC data store that holds data in the area will be impacted. See the Proposal for Revised Production Data Model in Epicentre v2.2 at the POSC Web site.
The classification of rock_feature is currently achieved by a "one-of" subtyping structure, forcing a choice to be made as to whether a rock feature be classified as a drilling_imposed_target, geologic_target, geologic_structure, sedimentary_feature, lithologic_feature or stratigraphic_feature. More flexibility is required to be able to handle the essentially interpretive nature of this part of the business.
Elf, Schlumberger
Potentially re-modeling of all the subtypes of Rock_feature. This requirement may also affect the Material model.
Anyone with a POSC data store that holds data in the area will be impacted. Proposed solutions have not yet been formulated. A work group will be formed for this area.
The current activity model does not support cause and effect, and the ability to model sequences of activities is restricted to scheduled activities.
Elf, Schlumberger, POSC/CAESAR
Adding cause and effect should be compatible with previous versions of Epicentre. Modeling sequences of activities may or may not be compatible depending on the solution formulated.
Proposed solutions have not yet been formulated, every effort will be made to formulate a solution that both meets the requirements and is compatible with previous versions of Epicentre.
The current facility model inadequately supports the identification of facilities. Many types of facilities, equipment and properties of these are missing from this model.
Elf, Schlumberger, Discovery
Adding additional types of facilities, equipment and their properties is compatible with previous versions of Epicentre. Adding additional attributes to the identification should be compatible from a data point of view, but may change application using this part of the model.
Proposed solutions have not yet been formulated, every effort will be made to formulate a solution that both meets the requirements and is compatible with previous versions of Epicentre.
The length available for names is too short for many entities in the model. There is a lack of consistency in the way "other_" entities are modeled, and some definitions are ambiguous and need clarification. Some indication of the deprecation of obsolete reference values is needed.
Shell, Mobil, POSC/CAESAR
Increasing the length available to an attribute that is already implemented as a variable character column in the relational implementation (VARCHAR2 for Oracle, for example) is compatible with previous versions of Epicentre. It should be possible to resolve the other requirements by the addition of optional attributes to existing entities and so these changes are compatible.
These changes should not cause problems of incompatibility with users of previous versions of Epicentre.
Some concepts, such as station count, line and point count missing from the model.
Elf, Discovery
Specific solutions have not be formulated, however it is expected that proposed solutions will be largely that of adding additional optional behavior.
Every effort will be made to formulate a solution that both meets the requirements and is compatible with previous versions of Epicentre.
CGM*PIP/III provided a basic set of CGM extensions for the efficient description of simple well log plots. Additional extensions, known as CGM*PIP/IV, Advanced Well Log Extensions, are required for the efficient description of advanced capabilities for more complex well log plots.
The new extensions were requested by the POSC Plot/Hardcopy Work Group, comprised of representatives from Schlumberger, Chevron, Zeh Graphic Systems, Western Geophysical and System Development Inc., based on recommendations by the SEG Graphics Standards subcommittee and feedback received in the POSC Request for Comment on Graphics Metafile Format in January 1994.
With respect to previous PIP specifications for Seismic and Continuous Rendering (PIP/I&II), a valid PIP/I metafile should be a valid PIP/III metafile and a valid PIP/II metafile should be a valid PIP/III metafile. With respect to the Basic Well Logs (PIP/III), the extensions of PIP/IV are a superset of the extensions of PIP/III. A valid PIP/III metafile is a valid PIP/IV metafile.
CGM*PIP/IV is a new specification in an area previously unspecified. The only impact will be on legacy metafiles which were generated using tools that do not implement the PIP specifications.
Add requirements to the Data Access and Exchange specification so that a data access layer could supply an application with sufficient information to respond intelligently when working with a subset of Epicentre.
Next Release work group meetings.
Will require the specification of some additional functionality within the Data Access specifications and the Static Work Environment.
The current suppliers of POSC data access layers will need to add these new features to be V2.2 compliant. The change should leave V2.1 upwardly compatible with V2.2.
Port the sample implementation of POSC’s Compatibility Layer to run on an Informix database.
Informix, various US Government agencies
None.
This has the potential of providing opportunities to additional POSC customers by making data access technology more widely available. This in turn, could make it easier to implement Epicentre and migrate legacy data.
The ‘supplemental library’ specification and sample implementation were intended to support logical access to frame data by applications which access a relational projection of Epicentre. The supplemental library and compatibility layer are substantially similar in how frame data are accessed, and with V2.2 it was intended that those wishing to implement the supplemental library could do so using the relevant parts of the Data Access specification, and those using the supplemental library implementation could migrate to a compatibility implementation. Accordingly, the supplemental library specification was deprecated, and the sample implementation was not upgraded for release with V2.2.
There are minor differences in how supplemental library and the compatibility layer deal with instances, entities, sessions, and errors, which unfortunately were not addressed in the V2.2 specification. This requirement is to correct that oversight.
Texaco
A new compliance option for compatibility layer implementations is defined, consisting of new functions to cast between surrogate keys and instance handles.
An addition to the DAE User Guide provides guidance for migration of pre-V2.1 applications using the supplemental library.
Commercial access facility developers have an additional opportunity for POSC-compliant product development. Customers using the supplemental library may migrate to current sample or commercial logical access layers.
To have a browser that works on software that POSC can freely and readily distribute with its product set, so that everything required to be able to use the Browser is self contained.
Tigress, Schlumberger, Landmark, Mobil, Chevron, POSC/CAESAR, Elf
Nil. Work required by POSC to migrate its document production tools to use the new software.
Positive only.
The details of the Test Plan for this release will be established in cooperation with the POSC’s beta test partners. The following will need to be established:
Copyright © 1994, 1995, 1996 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.