Rod pump failure prediction based on wellsite machine learning

Abstract

Systems and methods for real-time monitoring and control of well operations at the well site utilize machine learning (ML)-based analytics. These systems and methods perform ML-based analytics directly at the well site via edge devices on data from the well site to detect operations deviating from expected specifications and automatically respond to such anomalies. Edge devices can issue alerts regarding anomalies and take predefined steps to mitigate potential damage from such anomalies. Edge devices can also perform ML-based analytics on operational data from the well site using normal operating data to predict failures and failure times. This helps reduce downtime, minimize productivity and cost losses, and reduce health and safety risks to field personnel.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefits and priorities of U.S. Provisional Application No. 62 / 899,737, filed September 12, 2019, and U.S. Provisional Application No. 63 / 059,702, filed July 31, 2020, which are incorporated herein by reference in their entirety. Technical Field

[0003] This disclosure relates to monitoring oil and gas wells to ensure their proper functioning, and more specifically to methods and systems for using machine learning (ML)-based analytics at the well site to monitor and control well operations in real time to detect abnormal operating conditions. Background Technology

[0004] Oil and gas wells are typically used to extract hydrocarbons from underground formations. A typical well site consists of a wellbore drilled into the formation and a section of tubing or casing anchored in place within the wellbore to stabilize and protect it. The casing is perforated at a target depth within the wellbore to allow oil, natural gas, and other fluids to flow from the formation into the casing. The tubing extends downwards along the casing, providing a conduit for the oil and gas to flow upwards to the surface where they are collected. If there is sufficient pressure in the formation, oil and gas can flow upwards naturally along the tubing, but pumping equipment is usually required at the well site to bring the fluids to the surface.

[0005] Because of their remote locations, oil and gas wells often operate unattended for extended periods. During these intervals, numerous environmental and other factors can affect well operation. When problems arise, field personnel typically need to travel to the well site to physically inspect the equipment and perform any necessary repairs. This can be a costly and time-consuming undertaking, resulting in lost productivity and profitability for well owners and operators, and may also pose hazards to field personnel.

[0006] Therefore, although much progress has been made in the field of oil and gas production, it is easy to understand that continuous improvement is needed. Summary of the Invention

[0007] This disclosure relates to systems and methods for real-time monitoring and control of well operations at a well site using machine learning (ML)-based analytics. The system and methods perform ML-based analytics on operational data from the well site via an edge device directly at the well site to detect operations deviating from predicted specifications and automatically respond to such anomalous operations. The edge device can issue alerts regarding anomalous operations and take predefined steps to mitigate potential damage caused by such anomalous operations. The edge device can also perform ML-based analytics on operational data from the well site using normal operational data to predict failures and failure times. This helps reduce downtime, minimize productivity and cost losses, and reduce health and safety risks to field personnel.

[0008] Typically, in one aspect, this disclosure relates to a method for monitoring well site operations. The method specifically includes receiving well site data from a remote terminal unit (RTU) at the well site and performing machine learning (ML)-based analysis on an edge device at the well site using the well site data from the RTU. The method also includes identifying one or more dynagraph classifications on the edge device for well site operations from the ML-based analysis, and initiating response actions on the edge device based on the one or more dynagraph classifications. Response actions include at least one of recording the date and time, sending an alarm message to the control system, adjusting the motor speed of a rod pump, or shutting off the power to the rod pump, depending on the severity of the one or more dynagraph classifications.

[0009] Typically, in another aspect, this disclosure relates to an edge device installed at a well site and operable to monitor well site operations. The edge device particularly includes a processor and a storage device coupled to the processor. The storage device stores computer-readable instructions thereon for well site monitoring and control applications, which, when executed by the processor, cause the edge device to receive well site data from a remote terminal unit (RTU) at the well site and perform machine learning (ML)-based analysis on the edge device at the well site using the well site data from the RTU. The well site monitoring and control applications further enable the edge device to identify one or more dynamometer card classifications on the edge device for well site operations from the machine learning-based analysis, and initiate response actions on the edge device based on one or more dynamometer card classifications. Response actions include at least one of recording the date and time, sending an alarm message to the control system, adjusting the motor speed of the rod pump, or shutting off the power to the rod pump, depending on the severity of the one or more dynamometer card classifications.

[0010] In one or more embodiments, well site operations include manual lift operations performed by a rod pump assembly at the well site, and well site data includes images of dynagraphs obtained from the rod pump assembly at the well site.

[0011] In one or more embodiments, performing ML-based analysis includes inputting well site data into one or more ML models, and performing ML-based analysis further includes inputting the outputs from each of the one or more ML models into at least one ensemble model.

[0012] In one or more embodiments, historical data is used to train one or more ML models and combined models, and historical data is used to generate enhanced training data.

[0013] In one or more embodiments, identifying one or more indicator chart categories includes providing a probability for each of the one or more indicator chart categories, and the one or more indicator chart categories include one or more of the following: "fluid impact", "gas disturbance", "air lock", "normal", "plunger jam", "solid abrasion" and "pump wear".

[0014] In one or more embodiments, an operator is allowed to accept or reject each of one or more indicator diagram classifications, to provide an alternative indicator diagram classification for each of the rejected one or more indicator diagram classifications, and to perform transfer learning using the alternative indicator diagram classifications provided by the operator.

[0015] Generally, in another aspect, this disclosure relates to an edge device installed at a well site and operable to monitor well site operations. The edge device particularly includes a processor and a storage device coupled to the processor and storing computer-readable instructions thereon for well site monitoring and control applications. According to one or more embodiments disclosed herein, well site monitoring and control applications enable the edge device to monitor well site operations.

[0016] Generally speaking, in another aspect, this disclosure relates to a non-transitory computer-readable medium containing program logic that, according to one or more embodiments disclosed herein, performs well site monitoring operations when executed by operations of one or more computer processors.

[0017] Generally speaking, in another aspect, this disclosure relates to a method for predicting failure modes at a well site. The method specifically includes receiving dynamometer cards from a remote terminal unit (RTU) at the well site, and performing machine learning (ML)-based analysis on an edge device at the well site using the dynamometer cards from the RTU. The method also includes identifying dynamometer card classifications on the edge device for well site operations from the ML-based analysis performed on the dynamometer cards, and performing ML-based analysis on the edge device at the well site using the dynamometer cards and dynamometer card classifications. The method further includes estimating failure modes and failure times on the edge device at the well site based on the ML-based analysis performed on the dynamometer cards and dynamometer card classifications, and initiating response actions on the edge device based on the failure modes and failure times. Response actions include recording the date and time, sending an alarm message to the control system, adjusting the motor speed of a rod pump, or shutting off the power to the rod pump, depending on the severity of the failure mode and failure time.

[0018] Generally speaking, in another aspect, this disclosure relates to an edge device installed at a well site and operable to predict failure modes at the well site. The edge device particularly includes a processor and a storage device coupled to the processor. The storage device stores computer-readable instructions thereon for performing a failure prediction function. When executed by the processor, the failure prediction function causes the edge device to acquire a dynamometer card and dynamometer card classification of the well site, and to perform a machine learning (ML)-based analysis using the dynamometer card and dynamometer card classification. The failure prediction function also causes the edge device to estimate failure modes and failure times based on the ML-based analysis performed on the dynamometer card and dynamometer card classification. The failure prediction function further causes the edge device to initiate response actions based on the failure mode and failure time. Response actions include at least one of recording the date and time, sending an alarm message to the control system, adjusting the motor speed of the rod pump, or shutting off the power to the rod pump, depending on the severity of the failure mode and the failure time.

[0019] Generally speaking, in another aspect, this disclosure relates to a method for predicting failure modes at a well site. The method specifically includes obtaining a dynamometer card classification of the well site at a perimeter device, and performing a machine learning (ML)-based analysis on the perimeter device using the dynamometer card and the dynamometer card classification. The method also includes predicting failure modes and failure times at the perimeter device based on the ML-based analysis performed on the dynamometer card and the dynamometer card classification, and initiating response actions on the perimeter device based on the failure modes and failure times. Response actions include at least one of recording the date and time, sending an alarm message to the control system, adjusting the motor speed of a rod pump, or shutting off the power to the rod pump, depending on the severity of the failure mode and failure time.

