WITSML 1.4: Real-Time Data Exchange Standard in the Oil and Gas Industry

Introduction and History of  WITSML

Before the advent of WITSML, data exchange at the wellsite was often done manually, on paper, or using proprietary binary formats and protocols. These methods were not only time-consuming and error-prone but also limited the possibility of real-time analysis and quick decision-making. In the late 1980s, the WITS (Wellsite Information Transfer Specification) standard was introduced, which was a point-to-point binary data exchange protocol. Although WITS was considered a step forward, it had limitations in scalability and flexibility.

In the early 2000s, with the growth of web and XML technologies, a group of leading oil companies (including BP, Statoil, and Shell) initiated an effort to develop an XML-based data exchange standard, which eventually led to the creation of WITSML . In 2003, the responsibility for maintaining and developing the standard was transferred to Energistics , a non-profit industry consortium. The main goal of WITSML was to create a common XML-based language for the transfer of technical data related to drilling, well completion, and well intervention, using web standards (such as SOAP).

Architecture and Technical Specifications of WITSML 1.4

WITSML 1.4 , specifically version WITSML 1.4.1 released in September 2011, represents a significant improvement over previous versions (such as 1.3.1). This version is built on global World Wide Web Consortium (W3C) standards, including XML Schema for defining data structures and Web Services Description Language (WSDL) and SOAP (Simple Object Access Protocol) for communication protocols.

Data Objects in WITSML 1.4.1

WITSML 1.4.1 defines a set of independent but related data objects, each representing a specific type of information related to well operations. These objects are structured using XML Schemas. The most important data objects include:

• Well: General information about the well (name, location, status).
• Wellbore: Information about the wellbore (name, type, direction).
• Log: Measured data over depth or time (e.g., MWD/LWD logging data, geological logging).
• Trajectory: Wellbore path data including depth and 3D orientations.
• MudLog (WellboreGeology): Information about drilling mud and well geology.
• Rig: Information about the drilling rig and its equipment.
• DrillingReport: Daily drilling reports.
• FluidsReport: Reports related to fluid properties.
• SurveyProgram: Wellbore survey program.
• StimJob: Information about well stimulation operations.
• Tubular: Specifications for pipes and drilling strings.
• CementJob: Details of cementing operations.
• And many others, such as Attachment, ChannelSet, WellboreEquipment, RigUtilization, Risk.

Each data object has a hierarchical structure of elements and attributes that contain specific information. WITSML 1.4.1 defines three types of schemas for each data object:

1. Read Schema: For validating the responses of the `WMLS_GetFromStore` operation. All elements and attributes are considered optional.
2. Write Schema: For validating the inputs of the `WMLS_AddToStore` operation. The optional status of unique identifiers may change.
3. Update Schema: For validating the inputs of the `WMLS_UpdateInStore` operation. All elements and attributes except for unique identifiers and unit of measure (uom) attributes are optional.

WITSML 1.4.1 Store Application Programming Interface (API)

The WITSML Store API defines a set of Web Services-based operations that allow client applications to interact with a WITSML server (Store). These operations are as follows:

• WMLS_GetFromStore: This operation is used to retrieve data objects from the Store. The client can specify its request based on the object type (e.g., `log` or `trajectory`), its attributes (using an XML query), and a time/depth range.
  • Parameters:
    • `WML_ObjectType`: The type of data object (e.g., "wellLog").
    • `WML_QueryIn`: The XML query for filtering data.
    • `WML_OptionsIn`: Additional options for the query (e.g., return count, compression).
    • `WML_CapabilitiesIn`: Client capabilities.
  • Output: XML containing the requested data.
• WMLS_AddToStore: This operation is used to add new data objects to the Store.
  • Parameters:
    • `WML_ObjectType`: The type of data object.
    • `WML_XMLIn`: The XML of the data object to be added.
    • `WML_OptionsIn`: Additional options.
  • Output: Operation status (success/failure) and the unique identifiers (UIDs) of the added objects.
