Autonomous fault prediction and pump control for well optimization

Abstract

The system and method for real-time monitoring and control of wellsite operations uses wellsite edge analysis to detect abnormal operations. The system and method use machine learning (ML)-based analysis directly on the edge device at the wellsite to detect the possible occurrence of abnormal events and automatically respond to these events. Event detection can be based on trends identified in data acquired in real time from wellsite operations. Trends can be identified by correlation and by fitting line segments to the data and analyzing the slope of the line segments. When an abnormal event is detected, the edge device can issue an alert about the event and take predefined steps to reduce the potential damage caused by the event. 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 patent application claims priority to U.S. Provisional Application No. 62 / 829,834, filed on April 5, 2019, entitled “Autonomous Failure Prediction and Pump Control for Well Optimization,” and U.S. Provisional Application No. 62 / 967,492, filed on January 29, 2020, entitled “Well Site Edge Analytics,” and is incorporated herein by reference. Technical Field

[0003] The present disclosure relates to monitoring and controlling oil and gas wells to ensure proper operation of the wells, and more particularly, to methods and systems for using wellsite edge analysis to detect the occurrence of abnormal events and operating conditions to monitor and control well operations in real time. Background Art

[0004] Oil and gas wells are commonly used to extract hydrocarbons from underground formations. A typical well site consists of a wellbore that has been drilled into the formation and sections of tubing or casing cemented into place within the wellbore to stabilize and protect the wellbore. The casing is perforated at a certain target depth in the wellbore to allow oil, gas, and other fluids to flow from the formation into the casing. Tubing runs down the casing, providing a conduit for the oil and gas to flow upward to the surface where they are collected. If there is enough pressure in the formation, the oil and gas can flow naturally up the tubing, but pumping equipment is usually required at the well site to bring the fluids to the surface.

[0005] Because oil and gas wells are located in remote areas, they often operate unattended for extended intervals. During these intervals, many environmental and other factors can affect the operation of the well. When problems arise, field personnel often need to travel to the well site, physically inspect the equipment, and make any necessary repairs. This can be a costly and time-consuming endeavor, resulting in reduced productivity and profitability for the well owner and operator, and can also be dangerous to field personnel.

[0006] Therefore, while many advances have been made in the field of oil and gas production, it is easy to understand that there is still a need for continuous improvement. Summary of the invention

[0007] The present disclosure relates to systems and methods for real-time monitoring and control of well operations at a well site using edge analytics. The system and method deploy machine learning (ML)-based analytics directly on edge devices at the well site to detect the possible occurrence of abnormal events and operating conditions and automatically respond to these events. Event detection can be based on trends identified in operating parameter data obtained from real-time well operations. Trends can be identified by analyzing the rate of change of the data or by using statistical correlation techniques on the data. When it is detected that an abnormal event may be occurring or about to occur, the edge device can issue an alert about the event and take predefined steps to reduce the potential damage caused by the event. This helps reduce downtime, minimize productivity and cost losses, and reduce health and safety risks to field personnel.

[0008] In general, in one aspect, embodiments of the present disclosure relate to an edge device installed at a wellsite and operable to monitor wellsite operations. The edge device includes, in particular, a processor and a storage device, the storage device being coupled to the processor and storing thereon computer-readable instructions for a wellsite monitoring and control application. The wellsite monitoring and control application enables the edge device to receive wellsite data, in particular from a remote programmable automation (PAC) controller at the wellsite, the wellsite data representing one or more operating parameters related to wellsite operations. The wellsite monitoring and control application also enables the edge device to perform machine learning (ML)-based analysis at the wellsite using the wellsite data from the PAC. The wellsite monitoring and control application also enables the edge device to detect the occurrence of events related to wellsite operations based on ML-based analysis, and to initiate response actions on the edge device based on one or more events.

[0009] According to any one or more of the foregoing embodiments, the wellsite operation includes pumping operations performed by an ESP (electric semi-submersible pump) at the wellsite, and the wellsite data includes data related to the pumping operations performed by the ESP at the wellsite.

[0010] According to any one or more of the foregoing embodiments, the wellsite monitoring and control application further enables the edge device to stream the wellsite data in real-time into one or more ML models, the one or more ML models including a model that performs one of correlation-based detection and schematic-based detection, performs schematic-based detection by fitting a line segment to the wellsite data and determining the slope of the line segment, and / or performs detection of an event by comparing the slope of the line segment to a predetermined slope threshold.

[0011] According to any one or more of the foregoing embodiments, the wellsite monitoring and control application also enables the edge device to allow an operator to modify the slope thresholds and events corresponding to them in its predefined slope thresholds, the ML-based analysis is performed step by step using a predefined time window, and / or the predefined time window includes time windows with different durations based on the priority of the detected event.

[0012] In general, in another aspect, embodiments of the present disclosure relate to a method for monitoring wellsite operations. The method particularly includes receiving wellsite data from a remote programmable automation (PAC) controller at the wellsite, the wellsite data representing one or more operating parameters related to the wellsite operations. The method also includes performing machine learning (ML)-based analysis on an edge device at the wellsite using the wellsite data from the PAC. The method also includes detecting the occurrence of an event related to the wellsite operations on the edge device based on the ML-based analysis, and initiating a response action on the edge device based on the one or more events.

[0013] In accordance with any one or more of the foregoing embodiments, the wellsite operations include pump operations performed by an ESP at the wellsite, and the wellsite data includes data related to the pump operations of the ESP at the wellsite.

[0014] According to any one or more of the foregoing embodiments, performing ML-based analysis includes streaming the wellsite data in real-time into one or more ML models, the one or more ML models including a model that performs one of correlation-based detection and schematic-based detection, performs schematic-based detection by fitting a line segment to the wellsite data and determining a slope of the line segment, and / or performs detection of an event by comparing the slope of the line segment to a predefined slope threshold.

[0015] According to any one or more of the aforementioned embodiments, the method further includes allowing an operator to modify the slope threshold and the events corresponding thereto in its predefined slope threshold, the ML-based analysis is performed step by step using a predefined time window, and / or the predefined time window includes time windows with different durations based on the priority of the detected event.

[0016] In general, in yet another aspect, the present disclosure is directed to a non-transitory computer-readable medium containing program logic that, when executed by operation of one or more computer processors, performs wellsite monitoring operations according to any one or more of the embodiments disclosed herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] A more detailed description of the disclosure, briefly summarized above, can be obtained by reference to various embodiments, some of which are shown in the accompanying drawings. Although the drawings illustrate selected embodiments of the disclosure, these drawings are not to be considered limiting of its scope, as the disclosure may admit to other equally effective embodiments.

[0018] Figure 1 is a schematic diagram of an exemplary implementation of ML-based analysis at a wellsite according to an embodiment of the present disclosure;

[0019] Figure 2 is a block diagram of an exemplary edge device capable of performing ML-based analytics at a wellsite according to an embodiment of the present disclosure;

[0020] Figure 3 is a block diagram of an exemplary software architecture for deploying ML-based analytics to wellsite edge devices according to an embodiment of the present disclosure;

[0021] Figure 4 is a diagram illustrating exemplary operational stages of ML-based analysis at a wellsite edge device according to an embodiment of the present disclosure;

