Q.  When did the PRODML initiative start and what is it about?

A. In August 2005, a group of energy companies, software and service providers, and an industry standards organization launched an initiative focused on helping producers independently optimize their oil and gas production by improving data exchange and work process efficiency.

The committed funds and resources to a one-year project to develop Version 1.0 of a PRODML Standard (PRODuction xML). The Work Group included: BP, Chevron, ExxonMobil, Shell, Statoil, Halliburton, Invensys, OSIsoft, Petroleum Experts, Schlumberger, Sense Intellifield, TietoEnator, Weatherford, and POSC . IBM provided access to infrastructure in a neutral zone to all participants for testing.

Q.  What is the scope? What business problems or processes are involved?

A.  The first version of PRODML (V1.0) demonstrated support for data exchange between applications and data stores in the office domain (typically data historian and technical analysis applications). The emphasis is on near-real time optimization (i.e. optimization that can be achieved by making changes in the existing production configuration that can be effected within one day).Three use cases were used to develop the initial implementation of the standard:

• Gas Lift Optimization
• Optimizing Production from free flowing wells using real-time measurements and network models
• Field Wide Optimization based on real-time measurements, network models and production forecasts

In 2006, four pilot tests, based on the above use cases, were conducted using field data provided by the operators and applications and test code implementations of the PRODML standards provided by the software companies.

We expect PRODML capabilities to expand over time as business requirements are identified and as the standard matures.

Q.  What is meant by "plug-and-play" in this context?

A. Within a PRODML enabled workflow, the standard is designed to support interaction between software components from different vendors in a consistent way. These interactions are a combination of requests for services and responses to these requests, for example the supply of requested data. Within this context “Plug and Play” means that the services and data interactions are sufficiently well defined and implemented such that it is possible to exchange one vendor’s product with a functionally comparable product from another vendor and still maintain the overall integrity of the workflow, notwithstanding differences in underlying technical algorithms or correlations etc. This concept was successfully tested in some pilot implementations by running comparable products from different vendors in parallel. Note that in this context “Plug and Play” does not imply a self-configuring system where new components are recognized and necessary adjustments made to accommodate them.

Q.  What data types are supported?

A.  PRODML is focused on production optimization, hence the data relates to product flows and properties within production systems.  Two detailed data schemas are supported in Version 1.0:

• Production Reporting
• Well Test Reporting

Production Reporting specifies a point in a production network where data will be reported, a time or a range of time, and then the type of data to be obtained. The network comprises the production facilities. Its scope runs from the wells to the custody transfer points. Flow within the reservoir is out of scope. Process plant and pipeline flows are supported only to the extent that they both can be represented as generic “flow units” in the network, and that they contain fluid flows which can be represented by the production reporting flow model. The associated data may be flow rates, pressures or temperatures, and compositions or phase identifiers (e.g. oil, gas and water). The model provides for further identification of a parameter as measured, simulated, allocated, forecast data and so on. This allows different sources of data such as sensors, allocation systems, and simulators to be related to the same point in a network.

The Well Test Reporting schema defines the data types associated with periodic production flow tests on wells. Although the flows may be similar to those in the production reporting schema, well tests are sufficiently unique and commonplace to merit their own data schema.

PRODML does not support the transfer of data describing the network itself other than its topology. A logical Network Model supports the description of generic “flow units”, and how these connect to each other and this network “map” is then used to identify the flows described above. However, no physical attributes of the flow units (e.g. well depths or pipeline diameters) are definable.

As PRODML matures and business needs dictate, capabilities will expand to include more data types.

Q.  Does PRODML manage security of the data and information being exchanged?

A.  In general PRODML adopts recommendations for security which are the same as those for the WITSML Standards that support data exchange for Drilling and Completions.

PRODML implementers should use HTTPS (Hypertext Transfer Protocol over Secure Socket Layer) with Basic Authentication during data transfers. This provides a common basis for interactions to implement a reasonable degree of transport-level security. This principle does not limit the potential for a PRODML interaction being implemented with additional security measures.

Security implementations will vary according to the policies, procedures and requirements of both the target organizations environment and the nature of the data and interactions (sensitivity, importance etc.) in a given PRODML exchange. Development of industry standards for security are beyond the scope of the PRODML Standards.

Q.  What, if any, is the relationship between PRODML and WITSML?

A.  WITSML (Wellsite Information Transfer Standard Markup Language) is a family of Energistics Standards for transferring drilling and completion data as XML documents using web services. It was developed by a process similar to the PRODML effort, initially by means of an industry workgroup then transitioned to POSC (now Energistics).

In the case of PRODML, the intention was to build on and extend WITSML into the production domain. PRODML builds on the WITSML standards and in doing so, in some cases identifies potential updates and modifications to WITSML.  PRODML was not limited to use the same architecture as WITSML and indeed has defined different solutions apprpriate to the PRODML requirements.

Q.  What is the relationship between PRODML and Service Oriented Architecture?

A.  PRODML is aligned with the broad trend toward Service Oriented Architecture focusing on SOA implementation of work processes specific to the Oil and Gas Industry. The initial PRODML effort in 2006 identified several use cases and the associated data services. The transactions implemented in the pilot tests are potential building blocks for standard services. Currently these transactions are quite low level, resembling the generic capabilities of SQL.

This approach lends itself to flexible reconfiguration of the transactions to build more specific services, but it can be somewhat inefficient or ‘chatty’ and require detailed understanding between source and requesting application developers prior to implementation. More specific business services may require less programming and maintenance in the situation for which they have been designed. In other words PRODML Version 1.0 leans toward general functionality rather than performance or ease-of-use. It is hoped that this initial version has struck a balance appropriate for a foundation layer of an industry standard.