• WMLS_UpdateInStore: This operation is used to update existing data objects in the Store.
  • Parameters:
    • `WML_ObjectType`: The type of data object.
    • `WML_XMLIn`: The XML containing the changes and the UID of the object to be updated.
    • `WML_OptionsIn`: Additional options.
• Output: Operation status.

• WMLS_DeleteFromStore: This operation is used to delete data objects from the Store.
  • Parameters:
    • `WML_ObjectType`: The type of data object.
    • `WML_QueryIn`: The XML query to identify the objects to be deleted.
    • `WML_OptionsIn`: Additional options.
  • Output: Operation status and the number of deleted objects.
• WMLS_GetVersion: Used to get the API version supported by the Store.
• WMLS_GetCapabilities: Used to get the specific capabilities of the Store (e.g., supported object types or maximum response size).
• WMLS_GetMessage: Used to get more detailed error messages from the Store after a failed operation.

These operations form the basis for the structured exchange of information between different systems and software in oil and gas operational environments.

Applications and Advantages of WITSML 1.4

The WITSML 1.4 standard, due to its ability to create a standard communication channel for well data, has brought significant advantages to the oil and gas industry:

• Real-time Data Exchange: Enables the transfer of data from the wellsite to headquarters and vice versa in near real-time. This capability is essential for monitoring critical drilling parameters, such as pressure, temperature, rate of penetration, and drilling fluid properties.
• Increased Operational Productivity and Efficiency: With quick access to data, engineers and specialists can make more informed decisions, optimize operations, and prevent incidents. This leads to a reduction in Non-Productive Time (NPT) and cost savings.
• System Integration: WITSML, as a standard communication bridge, enables the integration of different software from various vendors; from data acquisition systems at the wellsite to analysis, simulation, and visualization tools in the office.
• Improved Data Quality and Analyzability: By defining a standard structure for data, it helps improve the quality and integrity of information. Structured data is easily analyzable and processable by intelligent analytical systems (such as data platforms and machine learning tools).
• Risk Reduction: Real-time monitoring of well and equipment status enables the early identification of anomalies and potential risks (such as wellbore instability, mud loss, or unwanted fluid influx), which helps reduce operational risks.
• Automated and Standardized Reporting: Data objects like `DrillingReport` enable the automated generation of daily and periodic reports in a standard format, which helps simplify administrative processes.

Examples of WITSML 1.4 applications include the transfer of Measurement While Drilling/Logging While Drilling (MWD/LWD) data for making decisions on drilling direction, sending drilling fluid property information to fluid engineers, and transferring pressure and temperature data from the bottom of the well to surface operations centers.

Challenges and Limitations in WITSML 1.4 Implementation

Despite its many advantages, the implementation and use of WITSML 1.4 also come with challenges:

• Performance Limitations of SOAP for High-Volume Real-Time Data: Although WITSML 1.4 is known as a "real-time" standard, the use of the SOAP protocol and the request/response model for data exchange can be challenging in scenarios with high data volumes and a need for very low latency. The overhead of XML and SOAP can lead to delays in data transfer. This limitation was one of the main reasons for the development of newer protocols like the Energistics Transfer Protocol (ETP) in subsequent WITSML versions.
• Interoperability Issues and "Dialects": Despite WITSML being a standard, in practice, there may be differences in how the standard is implemented by various vendors (known as "dialects"). This can lead to the need for developing converters or specific configurations for communication between different systems, although WITSML 1.4.1 tried to reduce these issues by providing more precise specifications and the Energistics certification program.
• Data Quality: The quality of input data into the WITSML system, especially when it originates from older sources (such as WITS-0 systems), can be a challenge. Inaccurate or incomplete data can lead to incorrect decisions.
• Lack of Full Standardization in Naming: Although the general data structure is standard, in some cases, the naming of specific parameters (such as log curves) may differ between vendors, which can complicate data display and comparison in dashboards and analytical tools.
• Managing Time and Depth Data: Maintaining data consistency across both time and depth domains, especially after corrections or the addition of new wellbore survey results, can be complex.
• Need for Interface Development and Maintenance: Implementing and maintaining WITSML interfaces requires technical expertise and sufficient resources, especially for companies with older legacy systems.