[0020] In one or more embodiments, the shape of the dynamometer associated with the failure mode is predicted on the edge device of the well site based on ML-based analysis performed on the dynamometer and dynamometer classification.

[0021] In one or more embodiments, performing ML-based analysis using indicator diagrams and indicator diagram classification includes performing ML-based analysis on a predetermined number of consecutive indicator diagrams. In one or more embodiments, the predetermined number of consecutive indicator diagrams all have a normal classification.

[0022] In one or more embodiments, predicting the failure mode includes predicting one of the following: fluid impingement failure or gas disturbance failure.

[0023] In one or more embodiments, performing ML-based analysis using dynamometer chart classification includes inputting the dynamometer chart classification data into one or more ML models. In one or more embodiments, training one or more ML models using historical data further includes generating enhanced training data using the historical data.

[0024] Generally speaking, in another aspect, this disclosure relates to an edge device installed at a well site and operable to predict failure modes at the well site. The edge device particularly includes a processor and a storage device coupled to the processor and storing computer-readable instructions thereon for performing a failure prediction function. According to one or more embodiments disclosed herein, the failure prediction function enables the edge device to predict failure modes and failure times at the well site.

[0025] A non-transitory computer-readable medium containing program logic, which, when executed by the operation of one or more computer processors, performs failure mode prediction at a well site according to one or more embodiments disclosed herein. Attached Figure Description

[0026] A more detailed description of the present disclosure, which has been briefly summarized above, can be obtained by referring to various embodiments, some of which are illustrated in the accompanying drawings. Although the drawings illustrate selected embodiments of the present disclosure, they should not be construed as limiting its scope, as the present disclosure may acknowledge other equally effective embodiments.

[0027] Figure 1 An exemplary well site deployment based on ML-based analytics according to an embodiment of the present disclosure is illustrated;

[0028] Figure 2 The illustration shows a block diagram of an exemplary edge device capable of performing ML-based analytics according to embodiments of the present disclosure;

[0029] Figure 3 A series of exemplary indicator diagram classifications according to embodiments of the present disclosure are shown;

[0030] Figure 4 An example of a HOG transformation indicator diagram according to an embodiment of this disclosure is shown;

[0031] Figure 5 An exemplary software architecture for deploying ML-based analytics to edge devices according to embodiments of the present disclosure is shown;

[0032] Figure 6 An exemplary workflow for identifying dynamometer diagrams using ML-based analytics, according to embodiments of the present disclosure, is shown.

[0033] Figure 7 The illustrations depict exemplary classifications according to embodiments of the present disclosure;

[0034] Figure 8 An exemplary indicator diagram evolution presentation according to embodiments of the present disclosure is shown;

[0035] Figure 9 An exemplary outline of indicator diagram classification according to embodiments of the present disclosure is shown;

[0036] Figure 10 An exemplary user feedback interface according to an embodiment of this disclosure is shown;

[0037] Figure 11 An exemplary workflow for implementing well site ML-based analysis according to embodiments of the present disclosure is shown;

[0038] Figure 12 An exemplary flowchart illustrating the implementation phases of ML-based analytics on an edge device, according to some embodiments, is shown;

[0039] Figure 13 An exemplary target definition phase is shown in some embodiments for ML-based analytics to predict future failures at edge devices;

[0040] Figure 14 Exemplary features of data used in some embodiments to predict future failures at edge devices are shown;

[0041] Figure 15 Exemplary fault classifications are shown in some embodiments for predicting future faults at edge devices;

[0042] Figure 16 This illustrates the data issues to consider when using ML-based analytics to predict future failures at edge devices in some embodiments;

[0043] Figure 17 Data is shown in some embodiments that supports the use of a series of continuous dynamometer maps to predict future faults at edge devices;

[0044] Figure 18An exemplary dynamometer evolution is shown, demonstrating the feasibility of using ML-based analytics to predict future failures at edge devices in some embodiments;

[0045] Figure 19 An exemplary flowchart is shown for a method in some embodiments for using ML-based analytics to predict future failures at edge devices;

[0046] Figure 20 Exemplary training data standards for training ML models to predict future failures at edge devices are shown in some embodiments;

[0047] Figure 21 Exemplary model inputs for training an ML model to predict future failures at edge devices are shown in some embodiments;

[0048] Figure 22 Exemplary techniques for sampling indicator maps to predict future faults at edge devices are illustrated in some embodiments;

[0049] Figure 23 This demonstrates how an exemplary ML model can be trained to predict future failures at edge devices;

[0050] Figure 24 An exemplary confusion matrix is ​​shown that can be used to evaluate the performance of a trained ML model;

[0051] Figure 25 Examples are shown in some embodiments of using ML-based analytics at the edge device to predict future failures;

[0052] Figure 26 Exemplary statistics regarding the future failure prediction time of true positives are shown according to some embodiments;

[0053] Figure 27 Exemplary metrics for predicting future failures are shown according to some embodiments; and

[0054] Figure 28 The illustration shows an exemplary instance of ML-based analysis for predicting future failures at an edge device, according to some embodiments.

[0055] Where possible, the same reference numerals have been used to denote common elements in the figures. However, elements disclosed in one embodiment may be advantageously used in other embodiments without specific description. Detailed Implementation

[0056] This description and accompanying drawings illustrate exemplary embodiments of this disclosure and should not be considered limiting. The claims define the scope of this disclosure, including equivalents. Various mechanical, compositional, structural, electrical, and operational changes, including equivalents, may be made without departing from the scope of this specification and claims. In some cases, well-known structures and techniques have not been shown or described in detail to avoid obscuring this disclosure. Furthermore, elements and related aspects thereof described in detail with reference to one embodiment may be included in other embodiments where they are not specifically shown or described, whenever feasible. For example, if an element is described in detail with reference to one embodiment but not with reference to a second embodiment, that element may still be claimed to be included in the second embodiment.

[0057] It should be noted that, as used in this specification and the appended claims, the singular form “a” and any singular use of any word includes plural references unless explicitly and unambiguously limited to a single reference. As used herein, the term “comprising” and its grammatical variations are intended to be non-limiting, such that references to items in a list do not exclude other similar items that may substitute for or be added to the listed items.

[0058] At a high level, embodiments of this disclosure provide systems and methods for using machine learning (ML)-based analytics at well sites to monitor and control well operations in real time. As used herein, the term "analysis" generally refers to the analysis of data and the identification and detection of meaningful patterns within that data. The disclosed systems and methods deploy ML-based analytics directly at an edge device at the well site to detect operations that deviate from predicted specifications and to automatically respond to such anomalous operations. As used herein, the term "edge device" refers to a device designed to provide access to or entry into a network, such as a local area network (LAN), wide area network (WAN), metropolitan area network (MAN), etc. The ability to perform machine learning-based analytics at an edge device offers numerous benefits, especially for remote well sites where the computational resources typically required for machine learning modeling may be unavailable. In this case (and others), performing ML modeling at an edge device allows operators to proactively manage remote well sites. In particular, an edge device equipped with ML-based analytics can automatically detect anomalous operations that may indicate suboptimal production and potential equipment failure, issue alerts regarding the anomalous operations, and take predefined steps to mitigate the potential damage caused by such failures. This helps reduce downtime, thereby minimizing lost productivity and costs, and reducing the health and safety risks to personnel who may have to make unplanned trips to the well site (i.e., reducing “commuting time”).

[0059] The benefits become even more apparent as ML-based analytics are implemented at well sites and the broader movement toward the so-called Industrial Internet of Things (IIoT) takes place. In an IIoT environment, well site operators increasingly leverage interconnected sensors and devices to collect and store vast amounts of data directly at the well site. This data can then be processed at the well site by edge devices equipped with ML modeling to monitor and control well operations. Consider a well site using reciprocating rod pump assemblies for artificial lift to extract oil from the wellbore. During the operation of the rod pump assembly, large amounts of data are typically collected in the form of dynacards or dynamometer charts. Edge devices equipped with ML modeling can process the dynacards in real time and identify when the rod pump assembly may be malfunctioning. The edge device can then generate alerts, execute emergency actions, and store the processing results in the cloud as needed. Once locally generated data is tagged and processed, it can be used to update and further train ML models, debug new edge devices, and generally improve well site operations.

