There’s been much talk about data quality, and we thought it was time to explain its value and impact with some real-world examples. We’ve performed data quality on thousands of wells in the US on land, offshore, and onshore. We’ve concluded that you must deploy smart data quality algorithms complemented by a data quality management services team with petroleum engineering staff, 24×7 to ensure analytical results are trustworthy.
We hear a lot of noise in the market about how AI can magically automate and fix all your data quality issues whether on the edge or in the cloud. The more high-resolution data you gather —often described as volume-of-data—the more AI is expected to fix your data issues. While that may be true tomorrow, we haven’t seen that today. We’ll share some real-world cases to explain why.
Let’s focus on one example of decreasing connection times which has a quick pay off for operators. Today, pipe connections are performed daily while drilling. The old way of recording each connection and sending the data in a PDF report is a thing of past. This process has been replaced by smart algorithms which are based on incoming raw data that can calculate details of the connection i.e., slip to slip, bottom to slip, and slip to bottoms as they happen automatically. Many startups and rig contractors claim they can calculate the connection times in real-time with high accuracy. Can they? We will let you judge.
Regardless of the data source, Rig PLC, electronic data recorder, and office WITML server/data aggregators, many things can go wrong between the source and destination of data flow when you are pulling high-resolution data. The quality of data can alter the accuracy of results which operators use to make decisions.
On paper, it seems easy. Get the source of data, apply the smart algorithms to calculate connection details, build some smarts to cancel the noise, and present via visualization the connection details. Right? Unfortunately, wrong! Our experience has found many possible issues which can occur with data quality that can throw off even the best algorithms acting on their own, whether in the office or at the edge. We’ll illustrate with a case study one of such issue with incoming raw data used to automatically calculate connections and the data quality issue it poses.
As you receive high-resolution data from any data source, you see depth jumps defined as abrupt change hole depth values during active drilling activity.
In this case, data provided from EDR (Electronic Data Recorder) had hole depth jumps of around 60 to 70 feet of data in the surface section of the well, which was affecting the depths these connections were recorded. The streamed data resulted in an offset between depths where connections were actually made on the rig floor to the depths showing in the office.
A smart algorithm could identify the depth jumps, and even in some cases fix it automatically but not every time. Why is that? There are multiple scenarios. Every depth jump might not refer to a footage gain or actual drilling activity. It might be a faulty sensor, or a lack of crew awareness to calibrate sensors on site while lowering each strand of drill pipe, or a communication loss from the rig floor to the office environment. The consequence of any of these reasons results in incorrect connection depths recorded and inaccurate analysis of connection times of the rig crew.
Any predictive analysis model needs the input of raw data from EDR to pass through a decision matrix of Yes or No for any desired outcome. Since the range of communication and data quality issues have an immensely greater wavelength and varying frequency of occurrence, a specific algorithm may not be able to cater to a smooth data curve. As a result, the outcome may be inaccurate and not reliable enough.
In this scenario, even after correcting the problem, the algorithm still showed connections that were made at depths which were misleading and inaccurate.
|Depth Without DQ (ft)||295||409||508|
|Depths with Data Quality Checks (ft)||264||351||439|
An algorithm could identify the depth jumps due to a sharp increase in depth; however, to replicate the drilling sections on the bottom activity on a rig, human intervention is inevitable. Our RTOC data quality team experts applied some of the help at this point, and in this case, helped regained the footage lost due to depth jumps and recalculated the depths at which connections were made. Data quality analysis of the flagged areas of interest showed the actual validated connection depths were 50 ft off. Can you imagine the poor decisions this can lead to if an engineer is using these results to make a decision?
This is just one of many possible data quality issues that can affect the accuracy of automated connection time analysis. To learn more how we address hundreds of poor data quality issues proactively to ensure accurate decision making, visit us at www.moblize.com.
by Amit Mehta and Vivek Kesireddy