[0022] Figure 5 is a data graph illustrating 2-variable outlier detection according to an embodiment of the present disclosure;

[0023] Figure 6 is a probability graph showing the evolution of a system from stable normal operation to an abnormal event according to an embodiment of the present disclosure;

[0024] Figure 7 is an array of probability graphs depicting multivariate probability determinations according to embodiments of the present disclosure;

[0025] Figure 8 is a table illustrating a portion of an exemplary database for correlation-based event detection at a wellsite edge device according to an embodiment of the present disclosure;

[0026] Fig. 9 is a flow chart depicting exemplary operational stages of schematic-based event detection at a wellsite edge device according to an embodiment of the present disclosure;

[0027] Fig.10 is a diagram illustrating exemplary event detection using time windows at a wellsite edge device according to an embodiment of the present disclosure;

[0028] Fig.11 is a diagram illustrating exemplary schematic-based event detection at a wellsite edge device according to an embodiment of the present disclosure;

[0029] Fig.12is a table showing exemplary slopes for schematic-based event detection at a wellsite edge device according to an embodiment of the present disclosure;

[0030] Fig.13 is a diagram illustrating exemplary event detection using multiple time windows at a wellsite edge device according to an embodiment of the present disclosure;

[0031] Figures 14A-14H is a screenshot showing an exemplary user interface for monitoring event detection at a wellsite edge device according to an embodiment of the present disclosure;

[0032] Fig.15 is another screen shot showing an exemplary user interface for monitoring event detection at a wellsite edge device according to the present disclosure; and

[0033] Fig.16 is another screenshot showing a probability graph of event detection at a wellsite edge device according to an embodiment of the disclosure.

[0034] Wherever possible, identical reference numerals are used to refer to identical elements in the drawings. However, elements disclosed in one embodiment may be beneficially utilized on other embodiments without specific recitation. DETAILED DESCRIPTION

[0035] The description and drawings illustrate exemplary embodiments of the present disclosure and should not be considered restrictive, and the claims define the scope of the present disclosure, including equivalents. Various mechanical, compositional, structural, electrical and operational changes may be made without departing from the scope (including equivalents) of this specification and claims. In some cases, well-known structures and techniques are not shown or described in detail to avoid confusing the present disclosure. In addition, as long as feasible, elements and related aspects thereof described in detail with reference to one embodiment may be included in other embodiments in which they are not specifically shown or described. For example, if an element is described in detail with reference to one embodiment, and the element is not described with reference to a second embodiment, the element can still be declared to be included in the second embodiment.

[0036] Note that, as used in this specification and the appended claims, the singular forms of "a," "an," and "the," as well as any singular form of any word, include plural references unless expressly and unambiguously limited to one reference. As used herein, the term "include" and its grammatical variations are intended to be non-limiting, such that the recitation of items in a list is not to the exclusion of other like items that can be substituted or added to the listed items.

[0037] At a high level, embodiments of the present disclosure provide systems and methods for real-time monitoring and control of well operations using machine learning (ML)-based analysis at a well site. The term "analysis" as used herein generally refers to data analysis and the identification and detection of meaningful patterns in the data. The disclosed system and method deploy ML-based analysis directly on edge devices at the well site to detect abnormal events and abnormal operating conditions and automatically respond to them. The term "edge device" as used herein refers to a device designed to provide access or entry to a network, such as a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), etc. Being able to perform ML-based analysis on edge devices provides many benefits, especially for well sites located remotely, where the computing resources typically required for ML modeling may not be available. In this case (and other cases), performing ML modeling on edge devices allows operators to proactively manage remote well sites. Specifically, edge devices equipped with ML-based analysis can automatically detect events and operating conditions that may indicate non-optimal production and possible equipment failures, issue warnings about the events, and take predefined steps to reduce the potential damage caused thereby. This edge analytics platform (EAP) helps reduce downtime, thereby minimizing productivity and cost losses, and reduces health and safety risks to personnel who might otherwise have to make unplanned wellsite trips (i.e., reducing “commuting time”).

[0038] When EAP is implemented at the well site, combined with the widespread movement towards the so-called Industrial Internet of Things (IIoT), the above benefits become more apparent. In the IIoT environment, well site operators are increasingly using interconnected sensors and devices to collect and store large 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 that produces oil from a wellbore using an electric semisubmersible pump (ESP). During the operation of the ESP, a large amount of raw data is typically collected, including wellhead pressure, pump discharge pressure, pump suction pressure, pump suction temperature, pump flow rate, motor temperature, etc. Edge devices equipped with ML modeling can process the data in real time and identify patterns in the data that may cause ESP failures. The edge device can then generate alerts, perform emergency actions, and store the results of the processing in local servers and / or the cloud as needed. Once the locally generated data is labeled and processed, it can be used to update and further train ML models, debug new edge devices, and generally improve well site operations.

[0039] Exemplary embodiments of ESPs herein can autonomously control ESP operations at a wellsite based on real-time data collected from surface and subsurface sensors. These embodiments can include systems and methods for building event-based ML models to identify patterns in time series data and other data sources, and act on these patterns to improve / mitigate the performance of the well. In this regard, multivariate time series data is received from sensors attached to, for example, variable speed drives (VSDs), downhole instruments, and surface instruments from various onshore wellsites and offshore platforms. For the latter, the data is typically available in an onshore control room, which is where edge analytics solutions are deployed.

[0040] The ESP discussed herein can capture high-frequency data and apply pattern recognition algorithms to provide early indications of abnormal ESP performance. The captured and verified patterns can then be used to reduce unplanned downtime, manage rig activity, improve production, and enhance operator experience. Other advantages of the technology disclosed herein include the ability of the ESP to detect abnormal ESP performance patterns in near real time based on high-frequency data captured from surface and subsurface sensors; the ability of the ML model to predict abnormal events and notify and / or take corrective actions based on a predetermined workflow; the ability of the EAP to improve ESP performance, which is converted into production optimization by tracking key performance indicators (KPIs) set by operational and production constraints; and the ability of the EAP to iterate the ML model over a period of time, during which the model accuracy is improved through operator feedback, captured knowledge, and real-world experience, thereby improving prediction accuracy. The latter can improve model accuracy through transfer learning techniques. Various types of analytical algorithms can be applied to raw high-frequency data to identify data trends that appear over a determined period of time. The trend can be a behavioral pattern observed in a set of data inputs that are consistent over a determined period of time. The pre-trained ML model is used to predict any abnormal behavior, whether ESP or production related, and corrective action can be taken, for example, to improve / mitigate well performance through VSD speed control. This corrective action can be in the form of a configurable template that indicates the type of action to be taken based on the predicted abnormal behavior, such as speeding up the pump to clear sand from the pump, etc. For example, the EAP can send a control command to speed up the pump within a determined time period to avoid the occurrence of abnormal behavior.

