ePermit Collaboration Stage One
Work-in-progress Review Material:
Overview

The Development of Shared Processes and Procedures by Participating U.S. Federal and State Regulatory Agencies to Support Well Permits & Activity Reports

February 2005 

Introduction

The reader of this Overview is presumed to have a material interest in this collaborative agency-industry standards development effort and to be familiar with the background information written on the preceding Web page. As stated there, this written overview should be supplemented by an in-person or conference call meeting before you begin reviewing this material in depth. Contact Alan Doniger of POSC (+1 713 267 5124) for arrangements.

Since December 2002, a broadly based group of agencies, the GWPC, and industry organizations have been working closely together to lay the foundation for a new generation of Internet and XML-based data exchange standards that can be successfully used by many agencies (state and federal) and many industry operators (large, medium, and small) for permitting and activity reporting. The thoughts and aspirations of this group are reported in the Business Case document published in early 2004. 

By the summer of 2004, an opportunity presented itself for a first stage work effort focused on the state of California. The main ingredients of this opportunity were:

• A major development by the California Department of Conservation of an online Web-oriented information system, CalWIMS, that included plans for a batch data receipt feature for new permit requests (Notices).
• Involvement in the CalWIMS effort by the GWPC.
• The presence in California of federal regulatory activity for drilling on federal lands administered by the California office of the BLM. 
• The availability of an industry standard, POSC's WITSML™, with growing acceptance and deployment in the U.S. and worldwide that has significant relevance for permitting data.
• The willingness of POSC to apply, adapt, and extend WITSML for regulatory use (WITSML Regulatory Standards). The willingness of the CalWIMS team, GWPC, and BLM to work together to achieve this important first step.

By July 2004, there was substantial agreement to proceed with what became known as ePermit Stage One. Notably, all parties agreed to coordinate the handling of Notices for drilling on federal land so that an industry operator can make one submission that is received by California and then automatically forwarded for parallel processing by the BLM.

Among the Stage One activities to-date are:

• August: BLM and POSC studied the CalWIMS data requirements and mapped these with the BLM permitting requirements
• September: POSC and the CalWIMS team met and reviewed POSC's first draft specifications for the new drill Notice, identifying issues and follow-up actions. Stage One plans and status were reported to the GWPC RBDMS meeting in New Orleans.
• October: POSC prepared and delivered the second draft specifications for the new drill Notice.
• November: Stage One status was updated to the GWPC RBDMS meeting in Denver. It was agreed that Stage Two should add one or more states that are RBDMS technology users, possibly Alaska. BLM used the second draft specifications to prepare a mapping with the PIDD Industry Dictionary. 
• December: The CalWIMS team provided feedback to POSC on the second draft specifications, encouraged that the specifications should be suitable for software development.
• January: POSC prepared the third draft specifications addressing all types of Notices. The CalWIMS team and GWPC adjusted the software development resource plan to reflect the use of standards-based batch data transfer specifications. 
• February: POSC prepared and posted review material based on the third draft specifications.
• March: POSC prepared the fourth draft specifications based on the final WITSML 1.3 specifications.

In February and March, the CalWIMS team expects to develop software to read and process batch submitted Notices as well as test software to produce batch Notices. BLM is in the process of finalizing plans for software development and testing to feed permit requests forwarded from California. At least one industry operator in California, ChevronTexaco, has plans to participate in the testing activities by preparing and submitted test Notices. Deployments by California and BLM are being planned to take place as soon as all components are ready and all parties of properly trained.

As plans for future stages of this overall initiative take shape, these plans will be posted here. As refinements are made to the WITSML Regulatory Standards, the technical review material will be updated. 

WITSML Regulatory Standards: Work Flow / Use Case

The WITSML Standards originated in 2001 to support the work flow for bringing drilling data from service companies to industry operators. Recognition and use of WITSML has increased steady from that time. The scope of WITSML has also grown. POSC is committed to using the WITSML Standards as the basis for all E&P technical data transfer standards. 

Information about the WITSML Standard can be found on the WITSML Web Site (www.witsml.org) as well as on the POSC Web Site (www.posc.org). 