[0060] In summary, embodiments of this disclosure provide methods and systems for developing and deploying robust ML modeling in an IIoT environment to automatically predict failures and suboptimal operations directly at the well site, and also ensure a high level of predictive capabilities through ML-based analytics, thereby increasing operator confidence.

[0061] Now for reference Figure 1 This diagram illustrates an exemplary well site 100 with ML-based analytics capabilities according to an embodiment of the present disclosure. It can be seen that a wellbore 102 has been drilled into the subsurface formation 104 at the well site 100, and a casing 106 has been cemented into the wellbore 102. In this example, the formation 104 no longer has sufficient formation pressure for natural oil production, therefore artificial lift is provided by a reciprocating rod pump assembly 108 installed at the well site 100. The rod pump assembly 108, also known as a horse-head pump jack, typically includes a motor unit 110 containing a variable-speed motor, a gearbox 112, a beam 114, a horse-head 116, a sling 118, a polished rod 120, a tee box 122, and a sucker rod 124, connected as shown. The operation of the rod pump assembly 108 is well known to those skilled in the art; therefore, for economic reasons, other common components such as moving valves, pump barrels, and stand valves are omitted here. Discharge line 126 will transport oil and other fluids produced from wellbore 102 to one or more storage tanks (not explicitly shown) for storage and treatment.

[0062] Control unit 128 at well site 100 collects data on various aspects of well site 100 for monitoring and tracking purposes. Control unit 128 includes a remote terminal unit (RTU) 130 (also called a remote telemetry unit), which collects data on motor operation from motor unit 110, including motor speed and load. This motor data is generated by a motor controller, typically a variable speed drive (VSD) in motor unit 110. RTU 130 also collects measurements from various wireless and wired field sensors (not explicitly shown) around well site 100. These field sensors include proximity sensors mounted near the crank arm of rod pump assembly 108 and load sensors mounted between sling 118 and polished rod 120. Based on this data, RTU 130 generates dynamometer diagrams, each representing a graph or curve of tension or load (vertical axis) on rod 120 versus displacement (horizontal axis) of rod 120 over one stroke or pump cycle (i.e., upward and downward movement). Other data collected by RTU 130 from field sensors may include fluid flow rate, temperature, pressure, etc.

[0063] Edge device 132 in control unit 128 provides network access or an entry point for RTU 130 to transmit collected data to external systems, such as Supervisory Control and Data Acquisition (SCADA) system 134 and / or network 136 (e.g., the Internet). Edge device 132 allows RTU 130 to send and receive data from external systems as needed via communication links (e.g., Ethernet, Wi-Fi, Bluetooth, GPRS, CDMA, etc.). From there, data can be forwarded to other systems within enterprise 138 and / or cloud 140 (which may include a private enterprise cloud) for further processing as needed. Any type of edge device or appliance can be used as edge device 132, provided that the device has sufficient processing power for the purposes discussed herein. Examples of suitable edge devices include gateways, routers, routing switches, integrated access devices (IADs), and various MAN and WAN access devices. According to embodiments of this disclosure, edge device 132 has the capability to perform ML-based analysis on the dynamometer diagram from rod pump assembly 108, as discussed herein.

[0064] Figure 2This is a block diagram illustrating an exemplary hardware architecture 200 for an edge device 132 according to an embodiment of the present disclosure. The edge device 132 shown herein is a gateway. In one embodiment, the edge gateway 132 includes a bus 202 or other communication path for transmitting information within the gateway, and a CPU 204, such as an ARM microprocessor, coupled to the bus 202 for processing information. The edge gateway 132 may also include a main memory 206, such as random access memory (RAM) or other dynamic storage device coupled to the bus 202, for storing computer-readable instructions to be executed by the CPU 204. The main memory 206 may also be used to store temporary variables or other intermediate information during the execution of instructions executed by the CPU 204.

[0065] Edge gateway 132 may also include read-only memory (ROM) 208 or other static storage devices coupled to bus 202 for storing static information and instructions for CPU 204. Computer-readable storage device 210, such as a non-volatile memory (e.g., flash memory) drive or disk, may be coupled to bus 202 for storing information and instructions for CPU 204. CPU 204 may also be coupled via bus 202 to human-machine interface (HMI) 212, such as a touchscreen interface, for displaying information to a user and allowing the user to interact with edge gateway 132 and RTU 130. RTU interface 214 may be coupled to bus 202 to allow RTU 130 to communicate with edge gateway 132. Network or communication interface 216 may be provided to allow edge gateway 132 to communicate with external systems such as SCADA system 134 and / or network 136.

[0066] The term "computer-readable instructions" as used above refers to any instructions that can be executed by CPU 204 and / or other components. Similarly, the term "computer-readable medium" refers to any storage medium that can be used to store computer-readable instructions. Such media can take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Non-volatile media can include, for example, optical discs or magnetic disks, such as storage device 210. Volatile media can include dynamic memory, such as main memory 206. Transmission media can include coaxial cables, copper wires, and optical fibers, including wires for bus 202. Transmission itself can take the form of electromagnetic waves, sound waves, or light waves, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media can include, for example, magnetic media, optical media, memory chips, and any other media from which a computer can read.

[0067] Well site monitoring and control application 220, or more precisely, computer-readable instructions, may also reside on or be downloaded to storage device 210. Well site monitoring and control application 220 may be executed by CPU 204 and / or other components of edge gateway 132 to perform ML-based analysis on dynamometer cards from RTU 130 to automatically detect abnormal operations and generate responses accordingly. This monitoring and control application 220 may be written using any known suitable software development environment in any suitable computer programming language known to those skilled in the art. Examples of suitable programming languages ​​may include C, C++, C#, Python, Java, Perl, etc.

[0068] According to an exemplary embodiment, the well site monitoring and control application 220 may include a data preprocessing module 222, one or more ML algorithms or models 224, and a response action module 226, etc. As the name suggests, the data preprocessing module 224 performs preprocessing (e.g., cleaning, image resizing, saliency mapping, etc.) on the dynamometer diagrams received from the RTU 130 for use by the monitoring and control application 220. The monitoring and control application 220 then inputs the dynamometer diagrams into one or more ML models 224 to determine whether they match or otherwise resemble one or more known dynamometer diagrams. In a preferred embodiment, the monitoring and control application 220 employs combinatorial modeling, where multiple different ML models 224 are combined to achieve more accurate results. Therefore, the combinatorial model is sometimes referred to as a meta-model. Based on the results, the response action module 226 takes appropriate response actions. For example, if the results indicate an abnormality or suboptimal operation, the response action module 226 can take actions ranging from recording the date and time of occurrence, to sending alarm messages to the SCADA system 134 and / or appropriate personnel, to adjusting the motor speed, and shutting off the power to the motor unit 110 (e.g., in the case of a catastrophic failure). The specific response action taken by the response action module 226 depends on the severity of the abnormal operation.

[0069] As an initial step, one or more ML models 224 should be properly trained before they can effectively perform their functions. Training can be performed using self-supervised learning methods, where labeled historical data is used as input to the ML model. Labeling refers to the process of annotating or describing dynamometer maps or specific regions within each dynamometer map and creating labels or tags for these regions. Training can be performed on Cloud 140 or Well Site 100 and may involve developing and validating the ML model using commercially available ML training tools. Developing ML models on Cloud 140 or a computing cluster platform offers additional benefits in terms of the availability of enhanced hardware resources providing high computing power, which can be very useful during the training phase. Data preprocessing and preparation are a critical part of this process, as properly labeled data is required to generate highly accurate ML models.

[0070] As part of data preprocessing for training purposes, historical dynamometer cards are converted into pixelated images. These images are then used to train a general-purpose ML model independent of the lever pump type, in order to extend the ability to train the model to general-purpose dynamometer cards produced by any type of lever pump. Examples of general-purpose ML models that can be trained include convolutional neural networks (CNNs), conjoined neural networks, support vector machines (SVNs), autoencoder neural networks, etc. The model predictions are then aggregated using ensemble modeling techniques, which assign greater weight to the model based on its accuracy for a given problem category. In some embodiments, the model may also be trained using the data points that constitute the dynamometer card instead of the dynamometer card image itself.

