Including XML Schema Tags for Production and Injection ... - IPEC

INCLUDING XML SCHEMA TAGS FORPRODUCTION AND INJECTION DATAREPORTING TO REGULATORY AGENCIES INTHE PIDD: A BUSINESS CASEPresented on behalf of the Ground Water Protection Council byW. Thomas Gillespie, Virtual Engineering Solutions, Inc.Deborah Gillespie, Virtual Engineering Solutions, Inc.Stan Belieu, Nebraska Oil & Gas CommissionABSTRACTState oil and gas board managers and technical staff believe that the eXtensibleMarkup Language (XML) is an ideal format for sharing data with oil and gas industryoperators. Two factors contribute strongly to this perception. The first factor is its lowcost in comparison with the cost of traditional electronic data interchange (EDI), which isbased on the X-12 transaction set. The second factor is the wide-scale availability ofXML development tools.For all XML-enabled data transfer applications, a schema, or standard set ofsyntax and formatting requirements specific to the oil and gas industry, is needed as ameans of first-round of data validation. Over the past 2 years, the Ground WaterProtection Council (GWPC), a nonprofit organization dedicated to serving the oil and gasindustry through the state regulatory agencies, has coordinated the development of such aschema. The extensive development effort has included Technical Advisory Groupmeetings, workshops, state agency conferences, and pilot studies funded through grantsfrom the Department of Energy (DOE) and the participating states. Agencies nationwidehave embraced the schema as a standard. Electronic reporting initiatives are now beinglaunched in Colorado and New York and are being planned in Montana, Alaska, Utah,Mississippi, Nebraska, and Pennsylvania.The schema on which all of these applications will be based is calledeReport.xsd. Now in version 3, the eReport schema governs production, injection, andlocational data. The schema itself is designed to be database-neutral, so users’ databasetable structures can remain unchanged.Because API has long written the standards for well construction, GWPCbelieves that API acceptance of any standard associated with the oil and gas explorationand development processes is both desirable and proper. GWPC therefore requested thatAPI review the schema for production and injection data reporting that it has developedthrough this collaboration of state agencies and industry volunteers and back its use. Thistopic was an agenda item at the PIDX meeting in August 2002, where meeting attendeesaccepted the eReport schema in its entirety into process for inclusion in the PIDX PIDD.

An oil and gas schema that the states have embraced and that API endorsesserves industry’s interest in the following ways:• Industry would be better able to leverage oil and gas exploration and resourcedevelopment efforts. Industry could produce more oil and gas more cost-effectively ifoperators had easier access to both the current and historical data warehoused inoversight agencies’ databases.• Improved data access in combination with desktop analytical tools also would behighly useful to operators in assessing production trends, risk, and other factors.• The massive efforts the agencies put forth to manage agency information processescan be scaled back to a much more efficient and effective level, with immediatefeedback to industry as to data transfer status.This paper presents the eReport schema and discusses its tag format and overallstructure. A description of how the state agencies are using the schema is included, alongwith examples of how XML-formatted data exchange under the aegis of an API-approvedeReport schema would benefit all concerned parties.OIL AND GAS INDUSTRY PERSPECTIVEIn addition to filing permits for all wells drilled, produced, serviced, andabandoned within the United States, oil and gas operators also are required to reportproduction and injection quantities and dispositions to various regulatory agencies, bothstate and federal. Some agencies require monthly reporting by lease or by well or byformation and others require annual reporting. Each agency may have different datafields or groupings required for their particular report. Although oversight agencies insuch states as Montana, Colorado, New Mexico, and others have accepted electronictransmissions of production and injection data from operators in an ASCII format forseveral years, this procedure, like the manual data collection systems still in use, has beenfraught with errors because of the inability to validate data easily, leading to excessiveiterations for corrections and manual data checks on the parts of both industry andagencies.From the industry viewpoint, with millions of oil and gas wells nationwide,providing this information through iterative, manual methods is a financial andadministrative burden. Particularly for small- to mid-sized and independent operators,preparing production reports often involves several format changes as data from onesystem is re-keyed or converted into another. In addition, the data reported—data thatmay be a part of the public record—remains difficult to access in agency datarepositories.The Internet format known as XML has made data exchange tools available tothe small- and medium-sized companies where previously only the largest companiescould meet the capital investment needed to effectively use EDI. Many tools are nowavailable to generate, validate, and accept XML-formatted data into receiving databases.Because of this combination of factors—the significantly reduced cost of operating an