[0041] In short, embodiments of the present disclosure provide methods and systems for developing and deploying robust ML modeling in an IIoT environment to automatically detect abnormal events and non-optimal operations directly at the well site, and also ensure a high level of accuracy in predictions through ML-based analysis, thereby generating increased operator confidence. Such abnormal events and non-optimal operations are referred to as "events" hereinafter, and may include, for example, a broken pump shaft, a hole in the tubing, a blockage at the pump suction, an increase in water cut (i.e., the amount of water in the well fluid), a well shut-in at the surface (i.e., a closed well), a blockage in the pump stage, an increase in reservoir pressure, an increase in free gas at the pump suction, wear at the pump stage, an increase in motor vibration, an open choke, etc. It should also be understood that the terms "detect" and "predict" are used interchangeably herein to refer to the EAP's ability to predict events based on the detection of patterns in the underlying data.

[0042] Reference now Figure 1, a schematic diagram of an exemplary EAP implementation at a wellsite 100 is shown according to an embodiment of the present disclosure. As can be seen, a wellbore 102 has been drilled into an underground formation 104 at the wellsite 100, and a casing 106 has been cemented into the wellbore 102. A pipe 108 extends from a wellhead 110 through the casing 106 down the wellbore 102 to receive and transport oil (or other fluids) from the formation 104. The formation 104 in this example no longer has sufficient formation pressure to produce oil naturally, so artificial lift is provided via an ESP 112 installed at the wellsite 100. The ESP 112 generally includes a motor 114, a seal 116, and a pump 118 connected as shown. The operation of the ESP 112 is well known to those skilled in the art, so other common components, such as a motor jumper base, a ground fault meter, etc., are omitted here for the sake of economy. A discharge line 120 transports the oil (or other fluid) produced from the wellbore 102 to one or more storage tanks (not explicitly shown) for storage and processing on the surface.

[0043] At the surface, a motor control unit 128, typically a variable speed drive (VSD), provides power (i.e., current and voltage) to the ESP 112 and regulates its operating speed. The motor control unit 128 is in turn controlled by a programmable automation controller (PAC) 130, which can provide control functions similar to a remote terminal unit (RTU), a programmable logic controller (PLC), or other similar programmable controller. The PAC 130 receives data about the operation of the ESP, including motor speed and load, from the motor control unit 128, and collects data about other operating parameters, such as flow rate, pressure, temperature, etc., from the wellbore 102. This data can be provided by various wireless and wired I / O devices located around and within the wellbore 102, including digital I / O devices 132, HART analog I / O devices 134, and non-HART analog I / O devices 136. Examples of I / O devices include temperature sensors, pressure sensors, flow rate sensors, proximity sensors, current / voltage sensors, vibration sensors, various actuators, etc. Based on the acquired data, PAC 130 may monitor and control the operation of ESP 112 and other operations at wellbore 102 according to its programming.

[0044] The motor control unit 128 may be one of several motor control units 128, each of which controls a respective ESP (not shown) for a respective well, which are connected to and controlled by the PAC 130. The PAC 130 receives data about the operation of the ESP from each motor control unit 128, as well as data about other well operating parameters provided by wireless and wired I / O devices at the well of each ESP. The edge device 138 provides the PAC 130 with an access or entry point to a field network 140, which allows the PAC 130 to transmit the collected data to a control system, such as a supervisory control and data acquisition (SCADA) system 142. Any type of edge device or appliance may be used as the edge device 138, as long as 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.

[0045] In some embodiments, an edge server 144 may also be provided that connects the field network 140 to an enterprise network 146. From there, the data may be forwarded to other systems within the enterprise, such as a SCADA historian 148, one or more operator stations 150, one or more engineering stations 152, and the like. In some embodiments, the data may also be transmitted to a private enterprise cloud, such as an on-premise cloud (OPC) 154, for further processing as needed. Optionally, for applications that are less concerned with strict data security, the data may also be transmitted to an external network 156, such as the Internet, and then transmitted to an external cloud 158 for further processing as needed. According to an embodiment of the present disclosure, as described below, the edge device 138 has the ability to perform ML-based analysis on data regarding ESP operations and other operations at the wellbore 102.

[0046] Figure 2is a block diagram illustrating an exemplary hardware architecture 200 of an edge device 138 according to an embodiment of the present disclosure. The edge device 138 shown here is a gateway. In one embodiment, the edge gateway 138 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 138 may also include a main memory 206, such as a 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.

[0047] The edge gateway 138 may also include a read-only memory (ROM) 208 or other static storage device coupled to the bus 202 for storing static information and instructions for the CPU 204. A computer-readable storage device 210, such as a non-volatile memory (e.g., flash memory) drive or disk, may be coupled to the bus 202 for storing information and instructions for the CPU 204. The CPU 204 may also be coupled to a human-machine interface (HMI) 212, such as a touch screen interface, via the bus 202 for displaying information to a user and allowing the user to interact with the edge gateway 138. A PAC interface 214 may be coupled to the bus 202 for allowing the edge gateway 138 to communicate with a PAC 130 or similar programmable controller. A network or communication interface 216 may be provided to allow the edge gateway 138 to communicate with external systems such as the SCADA system 140 and / or the network 142.

[0048] The term "computer-readable instructions" 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 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 the wires of bus 202. The transmission itself can take the form of electromagnetic waves, sound waves, or light waves, such as those generated during radio frequency and infrared 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.

[0049] The wellsite monitoring and control application 220, or more precisely, its computer readable instructions, may also reside on or be downloaded to the storage device 210. The wellsite monitoring and control application 220 may be executed by the CPU 204 and / or other components of the edge gateway 138 to perform ML-based analysis on data from the PAC 130 to automatically detect events and generate responses. Such a monitoring and control application 220 may be written in any suitable computer programming language known to those skilled in the art, using any suitable software development environment known. Examples of suitable programming languages ​​may include C, C++, C#, Python, Java, Perl, etc.

[0050] According to an exemplary embodiment, the wellsite 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. As the name implies, the data preprocessing module 222 performs preprocessing (e.g., filtering, smoothing, amplification, etc.) on the data received from the PAC 130 for use in the monitoring and control application 220. The monitoring and control application 220 inputs the preprocessed data into one or more ML models 224 for processing to determine whether the data matches or is similar to one or more known data patterns. In a preferred embodiment, the monitoring and control application 220 employs ensemble modeling, in which multiple different ML models 224 are combined to obtain more accurate results. Therefore, ensemble models are sometimes referred to as meta-models. Based on the results of the ML model processing, the response action module 226 takes appropriate response actions, ranging from recording the date and time of occurrence, to sending an alarm message to the SCADA system 142 and / or authorized personnel, to instructing the PAC 130 to cut off the power supply to the ESP 112. Note that although ML models are primarily discussed, one of ordinary skill in the art will appreciate that empirical models may be used for purposes herein in addition to or instead of ML models.