The WITSML Standard consists of two major portions:

• Over twenty XML-defined, integrated and related data transfer specifications, known as WITSML Object Definitions
• A set of Web Services protocols exclusively for handling WITSML object instances (messages) either to accomplish asynchronous data transfers of WITSML object instances from a source to a destination or to collect and make use of WITSML object instances. The first use case is called the WITSML Data Transfer Server Profile and the second use case is called the WITSML Data Management Server Profile. 

The WITSML Standards have evolved through several published versions:

• Version 1.0 in the autumn 2001
• Version 1.1 in mid-2002
• Version 1.2 in early 2003
• Version 1.3 due for release in March 2005

Notably, Version 1.3 extends WITSML beyond what we can call WITSML Drilling to address all well log data transfers (LWD and Wireline) and all use cases for well path data (planned, measured, and calculated). Work is underway now to develop extensions for the Completion activity, Production Optimization and Reporting, and Regulatory Permitting and Reporting. 

Version 1.3 also saw the introduction of WITSML Composite Object Definitions. These allow the packaging of a related set of object instances in a single XML-defined data file. Consider the example of a well path composite object that consists of one well object instance, one wellbore object instance, one trajectory object instance, and many trajectory station object instances. 

The current ePermit Stage One work effort involves the adoption, adaptation, and development of object definitions to address regulatory permit requests in general and especially to address the needs of the California state agency and the BLM federal agency in the U.S. 

1. Initial deployment plans by California and the BLM call for the use of XML data files prepared by industry in conformance with the WITSML Regulatory Standards and the specific usage criteria for California and, for federal lands, for the BLM.
   1. Large operators will be expected to develop or acquire the capability to produce conforming XML data files, most probably integrated with their internal systems.
   2. Medium-sized operators may be interested in new features for generating conforming XML data files included in existing or new commercial product offerings.
   3. Small operators are expected to use the CalWIMS online Web-based system (and not the batch Notice submission capability).
2. The transmission facilities, protocols for security, etc. will be specified by the California agency. At least initially, there is no intent to require the use of WITSML Server components.
3. California will define the guidelines for the transfer of attachment files (identified in batch XML data files as 'ancillary documents').
4. California will define the guidelines for preparing batch Notice XML data files for drilling on federal land that will enable California to forward the Notice XML data files to the BLM for processing.
5. On receipt and following security and integrity procedures, components of the CalWIMS system will retain the batch Notice XML data file for archival purposes, will provide acknowledgement of receipt to the sender, will interpret the Notice for regular processing within the CalWIMS system, and, if warranted, will forward the Notice XML data file to the BLM.
6. Except for fatal errors that cause a batch Notice XML data file to be rejected entirely, all corrections or other modifications will be made by operators following the CalWIMS procedures for Notices entered online.

Illustrating the WITSML Regulatory Standards

XML Schema is a W3C standard for defining sophisticated, encoded formats for data files to enable the transfer of such files between sending and receiving parties. Often, but not always, the parties are parties to a commercial transaction, i.e. an e-commerce transaction. In other cases, the exchange may represent a request for information, permission, or other action. They may also represent a response to such a request or a response to an arrangement or expectation established in some other manner. 

The WITSML Standards define a growing, integrated family of data transfer formats defined using XML Schema augmented by supplementary usage instructions and guidelines. 

An XML data file is an instance of a transfer encoded in conformance with a specific XML Schema. For example. ChevronTexaco may prepare an XML data file to represent a new drill Notice in accordance with the XML Schema called WITSML Regulatory and California agency provided guidelines in order to submit a batch Notice to the California state agency for review and approval. 

The remainder of this document provides an overview of the WITSML Regulatory Schema through an illustrative example of a new drill Notice batch submission. Please reference the various sample data files, forms, screen shots, etc. as they are mentioned. Note that there is a fairly technical primer on WITSML specification terminology, concepts, and constructs as well as an outline of the Schema source file outline structure at the end of this Web page. 

Example: Notice of Intention to Drill New Well

The following discussion refers the Notice of Intention to Drill New Well sample data illustrated three ways:

• CalWIMS Online Entry Screen Shots (Word File, 849 KB)
• Pseudo-Form Generated from Batch Submission XML Data File (XML File, 12 KB)
• Batch Submission XML Data File (XML File, 12 KB)

We will refer to the example as "the Notice". 

The Notice consists of 16 sections or data blocks:

1. Notice
2. CEQA (Environmental)
3. Status
4. Location
5. Surface Lease
6. Mineral Rights
7. Properties
8. Criticality
9. Type / Usage
10. Bottom Hole Location
11. Elevation
12. Well Bore
13. Casing String / Weight / Grade / Summary
14. Casing Cement
15. Contact / Additional Contacts
16. Lead Agency

more to be added ...

WITSML Regulatory Composite Schema Outline Structure

The following illustrates the schema structure. Each entry consists of an element or element group name optionally followed by a type. 

Note: Uses of low-level types, enumerations, etc. defined in files, such as baseType, cs_catalog, typ_baseType, typ_measureType, and typ_quantityClass are not listed here.

• documentInfo cs_documentInfo
• wellSet 
  • well co_well 
    • generalInformation co_wellHeader
      • grp_well
        • wellDatum cs_wellDatum
        • wellLocation cs_location
        • referencePoint cs_referencePoint
          • location cs_location
        • wellCRS cs_wellCRS
          • mapProjection cs_projectionx
          • geographic cs_geodeticModel
          • localCRS cs_localCRS
        • legalLocation cs_legalLocation
        • mineralLease cs_lease
          • alias cs_identifierStruct
        • surfaceLease cs_lease
          • alias cs_identifierStruct
        • offshoreLocation cs_offshoreLocation
        • latestProductionInjection cs_latest
        • wellAlias cs_wellAlias
        • classification cs_timeVariantClassification
        • businessAssociate cs_wellBusinessAssociate
          • role cs_identifierStruct
          • personName cs_personNameStruct
          • alias cs_identifierStruct
          • address cs_generalAddress
          • phoneNumber cs_phoneNumberStruct
            • qualifier cs_addressQualifierEnum
          • email cs_emailQualifierStruct
            • qualifier cs_addressQualifierEnum
          • contactPreference cs_contactPreferenceEnum
        • ancillaryDocument cs_ancillaryDocument
          • kind cs_classification
          • alias cs_identifierStruct
      • cs_commonData
      • cs_customData
    • regulatoryDocumentSet
      • regulatoryDocument co_regulatoryDocument
        • grp_regulatoryDocument
          • documentAlias cs_identifierStruct
        • cs_commonData
        • cs_customData
    • wellboreSet
      • wellbore co_wellbore
        • generalInformation co_wellboreHeader
          • grp_wellbore
            • cementSummary cs_casingCementSummary
            • casingPlugSummary cs_casingPlugSummary
          • cs_commonData
          • cs_customData
        • boreholeIntervalSet
          • boreholeInterval co_boreholeInterval
            • grp_boreholeInterval
            • cs_commonData
            • cs_customData
        • classifiedIntervalSet
          • classifiedInterval co_classifiedInterval
            • grp_classifiedInterval
            • cs_commonData
            • cs_customData
        • classifiedPointSet
          • classifiedPoint co_classifiedPoint
            • grp_classifiedPoint
            • cs_commonData
            • cs_customData
        • formationMarkerSet
          • formationMarker co_formationMarker
            • grp_formationMarker
            • cs_commonData
            • cs_customData
        • perforationIntervalSet
          • perforationInterval co_perforationInterval
            • grp_perforationInterval
            • cs_commonData
            • cs_customData
        • wbGeometry co_wbGeometry
          • perforationInterval co_perforationInterval
            • grp_wbGeometry
              • wbGeometrySection cs_wbGeometrySection
            • cs_commonData
            • cs_customData

WITSML Specification Technical Primer

WITSML Schema Glossary