XML data exchange system and the plethora of available XML development tools—theformat is ideal for state agencies with severely restricted budgets. XML is an idealmethod for sharing information between loosely coupled systems. A schema, or standardset of syntax and formatting requirements specific to the oil and gas industry, is needed asa first-round means of data validation in XML-based data exchange applications.An oil and gas schema approved by API would have greater utility andapplicability beyond the purposes of only the regulatory agencies. Indeed, agencies,industry operators, and other interested parties will reap significant benefits from parsingdata transfers against an Internet-based oil and gas schema. A few examples follow:• Administrative delays would be reduced because data validation would be automated.• Operators would receive immediate feedback as to data transfer status.• Wide-scale production data would become readily accessible to industry.• Software developers could write data-driven applications that are built around theschema.• Trading partners could readily exchange data.• Purchasers and transporters could use the schema to provide data to operators.• Industry owners who operate across state boundaries could report to multiple stateregulatory agencies in one standard format, reducing the need to customize theirproduction reports to conform to agency-specific formatting particularities.Because API has long written the standards for well construction, GWPCbelieves that API acceptance of any standard associated with the oil and gas explorationand development processes is both desirable and proper. GWPC therefore requested thatAPI review the schema that it has developed with the assistance of multiple states forproduction and injection data reporting and back its use as a standard for the oil industryThis topic was an agenda item at the PIDX meeting in August 2002, where meetingattendees accepted the eReport schema in its entirety and without amendment forinclusion in the PIDD.THE BUSINESS ISSUEOne of the primary benefits that would accrue to industry from improved dataaccess is the ability to leverage oil and gas exploration and resource development efforts.Industry could produce more oil and gas more cost-effectively if operators had access toboth the current and historical data warehoused in oversight agencies’ databases. Dataaccess in combination with desktop analytical tools also would be highly useful tooperators in assessing the risks of their operations. An API-recognized schema for oil andgas production and injection reporting would be the first step in providing consistent andbi-directional data exchange between agencies and operators.The dual goals of cutting the cost of oil exploration efforts while boostingresource output are not the only possible benefits that would accrue to industry with theadoption of a schema. A schema would make it possible to share data reporting andinterpretation tools and other features across disparate database systems.For example, data could be downloaded from multiple state databases and usedwith geographical information system (GIS) tools so that industry can obtain a clearer

picture of production trends, risk, and other factors across state boundaries withoutrequiring changes to anyone’s database table structure.Industry owners whose operations transcend state boundaries would have theirreporting requirements simplified under a standard schema because data formatting andsyntax for data transfers would be uniform nationwide. Data transfers would be parsedagainst this standard schema as a first-round data validation check. Second-round datachecks, which would be imposed at agencies’ Web servers as stored procedures, maydiffer across boundaries because of statute-imposed differences. However, variations inthese second-round checks would be handled by each agency’s Web application userinterface and would remain largely transparent to industry operators, who would receiveimmediate feedback as to data transfer status through the browser.Sharing data resources can be enormously profitable, both for the oil and gasoperators charged with developing the resource while safeguarding the environment andfor the oversight agencies in their role of analyzing risk and reporting trends. For bothparties, XML-formatted data exchange under the aegis of an API-approved schemarepresents a savings in the elimination of iterative medium changes during data transferand reduced costs in data analysis. Automating first-round data checks of electronicallytransferred data through a schema and then instituting agency-specific second-roundchecks through stored procedures at the database server means that the data will beavailable for download from the same database server more quickly.Use of a schema offers vast efficiencies over either of the procedures now inuse—paper submittals with manual validation and ASCII delimited transfers with manualvalidation—and will yield substantial cost and time savings that could be plowed backinto resource development. With the ability to evaluate production and injection dataacross leases and other boundaries, industry could put more effort into developing andmanaging the resource responsibly. Meanwhile, the massive efforts the agencies put forthto manage information processes can be scaled back to a much more efficient andtremendously more effective level. The business flow for such a reporting system isshown in Figure 1.ABOUT THE eREPORT SCHEMADEVELOPMENTGWPC is a nonprofit (501(c)3) organization whose members consist of state andfederal ground water agencies, industry representatives, and others, who work toward theprotection of the nation’s ground water supplies. In 1992, under grant fundingadministered to by the DOE, GWPC began coordinating the development of the RiskBased Data Management System (RBDMS) now in use by oil and gas agencies acrossthe nation to track well-related activities. In 2001, GWPC received an Energy 100 awardthat recognized RBDMS as one of the 100 best scientific and technologicalaccomplishments since the DOE's creation in 1977.GWPC has continued its tradition of excellence in software support for the oiland gas industry and source water protection agencies through the development of theEnvironmental Information Management Suite (EIMS). EIMS is GWPC’s strategic