[0051] Figure 3An exemplary architecture 300 is shown that can be used to deploy an ML model 224 (and associated modules) on an edge gateway 138. The edge architecture 300 in this example uses Microsoft IoT Edge 302, which decomposes local processing between Docker containers 304 on top of an Ubuntu core 306 to support embedded constraints. This container-based architecture simplifies deployment, but requires a Linux-based gateway capable of running Linux OS variants, and minimal computing resources (i.e., CPU, memory) similar to the well-known Raspberry Pi hardware. In this example, the container 304 for prediction includes MODBUS, which enables Modbus communication between the PAC 130 and the edge gateway 138. AzureML and EdgeAgent are also included, AzureML facilitates machine learning on Azure, and EdgeAgent checks hardware integrity and ensures that all necessary processes run seamlessly. The EdgeHub container supports communication with the cloud platform using a publish / subscribe approach (e.g., via the MQTT protocol). The cloud connection allows remote monitoring and management of the edge gateway 138 for maintenance purposes, as well as tracking the effectiveness and accuracy of the ML model 224, and can also remotely trigger transfer learning, a process known to those skilled in the art whereby knowledge gained in solving a problem is applied to a different but related problem. In short, Figure 3 The ML model deployment architecture 300 depicted in FIG. 1 is applicable to any edge gateway that meets the minimum hardware requirements, and uses a container 304 to deploy ML models and other associated components, making interoperability with different hardware platforms more seamless and easier to manage. One of ordinary skill in the art will appreciate that the present invention is not limited to this particular selection and arrangement of containers, and additional and / or alternative containers may be used within the scope of the present disclosure.

[0052] Prior to deployment on the edge device 138, the one or more ML models 224 first need to be trained to detect various types of events that are expected to occur in the field. Generally speaking, embodiments of the present disclosure consider two types of event detection techniques, graph diagnostic techniques and multivariate correlation techniques. Graph diagnostic techniques typically detect events based on the time rate of change or slope of data representing various well operating parameters (including ESP parameters) within a sliding time window. Combinations of parameters with specific slopes are compared to known combinations of parameter slopes for various events. For example, if the flow rate, wellhead pressure, and current are all decreasing, while the discharge pressure of the pump is increasing, then the ESP is likely experiencing or about to experience a broken shaft, etc. Multivariate correlation techniques typically detect events based on statistical correlations between the slopes of various well operating parameters within a given time window. Any technique can be used alone for event detection in this article, and preferably, the two techniques are used in parallel to complement each other. Regardless of which technique is used, or both are used, the ML models 224 first need to be trained before they can detect events with sufficient accuracy, such as Figure 4 Usually depicted in.

[0053] exist Figure 4 4, a graph 400 shows several graph lines, each line representing a data point of a well operating parameter (e.g., flow rate, pressure, temperature, voltage, current, etc.). Graph 400 and similar graphs herein are sometimes referred to as data graphs. As shown in graph 400, ML model 224 generally has two operating phases, a training phase 402 during which the model is trained using historical data sets to identify different events, and a prediction phase 404 in which the trained model is used to infer different events from data acquired in real time.

[0054] The historical data set typically contains measurements of various operating parameters acquired during previous operation of the ESP 112 and / or other ESPs (e.g., from the I / O devices 132-136). These parameters may include motor current, motor voltage, motor load, leakage current, motor temperature, motor output power, pump suction pressure, pump discharge pressure, wellhead pressure, flow rate, etc. Preferably, the historical data set is specific to a particular ESP 112 so that the performance of the (initially generic) ML model 224 can be customized with respect to that ESP. In either case, the training teaches the ML model 124 to recognize patterns in the data that, if not corrected, suggest that an event is currently occurring or will occur within a certain time.

[0055] In some embodiments, training can be performed using a self-supervised learning approach in which labeled historical data is applied as input to the ML model. Labeling refers to the process of annotating or describing data and creating labels or tags for the data. Training can be performed off-site (e.g., on the OPC 154) or at the well site 100, and can include using commercially available ML training tools to develop and validate the ML model. Developing the ML model on the OPC 154 or some other computing cluster platform has the additional spillover that the availability of enhanced hardware resources thereon provides high computing power, which proves useful during the training phase. Data preprocessing and preparation are a critical part of this process, as correctly labeled data is required to produce highly accurate ML models.

[0056] The marked or tagged historical data is then used to train a general ML model that is initially neutral with respect to the type of ESP in order to extend the capabilities of the trained model to generalized data generated by any type of ESP. Examples of general ML models that can be trained include Convolutional Neural Networks (CNN), Siamese Neural Networks, Support Vector Machines (SVN), Autoencoder Neural Networks, etc. Model predictions can optionally be aggregated using ensemble modeling techniques that give models more weight based on their accuracy for a given problem class. The trained ML model 224 is then evaluated against another training data set that was not used for validation purposes during the initial model training phase. Depending on the desired level of prediction accuracy (i.e., quality of service), the training phase can be repeated until satisfactory results are achieved. Model performance can be improved by improving data preprocessing techniques (such as requiring the use of high-resolution data), increasing the number of data sets, etc.

[0057] exist Figure 4In the example of , the historical data set helps the ML model 224 recognize that when a certain parameter or combination of parameters (e.g., motor leakage current, motor temperature, etc.) exhibits a particular behavior 406, such as a slope or a certain combination of slopes exceeding a particular correlation threshold within a given time window, if no corrective action is taken, event 1 (e.g., pump shaft breakage) typically occurs within a certain amount of time 408 or within an event occurrence time. Similarly, the historical data set can help the ML model 224 recognize that when another parameter or combination of parameters (e.g., pump suction pressure, pump discharge pressure, etc.) exhibits another behavior 410, if no corrective action is taken, event 2 (e.g., blocked pump suction) typically occurs within a specific event occurrence time 412. Pattern recognition training (and subsequent inference) can be performed incrementally for data points, such as within a 1 minute window, a 10 minute window, a 30 minute window, or some other selected time increment.

[0058] After achieving satisfactory results from the learning phase, the trained and validated ML model 224 can be deployed to the edge gateway 138. In some embodiments, the model is deployed with the commissioning of the edge gateway 138 when the edge gateway 138 is connected to the PAC 130 (i.e., not connected to the cloud). Although edge gateways generally have higher processing power than typical PACs, the type of ML model that can effectively operate on each type of edge gateway 138 should be considered to help provide a satisfactory response time for prediction or inference purposes. This helps ensure that the response time of the ML model is fast enough to identify any abnormal data in a timely manner so that effective actions can be taken automatically or by an operator.

[0059] Once the ML model 224 and its supporting components are deployed on the edge gateway 138, real-time prediction or inference can begin with the gateway receiving data from the PAC 130. The edge gateway 138 receives data from the PAC 130 in real time as raw data points reflecting measurements of various parameters, and then pre-processes (e.g., filters, smoothes, amplifies, etc.) the data points using the pre-processing module 222 of the monitoring and control application 220. The ML model 224 deployed on the edge gateway 138 then processes the data points to infer various events therefrom and outputs information about any inferred events. The response action module 226 receives the output and takes certain selected actions based on the output, including issuing an immediate flag to the SCADA system 142. In some embodiments, the output from the ML model 224 is also provided as feedback to the PAC 130 to take programmed corrective actions, such as adjusting the motor speed of the ESP 112 or cutting off the power to the ESP.

[0060] In some embodiments, the ability of ML model 224 to accurately infer various events from data using multivariate correlations is based on the extension of pairwise probability calculation techniques to multiple parameters, such as Figure 5-Figure 8 As shown and described.