[0071] Figure 3 Exemplary dynamometer diagrams, marked at high levels, are depicted, indicating several categories or types of well-known rod pump operating conditions observed by field personnel over time. The types of rod pump operating conditions shown here are: “fluid thrashing,” “gas disturbance,” “gas lock,” “normal,” “plunger jamming,” “solid abrasion,” and “pump wear.” These dynamometer diagrams can be used to train ML models 224 so that they can subsequently determine whether a dynamometer diagram from the well site resembles one of these dynamometer diagrams within a certain probability distribution. Within the scope of this disclosure, other dynamometer diagrams representing other types of rod pump operating conditions can also be used for model training.

[0072] In some embodiments, data augmentation techniques can be used to increase the size of the training set. Data augmentation involves creating new dynamometers using existing labeled dynamometers, thereby increasing the size of the training dataset. Models trained with augmented datasets are generally more robust and can even simplify the model computationally compared to models trained with smaller datasets or fewer examples. Data augmentation takes two or more dynamometers with the same labels and obtains an average dynamometer by averaging the data points of the source dynamometers. The result is that the new dynamometer has the same labels as the source dynamometers that can be added to the training set. This process can be repeated for many combinations of dynamometers for various types of rod pump failures and suboptimal operation. The new dynamometer can be combined with existing dynamometers to generate even more new dynamometers. This data augmentation can produce a large number of additional labeled dynamometers for model training purposes. For example, thousands of new dynamometers can be generated from hundreds of existing dynamometers. The number of dynamometers used to generate new dynamometers can be adjusted as needed.

[0073] The trained ML models 224 are then combined into a combined model, which is evaluated against an additional training set not used in the initial model training phase for validation purposes. The training phase can be repeated as needed for prediction accuracy (i.e., the required QoS) until satisfactory results are obtained. Model performance can be improved by refining data preprocessing techniques (e.g., requiring high-resolution images), increasing the number of labeled indicator cards, etc.

[0074] In some embodiments, one or more ML models 224 may use a data transformation technique called a directional gradient histogram (HOG), such as... Figure 4 As shown. HOG transforms a standard indicator map into a set of feature descriptors that define the indicator map. The HOG transform is well-known and commonly used in computer vision and image processing. For the purposes of this study, HOG allows for the extraction of important information about the indicator map image based on the magnitude of large pixel intensity gradients around the edges. Therefore, the HOG-transformed image is processed as an image feature rather than the original image, as... Figure 4 As shown in the figure, graphs labeled 400 and 402 are standard indicator graphs, while graphs labeled 400' and 402' are the corresponding HOG transformed indicator graphs displaying the feature descriptors. The feature descriptors can then be processed instead of the indicator graph images themselves. Examples of models using the HOG transform include k-nearest neighbors (kNN), the previously mentioned support vector machine (SVN), etc. Generating the aforementioned feature descriptors increases the variability of the input provided to the ML model, which can improve the combinatorial accuracy. Combinatorial accuracy can also be improved by avoiding models that are highly correlated with each other.

[0075] After achieving satisfactory results from the learning phase, the trained and validated ML model 224 can be deployed to the edge gateway 132. In some embodiments, the model is deployed by debugging the edge gateway 132 when it is connected to the RTU 130 (i.e., not connected to the cloud 140). Although the edge gateway has higher processing power than the RTU, the type of ML model that can run effectively on each type of edge gateway 132 should be considered to help provide satisfactory response times for prediction or inference purposes. This helps ensure that the ML model's response time is fast enough to promptly identify any abnormal power cards so that effective action can be taken automatically or by the operator.

[0076] Figure 5This is a block diagram illustrating an exemplary architecture 500 that can be used to deploy ML models on edge gateway 132. The edge architecture 500 in this example uses Microsoft IoT Edge 502, which decomposes local processing between Docker containers 504 onto an Ubuntu core 506 to support embedded constraints. This container-based architecture simplifies deployment but requires a Linux-based gateway capable of running Linux OS variants, and minimal computational resources (i.e., CPU, memory) similar to well-known Raspberry Pi hardware. Container 504 used for dynamometer card prediction in this example includes MODBUS, which implements Modbus communication between RTU 130 and edge gateway 132. This container also collects real-time dynamometer card data from RTU 130 after each pump stroke. AzureML is also included, which converts the dynamometer card into a pixelated image and uses a trained ML model 224 to identify the card's shape. Another container, EdgeAgent, checks hardware integrity and ensures all necessary processes run seamlessly. The EdgeHub container is able to communicate with the cloud platform using a publish / subscribe method (e.g., via the MQTT protocol). Cloud connectivity allows for remote monitoring and management of the edge gateway 132 for maintenance purposes, as well as for tracking the effectiveness and accuracy of ML models, and also enables remote triggering of transfer learning, a process discussed later in this paper. In short, Figure 5 The ML model deployment architecture 500 described herein is suitable for any edge gateway that meets the minimum hardware requirements, and the use of containers 504 to deploy ML models and other related components makes interoperability with different hardware platforms seamless and easy to manage. Those skilled in the art will understand that the invention is not limited to this particular choice and arrangement of containers, and that additional and / or alternative containers may be used within the scope of this disclosure.

[0077] Once the ML model 224 and its supporting components are deployed on the edge gateway 132, real-time inference can begin, with the gateway acquiring dynamometer maps from the RTU 130. The edge gateway 132 receives the dynamometer maps from the RTU 130 as load and displacement data points and uses the preprocessing module 222 of the monitoring and control application 220 to generate pixelated images of the dynamometer maps based on the data points. The preprocessing module 222 further preprocesses these pixelated dynamometer map images, for example, by cleaning the images and normalizing them to a predefined size and format. The ML model 224 on the edge gateway 132 then uses combinatorial modeling to infer the dynamometer map type (see...). Figure 3Specifically, for each cycle of the rod pump (i.e., one indicator diagram), a weighted output is generated indicating the probability that the indicator diagram matches a certain type. The response action module 226 receives this output and takes appropriate action, including immediately flagging the most probable cause of any pump problem to the SCADA system 134, as discussed later. In some embodiments, the output is also provided as feedback to the RTU 130 to issue a flag to the SCADA system 134.

[0078] Figure 6 A high-level workflow 600 is described illustrating the ML-based dynamometer card inference or identification process performed on edge gateway 132 as disclosed herein. Workflow 600 typically begins at stage 602, where dynamometer cards from rod pump assemblies (such as rod pump assembly 108) are input into edge gateway 132. These dynamometer cards then undergo preprocessing, where they can be cleaned and conformed to standardized dimensions, formats, and other criteria. In a typical well site deployment, the rod pump assembly generates dynamometer cards every few seconds based on the pump stroke rate; therefore, edge gateway 132 is preferably able to identify dynamometer cards every few seconds to provide an indication of pump performance in real time.

[0079] In stage 604, the preprocessed dynamometer card is processed through various ML models in edge gateway 132. These ML models can include any of the aforementioned ML models as well as other well-known models, such as CNN, Siamese, AE+FCN (autoencoder + fully connected network), HOG SVN, and HOG kNN (k-nearest neighbors). Each model takes the same preprocessed dynamometer card as input and provides a probability distribution for the dynamometer card type of that model. These probability distributions are then fed into a combined model (i.e., a meta-model), which combines them to provide the final dynamometer card type identification. In some embodiments, there may be two (or more) combined models processing the output from the ML algorithms, depending on the desired level of accuracy. The results from the combined models can then be averaged to provide a more accurate inference.

[0080] At stage 606, the identified dynamometer card type is provided as an output of edge gateway 132. In the illustrated example, the probability distribution of dynamometer card types identifies "fluid shock" as the most likely dynamometer card type, followed by "gas disturbance" with a lower probability, while the probabilities of the remaining dynamometer card types are negligible. This probability distribution can then be displayed on edge gateway 132, for example, on its HMI 212, and provided to SCADA system 134. In some embodiments, edge gateway 132 sends rod pump operating conditions to RTU 130, which correspond to the dynamometer card type with the highest probability.

