Operators group proposes data contract addendum to effectively unlock and utilize drilling data

Language submitted to IADC Contracts Committee encompasses QAQC, instrumentation, data storage and transmission, interoperability, data integration

By Dung Nguyen, ConocoPhillips, and Tim Wiemers, Shell Global Solutions (US)

Using Big Data visualization and analysis tools for drilling and completions operations can help personnel to more effectively and consistently unlock the learnings hidden in this overwhelming data set to improve operations (e.g., efficiency, trouble avoidance/mitigation, cost savings) in a more timely manner.

Big Data is not new, but our industry is only in the infancy of tackling it. Issues don’t start with the visualizations and analysis. It starts with how we get the data.

Does it meet our data needs/requirements?

• Instrumentation (accuracy, precision, frequency, reliability);

• Data storage and transmission (completeness, timeliness);

• Data transformation (comparability, consistency); and

• Data interoperability and integration (mnemonics, formatting, time synchronization).

To get to the point where we are using data more effectively to improve operations, we will each have to do our part (operators, rig contractors, service providers, etc). For this endeavor, it is recognized that we don’t have all the answers to current issues and that we won’t fully understand how data requirements will evolve in the future. To address this, systems and processes need to be able to incorporate learnings to continuously improve to meet current and future requirements.

The purpose of this article is to share the data issues/learnings that the Operators Group for Data Quality (OGDQ) has captured and the strategies/requirements behind the data contract addendum being proposed to IADC. The OGDQ is a group of more than 20 operating companies formed in 2014. Its goal is to develop common specifications and to promote standards that will enable process improvement and optimization.

STRATEGY: DATA CONTRACT ADDENDUM

Currently, there is a wide range in operator-defined data requirements depending on data workflows and system capabilities  – more advanced capabilities equate to more defined data requirements. The range varies from operator to operator but also from business unit to business unit for the same operator.

The OGDQ is leveraging the mission statement of the IADC Contracts Committee, which states: “To promote clarity and efficiency in commercial documentation within the global drilling community and foster a wider understanding of contracts and risk management.” The OGDQ is proposing that a data contract addendum would be the optimal method to define data requirements and further this understanding in the global drilling community.

By having a standard data contract addendum, this will:

• Set minimum consistent data requirements and quality of delivery across operators, improving the communication of data expectations/requirements and the ability for contractors to comply due to less variability on foundational data requirements amongst operators.

• Improve shared data learnings across the industry, thereby elevating our industry as a whole and serving as a foundation for the future of automation.

DATA CONTRACT ADDENDUM: SECTIONS

Quality Control/Assurance

Contract excerpt – “CONTRACTOR shall develop and maintain quality control/assurance documentation regarding its internal quality processes/standards for installation, rig-up, operation and maintenance of all EQUIPMENT.”

Key realizations were:

1) We need to understand our proper roles.

a. Operators are responsible for defining requirements with input from contractors.

b. Contractors are responsible for managing their processes/procedures to meet requirements.

c. Operators should not be managing contractor processes/procedures, but operators should be reviewing and providing input on bridging any gaps to meet requirements.

2) We don’t know what we don’t know.

a. We won’t ever have the perfect procedure/process to manage data quality. If we waited until we got it perfect, we may never get started.

b. Requirements will not be static. The systems should allow for adjustments and improvements.

By supporting our contractors’ quality control/assurance program, this will allow for the improvement of processes/procedures from documentation and data capture.

For example, how often should sensor accuracy be verified? (At rig-up? Daily? Every month?) Too seldom can result in inaccurate measurements due to sensors unknowingly drifting out of calibration. Too frequently may incur unnecessary costs and use of time. Striking the optimal balance requires data capture for statistical learning, which reviews can protectively improve through contractor quality processes.

Instrumentation

Contract excerpt – “Calibration and field verification shall be performed according to a schedule set out in CONTRACTOR’s internal quality processes/standards regarding each particular KEY INSTRUMENT.”

Ensuring instrumentation meet application requirements is one of the fundamentals for quality standards, such as ISO 9001, API Q1 and API Q2. With any manufacturing or operational process, how would you know if the process is running per requirements if the data quality from instrumentation is unknown?