[0061] Now go to Figure 5 , as background, an exemplary data graph 500 is shown reflecting data points for two parameters, variable 1 (e.g., discharge pressure) and variable 2 (e.g., flow), where one parameter is dependent on or correlated with the other parameter. A distribution of typical or statistically likely data points along variable 1 is indicated at 502, with statistically unlikely outliers indicated at 504, and a distribution of typical or statistically likely data points along variable 2 is indicated at 506, with statistically unlikely outliers indicated at 508. Region 510 defines the distribution of statistically likely data points within graph 500. By analyzing the distribution of data points for various parameters collected over time, a model can be developed based on the time rate of change or slope of the parameters using the statistically likely data point distributions.

[0062] Figure 6 is an exemplary probability graph 600 showing the probability of Figure 5 The probability of a parameter having a given slope based on the distribution of the data points for the parameter (i.e., the evolution from stable normal operation to abnormal operation). In the figure, ellipse 602 represents the region where the slope of the parameter is likely to be found within a 2-sigma confidence level (i.e., within a 95% confidence range) under normal operating conditions. In other words, a parameter having a slope within this region 602 indicates that the ESP is likely to be stable or operating normally. Conversely, circle 604 indicates a region where the slope of the parameter is less likely to be found. A parameter having a slope within this region 604 indicates that the ESP is likely to be unstable or operating abnormally (e.g., due to a surface shut-in).

[0063] The above probability can be determined by calculating the Mahalanobis distance d of the data in a manner known to those skilled in the art, as follows:

[0064] d=(x-μ)∑ -1 (x-μ) (1)

[0065] In equation (1), x is the state vector representing the slope of a given parameter, and μ is the mean of the state vector. The probability P of finding the slope in a given region can be determined by equation (2):

[0066] P = 1-χ 2 (d) (2)

[0067] Better modeling performance has been observed when the correlations are extended to more than two parameters and then mathematically combined (e.g., averaged), e.g. Figure 7700, one of which is indicated at 702, showing the distribution of data points for several pairs of parameters, including flow, wellhead pressure, pump discharge pressure, and pump suction pressure. The probability slope of each parameter in relation to one of the other parameters is represented by Pn,m. For example, the probability that the flow rate slope is related to the wellhead pressure is represented by P1,2, while the probability that the flow rate slope is related to the pump discharge pressure is represented by P1,3, and so on. The composite probability P can then be determined by averaging or mathematically combining the component probabilities, generally represented by Equation 3:

[0068] P= <P ij > (3)

[0069] Then you can set the initial threshold, such as Figure 8 As shown, this allows the correlation-based ML model 224 to detect slopes (based on historical data) that reflect events that are currently occurring or will occur within a certain period of time. Figure 8 , an initial correlation database 800 (or a portion thereof) is shown, which contains threshold slopes 802 (rows) in degrees for multiple well operating parameters (columns). Based on the statistical correlations discussed above, these threshold slopes 802 are considered to be strongly indicative of or associated with certain types of known events (causes) 804 at the well site, and can be minimum or maximum thresholds depending on the specific parameters. There may be multiple rows of slopes corresponding to the same type of event (cause) 804. If the slope derived from the data is close enough to the entry in the database, the correlation database 800 can be used to automatically identify events from the input data. The database 800 can be updated and enriched over time automatically and via manual user feedback, which allows less human intervention for known types of events.

[0070] The user may modify one or more threshold slopes 802 from time to time as desired, for example, based on real-world experience or observation. The type of event 804 reflected by the slope may also be defined (and redefined) by the user from time to time as desired. For example, a newly detected (unassigned) event based on the data may be associated with an existing event based on a specified slope difference parameter. Thus, a decision to associate a newly detected (and not yet assigned) event with an event type already present in the database 800 may be made based on the degree of difference between the slope of each signal of the newly detected event and the slope of the corresponding signal of the event already present in the correlation database 800. The degree of difference required before an unassigned event can be identified as the same type of event as in the database 800 may be adjusted as desired by adjusting, for example, a specified slope difference parameter for each signal.

[0071] Fig. 9 According to the embodiment of the present disclosure, Figure 4Flowchart 900 of the operational stages of the ML model 224. Here, the training stage 402 and the prediction stage 404 are shown as functional blocks, and the training stage 402 is broken down into several smaller steps, including an initial setup step 902, a visualization step 904, a user feedback and modification step 906, and a model training step 908. The prediction stage 404 mainly includes a step 910 of running the ML model 224 to provide real-time analysis and detection or prediction of events (i.e., fault prediction).

[0072] The initial setup step 902 mainly includes preprocessing, including labeling, of a training data set that will be used to train the ML model 224 for event detection or prediction. The initial setup begins by using a default set of schematic-based slope thresholds 912 from one or more historical data sets as a starting point. In some embodiments, the initial slope thresholds are stored in a file similar to Fig.12 The table depicted. Such a table is sometimes colloquially referred to as a "diagnostic diagram" because the slopes in the table are (or can be) derived from a graph used to graphically illustrate various well operating parameters (including ESP parameters). In some embodiments, the user can modify the thresholds and add or remove events during the initial setup before training begins. The resulting thresholds 914 are then stored as updates to the table or diagnostic diagram. Specialized thresholds reflecting abnormal events 916 and outages 918 from previous detections can also be added to the correlation database at this time.

[0073] Next, in a visualization step 904, a diagnostic diagram 920 is generated for a portion or a fixed length of the data set, which may be the entire data set, showing detected events and outage detections. In some embodiments, threshold events (i.e., events corresponding to thresholds), abnormal events, and outages may be displayed in different colors.

[0074] In the user feedback step 906, the user can label the thresholds and modify any thresholds on the diagnostic diagram as the user deems appropriate, thereby generating a modified diagnostic diagram 922. For example, the user can add or remove events, such as removing false positives, by clicking on the event and modifying the event (including providing a new label for the event). Any abnormal events 916 and shutdowns 918 added can be labeled at this time. The user then clicks the "Apply" button (if applicable) to apply the changes, which will also add a timestamp to the file storing the data. Otherwise, the user can simply restart the monitoring and control application to apply the changes provided by the user.

[0075] Once the training data set is labeled, the model training step 908 begins. In this step, the labeled training data set is used to determine how to use the above reference Figure 4The ML model 224 is trained and validated by performing event detection and prediction in a manner described in detail. Once the ML model 224 is trained and validated, the model execution step 910 can be performed by deploying the ML model 224 to the edge gateway 138 for real-time event detection or prediction, such as Fig.10 shown.