[0081] Figure 7An exemplary graphical demonstration 700 of the output of the combined model is shown, for example, displayed on an HMI (e.g., HMI212) or other display equipped with the ML-based analytics capabilities disclosed herein. Demonstration 700 shows an indicator diagram classification reflecting the possible operating conditions of a given rod pump assembly over a day, based on indicator diagrams from the rod pump assembly, where the vertical axis represents probability and the horizontal axis represents time. Each graph represents a match or similar... Figure 3 The probability of an indicator diagram falling into one of the indicator diagram categories (within a given QoS) is shown. For example, curve 702 represents the probability of an indicator diagram matching or similar to that of a rod pump assembly experiencing airlock. It can be seen that the combined model has identified a large number of indicator diagrams as having a high probability of being airlock indicator diagrams (especially between 6:00 AM and 9:00 PM) or gas disturbance indicator diagrams. From this demonstration 700, the operator can quickly infer whether the rod pump assembly may have airlock or gas disturbance problems at different times throughout the process.

[0082] Figure 8 Another exemplary graphical demonstration 800 showing the output of a combined model of a given rod pump assembly is provided, for example, displayed on an HMI (e.g., HMI 212) or other display on an edge gateway. This demonstration 800 is... Figure 7 The indicator diagram classification demonstration 700 is an extension of the previous demonstration and displays the actual indicator diagram of a given rod pump at a selected time point. The operator can click on any time point in demonstration 700 and view (e.g., via a pop-up window, a new screen, etc.) the corresponding indicator diagram 802 indicated at 802 in demonstration 800. In some embodiments, the corresponding indicator diagram 802 may be colored (e.g., red) or otherwise highlighted in the indicator diagram demonstration 800. Furthermore, the indicator diagram demonstration 800 also displays several immediately preceding indicator diagrams (e.g., 37 preceding indicator diagrams) overlapping each other. In some embodiments, these preceding indicator diagrams may also be colored (e.g., blue) or otherwise distinguishable. The operator can then cycle through the various indicator diagrams (e.g., via sliders, knobs, etc.) to view the evolution of the rod pump assembly from normal operating conditions to, for example, gas disturbances.

[0083] Figure 9 The outputs of several combined models from several edge gateways equipped with ML-based analytics are combined into a summary demonstration 900, which is displayed, for example, on a SCADA system or operator terminal. Demonstration 900 shows a classification of indicator diagrams reflecting possible operating conditions of several given rod pump assemblies throughout the day, based on indicator diagrams from rod pump assemblies, where the vertical axis represents the number of indicator diagrams (i.e., pump strokes) and the horizontal axis represents individual pumps. Each bar represents the ratio of the indicator diagrams to the strokes of a given rod pump assembly. Figure 3The summary lists the number of indicator diagrams that match or are similar to one of the indicator diagram categories (within a given QoS). For example, a bar marked 902 indicates that nearly 2000 indicator diagrams from rod pump 1 match or are similar to the indicator diagrams of the rod pump assembly experiencing gas disturbances. This summary allows operators to easily identify pumps with specific anomalies for further investigation.

[0084] In addition to the inference process described above for real-time prediction of the current state of the rod pump, in some embodiments, a process called “transfer learning” can also be deployed on the edge gateway 132. This process can be used if the prediction accuracy using a general ML model is deemed insufficient. For example, if the indicator card is unique for a specific pump behavior, the ML model may fail to recognize indicator cards not included in the training phase. As another example, the ML model may not be able to clearly distinguish between two similar indicator card types, such as “gas interference” and “gas lock” indicator cards. In this case, the indicator cards can be locally labeled by a field operator using a locally available HMI. These manually labeled cards can then be used to retrain the model (or parts thereof) to improve the model’s ability to recognize indicator cards that reflect the unique behavior of a specific pump or to better distinguish similar cards.

[0085] Figure 10 A graphical user interface 1000 is depicted, which may be displayed, for example, on an HMI (e.g., HMI 212) or other display on an edge gateway for implementing the aforementioned transfer learning. In this example, the user interface 1000 includes several navigation buttons, generally indicated by 1002, which allow the operator to navigate and otherwise scroll to access various functions available on the edge gateway. A dynamometer diagram area 1004 displays the dynamometer diagram of interest, which may be the current dynamometer diagram or an older one. A pump status area 1006 indicates the type or classification of the dynamometer diagram inferred by the combined model. In this example, the combined model has identified the dynamometer diagram shown in area 1004 as a dynamometer diagram that may match or resemble a rod pump experiencing fluid shock conditions. A description area 1008 provides a brief description of the fluid shock dynamometer diagram classification, and a suggestion area 1010 provides recommended actions or steps for the proposed dynamometer diagram classification. The operator can press the close button 1012 to accept the proposed dynamometer diagram classification, or the operator can press the reject button 1014 to reject the proposed dynamometer diagram category. In the latter case, the operator can label the indicator diagram using his own classification and then associate it with the indicator diagram of interest. Figure 1 The data is stored in the feedback database for later consideration and for model retraining and readjustment.

[0086] Specific embodiments of this disclosure have now been discussed. Figure 11This is a general method in the form of flowchart 1100, which can be used to implement well site-based ML analysis according to this disclosure. The method begins at 1102, where training is performed on one or more ML models already selected for the well site. The ML models may include any ML models discussed above, as well as other well-known ML models, depending on the well site equipment and operations (e.g., manual lift). While not required, combined models that combine the outputs of one or more ML models often provide more accurate results and should also be included and trained. Training can use previously collected, preprocessed, labeled, and stored historical well site data, as shown in 1104. The training data can be data points, or, in the case of rod pump assemblies used in the monitored well site, images of dynamometer charts or dynamometer cards can be used for training. As an optional step, the augmentation data indicated at 1106 can be derived from the historical data 1104 to increase the amount of data or dynamometer charts available for training.

[0087] At 1108, a decision is made to verify whether the trained model can produce sufficiently accurate results within the given QoS. Preferably, validation is performed using data different from the training data. For a negative decision, workflow 1100 returns to model training at 1102 for additional training. If the decision is positive, the trained and validated model is deployed to the well site at 1110. This deployment can be done by bringing an edge device already equipped with the model to the well site and setting it up. Alternatively, if a suitable network connection is available, model deployment can also be performed by downloading the trained and validated model to an edge device already installed at the well site.

[0088] Then, at 1112, the well site data is provided to the edge device for input into the ML model to monitor for anomalies or suboptimal operations at the well site. Data is acquired by the RTU via field sensors at the well site, and the RTU provides the data to the edge device in real time. As mentioned above, in cases of artificial lift or other auxiliary production at the well site, the data may be dynamometer images from the rod pump assembly. In some embodiments, at 1114, the output from the ML model may optionally be provided to the combined model to produce more accurate results. In either case, the final conclusion of the modeling (e.g., dynamometer classification) is output at 1116, typically in probabilistic form. This step may require displaying the conclusions on the edge device's HMI, storing them on local or remote storage or in a database, sending them to an external system (e.g., a SCADA host), and / or uploading them to a cloud computing platform for further processing.

[0089] In some embodiments, workflow 1100 may optionally allow an operator at 1118 to accept or reject a conclusion from the model (e.g., dynamometer classification). If the operator rejects the conclusion, at 1120 he has the opportunity to provide alternative conclusions for the data, for example, based on his real-world experience and observations. In some embodiments, any such operator feedback may be used during transfer learning at 1122 to improve the model's accuracy. Alternatively, the edge device may automatically take a response action at 1124 based on the conclusion from the model. Such response actions can range from simply recording the date and time, to sending an alarm message to the SCADA host, to adjusting motor speed or shutting off the power to the lever pump assembly when a catastrophic failure is identified. As previously mentioned, the specific response action the edge device is programmed to take may depend on the severity of the dynamometer classification. Thus, for example, a "fluid shock" classification might cause the edge device to send an alarm message only to the appropriate system or personnel, while a "plunger jam" classification might cause the edge device to send an alarm message and shut off the lever pump assembly.

[0090] In some embodiments, the dynamometer diagram classification output at 1116 can be further processed and used to predict future pump failures. Therefore, in addition to outputting the dynamometer diagram classifications to local or remote storage devices or databases, sending them to external systems, etc., the classification and basic dynamometer diagrams can be further output or otherwise provided to one or more additional ML models on the edge device to predict future failures. These additional ML models (which may be included in ML model 224) can be trained to predict anomalous operation at some future time (e.g., minutes, hours, days, etc.) based on the classification and basic dynamometer diagrams. The process of implementing ML-based analytics on the edge device to use dynamometer diagram classification to predict future failures, and the process of implementing ML-based analytics on the edge device to classify dynamometer diagrams, are similar, as... Figure 12 As discussed in the article.