Data Storage and Transmission

Contract excerpt – “CONTRACTOR shall transmit data to COMPANY as accurately and securely as practicable in accordance with current industry practice by agreed communications protocol and data standards meeting or exceeding those specified by COMPANY.”

Figure 1 illustrates a conceptual overview of how data may be gathered and transmitted by multiple parties. It is recognized that almost every drilling project incorporates unique data transmission configurations due to various providers and contractors performing different combinations of services and tasks.

The following are the two most common data transmission protocols used in drilling, with their pros and cons. Other data transmission protocols are also available. The selection of a transmission protocol requires an understanding of the application requirements and the transmission protocol capabilities/limitations.

1) Wellsite Information Transfer Specification (WITS)

o The WITS protocol is simple to understand, requires very low bandwidth and can be transmitted and received very near real time with low latency.

o However, the WITS Level 0 version most commonly utilized has limitations, including that it is a one-way-only communication. In the event the communications link goes down, there will be missing sections of data during downtime.

o Since there is only data being transmitted and no units or description information, there must be an offline agreement and full understanding between the sender and receiver regarding the representation of each packet of values.

2) Wellsite Information Transfer Markup Language (WITSML)

o WITSML allows for filling in data gaps in the event of a transmission failure.

o Although the WITSML standard defines the general structure, it does not define the specific names of the objects. Hence, many operators and major service providers have applied their own naming nomenclature to the objects. Thus, when exchanging data between multiple companies, either the sender or the receiver must apply the proper conversion schema in order to correctly translate between each other’s data tag names.

o WITSML has a much higher bandwidth requirement and much greater latency. WITSML would not be suitable for many machine control applications in which latency should be on the order of sub-second, or one second at the longest.

Data Transformation (Derived Data)

Contract excerpt – “CONTRACTOR shall, with the exception of proprietary formulas, make available to COMPANY all information regarding methods of filtering, sampling, smoothing, decimation or other modifications applied.”

Some of the drilling data provided is transformed (or derived) data, which means it is calculated from sensor measurements, such as bit depth, hole depth, rate of penetration (ROP) and weight on bit.

When comparing values (e.g., ROP for offset wells), it is fundamental to understand the basis of calculation in order to ensure a fair comparison is being made. Figure 2 is an example of two methods to calculate ROP for the same data set. Varying assessment of performance may be made:

• Depending on which calculation is used for a selected well;

• And if different calculations are used when comparing performance between wells.

This issue can be present within the same contractor, between contractors and within an operator’s data system.

INTEROPERABILITY AND DATA INTEGRATION

Contract excerpt – “CONTRACTOR shall time-synchronize the setting of all KEY INSTRUMENTS provided by CONTRACTOR used for data aggregation, collection and transmission to a COMPANY-specified time server.”

When combining data from different sources, it is easiest to merge when the data is in the same format and taken at the same time frequency. Complications occur when the data frequency is different and, for time-based data, if the time is offset. Generally, for time offsets, you will need to queue off key distinct events and use data tools to time-synchronize after receiving data. To save all the processing of time syncs after the fact, a proactive approach would be to time-sync data sources prior to data collection.

Contract excerpt – “Mnemonics for data transmission shall be agreed upon between COMPANY and CONTRACTOR for consistency.”

With mnemonics varying within the same contractor, this requires additional manual intervention or additional coding to handle variations for data integration, whether in a spreadsheet or in a database. By agreeing on a mnemonic standard per contractor, this reduces the additional work to correct for identified variations.

Conclusions

By using the proposed data contract addendum, operators will be responsible for defining data requirements/expectations, and contractors will be responsible for managing their systems and having in place a quality documentation and data-processing system to manage and improve delivery. The contract addendum will set the foundation to more effectively unlock and utilize our data.

The contractual concepts detailed in this article represent the collaborative efforts of the authors and the participants of the OGDQ. The data contract addendum is being submitted to the IADC Contracts Committee for review. Review and builds are also being requested from the industry. Future use of the data contract addendum will be the choice of each company. DC