• Data Object Schema - defines how to formulate complete XML data transfer files (documents, messages) of the type given by the schema name. For example, the well object schema guides the formulation of instances of well data transfer documents.
• Element - specifies how to formulate a single value. For example, the name element guides the formulation of instances of names in a data transfer document.
• Attribute - specifies how to formulate a qualifying value associated with an element value. For example, the language attribute for the name element guides the formulation of qualifiers to indicate the language of a specific instance of a name.
• Type - associates with each element and expresses the simple or complex structure, form, and range of values that can be used for instances (values) of the element.
• Component sub-schema - a schema fragment or, more formally, one schema type, expressing one or more structurally and semantically related elements that can be included in one or more schemas. For example, cs_documentInfo.xsd defines data concerning a business document. 
• Composite Object Schema - defines how to formulate a set of related data objects into a single XML data transfer file (document, message) of the type given by the composite schema name. Files built according to composite object schemas are completely equivalent to a set of separate object-level data files.  

It is a practice in the WITSML Standard to define Component Sub-schemas in anticipation of opportunities for re-use even if such an opportunity does not currently exist.

WITSML Naming Conventions

• Schema source files end with '.xsd'
• Data Object Schemas begin with 'obj_' and take the name of the object they describe, e.g. obj_well.xsd describes the well data object. 
  • The root element is a container for multiple occurrences of the object. It is named as a plural of the object name formed by adding an "s", e.g. wells. 
  • The first sub-element corresponds to a single occurrence of the object. It is named with the object name, e.g. well. So-called unique identifier (uid) values are defined as attributes to the singular object element.  
• Component Sub-Schemas begin with 'cs_' and take the name of the type they describe, e.g. cs_documentInfo.xsd describes type documentInfo. 
• There are five kinds of element types, named as follows:
  • Type definition only, camel-case beginning with a lowercase letter, e.g. <xsd:element name="mdKickoff" type="measuredDepthCoord" ... />
  • Type definition with enumerated values, camel-case beginning with an uppercase letter, e.g. <xsd:element name="shape" type="WellboreShape" ... />
  • Type definition by reference to a component schema, e.g.<xsd:element name="customData" type="cs_customData" ... />
  • The equivalent of a copy and paste function via a reference to an element group schema, e.g. <xsd:group ref="grp_well" ... />
  • Type definition by reference to a definition in the same schema source file (used in Composite Object Schemas), e.g. <xsd:element name="well" type="co_well" ... />
• Composite Object Schemas begin with 'WITSML_' and take the name of the composite being described, e.g. WITSML Regulatory. The root element is named for the composite, e.g. WITSMLRegulatory with type="witsml:allObjects". Constituent objects either appear as singular elements or as plural elements named by appending the word "Set" to the object name (enclosing the singular element). 

WITSML Low-Level Type Definitions

There are a number of special schema source files that address low-level, simple type definitions. Each file contains multiple type definitions. Each of these files includes the following file directly and those that follow indirectly. 

• cs_catalog.xsd - types that restrict content to stated (enumerated) lists of values. 
• cs_dataTypes.xsd - types that are simple (general purpose or specialized)
• typ_measureType.xsd - types for measurements, each including a numeric quantity and a unit of measure attribute. 
• typ_quantityClass.xsd - defines valid units of measure for each type of measurement.
• typ_baseType.xsd - defines the most fundamental types from which other types are derived.

Note: Lists of values that tend to change frequently are defined in enumValues.xml, an XML data file rather than being defined as part of the schema specifications. Unit of measure conversion information is defined in witsmlUnitDict.xml. 

Glossary

• borehole - A hole excavated in the earth as a result of drilling or boring operations. The borehole may represent the hole of an entire wellbore (when no sidetracks are present), or a sidetrack extension. A borehole extends from an originating point (the surface location for the initial borehole or kickoff point for sidetracks) to a terminating (bottomhole) point.
• sidetrack - A borehole that originates in another borehole as opposed to originating at the surface.
• wellbore - A unique, oriented path from the bottom of a drilled borehole to the surface of the earth. The path must not overlap or cross itself. A wellbore can represent one and only one sidetrack or initial borehole. 
• well - A unique surface location  from which wellbores are drilled into the earth for the purpose of either (1) finding or producing underground resources; or (2) providing services related to the production of underground resources.

page top