DOC

PRODML_DataSchema_V1.0

By Clyde Ferguson,2014-01-10 05:46
6 views 0
PRODML_DataSchema_V1.0

     www.PRODML.org

    Data Schema

    Version 1.0

    This document was produced by the POSC & the PRODML Work Group

    Documentation Overview

    Document Use Recommendations by Role Copyright (c) 2006 Petrotechnical Open Standards Consortium, Inc. (POSC). All rights reserved.

    POSC? and the POSC logo? are registered trademarks of POSC.

PRODML Data Schema

PRODML V1.0 Page - 2 of 12

116328425.doc

null

PRODML Data Schema

    Table of Contents 1 Preface ................................................................................................................................ 5 2 Contents .............................................................................................................................. 5 3 Product Flow Model .............................................................................................................. 5 3.1 Gas Lift Example ............................................................................................................ 6 4 Product Volume Report ........................................................................................................ 6 4.1 Mapping to Business Terms ............................................................................................ 7 4.2 Gas Lift Example ............................................................................................................ 7 5 Well Test Report................................................................................................................... 7 6 WITSML Introduction ............................................................................................................ 8 7 WITSML Data Object Schema Design: ................................................................................. 9 8 WITSML Naming Convention in Schemas: ........................................................................... 9 9 Schemas: ........................................................................................................................... 10 9.1 productFlowModel data object ...................................................................................... 10 9.2 productVolume data object ........................................................................................... 11 9.3 wellTest data object ...................................................................................................... 12

PRODML V1.0 Page - 4 of 12

    116328425.doc

PRODML Data Schema

PRODML Data Schema

    1 Preface

    This material has been crafted to be compatible with the WITSML v1.3.1 specification. All schema files and this documentation can be downloaded here (0.8 MB zip).

    Further information requests and technical feedback may be addressed to POSC.

    2 Contents

    ; Product Flow Model

    o Gas Lift Example

    ; Product Volume Report

    o Mapping to Business Terms

    o Gas Lift Example

    ; Well Test Report

    ; WITSML Introduction

    ; WITSML Data Object Schema Design

    ; WITSML Naming Convention in Schemas

    ; Schemas

    o productFlowModel data object

    o productVolume data object

    o wellTest data object

    3 Product Flow Model

    The Product Flow Model can be used to define a directed graph of flow connections. The basic building block is a Unit which can be used to define the flow behavior of any facility (where the term facility represents any use of equipment to perform a function) such as a separator, a wellhead, a valve, a flowline. It utilizes a general hierarchy of:

    ; Model

    o Network (representing a Model or a Unit within another Network)

    ; Unit (representing one Facility)

    ; Port (which connects to other ports)

    The network only describes how things are connected for the purposes of enabling fluid flow. It does not attempt to provide physical descriptions of the things that are connected. The ports may also represent measurement points within the network. The following are some general characteristics of the flow network model:

    ; Supports knowledge of facility parameters that are expected to be available on a unit. For

    example, valve status.

    ; Supports knowledge of the properties that are expected to be available at a port. For

    example, flow rate.

    ; Supports finer grained details of the internal connectivity of a unit. That is, an internal

    model.

    ; Supports knowledge of the expected direction of flow. Inlet or outlet.

    ; Supports knowledge of the expected types of flow. For example, production, injection,

    gas lift, export.

    ; Supports knowledge of time varying connections.

    PRODML V1.0 Page - 5 of 12

    116328425.doc

PRODML Data Schema

    ; Supports the expected types of product. For example, oil, water, gas, H2S.

    ; Supports external connections to other network models. For example, between fields.

    ; Supports multiple aliases of units and ports (e.g., SCADA equipment tags).

    ; Supports multiple different network descriptions of the same installation.

    ; Does not support knowledge of how something actually flowed. See the productVolume

    report.

    ; Does not support physical descriptions of the connected units. PRODML future work. It is anticipated that the flow network can provide a mechanism to initialize and update software which processes information related to fluid flow. For example, a historian could initialize all of its internal SCADA equipment tags using aliases defined in the network. A simulator could initialize its internal model and could then monitor for mismatches between that internal model and the external site model. The "expected" information can allow an application to understand "where" to look for data. For example, controls exist in the network where facility parameters such as "block valve status" are be expected.

    See the PowerPoint file for an overview of the Product Flow Model. This model defines how product could flow. The Product Volume Report is required in order to define how it actually

    flowed.

    3.1 Gas Lift Example

    As part of the initial PRODML project, a Gas Lift Optimization scenario was developed in order to paper test the requirements of an optimization loop. As part of that exercise, a flow network picture was drawn in order to better visualize the scenario and to understand where measurement points existed within that scenario. In turn, a flow network was generated to match the scenario. See file Gas_Lift_Scenario_Network_Construction.ppt for a pictorial view of this

    process. The example XML in the schema section represents this network.

    4 Product Volume Report

    The Product Volume Report can be used to define, for example, the daily volume of oil production at each wellhead. It can also define other characteristics (pressure, temperature, flow rate, concentrations, etc) associated with that wellhead. The report can be a simple one for something like one well or it can be a complex one for something like an offshore field with multiple platforms. It utilizes a general hierarchy of:

    ; Report

    o Facility (wellhead, separator, flowline, choke, completion, ...)

    ; Parameter Set (block valve status, reciprocating speed, available

    room, ...)

    ; Parameter

    ; Flow (production, injection, export, import, gas lift, ...)

    ; Product (oil, water, gas, CO2, oil-gas, cuttings, ...)

    ; Period (instant, day, month, year, year-to-date, month-

    to-date, ...)

    ; temperature

    ; pressure,

    ; flow rate

    ; ...

    Parameter Sets allow time varying "usage" parameters to be defined for the facility. For example, a valve status may be toggled from "open" to "closed" to indicate that a well is offline. PRODML V1.0 Page - 6 of 12

    116328425.doc

