The objective of this research primarily focused on creating a stuck pipe prediction computer model using machine learning to evaluate stuck pipe risks during a drilling operation. This research intended to build prediction models using two machine learning algorithms, namely, the artificial neural network (ANN) and support vector machine (SVM). The final models were expected to predict cases as stuck or non-stuck. The prediction capabilities and accuracies of the generated models were to be compared to determine the best prediction model. The ultimate goal was to use the prediction model to reduce the occurrence of stuck pipe events and hence the non-productive time (NPT). Lowering the NPT would have a positive impact for controlling the drilling operation costs. There are three types of machine learning, namely, supervised learning, unsupervised learning and reinforcement learning. The nature of this research fulfills the criteria of supervised learning. The data sets collected were labelled as either stuck or non-stuck cases. With the labelled data, the machine learning algorithms (ANN and SVM) would try to uncover the underlying pattern of stuck pipes by examining the data sets. During the training process, direct feedback was given to the model to indicate whether the predicted results from the model matched with the actual cases. The model took note of incorrect predictions and reiterated the training process to improve the prediction accuracy. The finalized model was expected to be able to predict stuck pipe events with the inputting of new data sets. Below is the detail of the planned steps in conducting this study. ANN models are effective in handling data with noise, mimic neural networks, perform better than regression based models and accurately predict highly non-linear parameters [
30]. In the past, statistical/regression-based models have shown accurate prediction for a lower number of parameters having linearity [
31,
32]. As the present study involved a large number of non-linear parameters, the advanced statistical approach of machine learning was adopted to accurately predict stuck pipes to reduce the non-productive time (NPT).
3.1. Data Sourcing and Gathering
Machine learning is usually associated with the term “big data”, a term that refers to large volumes of data. Previously, people extracted useful information from these big data through classification and sequence analysis. However, the emergence of machine learning has allowed users to tap big data and identify hidden patterns and unknown correlation unbiasedly. Machine learning can train a predictive model by taking advantage of the sheer volume of data. This translates to a more generalized trained model that is able to predict different scenarios. In this research, the stuck pipe data set was collected using the Data Analyzer software. The software can be used to perform data querying to systematically pull data from the database. The database contains all the drilling operation data, including but not limited to daily drilling report operation details; daily drilling fluid properties; the Bottom Hole Assembly (BHA) specification; bore-hole conditions such as the inclination, azimuth, bore-hole diameter, Measured Depth (MD) and True Vertical Depth (TVD); the casing Outer Diameter (OD) and Inner Diameter (ID); and operating conditions such as the flow rate, rotational speed and rate of penetration (ROP). Instead of going through all the well documents such as the Notice of Operation (NOOP), Daily Drilling Report (DDR), Final Well Report (FWR), well trajectory and Stuck Pipe Review Report manually to extract the necessary information, pulling data using Data Analyzer is deemed more efficient and less time consuming. On top of that, most of the aforementioned well documents are not readily available and required repeat browsing through various sources such as shared common drives or the Well Files Center to collect them. With that in mind, the data extraction in this study was performed mainly by utilizing the Data Analyzer software. The documents from the wells were used as a secondary source for data for quality assurance/quality control (QA/QC) and cross-checking should there have been any discrepancy among the data collected with the Data Analyzer software. Apart from that, missing data could also be filled in using the information from the well documents.
The data gathering process was divided into two parts, which were gathering stuck data and gathering non-stuck data. Stuck data collection began with obtaining the list of the well names that contained the “PFP” code in the activity codes column. An activity code was assigned for every well activity recorded inside a daily drilling report. An activity code was used to categorize the type of well activity. In the case of stuck pipes or stuck tools, the “PFP” activity code, which was categorized under NPT activity codes, was to be assigned to that particular well activity. By searching for all the wells that contained the “PFP” activity code, a list of wells that experienced stuck pipes/tools could be identified. The activity code “PFP” was classified under the “HOLP” impact code, which represented NPT due to a “Bore-hole Problem”. The next step was gathering all the predetermined drilling parameter data that were related to the causes of stuck pipes based on the well names on the list. However, it should be noted that not all the wells that contained the “PFP” code experienced stuck pipes due to drilling operations that employed “unsuitable” drilling parameters that potentially led to stuck pipes. For example, some of the “PFP” activity codes highlighted stuck tools while wire line operations were being run. These kind of data were filtered out, since our research focus was on the drilling-related stuck case.
Table 1 presents all the well activities with the “PFP” activity code that were filtered out and would not be collected as part of the data sets.
After confirming that a well had encountered a drilling-related stuck pipe, the drilling parameters that the well was subjected to were collected. In order to capture the drilling condition that potentially caused the stuck pipe case, the drilling parameters on the stuck day, which is for the first “PFP” activity code, and the drilling parameters 2 days prior to the stuck pipe event were collected. In total, 3 days’ worth of drilling data were collected for any particular stuck pipe case that was drilling related. However, during the process of data collection, it was observed that a lot of the drilling data on the day of the first “PFP” activity codes were not complete or irrelevant. If a stuck pipe occurred relatively late that day, it was possible for a full set of drilling data to be obtained. However, if the stuck pipe occurred relatively early on that day, the drilling data may have been irrelevant because the recorded data were the drilling parameters that the well experienced during the efforts to free the stuck pipe, which are not from drilling operation. Hence, for any stuck pipe case, the number of data sets could range from one to three sets.
Using the Data Analyzer software, the drilling parameters data sets were extracted out batch by batch using several different queries. There initial idea was to extract all the drilling parameters in a single query so that all the data could be presented in a single table. This could facilitate the processing of the data sets later on as one could omit the process of cross checking within several tables of data. However, upon closer examination of the data structure of the drilling database, it was suggested that a single query could not be used to extract all the drilling parameters in single table. For example, a single day of daily drilling report (DDR) may contain up to 30 activity codes, but usually, only a single set of drilling fluid data was available for any single day of drilling operation. Additionally, BHA specification records are not tabulated on a daily basis and are only recorded whenever there is change of BHA during the drilling operation. Hence, it was rather difficult to extract all of the data at once in just a query. The way forward in light of this challenge was to extract the data separately through several queries.
Table 2 shows the summarized drilling parameters recorded in the master list. This list shows the initial proposed drilling parameters to be collected. Based on the data quality and data completeness, the data quality pass column assigns a “Y” or “N” to label each row of data.
For gathering non-stuck data, the “DRL” activity code is used. The “DRL” activity code is assigned to well activities that are related to drilling or sidetrack drilling. Any well that does not have the “PFP” activity code could be a target well for gathering non-stuck data. Since the data scarcity lay in stuck data and not with the non-stuck data, greater flexibility could be allowed in gathering non-stuck data. The stuck data were gathered from any wells in the database of an identified drilling operator that bore the “PFP” activity code regardless of the year of drilling, since the stuck cases were rarer that the non-stuck case. To the contrary, the non-stuck data were to be gathered from the wells with no “PFP” activity code, which were drilled from the year 2016 to the year 2019. This is because the data quality and completeness are generally improved with the latest data record as observed during the process of gathering non-stuck data. Furthermore, data records that were not complete or doubtful could be simply filtered out, as abundant non-stuck data were collected. In the case of stuck data, 3 days’ worth of drilling data prior to and during the pipe stuck event were taken, but one drilling data set was taken for each bore-hole section for non-stuck data. For example, a well that drilled 17.5”, 12.25”, 8.5” and 6” bore-hole sections would have four data records. The purpose behind this was to have more data variety included in the data sets so that the machine learning model could be trained to be more generalized in terms of its predictive capability. At the end of data gathering, a total of 111 wells are identified as having the “PFP” activity code. There were 50 wells remaining after filtering out the wells that had non-drilling-related “PFP” activity codes. Stuck data were to be collected from these 50 wells. On the other hand, for the non-stuck data, a total of 82 wells that were drilled between the year 2016 and year 2019 were identified as target wells. As mentioned before, a few data rows could be extracted from any particular well, be it a stuck or non-stuck well. The final number of a data row could only be determined after the collected data were subjected to a data cleaning process, where the data integrity, quality and completeness were examined.
3.2. Data Review, Cleaning and Preparation
After extracting stuck and non-stuck data with the Data Analyzer software, the drilling parameter data rows were tabulated in Excel format. Although some basic filtering was performed on the raw data to remove unqualified data, the extracted data values were not thoroughly examined. Hence, the next step was to check for data quality and completeness. The percentage of data completeness was measured using Equation (1).
Upon checking for overall data completeness, it was found that several data columns such as “calcium (ppm)” and “Cl- (ppm)” had relatively low data completeness. Their data completeness was measured to be 38.89% and 61.11%, respectively, for stuck data and 19.78% and 26.92%, respectively, for non-stuck data. Hence, it was decided that these two data columns would not be dropped as inputs for machine learning training because the drilling parameters were no longer representative with such high missing data points. Apart from that, the data completeness of “Filtrate, American Petroleum Institute (API) (cc/30min)” and “Filtrate (API) (cc/30min)” were also not high, comparatively. Their data completeness was measured to be 65.87% and 55.56%, respectively, for stuck data and 34.62% and 75.27% respectively, for non-stuck data. However, upon further investigation, it was discovered that for most of the synthetic based muds (SBM) used in drilling, only high-temperature high-pressure (HPHT) filtrate loss tests were conducted, not API filtrate loss tests. The same happened for WBM drilling mud, where only API filtrate loss tests were generally conducted and not HPHT filtrate loss tests. This explained their low data completeness. In order to rectify this problem, it was decided to combine these two data columns into one. For SBM drilling mud, HPHT filtrate loss was used, while for WBM drilling mud, API filtrate loss was used to populate the combined data column. Although putting API and HPHT filtrate test values into a single data column seems to be counter-intuitive because their lab testing parameters are different, their difference would be captured by the machine learning model training with the introduction of a data column that indicated the type of mud used. Next, a check was performed on the solid %, water % and oil % data column. In an ideal situation, these three columns should add up to 100%. Some of the data rows record solid % separately from water % and oil %, which results in total values exceeding 100%. An example of a defective data record may have 23% solids, 70% water and 30% oil. In this case, Equations (2) and (3) were applied on the water % and oil % to scale them proportionally so that the sum of solid %, water % and oil % was 100%.
Besides that, it is worth mentioning that TVD was excluded as an input for machine learning model training. This is because the database of the operator has data corruption in all the depth-related data such as for the MD and TVD. Any attempt to query depth-related data with the Data Analyzer software caused the software to crash. At the beginning of data collection using the Data Analyzer software, it was difficult to troubleshoot the problem of the software crashing. Eventually, it was possible to pin down the root cause of the software crashing, which was the querying of corrupted depth-related data. Although the depth-related data could not be extracted directly from the Data Analyzer software, we were able to compile the data column for “MD” by manually reading through daily operation summaries extracted with the Data Analyzer software; the mentioned drilled depth could be taken as the “MD” data point. The daily operation summary usually only mentioned the drilled depth (MD) and lacked TVD information. This resulted in rather low data completeness in the TVD data column, with 24.6% for stuck data and 2.75% for non-stuck data. Despite best efforts to extract all the depth-related data, only the “MD” data column had the necessary data completeness to fulfill the machine learning model training requirements. The lack of TVD data might not be as critical where the inclusion of MD and inclination data are able to compensate the loss of TVD information to a certain extent. MD was extracted from the operation summary in the Daily Drilling Report (DDR). The DDR is in PDF format whereas the Excel sheet is the output format for queries from the Data Analyzer software. Furthermore, the differential pressure data column was excluded from the training inputs list because the key components to calculate it were absent. Differential pressure can be calculated by finding the difference between the hydrostatic pressure of the drilling fluid and the formation pressure. Drilling mud hydrostatic pressure can be calculated using Equation (4).
Since TVD data were not available, the drilling mud hydrostatic pressure could not be calculated. Moreover, the formation pressure measurement was not taken at all depths during drilling operation. The only possible way to obtain the formation pressure at any particular depth is to get it from the Pore Pressure Fracture Gradient (PPFG) graph, which is at best only an estimation. Differential pressure is one of the vital parameters in measuring differential sticking, and it would definitely have been useful to include it in the model training. However, a check on the collected data showed that only 8 out of the 50 wells that experienced stuck pipes had differential sticking. In other words, only 16% of the stuck pipes were due to differential sticking. If the non-stuck data were factored in, the differential sticking data portion was further reduced. The data sets for differential sticking were too small compared to the mechanical sticking and non-stuck data, and hence, the benefit of including differential pressure as a model training parameter was miniscule. This is also the reason why the scope of the machine learning model changed from predicting differential sticking, mechanical sticking and non-stuck cases to predicting stuck and non-stuck cases.
Table 3 shows a list of the drilling parameters to be inputted into the training model. Nineteen drilling parameters were finalized after taking the above-mentioned issues into consideration.
Noise and outlier in data sets will introduce errors and interfere with the model training. The training of a model might be skewed, which can result in the inability of the model to predict accurately. Hence, the data values need to be evaluated before they are ready to be used for model training. Data evaluation is performed to check for any erroneous or erratic values that do not make sense from an engineering perspective. For each data column, the inspection starts at the minimum and maximum values because illogical numbers usually appear at the extreme ends of the value ranges. Examples of invalid data values are a 3335 gpm flow rate, 450 rpm rotation speed and 4908 ft BHA length, just to name a few. These unacceptable data values were corrected by cross-checking with other sources of information, primarily, the operation summary. In some cases, invalid data values that were extracted with the Data Analyzer software were removed. The last step of preparing the data sets was converting qualitative data columns such as mud type and stuck/not stuck condition to binary format so that the data set was readable by the machine learning programming software. For the mud type data column, 1 was assigned to all WBM, while 0 was assigned to all SBM data points. For the stuck/no stuck condition, 1 was assigned to all stuck data, while 0 was assigned to all non-stuck data. At the end of the data review, cleaning and preparation process, 123 rows of stuck data and 145 rows of non-stuck data had been successfully collected. In total, 268 rows of data set were to be used in machine learning model training and testing.
3.5. Prediction Model Fine Tuning
The ANN and SVM prediction base models were subjected to further fine tuning to improve their prediction performance. Sensitivity analysis was conducted on these base models to identify the best configuration of a machine learning architecture. For the ANN model, sensitivity analysis was conducted based on different activation functions. Another ANN model was built using the hyperbolic tangent activation function. The same 3-hidden-layers network topology was used with each hidden layer consisting of a maximum of 10 neurons. All possible combinations of neuron numbers in each layer were tested; hence, another 1000 training models were produced at the end. For the SVM model, sensitivity analysis was conducted by altering the kernel functions from the “vanilladot” Linear kernel function to the Radial Basis kernel function and Polynomial kernel function. Apart from that, the regularization factor (
C) and hyper-parameters such as the polynomial degree (
D) and sigma (
σ) were also adjusted to create a variety of case studies to test for the potential of the SVM model. As for the ANN model, all possible combinations of the regularization factor (
C) and hyper-parameters were tested. The ranges of the regularization factor (
C), sigma (
σ) and degree (
D) used in this sensitivity analysis are summarized in
Table 7.
In summary, for the linear kernel function SVM model, by varying the regularization factor (C), a total of six models were produced at the end. For the radial basis kernel function SVM model, by varying the regularization factor (C) and sigma (σ) to form different combinations, a total of 30 models were produced. For the polynomial kernel function SVM model, by varying the regularization factor (C) and polynomial degree (D) to form different combinations, a total of 30 models were produced. In total, 66 models were produced for the sake of performing sensitivity analysis on the SVM model. In the ANN model case, each activation function was used to produce 1000 models. Hence, by having two different activation functions, which are the logistic activation function and hyperbolic tangent activation function, a total of 2000 models were produced. At the end of the sensitivity analysis, the prediction results from all these models were collected and tabulated. By examining all the results, the best machine learning configuration could be determined for both the ANN and SVM models. The results also give an insight into the potential for improvement through the fine tuning of the base models.