approach to assist states and industry in managing information about oil and gasproduction wells, underground injection wells, source water, and watersheds. EIMSoffers flexible integration of customizable data management tools including RBDMS, aSource Water database to support Source Water Assessment Programs, and tools such aswellbore schematic utilities, multilateral well construction tracking, Internet reporting,online GIS applications, and more. GWPC is interested in making these EIMS tools andthe necessary technical support available to those parties who want them nationwide (seeFigure 2).In the last 2 years, GWPC and the oil- and gas-producing state agenciesnationwide have worked to develop a schema for oil and gas production and injectionreporting that could be used with Web-enabled databases. The schema itself is designedto be database-neutral, so that users do not need to change their table structures. Thanksto the dedication of the Technical Advisory Group members and the participating stateagencies, such electronic reporting initiatives are now being launched in Colorado andNew York and are being planned in Montana, Alaska, Utah, Mississippi, andPennsylvania. All of these installations are or will be based on the oil and gas schemadeveloped for this purpose, which is now called eReport.xsd.Now in version 3, the eReport schema was developed through extensive reviewsof W3C standards, the PIDX PIDD, and the regulatory requirements and business rules ofthe participating agencies. The GWPC’s Technical Advisory Group, comprising ITmanagers and database administrators for oversight agencies nationwide, participated inthe development and review of the eReport.xsd through meetings and workshops. Grantfunding from the DOE and participating state agencies has been made available to launchpilot studies to test the results, which have been highly successful. Industry operators inNew York have praised the process streamlining that has resulted from using applicationsthat reference the eReport.xsd to transfer data to agencies. At this time, the Colorado Oiland Gas Conservation Commission is proceeding with testing the use of XML filetransfers from oil and gas industry databases as an integral component of well reportingactivities and plans to roll out the application soon.GWPC solicited API’s review at this point in the development process, and APIconcurred with the opinion that incorporating these schema tags into the PIDD will havefar-reaching benefit for all concerned parties. The state agencies that GWPC representswill continue to build on this schema for other aspects of oil and gas reporting andpermitting and welcome the collaboration of agency volunteers.STRUCTURE OF THE SCHEMAAs shown in Figures 3 and 4, the content model for the eReport oil and gasschema is based on a flat catalog of all acceptable elements in an XML-formatted transferof production and underground injection control (UIC) data into states’ primary oil andgas database. The schema is based on the root element eReport, which has only onesubordinate global element, Company.In addition to simple elements to identify company addresses and telephonenumbers, the Company global element includes another critical global element, Facility.A facility can be a single well, a lease, a unit, a tank farm, or any other method of

grouping oil, gas, and UIC structures and entities. Therefore, this schema can be used toreport production and UIC data in a format that matches the targeted agency’s mandatedmethods for reporting. For maximum flexibility, two levels of the FacilitiesType globalelement have been defined in the schema. The same data elements associated with thetop-level FacilitiesType are repeated in a subordinate Facility global element. Stateagencies may wish to use both levels of Facilities, if for example, data is collected bothby lease and by well.The schema itself is shown in at the end of this technical paper. Although eachagency will institute its own second-round data validation checks as stored procedures oneach Web server, the schema itself imposes formatting and syntax requirements on allfields included in data transfers and requires that three fields in particular be present in alldata transfers to pass first-round checks:• CompanyID• First-level FacilityID• First-level FacReportingPeriodFUTURE DEVELOPMENT AND VERSIONCONTROLAlthough version 3 of the schema covers production, injection, and locationaldata, the participating agencies are interested in expanding the schema to coverpermitting issues. This schema expansion will be developed through the same open,cooperative effort that has characterized the schema development process to date. TheGWPC and partnering state agencies actively encourage the participation of API, PIDX,and REGS representatives in this process.The life cycle of a well, from a regulatory perspective, could easily exist in asingle schema. To meet the accelerated development schedule demanded by governmentand industry, a process unhindered by bureaucracy must be put into place to namestandards. The ideal medium to document future schema changes and additions may bethe PIDD, which could exist on API’s Web site for universal access. GWPC and the stateagencies would particularly welcome API’s inclusion of the eReport schema tagsdeveloped to date in the PIDD. Columns could be added to the PIDD to reflect thefollowing:• XML tag name• Data type• Occurrences• Restrictions• Namespace• Parent TypeIf API assigned one of its employees to manage PIDD changes, additions andrevisions could be submitted to that individual and posted after review for conflicts. Thiswould ensure neutrality and timeliness of updates.