[0091] Figure 12Flowchart 1200 illustrates an overview of the stages involved in implementing ML-based analytics on an edge device. The process begins with a goal definition phase 1202, where specific goals or objectives for the ML-based analytics are defined. Goals can be business goals (e.g., identifying consumer preferences) or technical goals (e.g., predicting system failures), or a combination of both. Once one or more goals are defined, analysis is performed on the data available to achieve those goals through a data analysis phase 1204. The data analysis phase determines whether the available data is, or includes, a data type that an ML model can process to achieve the goals. After analyzing the data, an initial dataset is prepared in a data preparation phase 1206 for training the ML model to achieve the goals. This data preparation phase includes labeling and annotating the data or certain features of the data that are important for achieving the goals. This phase is followed by a modeling phase 1208, where a training dataset is applied to train one or more ML models to achieve the goals. Unlabeled or raw datasets may also be applied to the ML models in the modeling phase 1208 to validate the effectiveness of the training. Finally, in deployment phase 1210, any one or more models based on the best (i.e., most accurate) results of predefined QoS are deployed on the edge device.

[0092] Flowchart 1200 and its various stages can be used to implement ML-based analytics to classify indicator cards at the edge device, as described above. Flowchart 1200 can also be used to implement ML-based analytics to achieve other objectives at the edge device. For example, in addition to classifying indicator cards according to failure modes, embodiments of this disclosure can implement ML-based analytics at the edge device to predict future failures based on indicator card classification.

[0093] Figure 13 The illustration shows exemplary details of a target definition phase 1202 for implementing ML-based analytics at an edge device to predict future failures in some embodiments. In some embodiments, such failure prediction capabilities or tools can be used as part of monitoring and control applications 220. Figure 2 It is implemented as a part of ). Figure 13As shown, one objective of the fault prediction function could be to predict whether a pump assembly will experience a defect or failure in the near future based on indicator card classification. A related objective might be to predict the shape of the indicator card associated with any predicted fault. Several points need to be considered to achieve these objectives. For example, how far in advance can a fault be predicted, and whether the indicator card shape used for predicted faults and the shape used for actual faults have the same classification. Furthermore, is the shape similarity prediction accurate enough to justify adjusting pump parameters? Some exemplary requirements for achieving these objectives include initially focusing on two types of fault modes, namely gas disturbances and fluid shocks, as preventative measures can be taken to mitigate these fault modes. Ideally or preferably, an alert should be issued as soon as possible so that the control system and / or operator have sufficient time to take preventative measures. Similarly, the ML model should operate effectively for any pump assembly without prior customization and does not need to predict the exact shape of the indicator card (i.e., a sketch with the correct scale is sufficient).

[0094] Figure 14-18 Exemplary details of the data analysis phase 1204 for fault prediction functionality in some embodiments are shown.

[0095] refer to Figure 14 For the data to be used, various data characteristics need to be considered. As mentioned earlier, in some embodiments, the data to be used includes indicator cards and their classifications (e.g., such as...). Figure 11 (Output at point 1116 in the data). Features available for fault prediction in this data include the indicator card timestamp (YYYY-MM-DD, HH:MM:SS), indicator card stroke count (integer), whether the indicator card represents an outlier (Boolean), the specific pump, rod displacement vertex (horizontal axis vertex), load vertex (vertical axis vertex), and fault probability of the indicator card. In the example shown, the indicator cards come from two different wells, Well A (5 pumps) and Well B (3 pumps), spanning several months and involving 8 fault modes or classifications indicated by 8 probabilities.

[0096] Figure 15 This document shows a list of fault categories and their frequency of occurrence at each well, for each category, in some embodiments. These categories are generally well-known to those skilled in the field of artificial lift and include fluid impaction, gas disturbance, gas lock, normal operation, plunger jamming, solid abrasion, solids in the pump, and worn pump. Other indicator card categories besides those shown here may also be used.

[0097] Figure 16Examples of other considerations that can be taken into account in data analysis phase 1204 are shown. For example, it has been observed that fault prediction works best when the ML model is provided with a regular sequence of continuous dynamometer cards and their classification. Any gaps or gaps in the sequence (e.g., due to data communication problems) or irregular time steps (e.g., due to variations in pump operating parameters or sensor data processing time) can negatively impact fault prediction. For the purposes of the embodiments herein, analyzing a sequence of, for example, 10 dynamometer cards distributed over several minutes is different from analyzing 10 dynamometer cards distributed over several hours. Therefore, it is necessary to analyze the timestamps of the dynamometer cards in the sequence, and if the difference in timestamps between the first and last (e.g., the 10th) dynamometer card exceeds a certain threshold, fault prediction may not output sufficiently accurate predictions.

[0098] It was also observed that, see Figure 17 As shown, fault prediction performs better when the ML model provides at least 10 consecutive indicator cards and classifications, although fewer than 10 consecutive indicator cards and classifications (e.g., 9, 8, 7, 6, 5, etc.) can certainly be used, depending on the required QoS. It was also observed that fault prediction is best when the ML model is provided with at least 10 consecutive indicator cards with a "normal" classification, although other types of indicator card classifications can certainly be used depending on the required QoS.

[0099] Figure 18 An example illustrating the evolution of indicator cards over time demonstrates the feasibility of using indicator card classification to predict future failures. In this figure, several diagrams representing overlapping indicator cards are shown at 1800. Red diagram 1802 represents a specific indicator card at a given time t, while light blue diagram 1804 represents multiple preceding indicator cards. It can be seen that over time, the shape of the indicator card evolves from the generally rectangular shape of the light blue indicator card 1804 to a more deviated shape of the red indicator card 1802. This shows that indicator cards can (and indeed do) evolve gradually according to observable and predictable trends. On the other hand, certain types of “random” evolution have also been observed, leading to abrupt shape changes between two consecutive indicator cards, such as when solids enter the pump. The latter type of pump problem cannot be easily or readily predicted because they rarely exhibit any obvious early signs that foreseeable problems.

[0100] Figure 19-22 The illustration shows exemplary details of the data preparation phase 1206 for fault prediction functionality in some embodiments.

[0101] refer to Figure 19An exemplary flowchart 1900 illustrates a method that can be used in the data preparation phase 1206. Typically, if an ML model infers that certain pump defects may occur during normal operation based on a number of consecutive "normal" indicator cards, the method predicts the defects, and if the ML model infers the possible presence of defects, it also predicts the shape of the indicator card corresponding to the defect. In some embodiments, the predicted shape of the indicator card may resemble... Figure 3 The shape of the indicator card shown depends on the specific failure mode inferred by the ML model. Therefore, if the ML model infers that a "fluid shock" condition will occur soon, the shape of the indicator card predicted by the ML model might resemble... Figure 3 One of the 300 indicators of the shape of the indicator card for fluid impact, and so on.

[0102] This method typically began in 1902, where the indicator card and its classification (e.g., from...) were obtained. Figure 11 (Output at 1116). At 1904, determine if the indicator card category is not a statistical "outlier". If not, ignore the indicator card and reset the indicator card sequence at block 1906, and the method returns to 1902 to obtain the next indicator card and category. If yes, determine at 1908 if the indicator card category is "normal". If no, the indicator card is also ignored, and reset the indicator card sequence at block 1906. If yes, add the indicator card to the current indicator card sequence, and update the number of indicator cards in the sequence accordingly at 1910.

[0103] In 1912, it is determined whether the last X indicator cards all have a "normal" classification, where X can be at least 10, for example, depending on the specific application. If not, the indicator card sequence is reset in block 1906 and the method returns to 1902 to obtain the next indicator card and classification. If yes, the X indicator card sequence is provided to, or otherwise input into, the ML model in 1914 for inference to see if a fault is likely to occur within the next Y minutes, where Y can be, for example, 10 minutes or some other time interval incorporated into the ML model. If the ML model infers that a fault is likely to occur within the next Y minutes, then the model also infers the indicator card shape associated with the predicted fault.

[0104] In step 1916, it is determined whether a fault occurs within the next Y minutes, as predicted by the model. If not, the indicator card sequence is reset in block 1906, and the method returns to step 1902 to obtain the next indicator card and classification. If yes, the fault-related indicator card shape is fed back to the ML model in step 1918 for regression analysis and further model training. Afterward, the method returns to step 1902 to obtain the next indicator card and classification.