[0076] Fig.10 A method using a sliding time window is graphically depicted, which an edge gateway 138 at a well site can execute to detect or predict an event. The method includes receiving data from or about an ESP 112 at an edge gateway 138 in real time, shown here in real time in the form of a schematic diagram 1000. In some embodiments, the data can be streamed to the edge gateway 138 in real time, or it can be provided to the edge gateway 138 on a pre-arranged basis. Several exemplary graphs are shown in the schematic diagram 1000, each graph line representing an operating parameter associated with the ESP, including a wellhead pressure 1002, a pump discharge pressure 1004, a fluid flow rate 1006, and a motor leakage current 1008. Upon receipt, the edge gateway 138 inputs these graph lines, or more precisely, the data below the graph lines, into the ML model 224. The ML model 224 then processes the data to detect an event from the data pattern therein. As previously described, one method of detecting an event is to check whether the slope of a given operating parameter or the slope of a combination of operating parameters matches any slope or slope combination in the diagnostic diagram. The slope of the graph line can be determined by fitting a line segment to the graph line using a curve fitting technique and then determining the slope of the line segment. Box 1010 shows an example of a line segment 1012 that has been fitted to a portion of the graph line 1008. The slope of the line segment 1012 can be expressed in degrees (e.g., -52.2 degrees) or as a ratio of vertical distance to horizontal distance. Thereafter, the ML model 224 examines the slopes from each graph line or combination of graph lines to identify patterns that indicate an event (e.g., solids / sand ingestion, gas ingestion, pump wear, holes in a pipe, motor / cable degradation, open choke, etc.) is currently occurring or has occurred within a certain period of time.

[0077] In some embodiments, event detection or prediction is performed stepwise for the data, as described above. This can be seen in the form of a time window 1014 starting at time t, a second time window 1016 starting at time t+1, etc. Slope determination can then be performed for each chart line on a per-window basis (i.e., one slope determination per window), or multiple slopes can be determined for a given chart line within a given window, and then mathematically combined (e.g., averaged) according to the frequency of data changes. The time window preferably has a uniform size (indicated by the label "window") and is preferably incremented in uniform steps (indicated by the label "stride"). The window size and increment step can be selected according to the needs of the specific application and can be on the order of seconds, minutes, hours, or days. In some embodiments, a window size and increment step based on a certain number of data points (e.g., for low-resolution data) rather than a time interval can also be used.

[0078] Fig.11 1100 is another diagram that graphically depicts in more detail a real-time event detection or prediction method performed by an edge device 138 using an ML model 224. In this view, there are several time windows, as shown at 1102, 1104, and 1106. For each graph line within each window, the slope determined by the ML model 224 is represented by a line segment, one of which is indicated at 1108. The different slopes or combinations of slopes for each window 1102, 1104, and 1106 are then compared to thresholds in the diagnostic diagram (see, e.g., Fig.12 ) to perform event detection or prediction. For example, in the first window 1102, the slope of each graph line is relatively flat and therefore does not meet or exceed any threshold in the diagnostic diagram. On the other hand, the combination of slopes in the second window 1104 indicates a high probability that event 1 (e.g., an open throttle) will occur within a given amount of time, while the combination of slopes in the third window 1106 indicates a high probability that event 2 (e.g., a blocked pump discharge) will occur within a given amount of time.

[0079] Fig.12 12 is a table 1200 showing exemplary schematic diagnostic thresholds (or portions thereof) that may be entered (see Fig. 9 914 in Table 1200) and are used by the schematic-based ML model 224 to perform event detection or prediction. Based on previous work done in the field and / or previously published results from real-world wellsite data, these threshold slopes (such as the threshold slopes shown in column 1202) are considered to be strongly indicative of known events or associated with certain types of known events (such as the known events listed in column 1204). In some cases, one or more of the slope thresholds in table 1200 may be associated with a known event from a wellsite. Figure 8It is possible and expected that one or more slope thresholds of the correlation database 800 in the example 1202 may coincide or overlap. These slope thresholds 1202 may be modified from time to time according to the needs of the user.

[0080] Table 1200 in this example also includes a time window column 1206, which shows the time window in which the event is preferably detected or predicted, and the operating parameters associated with event detection or prediction. Thus, for example, the broken shaft event is preferably predicted within a 6-hour window or a 12-hour window. The operating parameters in this example include flow rate 1208, wellhead pressure 1210, pump discharge pressure 1212, pump suction pressure 1214, and motor speed 1216. Other parameters may certainly be included within the scope of the present disclosure. In this example, if the slope of the underlying data exceeds the (minimum or maximum) slope listed in the operating parameters 1208-1216 (e.g., -20, -20, 20, and 0) or some combination thereof within a 6-hour or 12-hour time window, the ML model 224 will detect the broken shaft event. In some embodiments, rather than using a specific numeric value for the slope (e.g., degrees, ratio, etc.), a range of slopes may be used, such as -10 to -20, or descriptive categories may be applied to the slope, such as "stable," "slightly decreasing," "slightly increasing," "step-increasing change," etc.

[0081] Fig.13 1300 is a diagram illustrating a method of detecting events in accordance with some embodiments, in which the correlation-based and / or schematic-based ML model 224 uses several time windows, each with a different duration. The different durations allow for the detection or prediction of events with different priorities or urgency. For example, the ML model 224 may use a time window 1302 with a shorter duration (e.g., 1 minute) to detect or predict high priority events or events that may cause near-term failures. Conversely, the ML model 224 may use a second time window 1304 with a medium duration (e.g., 15 minutes) to detect or predict medium priority events or events that may cause long-term failures. The ML model 224 may also use a third time window 1304 with a longer duration (e.g., one hour) to detect or predict all other events.

[0082] Figures 14A-14HAn exemplary user interface 1400 is shown that may be used with a monitoring and control application 220 running on an edge device 138 in accordance with an embodiment of the present disclosure. The user interface 1400 allows an operator to monitor a wellsite in real-time based on well operating parameters that are streamed in real-time to the edge device 138. The user interface 1400 may also be used for model training purposes by inputting historical data sets to the edge device 130 and having the ML algorithm 224 learn from the data using operator feedback and adjustments to the data provided through the user interface.

[0083] First reference Fig.14A , at 1402, well operating parameters (including ESP parameters) received (or capable of being received) by the edge device 138 are listed by type. In some embodiments, the operating parameters 1402 may be color coded or otherwise visually distinguished to allow an operator to individually identify each parameter. It should of course be understood that other parameters known to those skilled in the art may also be used in addition to the parameters shown in 1402. Then, at 1404, the user interface 1400 reproduces or displays these operating parameters in a graphical manner. The time scale displayed in this example is in days, but different time scales (e.g., minutes, hours, weeks, etc.) may certainly be used. A set of options indicated at 1406 allow the user to select specific types of data to be displayed, such as production data, electrical data, etc., and to hide unselected data. Event filter options 1408 allow the user to specify the types of events to be displayed. In this example, the user can select from events detected via manual user feedback, correlation-based events, schematic-based events, and jumps. Selecting correlation-based events causes the user interface 1400 to display events detected using correlation, such as Fig. 14B shown.

[0084] exist Fig. 14B , user interface 1400 shows two correlation-based events detected from data by monitoring and control application 220 of edge device 138, as shown at 1410 and 1411. Time windows 1412 and 1413 for events 1410 and 1411 are also shown. In this example, ML model 224 in monitoring and control application 220 responsible for (trained to) detect correlation-based events has detected abnormal or unusual behavior from the data within the time window, but has not yet actively matched the behavior to known events in the correlation database, so events 1410 and 1411 have been designated as "unassigned."