The state agencies fully expect that the eReport schema will continue to bedeveloped into the future to cover other oil- and gas-related functions. Both GWPC andthe agencies look forward to API’s review comments and active participation in theprocess.STATE AGENCY USE OF THE SCHEMAAs mentioned previously, state agencies are in the process of implementingInternet-based production and injection reporting applications. Although the applicationsthat accept the data transfers differ from state to state, they use a common schema: theeReport.xsd discussed in this paper. Since the XML data transfers are parsed against theschema, any XML file submitted to one of these agencies must reference the schemauniversal resource locator in the file namespace and the reported data must conform tothe syntax rules described within the schema.Compliance with the schema requirements moves the data into the next phase ofintegrity checks at the agency server. However, a data transfer that fails to conform to theformat and syntax will cause the parser to stop processing and the data transfer to berejected. The generic data flow in the XML transfer to the agencies is shown in Figure 5.The oversight agencies will import XML data transfers from industryrepresentatives into a database structure that contains tables corresponding to the parentelements in the schema. This entity relationship diagram is shown in Figure 6. The tablesin the data structure are named 'tblXML' followed by the schema parent element name.An ActiveX .dll developed for this purpose reads the XML data and stores theinformation in a database.Second-round data checks, which are imposed at the agencies’ Web servers asstored procedures, also differ across boundaries because of statute-imposed differences.However, variations in these second-round checks are handled by each agency’s Webapplication user interface and will remain largely transparent to industry operators, whowould receive immediate feedback as to data transfer status through the browser. Forexample, some of the second-round data validations being used in the Colorado eReportWeb application follow:• Codes, IDs, and API well numbers must be valid.• If a value is reported for injection, the casing and tubing pressure must be reported.• If a sold value is present, then the quality (specific gravity or BTU) must be reported.• Specific gravity must be a value between 5 and 80.• All numbers must be whole numbers except specific gravity.• The number of days producing should not exceed those in the month.Other states may choose to use other data validations or to activate other schematags as being required fields.

SUMMARY: BUSINESS BENEFITS OF AN API-APPROVED SCHEMAThe widespread utility of the current eReport schema in standardizing data fieldformatting and syntax requirements for production and injection reporting among theagencies nationwide also demonstrates three genuinely valuable opportunities for the oiland gas industry at large:• The schema makes use of improved technology to simplify data transfer andautomate validation processes, thus eliminating administrative layers of re-keyingand manual review cycles.• Feedback as to data transfer status is immediate, thus eliminating the delays thatindustry experiences as a result of agency rework loops.• Data transfer between industry and agencies can become bi-directional. Improveddata access by industry would greatly leverage exploration and resource developmentefforts by facilitating production trend analysis across lease, state, federal, and otherboundaries.From the start, the process to develop the schema has been an open, cooperativeprocess that has involved multiple state agencies and has been funded through DOE grantand matching state funds administered by the GWPC. Volunteers from industry are nowproviding testing and feedback and will be tapped to participate in the review group thatwill oversee continued development. The PIDX committee members’ acceptance of theeReport schema tags for use in reporting production and injection data indicatesagreement with GWPC and partnering states on the viability of this method of bridgingthe data management needs of both industry and oversight agencies.On behalf of GWPC, the schema is now being hosted at the following URL:http://VirtualES.com/xml/eReport.xsd. Data element occurrence and formatting can bereviewed at http://virtuales.com/xml/SchemaVer3Doc/eReport_ver3.html.

Operator createsXML file via Webform or databaseexportFile transferred to agencyvia Web form or POP 3mail message attachmentPrimaryedit foracceptanceYesParsedintoTemporaryStorageNoError and technical correctionAgencyProcessed forDetailedTechnicalAcceptanceApproval returned to operatorAcceptedintoAgencyDatabaseFigure 1. Process Flow for eReporting Oil and Gas Data to Oversight Agencies. Industryoperators could report production and injection data directly to agency databases via theInternet. The data transfer file would include a reference to the standard oil and gasschema. The data would be instantaneously parsed against the schema as a first-roundprimary data validation check. Status would be returned to the user’s browser.

Figure 2. EIMS Software Installations Nationwide. GWPC’s EIMS software isdeveloped and tested through the active participation of the state agencies it represents,thus ensuring the software’s compatibility with the agency requirements nationwide.

Figure 3. The eReport Schema Structure. In addition to imposing formatting and syntaxrequirements for all fields, the schema mandates three required fields for a data transferto pass first-round data checks: CompanyID, first-level FacilityID, and first-levelFacReportingPeriod elements. Agencies have the flexibility to activate other elementsthrough second-round data validations. See Figure 4 for an expanded view of the Facilityelement.