[0105] Optionally, although not technically part of data preparation, in some embodiments, in response to a fault that actually occurs in 1918 or is predicted in 1914, one or more predefined actions may be taken in 1920 and / or 1922. Such actions could range from recording the date and time of the fault, to sending alarm messages to the SCADA system and / or appropriate personnel, to adjusting motor speed, and shutting off power to the motor unit, etc. The specific response actions taken can be programmed to depend on the severity of the predicted fault mode and how long before the fault occurs. Thus, for example, if a “fluid shock” condition is predicted to occur within two days, an alarm message can be set for the appropriate system or personnel, while if a “fluid shock” condition is predicted to occur within two minutes, an alarm message can be automatically sent while simultaneously adjusting motor speed or other pump parameters.

[0106] Figure 20 Exemplary standards for preparing training datasets that can be used to train ML models for fault prediction are illustrated in some embodiments. It has been observed that fault prediction performs best when the ML model is trained with training data containing sufficiently long sequences of normal indicator cards (e.g., at least 10, 9, 8, 7, 6, 5, etc., consecutive indicator cards), followed by indicator cards with one of the problem categories, such as fluid impingement or gas disturbance. The training data for the ML model can also be augmented to create additional datasets to enhance model training in the manner described earlier herein.

[0107] Figure 21 The diagram shows some inputs provided to the ML model from each dynamometer card. It can be seen that each dynamometer card is generally defined by four points A, B, C, and D, representing the angle of the dynamometer card; the vertical axis represents the load on the rod; and the horizontal axis represents the position or displacement of the rod. In some embodiments, the input to the ML model is obtained by sampling each dynamometer card along a segment ADC of the dynamometer card, although segment ABC can also be used within the scope of this disclosure. The model input may also include certain statistical information about the samples, such as mean, slope, standard deviation, etc.

[0108] Figure 22 Several diagrams are shown illustrating further details of an exemplary technique used for sampling the dynamometer card. The original dynamometer card is shown in Diagram 1. In Diagram 2, segments AC are identified for the dynamometer card, as shown. In Diagram 3, minimum / maximum ratios are defined, for example, 1 is the maximum value and 0 is the minimum value. In Diagram 4, multiple samples of segment AC are obtained along the horizontal axis, for example, 10 samples. In Diagram 5, multiple samples of segment AC are obtained along the vertical axis, for example, 10 samples. These samples are then used as input to an ML model for training. Dynamometer card samples used as input during real-time operation can be obtained in a similar manner.

[0109] Figure 23-27 Exemplary details of the modeling phase 1208 of the fault prediction function in some embodiments are shown.

[0110] refer to Figure 23 Several ML models can be used to implement the fault prediction function disclosed in this paper. Some of these ML models include LSTM (Long Short-Term Memory), XGBoost, CNN LSTM (Convolutional Neural Network LSTM), and combinations of statistical and momentum methods. Implementations of the fault prediction function described herein consider using any one or a combination of these ML models to predict faults in advance.

[0111] Figure 24 An exemplary confusion matrix 2400 is shown that can be used to evaluate the performance of a trained ML model. Matrix 2400 shows how many positive predictions were validated correctly (meaning there will be a problem with the pump in the near future) and how many negative predictions were validated correctly (meaning there will be no problem with the pump in the near future). It also shows how many positive and negative predictions were validated incorrectly, meaning the model predicted a problem that did not actually occur (i.e., false positives or FP), or the model predicted no problem that actually occurred (i.e., false negatives or FN). For reference, the data used to construct this confusion matrix 2400 was obtained from four wells over a period of approximately one month.

[0112] Figure 25 Exemplary operation of the fault prediction function in some embodiments is illustrated. In the figure, the column labeled "Index" represents the indicator card number, and... Figure 14 The `stroke_nb` column is the same as the `stroke_nb` column. The column labeled "Category" indicates the category of the indicator card. The "Prediction" column indicates whether a fault is predicted and the number of times a fault is predicted. The "Fault Time" column indicates the fault time in seconds. Fault prediction is based on the premise that if there is at least one true positive (TP) before the fault, then the fault is correctly predicted, and the prediction time is the incremental time between the first TP and the fault. It can be seen that the ML model predicts that a fault may occur based on indicator cards 56315, 56316, and 56317, and that the fault may occur within 485 seconds, 454 seconds, and 418 seconds, respectively. However, the subsequent prediction by the ML model that there is no fault on the next four indicator cards is invalid, but one or more of these indicator cards prove to be actual faults (i.e., false negatives or FNs). Starting with indicator card 56322, the ML model again predicts that a fault may occur within 241 seconds. This prediction is considered valid because the fault does indeed occur within 241 seconds.

[0113] Figure 26 Statistical analysis of the prediction time or failure time of true positives predicted by the ML model with predictive capabilities is shown in some embodiments.

[0114] Figure 27 Statistical analysis of several metrics observed in predictions provided by ML models with predictive capabilities in some embodiments is shown.

[0115] Figure 28 The illustration shows exemplary details of deployment phase 1210 of the fault prediction functionality in some embodiments. As previously mentioned, the prediction functionality will be deployed at the edge, meaning it will run on a local gateway device at the well site. In one example, a solution from Kelvin, Inc. could be used to deploy the prediction functionality, which provides a platform that allows users to build, deploy, and manage applications alongside automation systems.

[0116] exist Figure 28 In the exemplary deployment, the rod pump assembly 2802 includes a variable speed drive (VSD) 2804 that controls the motor unit (not explicitly shown) for the rod pump assembly. A remote terminal unit (RTU) 2806 collects data on various aspects of the operation of the rod pump assembly, including the operation of the VSD 2804, for monitoring and tracking purposes. The RTU 2806 also collects measurements from various wireless and wired field sensors (not explicitly shown) around the well site. Based on this data, the RTU 2806 generates dynamometer cards, each representing a graph or curve showing the relationship between tension or load (vertical axis) and displacement (horizontal axis) on the rod in the rod pump assembly 2802.

[0117] Edge device 2808, such as a gateway, provides network access or entry point for RTU 2806 and other RTUs at the well site to transmit collected data to external systems, such as Supervisory Control and Data Acquisition (SCADA) systems and / or private or public networks (e.g., the Internet). In some embodiments, the gateway may include a Modbus workload component 2810 or a similar component that receives indicator cards from RTU 2806 and other RTUs at the well site. Modbus workload component 2810 provides indicator cards to indicator card identification component (DRC) 2812 in gateway 2808. DRC 2812 processes and classifies indicator cards according to one of several indicator card classifications in a manner described herein. DRC 2812 then transmits the classified indicator cards to indicator card prediction component (DFC) 2814 in gateway 2808. DFC 2814 analyzes the sequence of indicator cards and classifications and predicts whether problems will occur in pump assembly 2802 in the near future, in a manner described herein. If so, the DFC 2814 can also predict the shape of the indicator card that is related to or represents this future problem. Afterward, the DRC 2812 and DFC 2814 output their results to one or more external systems 2816.

[0118] As understood above, edge gateways equipped with ML-based analytics as discussed in this article can be deployed in various ways, including as standalone, on-premises solutions without cloud connectivity. This standalone solution integrates seamlessly with existing or new SCADA systems, allowing centralized use of feedback from the edge gateway to support real-time decisions that improve operational efficiency. On-premises solutions are preferred if there is no WAN connectivity, or if the carrier is unwilling to share data on a cloud platform via a public internet connection.

[0119] Alternatively, edge gateways with ML analytics can leverage full cloud connectivity, where multiple such gateways can be maintained and managed through a cloud platform. This option allows for the retraining of ML models using real-time data collected from multiple edge gateways, resulting in more accurate applications at the edge. This retraining process can be automated, and the retrained model can be deployed to multiple gateways according to a pre-defined schedule, provided the model accuracy reaches a predefined level or when unique functionalities are added (e.g., through transfer learning).

[0120] For additional details and specific exemplary implementations of the various embodiments of this disclosure, readers may refer to SPE-192019-MS (“Edge Analytics and Future of Upstream Automation”), SPE-192513-MS (“IIoT Edge Analytics: Deploying Machine Learning at the Wellhead to Identify Rod Pump Failure”) and SPE-192886-MS (“Deploying Machine Learning at the Wellhead to Identify Rod Pump Failure”).