[0085] Fig. 14CAn example is shown where the operator additionally selects a schematic-based event from the event filter 1408. As can be seen, the user interface 1400 now displays two schematic-based events 1414 and 1415 and the two correlation-based events 1410 and 1411 from the previous figure. When the schematic-based and correlation-based models detect an event within the same or overlapping time windows, this indicates that the event is likely to be real (i.e., not a false positive). The ML model 224 responsible for (trained to) detect schematic-based events in the monitoring and control application has positively identified from the data that the same anomaly or abnormal behavior is a perforation blockage (i.e., a perforation in the pipe is blocked, thereby preventing fluid from moving freely through the hole). Note that clicking on any event or hovering the cursor over any event will bring up a pop-up box 1416 that displays additional details about the event, such as the start and end date / time, the data source, the ML model used to detect the event, etc.

[0086] Fig.14D An example of an operator additionally selecting an event identified through user feedback is shown. One such event is displayed at 1418 along with a time window 1420 for that event. In some embodiments, each time window may have a different color or be visually distinct from the other time windows for ease of reference. Create event button 1422 allows the operator to manually create an event. This option is particularly useful when the operator knows or strongly suspects that an event has or will occur through visual inspection of the data (e.g., based on previous experience, etc.), but neither the correlation-based ML model nor the schematic-based ML model has detected the event. In this case, the operator can click on Create event button 1422 to add the event, as shown in the figure. Fig.14E shown.

[0087] exist Fig.14E , an operator has selected a data point 1424 on one of the graph lines, wherein the graph line represents an operating parameter that the operator believes is indicative of an event. Selecting an event type option 1426 allows the operator to select an event type, such as an electrical event. Selecting a duration option 1428 allows the operator to select a time window for the event, such as 3 hours, 6 hours, 12 hours, etc. Selecting an add event option 1430 causes the user interface 1400 to add the selected data point 1424 as a user feedback event, such as Fig.14F shown.

[0088] exist Fig.14F, the user interface 1400 now displays the selected data point 1424 as an electrical event 1424 with a 6 hour time window 1432, as selected by the operator. The user interface 1400 also automatically adds this user created event 1424 to the database for use in the correlation based model and the schematic based model that will be used for future pattern recognition. In addition to adding events, the operator can also modify any event by selecting the event and selecting an event type for the event, such as Figure 14G shown.

[0089] exist Figure 14G In the example of FIG. 1400 , an operator has selected one of the “unassigned” events identified by the correlation-based model ( 1410 and 1411 ). Based on previous experience, the operator knows or strongly suspects that the data underlying the event reflects a surface shut-in event (i.e., the well has been shut in at the surface). Therefore, the operator can select a surface shut-in type for the event to assign an event type to the event. Thereafter, the user interface 1400 causes the event type of the event to be changed to the selected type and also updates the database of the ML model to reflect that the underlying data represents a surface shut-in event. In this way, the operator can help improve the recognition accuracy of the model.

[0090] User interface 1400 may also display "jump" type events. Fig.14A Recall that the event filter option 1408 allows the user to specify which type of event or events are displayed, including events detected via manual user feedback, correlation-based events, schematic-based events, and jumps. Jumps are essentially changes between time steps in time series data, like data representing various well operating parameters 1402. Techniques for detecting jumps are well known to those skilled in the art and may include, for example, open source libraries available from Arundo Analytics, Inc. of Houston, Texas, USA. Such jumps may be visualized by the user interface 1400 as a stacked bar chart.

[0091] Reference again Figure 14G , a set of stacked bar graphs are shown at 1436 representing jumps in the time series data of the well operation parameter 1402. In this example, each bar graph represents the number of jumps seen in the selected time series data set on a given date. If the user selects a different set of time series data, the user interface 1400 updates the bar graph 1436 to reflect the number of jumps seen in the selected data. Generally speaking, the greater the number of jumps, the greater the probability that the detected event is a real event. Selecting (e.g., by double-clicking, clicking, etc.) one of the bar graphs causes the user interface 1400 to zoom in on the portion of the data reflected by the selected bar graph, such as Fig.14H shown.

[0092] exist Fig.14H In the example of FIG. 14 , user interface 1400 zooms in on the data of the selected bar graph (e.g., Figure 14G 1436a-c), as shown in a smaller time scale 1438 (i.e., hours rather than days). From this view, the user can see that the selected jump contains three separate jumps, as shown in 1436a-c, which are stacked one on top of the other. The user interface 1400 also displays a jump line 1440 that graphically represents the jump in the data. Clicking or hovering the cursor over any point on the line causes the user interface 1400 to display a pop-up box 1442 that contains the details behind the jump, such as date / time, data type, etc.

[0093] Fig.15 15 is an optional user interface 1500 of the monitoring and control application 220 of the edge gateway 138, which can be displayed to an operator. The user interface 1500 again presents the operator with a graphical visualization of data 1502 flowing from or around the ESP 112. The user interface 1500 also displays a probability line 1504 that indicates the likelihood of any event or fault detected by the ML model in the monitoring and control application 220. In general, the higher the probability line 1504, the greater the probability of the event occurring.

[0094] exist Fig.15 In the example of , the ML model 224 has detected a slope or combination of slopes in the streaming data 1502 that reflects the occurrence of a sand ingestion event within approximately two days. The event is indicated by a peak 1506 in the probability line 1504, accompanied by an alert 1508 indicating the event. The event is also displayed in the user interface 1500 as a shaded area 1510. The ML model 224 has also detected a slope or combination of slopes in the streaming data 1502 that reflects the occurrence of a failure event within approximately two and a half days. The event is indicated by a peak 1512 in the probability line 1504, accompanied by a warning 1514 indicating the event. The event is also displayed in the user interface 1500 as a shaded area 1516. The operator can then select any of these events or their alerts and alarms to view the details of the event (e.g., underlying data, slopes, etc.), as shown. Fig.16 shown.

[0095] exist Fig.16, the operator has selected the event indicated at 1506, which causes the user interface 1500 to call up a failure probability graph 1600 for that event. The failure probability graph 1600 presents the user with a graphical visualization of the failure probability of the event 1506 detected by the ML model 224 as a function of the event occurrence time, as indicated by line 1602. From the graph 1600, the user can see the details of the distribution of the failure probability over time. Thus, in this example, the failure probability is highest over the next 10 to 20 hours and then gradually decreases thereafter.

[0096] Based on the foregoing, it can be appreciated that the edge gateway with ML-based analytics discussed herein can be deployed in a variety of ways, including as a standalone on-premises solution where the edge gateway has no connectivity to a cloud platform. Such a standalone solution integrates seamlessly with an existing or new SCADA system, where feedback from the edge gateway can be used in a centralized manner to support real-time decisions that help improve operational efficiency. An on-premises solution is preferable in situations where there is limited or no WAN connectivity, or where operators are reluctant to expose data on a cloud platform over a public Internet connection for data security purposes.

[0097] Alternatively, edge gateways with ML-based analytics can leverage full cloud connectivity, where multiple such gateways can be maintained and managed through a cloud platform. This option allows real-time data collected from multiple edge gateways to be used to retrain ML models, enabling more accurate applications at the edge. This retraining process can be automated as long as the model accuracy reaches a predefined level, and the retrained model can be deployed to multiple gateways based on a preset schedule.

