Appendix A to E
Appendix A (Exploration Surveying and Drilling)
Appendix B (Specification 1 to 25)
Data Management Standards The EP Data Model (Epicentre)
Simply having a shared data store that every application uses does not solve the problem of interoperability if all applications do not also share a common understanding of data. POSC has built the Epicentre data model to establish that common understanding of data. It defines the semantics of many technical areas of EP interest, and it is a major architectural component of the SIP, giving meaning to the data in a PDS.
Epicentre is defined independently of applications and at a logical level, independent of any implementation as a data store. Because of its implementation independence, POSC refers to Epicentre as a logical data model.
It is also designed to integrate data from different disciplines and has the capability of storing the complete life cycle information of oil and gas assets.
The POSC Data Store
In non-integrated systems, it is common practice for each application to store the data it needs in a unique, internal format customized for its own needs. If a user converts data into the format needed by such an application, any items present in the original data that are not needed by that application are discarded in the conversion process. Once the results of that application are re-converted into the original format, only a subset of the original data remains. This loss of data in the conversion from one format to another is a frequent vexation to today's users of EP computing technology.
As vendors move to more integrated solutions, the problem of application isolation is reduced, since integrated applications frequently shared the same data store. If this data store is unique to a particular vendor, however, there is still a problem of interoperability between different vendors' applications and/or internally developed EP data stores and applications.
It is no longer acceptable to think of data as belonging to one application, or even a set of applications. Data is a corporate asset. It will be operated upon by a variety of applications (most likely from several vendors) and is shared by employees throughout the organisation and its service companies. This presents a need for a place to store EP data in a standard way, independent of any application or set of applications. POSC refers to this as the POSC Data Store, or PDS. The PDS is a key concept in the POSC computing environment.
POSC Data Store Application Programming Interface (DAE)
Linked closely with Epicentre is the specification of how applications gain access
to the PDS through an Application Programming Interface (API). The data access
API is another major component of the Software Integration Platform and is
known as the Data Access and Exchange (DAE) Specification.
The purpose of the DAE is to specify that a PDS must perform certain functions, and applications must be able to invoke those functions in specified ways. The DAE does not specify how those functions must be implemented, thus allowing suppliers of POSC Data Store technology the freedom to experiment with different implementation approaches. POSC refers to an implementation of the DAE specifications as a Data Access and Exchange Facility (DAEF).
POSC specified an EP data access API for two primary reasons:
To provide the ability to implement features found in Epicentre which provide added value in data management, for example complex data types common to the EP industry (well logs, seismic cubes, etc.), multiple inheritance of entity characteristics and strong enforcement of logical model rules. Most database systems available when the POSC specifications were created did not support these features. Therefore, the API was designed to provide these capabilities. Today, database vendors are beginning to sell products capable of handling complex data types, inheritance and improved rules enforcement. The introduction of these products into the marketplace will allow software developers to deliver thinner, more efficient implementations of the POSC DAE.
To insulate applications from underlying actual implementations of the PDS. There are two primary advantages of isolating application data access from the physical data storage mechanism. First, there are many vendors of database software, and not all EP companies use the same database vendor. Therefore, it is in a software developer's best interest to use a common API for data access. This decreases the work required to make applications available to the widest possible range of consumers, thus lowering software costs to the EP community. Second, rapid advances in database technology, computer hardware and operating systems and networking software make it impossible to create lasting standards based on specific vendor products. Creating an independent API specification leaves room for diversity and improvement in storing and managing data and insulates applications from these variations.
POSC has been working with the database industry to incorporate EP data access needs into SQL3, the next revision of ANSI standard SQL. POSC efforts in this area are very promising, and it now appears that SQL3 will be closely aligned with the current specification of the DAE. This means that future versions of widely available, SQL3-based database software should more easily support the implementation of POSC data stores.
How Epicentre and the DAE are related? Epicentre defines the data structure the DAE can access. Developers using the DAE refer to data in Epicentre terms (logical model terms), and the DAE translates those references into forms suitable for accessing the data, as it is physically stored. A storage implementation of the logical data model is commonly referred to as a physical implementation.
As long as a common API is utilized to access data and the data is well defined,
the physical details of how the data is stored do not affect the logic of an
application. The physical storage mechanism may, however, have a great effect
on the performance of an application. By separating the logical view of the data from its physical implementation, PDS suppliers may experiment with different hardware and/or software platforms for implementing a PDS, allowing a PDS implementation to be tuned for a desired performance bias.
Epigramme and the POSC Exchange Format (PEF)
Epigramme is the POSC-defined format for exchange of Epicentre-defined data between heterogeneous computing environments. Epigramme enables a direct, intelligent exchange capability between POSC computing environments and establishes a buffer between heterogeneous systems.
An Epigramme file may be a complete Epicentre data set (i.e., the full content of a POSC Data Store) or a selection of data (i.e., a subset of a complete data set).
Exchanging Data using POSC Exchange Operations
The POSC Exchange Operations specify functions to extract data from a POSC Data Store into an exchange set and to integrate data from an exchange set into a POSC Data Store.
An exchange set may be an extraction of all data in a source data store or a user- defined selection of data. Data are integrated into the target data store by merging existing and new data based on natural identifier correlation. The exchange operations also specify how an exchange application determines which data needs to be included in the exchange file as a result of the user's selection.
For example, assuming a user only selects wellbores for extraction, the identifiers and aliases of related wells will also be included in the exchange set (because each wellbore must be part of a well). Subsequently, on import, each new wellbore instance is related to an existing well instance whose identifier or alias matches the new wellbore's well identifier or alias.
The POSC Exchange Operations are defined as a layer, which accesses a data store through the DAE API. The user typically accesses this layer through an exchange application. The user creates, modifies or uses predefined exchange descriptors, which define the details of the operation, and then invokes the required functions. The POSC Exchange Operations are fully dynamic; exchange applications may be dynamic or specific to a particular EP domain or exchange requirement.
User Interface Style Guide
Reducing the amount of training users require when encountering a new
application is another part of POSC's technical objective. Currently, much of the
learning that is necessary, concerns routine tasks that are not unique to any one
application. These common tasks (such as obtaining a paper printout of some
results or zooming in for a closer look at a graphics display) could always be done
in the same way but usually are not, simply because different application
developers, working independently of each other in different organisations, come
up with different solutions. POSC is uniquely situated in the EP industry to provide
a specification of one specific way of providing these common functions that
can then be followed by application developers throughout the industry. The definition of how these functions should be provided by application programs is called POSC's User Interface Style Guide.
Base Computer Standards
The specification of well-defined APIs is critical to the achievement of application portability, which is necessary if EP companies are to be able to effectively integrate applications developed by different vendors on different systems.
Applications must also interface with the computer systems that they run on, the operating systems, language compilers, etc. These must all be handled in a way that facilitates portability also, if the industry is to meet the objective of application portability and interoperability. Accordingly, POSC has endorsed a set of general computing standards designed to keep applications from being tied to any one vendor's underlying hardware or software. These endorsements are referred to as the Base Computer Standards.
Internet Data Exchange standards Chemical UsageML
This is a specification for information that describes the nature, usage and potential hazards of chemicals to be used in the exploration and production of petroleum hydrocarbons. Implementation of this specification is intended to enable seamless transfer, exchange, and storage of chemical usage information between oil companies, oil service companies and government agencies responsible for oversight of petroleum operations. The format specified here is in the eXtended Mark-up Language (XML) which enables the data to be encoded, transmitted and viewed using standard Internet and World Wide Web technologies. Equally important, XML enables the meaning of the data to be conveyed, viewed, and comprehended together with the data values.
XML Objects
One of the major contributions is to define standard objects for transfer of data and information. When XML became a standard way for transfer, POSC began studying how to implement such a process. XML Schema allows these objects to be specified in such a way that they may be reused in standard exchange documents. In developing these standard objects, it became apparent that there should also be consistent ways to develop the objects. These ways are grouped under the general heading of patterns, although it is difficult to separate the developed objects from the patterns. By combining these patterns with the objects that are being developed, it is becoming possible to more easily generate standardised exchange sets, even though these standardised sets are built for a particular use.
WITSML
Much of the data needed to feed all phases of the oil field life cycle processes, can
be shared between Service Companies and EP companies during the planning and
execution phases of the wellbore construction process. The “right time” seamless
flow of this data between operators and service companies will speed and enhance decision-making. For this to become viable, a new data exchange standard needs to be defined and adopted by the oil and gas industry. The goal of the WITSML initiative is to define, document, and promote the implementation of such a standard. Wellsite Information Transfer Standard Mark-up Language is a standard for transferring data between service companies and operators. It is a standard for drilling information transfer. The data is transferred as XML documents over SOAP (programming interface) and HTTP/S. WITSML is object oriented.
The data objects are:
•
Well
•
Wellbore
•
Rig
•
Rig Equipment
•
Pump
•
Location
•
Units
•
Trajectory
•
Target
•
Bit Record
•
Fluids Report
• Bottom Hole Assembly
•
Wellbore Geometry
•
Casing Scheme
•
Open Hole
• Daily Operations
•
Cement Job
•
Log
•
Real Time
•
Mud Logging
Note: The number of data objects is not fixed. During SIG meetings people discuss and introduce new possible data objects for WITSML.
WellHeaderML (No information).
WellLogML
WellLogML is, by design, a simple format for exchanging well log data over networks (Internet and intranets), simple to understand, human-readable, and accessible to text and XML-processing tools and utilities. It specifies how the curve data should be structured.
LogGraphicsML
LogGraphicsML is an XML-based mark-up language for reusable and sharable
definitions of graphic presentations of well log data. It specifies how curve data
should be displayed on the plot.
WellPlotML
WellPlotML aims to establish the way users can collaborate over the Web (Internet and/or Intranet) using WellLogML, LogGraphicsML and other evolving standards. WellPlotML creates a rich, collaborative environment where team- members could publish, view, access and discuss various types of log plots and log data just by using their web browser.
PEF XML
The Epicentre XML Exchange Format is based on the Express Specification of the Epicentre Data Model (described in paragraph 4.3.1). The purpose of defining an XML Exchange Format is to be able to exchange data based on an Epicentre Data Model. It has been found that the PEF, based on RP66, is too burdensome for most exchanges. With the emergence of XML as an exchange format, it is useful to be able to express the data in this format.
Practical EP standards Reference Entities and Values
Sets of standard reference values used to express and classify petrotechnical business activities and data.
Practical Well Log Standards (PWLS)
To help find important Well Log data, use this consistent, recognized reference standard. Several Well Log management business issues motivated the PWLS.
Users have difficulty finding the important Well Log data, because there are so many types of curves. Names for both individual curves and collections of curves are complex and are changing at an ever-increasing rate. The lack of consistency over time is confusing for experts and generalists alike. Until now, there has been no recognized central source for Well Log naming standards. POSC organized the PWLS project to establish and promulgate such standards for use throughout the industry.
Most of the business value of Well Log data is concentrated in a relatively small number of types of curves. There is on the order of 50,000 visible acquisition curve types of which about 1,000 deliver the majority of the value.
The goal is to remove the mystery surrounding curve names caused by the current proprietary and esoteric naming systems.
Data Store Solutions (DSS)
DSS SIG is an affinity interest group of EP industry organisations that study and
promote ways to positively impact the definition, movement, and storage of EP
data, information, and knowledge. Five central recommendations are being
published now. POSC and the SIG participants will promote and refine the
recommendations with the ultimate goal being their adoption and the realisation
of the associated benefits. Here are brief statements of the recommendations:
EP organisations should use a high-level catalogue
(discovery.com) based onstandards that are published and maintained by POSC. Doing so can improve significantly the process of finding and assessing the value of stored data, information, and knowledge. Catalogue standards and best practice guidelines will help establish disciplined but pragmatic procedures for storing external acquisitions and internal results in terms of catalogue attributes and valid attribute vocabularies.
EP organisations should commit strongly to the use of industry standards for sets of reference values, including those developed and maintained by POSC. The recommendation highlights several to be considered first, namely those addressing cartography, country, currency, units of measure, well elevation, types of well logs and curves, well naming system, well purpose, and well status.
The use of standard sets of reference values will significantly improve the ability to share and understand data across organisation, discipline, and time boundaries.
EP organisations should agree on and adopt practical guidelines and best practices for the process of publishing results from active projects and ongoing operations. It is anticipated that such guidelines will address quality control, minimum content, retention criteria, and the forming of suitable catalogue entries (as proposed in #1). Agreement and use of publishing guidelines can greatly enhance the ability to confidently apply analytical results and, moreover, to re- use past or outside results.
EP organisations should develop and use an annotated directory of inter-company information transfer standards to be published and maintained by POSC. Such a directory would help ensure awareness of not only the existence of transfer standards, but also of the characteristics, capabilities, and constraints of each.
The availability of such a current and maintained directory can expedite the use of the best means of moving data between organisations. It also can help the industry take the collaborative actions necessary to define new or improved transfer standards where they can have the greatest positive impact.
EP organisations should support the development and use of data transfer standards specifically designed to support data previewing, especially Internet- based data previewing. The recommendation focuses on graphical previewing of production volumes, well log data, well schematics (mechanical) data, and well test results. The publication of previewing data transfer standards will contribute to the ability to efficiently and economically examine and competently evaluate the fitness for purpose of candidate data from a wide variety of sources (internal and external).
By their nature, some these recommendations call for further clarification, analysis, and details.
Property Type Definitions
A hierarchical model of measured and calculated properties geared for classifying
specific kinds of petrotechnical data, such as well log curves.
EP Business Process Reference Model (EPBM)
The EPBM is a hierarchical model of the activities of a typical oil company. The purpose for publishing and maintaining an EP business process reference model is to serve as a relevant source of vocabulary and concepts to support collaborative work within the POSC community. The current version of the reference model is based on material submitted to POSC that has been actively in use for over six years. The process model covers a wide range of activities for an EP company. To the extent possible, the process model does not depend on or promulgate any specific organisational structure or technical tools.
High-Level Business Processes
The high-level business processes are illustrated in Figure 1. The model is heavily based on the concept of Asset Management through structured Activity Management (the blue process boxes).
A traditional five-stage Asset life cycle is followed for each managed Asset (the process boxes numbers 1 through 5).
The activities planned and carried out for any specific Asset are assembled from 14 major execution and support processes (the green lettered process boxes).
The company as a whole is integrated through Company Management,
Accountability Management, and Business Process Program Management
activities (the red process boxes).
Business Process Resources
The process model describes interactions among various kinds of resources:
Actors
Internal: Workers, Teams, Organisations fulfilling various roles: manager, geologist, etc.
External: Business Associate Organisations and People fulfilling various roles: owners, partners, suppliers, customers, and regulators. Note:
Although these are actors in their own right, the process model focuses on the internal actors.
Props (things acted upon)
Tangibles: Earth Features, Materials, Equipment, and compositions thereof fulfilling various roles as: surface facilities, down-hole facilities, pipeline facilities, etc.
Intellectual Materials: Documents, File Folders, Digital Databases, etc.
made up of combinations of Knowledge, Information, and Data and fulfilling various roles: Proposals, Study Results, Field Measurements, Interpretations, Accounts, Transactions, Reports, Web pages, etc.
Actors and Props are referenced in the names and descriptions of business processes. There is intent to formalize references to such resources, which in their own right are Reference Entities and Value Sets.
Business Process Hierarchy
The process model is presented as a hierarchy, that is, each process occupies a node and is a specialization of its more general parent node process. For purposes of presentation and consistency, there is a linear ordering of all nodes that share the same parent node. Where it makes sense for such nodes to be carried out in a given order, the linear ordering reflects that order. In general, however, any given process may succeed by any other process(es).
Business Process Identification
Each business process is identified in three ways:
Process Name - A natural English language verb phrase that seeks to convey the full meaning of the process.
Process Node and Path - An English language noun or short noun phrase that conveys the essential character of the process and that, together with the Id's of its parent nodes, conveys the full meaning of the process.
Traversal Code - A progressive code formed to generate the desired linear hierarchy ordering of the processes.
The many business processes that have an obvious single next step process, have
the Process Path/Node for that process recorded.
Process Model Development Opportunities
Consideration will be given to the addition of a new high-level process for new EP technology investigation and deployment. Sub-processes could include: Plan Technology Strategy (in line with corporate strategies); Identify and Prioritize Technology Needs; Publish Technology Requirements; Evaluate Technology Opportunities; Select New Technology; Plan New Technology Adoption; Acquire, Develop, and Deploy New Technology; and Evaluate New Technology Lessons Learned.
EP Catalogue Standards
Attributes and vocabulary to support high-level EP catalogues. The purpose for publishing and maintaining EP Cataloguing Standards is to facilitate and improve the long-term storage, discovery, and retrieval for use of information irrespective of form or subject. The goal is to ensure that all relevant information is found with as small a number of relevant matches as possible, high recall and high precision
Shared Earth Model (SEM)
Earth models are the central focus of decision making in today's fast changing EP business environment. They influence where to acquire leases, what prospects to drill, how to enhance production, and, eventually, when to divest the asset. As crucial as they are, many decisions are being taken based on models that take too long to develop, are mutually inconsistent, of unspecified reliability and of dubious provenance. At a minimum, the business impact of this is increased operating or capital costs, but it could also result in significant lost opportunities.
Models are built from individual interpretations of faults, horizons, and rock properties that are created over time like a jigsaw puzzle. They are typically created after the basic interpretation work is done and without the assistance of the interpreters. During model construction, it is customary to cycle back to the interpretations to make adjustments. Adding new data, like obtaining a new seismic survey or drilling a new well, can also cause interpretations to be reworked and models to be revised. Because Earth Models embody complex concepts with intricate interdependencies, a simple label is not sufficient to communicate the necessary information.
In practice, asset teams rely on several interdependent models developed in various different pieces of software by different discipline experts. Knowing who created the interpretations, how much confidence the interpreter had in them, which software packages were involved, what models they are used in, and so forth, is critical information for the EP decision maker. But the fact is there is no common, easy to use way to capture this information today. The POSC SEM project is designing a set of open services, epiSEM Information Services, to provide knowledge capture facilities that address this very problem.
EpiSEM Information Services will enable shared facilities that allow the
dependencies between components of different models from one or more vendors
to be registered, maintained, and queried in an open and shared catalogue. In an
epiSEM-enabled environment, interpreters, earth modelers, and decision-makers
will be able to:
Find pre-existing interpretations and supporting data sets within the organisation, asset or project scope
See who authored previous work, when and with what software Review assumptions, quality and uncertainty of pre-existing analyses Prevent deletion of models, which have dependencies upon, or are depended upon by other models.
Today, the project design team has established architecture for epiSEM Information Services that is open, layered, scaleable and distributed. The team's proposals have cross-industry support, meet actual needs, and could appear in vendor products to provide real benefits within the next two years.
Phase 1 of the SEM project has reached completion, and POSC is now seeking sponsorship for a second phase, beginning in 2000, to develop a proof-of-concept
epiSEM implementation. Through the development of this proof-of-concept weexpect to refine the specifications sufficiently such that vendors can see the future value in implementing them in their products in a secure, robust and interoperable manner and users can appreciate the value of having such services available to them.
RP66 Well Data Exchange Organisation Codes
RP66 is a list of 'organisation codes’, which primarily identify organisations. This is also used to define meta data resource identifiers referred to by RP66 data sets.
DLIS Channel Dictionary
Dictionary of DLIS Channel Identifiers is an integrated presentation based on dictionaries submitted by service companies.
Application Interoperability Standards Subsurface Interpretation Business Objects (Includes revised Base Computer Standards)
Achieving interoperability for end-users requires the use of an agreed upon
architecture or description of how software components should be developed and
how they are expected to inter-relate. Thus interoperability is accomplished
through the use of common, shared services and well-defined business objects
for use as application components. The goal is delivering application
interoperability to the EP business practitioner (end-user). This will ultimately
mean plug and play of application components from various sources and use of
multiple data stores.
Appendix C (Questionnaire)
Introduction to the questionnaire
(questionnaire on page 2 – 4)I, Marco Beringer, am a student and doing an internship about a compliance with POSC standards. In Groningen, I study Business Administration/Technical
Engineering (major IT). To graduate and get my title 'Drs.' (Dutch master's degree) I have to do an internship. Shell EP offered me an internship at Shell EPT-IT-EI/NAM in Assen.
I am in a phase where I have to a study on POSC and its standards. The University expects from me to do a research that is scientifically based. The research will have an elicitation/analysis phase and an evaluation phase. In the first phase I need to understand, e.g., the origin of the problem, POSC principles, the relevancy of using certain standards, etc. POSC has made specifications in different areas, after the first phase I should conclude on which
specification(s)/area(s) I have to focus.
POSC standards is seen by Shell as a non-competitive edge. This research tries to reveal the value of standards to the EP Industry and the implementation degree of certain standards. If this research will help/speed up the implementation of the standards by Shell and other parties, it can be seen as a success. Shell has no problem of sharing the results of this research to other EP companies. The idea behind POSC is that the whole industry benefits from using these standards.
When Shell adopts certain POSC standards, it will not benefit to Shell if no one else would adopt these standards.
The answers on the open questions will be presented as a general view. I will not quote companies and use their names in the conclusions I make from this
questionnaire (here I mean anonymity).
This questionnaire should help me to understand the relevancy of POSC and its specifications. The first part of the questionnaire focuses on the specifications (closed questions). The second part contains 3 open questions about POSC’s role in general.
I am asking you about approximately 20 to 30 minutes of your time for filling in the questionnaire. The answers will be interpreted as a unified company
response.
Sincerely,
Marco Beringer
I. Which POSC specifications (comparatively to each other) do you think are relevant for the EP Industry at a present day?
Where possible I have linked the specifications to the POSC-site for a description. Descriptions of specification 1 to 7 can be viewed by clicking on 'Data Management…Platform'.
N/A = Not Applicable
UN = Unknown
1 = Very Low
2 = Low
3 = Average
4 = High
Relevancy scale goes from 1 to 5
N/A: there is no relevancy to comply with a certain specification
UN: unknown, if you can not answer the question according to
the knowledge you have about the specification
Specification Area
5 = Very highNumber
Data Management (see overview:
about Software Integration Platform)
N/A UN 1 2 3 4 5
1
EP Data
model (Epicentre)
2 POSC Data Store (PDS)
3
POSC Data Store Application
Programming Interface (DAE)
4
Epigramme and the POSC
Exchange Format (PEF)
5 POSC Exchange Operations
6 User Interface StyleGuide
7 Base Computer Standards
Internet Data
Exchange Standards N/A UN 1 2 3 4 5
8
Chemical UsageML9
XML Objects10
WITSML11 WellHeaderML (no link possible)
12
WellLogML13
LogGraphicsML14
WellPlotML15
PEF XMLPractical EP Standards N/A UN 1 2 3 4 5
16
Reference Entities and Values
(no link possible)
17
Practical Well Log18
POSC Data Store Solutions19
Property Type Definitions
(no link possible)
20
EP Business Process Model21
EP Catalogue Standards22
Shared Earth Model (SEM)23
R66 Well Data Exchange Organisation
Codes
24
DLIS Channel DictionaryApplication
Interoperability Standards N/A UN 1 2 3 4 5
25
Subsurface Interpretation Business
Objects
Any comments to strengthen your choice
(please give the specification number, followed by the arguments)
………
………
………
………
………
………
………
………
………
………
………
………
………
………
………
………
II. How do you see the role of POSC as a body in the EP Industry?
………
………
………
………
………
………
………
………
III. What are the advantages in general of sharing KID on the basis of POSC standards?
(knowledge, information and data=KID)
………
………
………
………
………
………
………
………
………
IV. What are the disadvantages/constraints of sharing KID on the basis of POSC standards?
………
………
………
………
………
………
………
………
Thank you very much for filling in this questionnaire. If you have any questions or comments, please contact me through mail:
Marco.Beringer@Shell.com