[0121] In the foregoing discussion, reference has been made to various embodiments. However, the scope of this disclosure is not limited to the embodiments specifically described. Rather, any combination of the described features and elements, whether or not they relate to different embodiments, is contemplated for implementation and practice of the contemplated embodiments. Furthermore, while embodiments may achieve advantages over other possible solutions or prior art, whether a given embodiment achieves a particular advantage does not limit the scope of this disclosure. Therefore, the foregoing aspects, features, embodiments, and advantages are merely illustrative and should not be considered as elements or limitations of the appended claims unless expressly recited in the claims.

[0122] The various embodiments disclosed herein can be implemented as systems, methods, or computer program products. Therefore, aspects can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects, which can generally be referred to as “circuit,” “module,” or “system.” Furthermore, aspects can take the form of computer program products embodied in one or more computer-readable media, on which computer-readable program code is embodied.

[0123] Any combination of one or more computer-readable media may be used. The computer-readable medium may be a non-transitory computer-readable medium. A non-transitory computer-readable medium may be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof. More specific examples (not an exhaustive list) of non-transitory computer-readable media may include: electrical connections having one or more wires, portable computer floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, RF, etc., or any suitable combination thereof.

[0124] Computer program code used to perform the operations of various aspects of this disclosure can be written in any combination of one or more programming languages. Furthermore, such computer program code can be executed using a single computer system or multiple computer systems communicating with each other (e.g., using a Private Area Network (PAN), Local Area Network (LAN), Wide Area Network (WAN), Internet, etc.). Although the various features described above are illustrated with reference to flowcharts and / or block diagrams, those skilled in the art will understand that each block of the flowcharts and / or block diagrams, as well as combinations of blocks in the diagrams, are significant. Flowcharts and / or block diagrams can be implemented using computer logic (e.g., computer program instructions, hardware logic, combinations of both, etc.). Typically, computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus. Furthermore, using a processor to execute such computer program instructions produces a machine capable of performing the functions or actions specified in the flowchart and / or block diagram blocks or blocks.

[0125] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and / or operation of various implementations of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or code portion, comprising one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may not appear in the order indicated in the figures. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order, depending on the functionality involved. It should also be noted that each block illustrated in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a hardware-based dedicated system that performs the specified function or action, or a combination of dedicated hardware and computer instructions.

[0126] It should be understood that the above description is intended to be illustrative and not restrictive. Many other embodiments will become apparent upon reading and understanding the above description. Although specific examples are described herein, it should be recognized that the systems and methods of this disclosure are not limited to the examples described herein but can be implemented with modifications within the scope of the appended claims. Therefore, the specification and drawings should be considered illustrative rather than restrictive. Consequently, the scope of this disclosure should be determined by reference to the appended claims and the full scope of their equivalents.

Claims

1. A method for predicting failure modes at a well site, comprising: Receive the indicator card from the remote terminal unit (RTU) at the well site; Machine learning (ML) based analytics are performed on edge devices at the well site using indicator cards from the RTU. These edge devices are designed to provide the well site with access to or entry into a network, including a local area network (LAN), a wide area network (WAN), or a metropolitan area network (MAN). Based on ML-based analysis performed on the indicator cards, the classification of indicator cards on edge devices used for well site operations is identified; Perform ML-based analysis on edge devices at the well site using dynamometer cards and dynamometer card classification; Based on ML-based analysis of dynamometer cards and dynamometer card classification, failure modes and failure times are predicted on edge devices at the well site. and Response actions are initiated on the edge device based on the fault mode and the time of failure. Depending on the severity of the fault mode and the time of failure, the response actions include at least one of recording the date and time, sending an alarm message to the control system, adjusting the motor speed of the rod pump, or shutting off the power to the rod pump.

2. The method of claim 1, further comprising estimating the shape of the indicator card associated with a failure mode on the edge device at the well site based on ML-based analysis performed on the indicator card and indicator card classification.

3. The method as described in claim 1, wherein, Performing ML-based analysis using indicator cards and indicator card classification includes performing ML-based analysis on a predetermined number of consecutive indicator cards.

4. The method of claim 3, wherein, The predetermined number of continuous indicator cards all have normal classification.

5. The method of claim 1, wherein, The predicted failure mode includes predicting either fluid impingement failure or gas disturbance failure.

6. The method of claim 1, wherein, Performing ML-based analysis using indicator card classification involves inputting the indicator card classification into one or more ML models, each indicator card classification being one of fluid impact, gas interference, air lock, normal, plunger jamming, solid abrasion, solids in the pump, and wear of the pump.

7. The method of claim 6, wherein, The one or more ML models are trained using historical data, and also include using the historical data to generate enhanced training data.

8. A device installed at the edge of a well site, operable to predict failure modes at the well site, comprising: processor; and A storage device, coupled to the processor, stores computer-readable instructions for performing fault prediction functions thereon; Among them, the fault prediction function, when executed by the processor, enables the edge device to: Obtain dynamometer cards and dynamometer card classifications for use at the well site; Perform ML-based analysis using indicator cards and indicator card classification; Based on ML-based analysis performed on the indicator card and indicator card classification, failure modes and failure times are predicted; and Response actions are initiated on the edge device based on the fault mode and fault duration. Depending on the severity of the fault mode and the fault duration, the response actions include at least one of the following: recording the date and time, sending an alarm message to the control system, adjusting the motor speed of the rod pump, or shutting off the power to the rod pump. The edge device is designed to provide the well site with access to or entry into a network, including a local area network (LAN), a wide area network (WAN), or a metropolitan area network (MAN).

9. The edge device as claimed in claim 8, wherein, The fault prediction function also enables the edge device to predict the shape of the indicator card associated with the fault mode based on ML-based analysis performed on the indicator card and the indicator card classification.

10. The edge device as claimed in claim 8, wherein, The fault prediction function enables the edge device to perform ML-based analysis by performing ML-based analysis on a predetermined number of consecutive indicator cards.

11. The edge device as claimed in claim 10, wherein, The predetermined number of continuous indicator cards all have normal classification.

12. The edge device as claimed in claim 8, wherein, The fault prediction function enables the edge device to predict fault modes by estimating either fluid impact faults or gas interference faults.

13. The edge device as claimed in claim 8, wherein, The fault prediction function enables the edge device to perform ML-based analysis by inputting the indicator card classification into one or more ML models, each indicator card classification being one of fluid impact, gas interference, air lock, normal, plunger jamming, solid abrasion, solids in the pump, and worn pump.

14. The edge device as claimed in claim 13, wherein, The one or more ML models are trained using historical data and augmented training data generated using the historical data.

15. A method for predicting failure modes at a well site, comprising: At the well site, dynamometer cards are classified for use with the edge device, which is designed to provide the well site with access to or entry into a network, including a local area network (LAN), a wide area network (WAN), or a metropolitan area network (MAN). Perform ML-based analysis on edge devices at the well site using dynamometer cards and dynamometer card classification; Based on ML-based analysis of dynamometer cards and dynamometer card classification, failure modes and failure times are predicted on edge devices at the well site. and Response actions are initiated on the edge device based on the fault mode and the time of failure. Depending on the severity of the fault mode and the time of failure, the response actions include at least one of recording the date and time, sending an alarm message to the control system, adjusting the motor speed of the rod pump, or shutting off the power to the rod pump.

16. The method of claim 15, further comprising estimating the shape of the indicator card associated with a failure mode on an edge device at the well site based on ML-based analysis performed on the indicator card and indicator card classification.

17. The method of claim 15, wherein, Performing ML-based analysis using the indicator card and the indicator card classification includes performing ML-based analysis on a predetermined number of consecutive indicator cards.

18. The method of claim 17, wherein, The predetermined number of continuous indicator cards all have normal classification.

19. The method of claim 15, wherein, The predicted failure mode includes predicting either fluid impingement failure or gas disturbance failure.

20. The method of claim 15, wherein, Performing ML-based analysis using the indicator card classification involves inputting the indicator card classification into one or more ML models, each indicator card classification being one of fluid impact, gas interference, air lock, normal, plunger jamming, solid abrasion, solids in the pump, and worn pump.

Images