PRODML Data Schema

    The Flow may be associated with a Port in the Product Flow Model in order to support detailed analysis of a flow network. This can allow for unambiguous association of data with a complicated network.

    This schema was originally designed to support production reporting (for the Norwegian OLF Partner Daily Reporting project) but it has been extended by PRODML to also support an optimization process. The key extensions were:

    ; Adding "current" time and time range query parameters.

    ; Adding generalized facility usage parameters (e.g., valve status).

    ; Adding additional enumerated values.

    ; Adding alert structures.

    ; Allowing versions of flow data.

    4.1 Mapping to Business Terms

    The enumerated values are especially important because they provide the mechanism for mapping the data back to real world business terms. The key kinds are:

    ; Facility Kind (e.g., well, wellhead, tubing head, separator, block valve, ...)

    ; Port Direction (i.e., inlet or outlet)

    ; Flow Kind (e.g., production, injection, gas lift, ...)

    ; Product Kind (e.g., gas, oil, water, ...)

    ; Period Kind (e.g., day, month, year, month to date, ...)

    These kinds, in addition to the specific property type (e.g., pressure), allow an instance of data to be related to one "fluid flow" business term. The production reporting context utilizes several different Period Kinds while the production optimization context primarily focuses on an instant in time. In addition, qualifiers allow variations on a theme to be captured:

    ; Qualifier (e.g., measured, simulated, recommended, etc.)

    ; Sub-qualifier (e.g., fixed, minimum, etc.)

    See the PRODML data qualifier spreadsheet for a example of terms that have been utilized to

    date. Future PRODML work will extend this list to include a broader context. This work will need to be coordinated with efforts within the production reporting context.

    4.2 Gas Lift Example

    As part of the initial PRODML project, a Gas Lift Optimization scenario was developed in order to paper test the requirements of an optimization loop. As part of that exercise, data values were defined to correspond with the network described above. See file Gas_Lift_Example_Data.xls for

    tabular view of the data. The example XML in the schema section represents the contents of this file. Note that this simplistic scenario assumes that measurements for several properties all occurred at the same time which is not particularly realistic.

    5 Well Test Report

    The Well Test object captures the results of a well test. This object is derived from the well test part of the older POSC ProductionML schema. It utilizes a general hierarchy of:

    ; wellTest

    o fluidLevelTest

    PRODML V1.0 Page - 7 of 12

    116328425.doc

PRODML Data Schema

    o productionTest

    ; testInterval

    ; wellheadData

    ; bottomholeData

    ; separatorData

    ; wellTestCumulative

    ; productionTestResults

    o injectionTest

    ; testInterval

    ; wellTestCumulative

    ; injectionTestResults

    Each Well Test Report can represent one and only one of: a Fluid Level Test, a Production Test or an Injection Test

    6 WITSML Introduction

    The Wellsite Information Transfer Standard Markup Language (WITSML) is a standard for sending well site information in an XML document format between business partners. These PRODML schemas are crafted to be conformant to the design characteristics of WITSML version 1.3.1. XML schemas are used to define the content of an XML document. The WITSML standard consists of two specifications which are versioned independently: Data Schema and Application Program Interface (API). This section provides an overview of the Data Schema design. The WITSML data schema consists of a set of independent but relatable data object schemas. A data

    object schema defines a set of data that can be transmitted within a single XML document and represents a cohesive subset (e.g.; well, wellbore, rig, etc.) of an overall logical schema related to a single domain (well). Data object schemas contain attributes, elements, and included component sub-schemas.

    Component schemas are XML schemas, but these schemas do not represent complete data objects. A component schema may be included by more than one data object schema. All component schemas are prefixed with (cs_). Each component schema file generally defines one type that has the same name as the file name.

    An attribute group file (attgrp_uid.xsd) is used to define a unique identifier (uid) attribute for all recurring container elements. A container element is an element that contains other elements. The uid attribute is optional but is required within the context of a WITSML server. This is the equivalent of a RDBMS system generated primary key.

    Low level simplistic types are defined in the following files. Each file defines many types. Each component schema file must directly or indirectly include file typ_dataTypes.xsd. If a component schema includes another component schema then it will be indirectly including typ_dataTypes.xsd.

    ; typ_dataTypes.xsd defines simplistic data types referenced by elements and attributes

    in WITSML data object and component schemas. Some of these types are included from

    the following special data type files.

    o typ_catalog.xsd defines the data types referenced by elements and attributes in

    WITSML data object and component schemas that are restricted content. For

    elements restricted by content, the valid (enumerated) values are defined in this

    schema.

    ; typ_measureType.xsd defines the subset of POSC measure types that

    are used in this specification. These types represent a numeric quantity

    with a unit of measure (uom) attribute. The allowed units of measure are

    controlled by types in file typ_quantityClass.xsd (see below). PRODML V1.0 Page - 8 of 12

    116328425.doc