[0098] In the foregoing discussion, reference has been made to various embodiments. However, the scope of the present disclosure is not limited to the specific described embodiments. On the contrary, any combination of the described features and elements, whether or not related to different embodiments, is contemplated to implement and practice the intended embodiments. In addition, although the embodiments may achieve advantages over other possible solutions or prior art, whether a particular advantage is achieved by a given embodiment does not limit the scope of the present disclosure. Therefore, the foregoing aspects, features, embodiments, and advantages are merely illustrative and are not considered to be elements or limitations of the appended claims unless expressly stated in the claims.

[0099] The various embodiments disclosed herein may be implemented as systems, methods, or computer program products. Thus, various aspects may take the form of a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which are generally referred to as "circuits," "modules," or "systems." In addition, various aspects may take the form of a computer program product contained in one or more computer-readable media having a computer-readable program code contained thereon.

[0100] Any combination of one or more computer-readable media can be utilized. Computer-readable media can be non-transitory computer-readable media. Non-transitory computer-readable media can be, for example but not limited to, electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. More specific examples (non-exhaustive list) of non-transitory computer-readable media can include the following: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, radio frequency, etc., or any suitable combination of the foregoing.

[0101] The computer program code for performing the operations of various aspects of the present disclosure may be written in any combination of one or more programming languages. In addition, such computer program code may be executed using a single computer system or through multiple computer systems that communicate with each other (e.g., using a dedicated local area network (PAN), a local area network (LAN), a wide area network (WAN), the Internet, etc.). Although the various features described above are described with reference to flowcharts and / or block diagrams, it will be understood by those of ordinary skill in the art that each box of the flowcharts and / or block diagrams and the combination of boxes in the flowcharts and / or block diagrams may be implemented by computer logic (e.g., computer program instructions, hardware logic, a combination of both, etc.). Typically, computer program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device. In addition, execution of such computer program instructions using a processor generates a program capable of executing the flowcharts and / or block diagrams. Figure 1 One or more boxes specify the function or action of a machine.

[0102] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, function and / or operation of various embodiments of the present disclosure. In this regard, each frame in the flow chart or block diagram can represent a module, a code segment or a code portion, which includes one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions mentioned in the frame may not occur in the order mentioned in the figure. For example, the two frames shown in succession can actually be performed substantially simultaneously, or these frames can sometimes be performed in reverse order, depending on the functions involved. It will also be noted that each frame of the block diagram and / or flow chart illustration and the combination of frames in the block diagram and / or flow chart illustration can be implemented by a system based on special-purpose hardware or a combination of special-purpose hardware and computer instructions that performs a specified function or action.

[0103] It should be understood that the above description is intended to be illustrative rather than limiting. After reading and understanding the above description, many other embodiments are apparent. Although the present disclosure describes specific examples, it should be appreciated that the systems and methods of the present disclosure are not limited to the examples described herein, but can be modified to be implemented within the scope of the appended claims. Therefore, the description and the drawings are to be considered illustrative rather than restrictive. Therefore, the scope of the present disclosure should be determined with reference to the appended claims and the full scope of equivalents to which these claims are assigned.

Claims

1. An edge device installed at a well site and operable to monitor well site operations, comprising: processor; and A storage device coupled to the processor and storing thereon computer-readable instructions for a wellsite monitoring and control application, which, when executed by the processor, cause the edge device to perform the following operations: receiving wellsite data from a remote programmable automation controller (PAC) at the wellsite, the wellsite data representing one or more operating parameters associated with the wellsite operation; Using the wellsite data from the automation controller PAC, performing machine learning (ML)-based analysis on the edge device at the wellsite, the edge device being arranged between the automation controller PAC and a network at the wellsite and operable to provide access or entry from the wellsite to the network, the network comprising a local area network (LAN), a wide area network (WAN), or a metropolitan area network (MAN); detecting, on the edge device, the occurrence of an event related to the wellsite operation based on machine learning (ML)-based analysis; and Initiate a response action on the edge device based on the one or more events, wherein the one or more machine learning (ML) models include a machine learning (ML) model that detects events using one or more of correlation-based detection and diagnostic schematic-based detection, and wherein the monitoring and control application causes the edge device to perform diagnostic schematic-based detection by fitting a line segment to the wellsite data and determining a slope of the line segment.

2. The edge device according to claim 1, wherein: The wellsite operations include pump operations performed by an electric semi-submersible pump ESP at the wellsite.

3. The edge device according to claim 2, wherein: The wellsite data includes data related to pump operations performed by an electric semi-submersible pump ESP at the wellsite.

4. The edge device according to claim 3, wherein: The monitoring and control application enables the edge device to perform machine learning (ML) model-based analysis by streaming wellsite data into one or more machine learning (ML) models in real time.

5. The edge device according to claim 1, wherein: The detection of the event is performed by comparing the slope of the line segment to a predefined slope threshold.

6. The edge device according to claim 5, wherein: The monitoring and control application enables the edge device to allow an operator to modify a slope threshold and an event corresponding thereto within the predefined slope threshold.

7. The edge device according to claim 6, wherein: The monitoring and control application enables the edge device to perform machine learning (ML) based analysis step by step using a predefined time window.

8. The edge device according to claim 7, wherein: The predefined time windows include time windows having different durations based on the priority of the detected event.

9. A method for monitoring wellsite operations, comprising: receiving wellsite data from a remote programmable automation controller (PAC) at the wellsite, the wellsite data representing one or more operating parameters associated with the wellsite operation; Performing machine learning (ML)-based analysis on an edge device at the wellsite using the wellsite data from the automation controller (PAC), the edge device being arranged between the automation controller (PAC) and a network at the wellsite and operable to provide access or entry from the wellsite to the network, the network comprising a local area network (LAN), a wide area network (WAN), or a metropolitan area network (MAN); detecting, on the edge device, the occurrence of an event related to the wellsite operation based on machine learning (ML)-based analysis; and Initiate a response action on the edge device based on the one or more events, Wherein, the one or more machine learning ML models include a machine learning ML model that detects events using one or more of correlation-based detection and diagnostic schematic-based detection, and wherein the diagnostic schematic-based detection is performed by fitting a line segment to the wellsite data and determining the slope of the line segment.

10. The method according to claim 9, wherein: The wellsite operations include pump operations performed by an electric semi-submersible pump ESP at the wellsite.

11. The method according to claim 10, wherein: The wellsite data includes data related to pump operations performed by an electric semi-submersible pump ESP at the wellsite.

12. The method according to claim 11, wherein: Performing machine learning (ML) based analysis includes streaming wellsite data into one or more machine learning (ML) models in real time.

13. The method according to claim 9, wherein: Detection of an event is performed by comparing the slope of the line segment to a predefined slope threshold.

14. The method of claim 13, further comprising allowing an operator to modify the slope threshold and the event corresponding thereto in the predefined slope thresholds.

15. The method according to claim 14, wherein: The machine learning ML based analysis is performed step by step using a predefined time window.

16. The method according to claim 15, wherein: The predefined time windows include time windows having different durations based on the priority of the detected event.

17. A non-transitory computer readable medium containing program logic that, when executed by operation of one or more computer processors, performs the wellsite monitoring operation according to any one of claims 9 to 16.

Images