Figure 4. eReport Schema Facility Element. The same data elements associated with the top-levelFacilitiesType are repeated in a subordinate Facility global element. State agencies may wish to useboth levels of Facilities, if, for example, data is collected both by lease and by well.

eReport(XMLtransfer)LocalDatabaseQueryOil & GasIndustryUsersSecureWebServerSchema Compliance?Data Validated?Data OK/Data Not OKWeb ServerDatabaseFirewallNotice of Data Transfer Status(Pass/Fail with Reason)On QC Pass/ReplicationStateAgencyDatabaseFigure 5. XML Data Flow for Uploading eReport Submittals to Agency Databases. The results oflocal database queries are uploaded from industry databases in eReport schema-compliant XML files.Files that are successfully parsed against the schema are passed to the second-round validation checksat the database server. Status messages (pass/fail) are returned to the user’s browser within seconds ofupload.

Figure 6. Complementary Entity Relationship Diagram for the eReport.xsd. Any custom databaseapplications designed for industry use in creating eReport schema-compliant XML files must includethese tables to function successfully.

THE eREPORT SCHEMA- - - Oil and gas production and UIC reporting for state regulatoryagencies. Version 3- - - - Location coordinates and metadata- - - Location section.- - Location township.- - Location township direction.- - Location range.- - Location range direction.-

- Location quarter quarter.- - Location town.- - - - Location meridian.- - Location method (GPS, Map, Survey).- - Location latitude.- - Location longitude.- - Location datum.- - Location UTM X coordinate.- - Location UTM Y coordinate.

- - Location UTM zone.- - API state code.- - API county code.- - Tax map and/or parcel number. Also known as section blockand lot.- - Name, address, and phone number ofoperator- - - Unique ID for this company.- - Name of this company.- - - - Company street number.-

- - Company street name.- - - Company street direction.- - - - Name of the city where the company islocated.- - - State in which the company is located.- - - - Company zip code.- -

- - Company zip code extension ("plus 4").- - - - Company telephone number.- - - - Company fax number.- - - - Information on tanks/storage facilities- - - Unique ID for tank at this facility.- -

- - Capacity of tank in barrels.- - - - Volume of fluid pad held in tank.- - - - Type of fluid held in tank.- - - - Date tank was installed. Use yyyy-01-01 if exact date isunknown.- - Description of tank.- - -

- Tank type.- - - - Tank construction.- - - - Tank base.- - - - Data on fluids/gas produced from a well andpurchases- - - Oil, gas, water produced or other fluid. Standard codesneeded.- - -

- Beginning fluid inventory.- - Ending fluid inventory.- - Units used to report quantities of fluid produced ortransferred.- - - - Quantity produced.- - Maximum daily quantity of fluid produced.- - Duration of producing period in days.- - Average daily fluid production.- - Description of or comments aboutproduction.- - Fluid disposition data.

- - - - Code to indicate how the fluid was was exported. For examplesold, flared, injected, etc.- - Quantity of fluid transferred.- - ID for pit, injection well, or other destinationlocation.- - ID for sales transporter.- - - - ID for this purchaser.- - - - Date of sale.- - BTU rating of gas.

- - Specific gravity of oil involved in this sale.- - Dollar value of fluid at well head.- - Injection pressures and volumes- - - Injection type (water, CO2, etc.)- - Cumulative fluid injection.- - Quantity injected.- - Maximum daily quantity injected.- - Units of injectate.- - Days in period that injection occurred.

- - Injection pressures. Multiple locations can be used byspecifying different location values- - - - Location of injection pressure measurement (casing, tube,manifold).- - - - Average injection pressure at this location.- - Maximum injection pressure at thislocation.- - Date and time that injection pressure wasread- - Facility information on one level- - -

Unique ID for this facility.- - - - Production period for the facility. For monthly reporting,format will be mm/yyyy. For annual reporting, format will beyyyy.- - - - If true, correction of previously submitteddata.- - Code to indicate if this is a well, lease, or facility (well leasefacility).- - - - Status of facility/well such as 'A' active or 'PA' plugged andabandoned.- - Operator unique ID (serial number) for thisfacility

- - Description of facility.- - Method of production- - Meter ID, if appropriate.- - - - Producing formation.- - - - Name of facility, lease, or well. Depends on how wells aregrouped.- - - - Name of the producing field.- -

- - Group that this facility belongs to. For example a unit name fora well.- - Facility information recursed (i.e. facility, subset of facility(well))- - - - - - - Code to indicate inventory item. For example 'PR' for producingwells- - Quantity/count of this item (well type,etc.)