PRODML Data Schema

    ; typ_quantityClass.xsd defines the enumerated POSC unit of

    measure acronyms for each measure type.

    ; typ_baseType.xsd defines the lowest level types.

    These are the types from which all other types are

    derived. They allow the underlying behavior of types to

    be controlled in one place. For example, all types are

    constrained to not allow an empty value and strings are

    constrained to not allow a blank value.

    The typ_catalog.xsd file contains enumerations that are considered to be relatively static and should not require frequent changes. However for some data the list of recognized values may change relatively frequently. For this type of data the values are enumerated in file enumValues.xml.

    The unit of measure conversion information is defined in file witsmlUnitDict.xml. Abbreviations

    used within the WITSML schemas are documented here.

    7 WITSML Data Object Schema Design:

    Since all XML documents can only have one root level element and there are situations where it is necessary to send multiple occurrences of a data object in a single XML document (e.g.; multiple wellbores in a well), a pluralized version of the data object name was established as the schema root element. That is, the object name followed by an "S" (e.g.; wells, wellbores, etc.). In some cases, this leads to incorrect pluralization (e.g., trajectorys), but is required to order to meet the requirements of the WITSML API which generates root tag names based on the data object name. One component schema is included in all plural data object schemas:

    ; cs_documentInfo.xsd Defines information that is relevant to a specific document such

    as when the document was created and who was responsible for creating the document. The unique identifiers (uid) for data objects are always defined as attributes at the singular data object name level.

    8 WITSML Naming Convention in Schemas:

    A WITSML type can be one of four kinds; a definition only with possibly a restricted size specified, a definition with enumerated values that are permitted, a reference to a component schema and a reference to a element group schema. While not really a type, the element group schemas allow the same elements to be used in multiple different contexts. In order, to help identify which type is being referenced, the following naming convention is used.

    ; Type definition only - starts with lowercase, each new word begins with uppercase

    <xsd:element name="mdKickoff" type="measuredDepthCoord" minOccurs="0"/>

    ; Type definition with enumerated values starts with uppercase and each new word

    begins with uppercase

    <xsd:element name="shape" type="WellboreShape" minOccurs="0"/>

    ; Reference to a component schema can be identified by the a "cs_" prefix. <xsd:element

    name="customData" type="cs_customData" minOccurs="0" maxOccurs="1"/>

    ; Reference to an element group schema can be identified by the a "grp_" prefix.

    <xsd:group ref="grp_well" minOccurs="0" maxOccurs="1'/>

    PRODML V1.0 Page - 9 of 12

    116328425.doc

PRODML Data Schema

9 Schemas:

    This release includes the following data object schemas, component schemas and element group

    schemas.

    9.1 productFlowModel data object

     Links to Documents

     XML via Style Schemas XSD XML Style Sheet Schema Document Sheet Source

     obj_productFlowModel.xsd XSD XML XML/XSL XSL

     grp_productFlowModel.xsd XSD

     cs_productFlowExternalReference.xsd XSD

     cs_productFlowNetwork.xsd XSD

     cs_productFlowlExternalPort.xsd XSD

     cs_productFlowUnit.xsd XSD

     cs_productFlowExpectedUnitProperty.xsd XSD

     cs_productFlowPort.xsd XSD

     cs_connectedNode.xsd XSD

     cs_productFlowQualifierExpected.xsd XSD

     cs_productFlowExpectedPortProperty.xsd XSD

     cs_productFlowQualifierExpected.xsd XSD

     cs_commonData.xsd XSD

     cs_customData.xsd XSD PRODML V1.0 Page - 10 of 12 116328425.doc

Report this document

For any questions or suggestions please email
cust-service@docsford.com