Patent Application
20190287005
An oil and gas production environment can include multiple well sites, each configured with one or more electrical pumping systems that are used to collect oil for further processing and distribution. The pumping systems can include a variety of machinery used in the production process, such as electrical submersible pumps (ESPs). The ESPs can be configured to include sensors capable of transmitting sensor data that can be used to monitor operating conditions of the pump. The operating conditions can indicate the current performance or operational state of the ESP at a specific and immediate moment in time.
An ESP can experience a wide variety of operating conditions over its operational lifetime that are associated with the mechanical, electrical and fluidic operation of the ESP. Monitoring ESP operational data can be a valuable practice to ensure ESPs are performing as specified within stable operating conditions. Unstable or undesirable operating conditions can reduce the performance of the ESP and thereby reduce an amount of remaining useful life for the ESP to remain in operation. Anomalous operating conditions can cause ESP shutdowns when operating conditions are determined to be outside of safe or expected operating condition ranges. ESP shutdowns can reduce the oil or gas production for a particular well site which can increase maintenance and production costs and strain already reduced workforces.
Machine learning is an application of artificial intelligence that automates the development of an analytical model by using algorithms that iteratively learn patterns from data without explicit indication of the data patterns. Machine learning is commonly used in pattern recognition, computer vision, language processing and optical character recognition and enables the construction of algorithms that can accurately learn from data to predict model outputs thereby making data-driven predictions or decisions. Machine learning can be utilized to develop a predictive model capable of determining and generating diagnostic and prognostic data for an electrical pump based on operational data of the pump.
In one aspect, methods for are provided. In one embodiment, the method can include receiving operational data associated with an operating condition of a pump. The method can also include determining prognostic data using the received operational data and a first predictive model trained to receive operational data and, in response to the receiving, generate prognostic data associated with the pump. The prognostic data including a plurality of metrics associated with the pump and predicted in relation to the operational data. The method can further include transmitting the prognostic data. The method can also include performing at least one of the receiving, the determining, and the transmitting by at least one data processor forming part of at least one computing system.
Non-transitory computer program products (i.e., physically embodied computer program products) are also described that store instructions, which when executed by one or more data processors of one or more computing systems, causes at least one data processor to perform operations herein. Similarly, computer systems are also described that may include one or more data processors and memory coupled to the one or more data processors. The memory may temporarily or permanently store instructions that cause at least one processor to perform one or more of the operations described herein. In addition, methods can be implemented by one or more data processors either within a single computing system or distributed among two or more computing systems. Such computing systems can be connected and can exchange data and/or commands or other instructions or the like via one or more connections, including a connection over a network (e.g. the Internet, a wireless wide area network, a local area network, a wide area network, a wired network, or the like), via a direct connection between one or more of the multiple computing systems, etc.
These and other features will be more readily understood from the following detailed description taken in conjunction with the accompanying drawings, in which:
It is noted that the drawings are not necessarily to scale. The drawings are intended to depict only typical aspects of the subject matter disclosed herein, and therefore should not be considered as limiting the scope of the disclosure.
Electrical submersible pumps (ESPs) are an efficient and reliable artificial-lift device configured to bring moderate to high volumes of fluids to the surface from the wellbores in which they are submerged. ESPs are frequently interfaced to sensors that are configured to collect operational data pertaining to a particular operating condition or measurement variable associated with the ESP. Typically, such sensor data can provide operators with insight about the condition, production rate, and operational performance of the ESP itself as well as specific components of the ESP.
However, the ESP sensor data is limited to data that has been received in the past or in the present moment and thus is associated with the historical or recent operating conditions. In this way, the sensor data provides limited insight into the future operational performance or remaining operational lifespan of an ESP. Oil and gas production operators need systems and methods that can be configured to provide insight into future operating conditions such as the remaining operational lifespan, also known as a remaining useful life, of an ESP. Being able to determine future operating conditions of ESPs would allow operators to better mitigate and plan for ESP failures which can be expensive and require complex logistical efforts to source, install and configure of ESP replacements in order to restore a well site to full production capacity. Providing operators with future operating condition data allows the operators to source replacement ESPs or parts in advance, better manage ESP resources, and minimize ESP down-time.
While determining an amount of remaining useful life for an ESP may address longer term ESP operation, oil and gas production operators also require systems and methods to monitor and diagnose more immediate conditions of ESP operation. The received sensor data can include large amounts of operational data from many ESPs or ESP components that can be challenging to review and manage manually. While ESP diagnostic systems can be automated to reduce the manual burden of reviewing the large volume of sensor data, such systems can require extensive manual configuration to input operating condition thresholds used to evaluate the sensor data for anomalous operating conditions. One drawback to such systems is the need to define the anomalous operating conditions in advance and to tune the operating condition thresholds to adequately detect when an ESP is operating outside of its desired or specified operating conditions. For example, traditional ESP diagnostic systems may evaluate threshold violations for a single operating condition variable or multivariate behavior for groups of operating condition variables. This can increase the costs and complexity of the condition monitoring system itself and require a more technically skilled workforce to deploy and operate such systems. In addition, such systems can be limited to detect only previously known anomalies and can be unable to determine anomalous data because the system has not been configured with prior knowledge of the characteristics of an anomalous operating condition or a particular ESP or sensor which may be providing the anomalous data.
An improved ESP diagnostic and prognostic system can be configured to receive operational data from one or more ESPs and to automatically determine prognostic data associated with longer-term operating conditions, such as an amount of remaining useful life. The improved ESP diagnostic and prognostic system can also be configured to determine diagnostic data associated with more near-term operating conditions, such as one or more anomalies associated with sensor data that can be received from an ESP or a component of an ESP. Such an improved ESP diagnostic and prognostic system can provide oil and gas production operators with greater insight into the current operating conditions of ESPs deployed at a well site and can also aid forecasting future operational capacity based on the amount of useful life remaining in an ESP. The improved ESP diagnostic and prognostic system can generate data about current and future operating conditions to assist operators in planning inventories of replacement parts, determining schedules and logistics for replacing ESPs or the ESP components, while maintaining production of a well site at acceptable and profitable levels.
Thus, systems and methods to automatically determine and generate ESP diagnostic and prognostic data based on ESP operational data may significantly increase the operational performance and longevity of ESPs deployed at a well site. In addition, an improved ESP diagnostic and prognostic system can reduce the number of skilled resources required to detect and characterize sensor data in order to determine anomalous operating conditions. For example, operational data received from sensors coupled to an ESP or its components can be received and processed by the improved ESP diagnostic and prognostic system and the results can be provided in a graphical user interface (GUI) configured to display diagnostic data, such as anomalous sensor data, and/or prognostic data, such as metrics related to amounts of operational capacity remaining in the ESP or its components. Without an improved system as will be described further herein, substantial computing resources would be required to collect sensor data from each ESP and/or its components and to process the data to determine diagnostic and prognostic data and to provide the data for display in a single, unified GUI allowing users to view and interact with the data.
An ESP diagnostic and prognostic system is provided herein including systems, methods, and computer-readable mediums for determining and generating diagnostic and prognostic data for an ESP based on operational data collected from sensors coupled to the ESP. The generated diagnostic and prognostic data are determined and generated by a predictive model that has been trained in a machine learning process to receive operational data associated with an ESP or its components and to generate diagnostic data, including anomalous operating conditions related to an ESP or its components, and prognostic data, including measurements of remaining useful life of the ESP or its components. The ESP diagnostic and prognostic system can also include a GUI to present the diagnostic and prognostic data for one ESP or a fleet of multiple ESPs in a dashboard-like display that can be configured based on user preferences. The GUI can be configured to allow users to interact with the data, for example by filtering or sorting the data. The GUI can also be configured to execute functionality related to one ESP or multiple ESPs based on the users' interaction with the GUI.
Embodiments of systems and corresponding methods for generating diagnostic and prognostic data based on operational data associated with an ESP are discussed herein. However, embodiments of the disclosure can be employed for generating diagnostic and prognostic data based on operational data associated with other types of machinery without limit.
As shown in
The clients 105 can include a large-format computing devices or any other fully functional computing device, such as a desktop computers or laptop computers, can transmit ESP operational data to prediction server 115. Additionally, or alternatively, other computing devices, such as a small-format computing devices 105 can also transmit ESP operational data to the prediction server 115. Small-format computing devices 105 can include a tablet, smartphone, personal digital assistant (PDA), or any other computing device that can have more limited functionality compared to large-format computing devices. For example, client 105A can include a laptop configured with a web-browser to display a sensor management application configured with respect to a number sensors coupled to one or more ESPs located within one or more wells at an oil field. Client 105B can include a sensor coupled to the wellhead and configured to transmit wellhead pressure data as operational data. Client 105C can include an ESP controller configured to transmit ESP voltage data as operational data. Additionally, client 105D can include a computing device configured to display diagnostic and prognostic data associated with the ESP operational data received from clients 105A-105C.
The architecture 100 also includes a database 110 that can store ESP operational data received from the clients 105 or from other computing devices via a network. In some embodiments, the database 110 can store historical ESP operational data associated with past failures or undesirable operating conditions exhibited by one or more ESPs. The database 110 can also store ESP operational data that can be used as training data, such as training data 120, which can be used to train one or more predictive models. In some embodiments, the databased 110 can also store ESP operational data that can be used as prediction data, such as prediction data 125, which can be used by the prediction server 115 to determine and generate the predicted prognostic data 155 and the diagnostic data 165. The database 110 can further store the diagnostic and prognostic data generated by the prediction server 115.
As further shown in
As shown in
The model training system 130 configured on the prediction server 115 includes a feature selector 135, which is used in the supervised training aspect of the machine learning process to select subsets of features in the ESP operational data. The model training system 130 also includes a model trainer 140 which uses a selected machine learning algorithm to process the selected subsets of features and generate a new training model 145. The new training model 140 can be subsequently used outside of the machine learning process as a prognosis prediction model 150 configured to predict prognostic data 155 based on the received the prediction data 125.
As shown in
The prediction server 115 also includes a model trainer 140. In some embodiments, the model trainer 140 can be included in the prediction server 115. In other embodiments, the model trainer 140 can be located remotely from the prediction server 115. During the training aspect of the supervised machine learning process, the model trainer 140 receives the training input including the selected subsets of features of the ESP operational data from the feature selector 135 and iteratively applies the subsets of features to the previously selected machine learning algorithm to assess the performance of the algorithm. As the supervised machine learning algorithm processes the training input, the model trainer 140 learns patterns in the training input that map the machine learning algorithm variables to the target output data (e.g., the predicted prognostic data 155) and generates a training model 145 that captures these relationships. For example, as shown in
As further shown in
As further shown in
In some embodiments, the diagnostic prediction model 160 can be configured within or separately from the model training system 130. In some embodiments, the diagnostic prediction model 160 can be configured within the prediction server 115. In some embodiments, the diagnostic prediction model 160 can be communicatively coupled to the prediction server 115 but located remotely from the prediction server 115. For example, the diagnostic prediction model 160 can be located in a remote, cloud computing environment that is coupled to the clients 105 via a network. In some embodiments, the diagnostic prediction model 160 can be located in proximity to the configuration of ESPs, also known as an “edge” configuration.
As shown in
As shown in
The system 200a also includes a client 105. The client 105 communicates via the network 235 with the server 115. The client 105 receives input from the input device 205. The client 105 can be, for example, a large-format computing device, such as large-format computing device 105 as described in relation to
As further shown in
As shown in
As further shown in
The server 115 also includes a memory 250 configured to store the computer-readable instructions and/or ESP operational data associated with predicting diagnostic and prognostic data based on the received ESP operational data. In some embodiments, the memory 250 can store data which may be used in the training phase of the machine learning process. For example the memory 250 can store time-series datasets of ESP operational data, such as datasets associated with the operating conditions of a particular ESP over time. Additionally, or alternatively, the memory 250 can store streaming ESP operational data that has been received from customers in real-time or near real-time, as well as previously provided ESP operational data. In some embodiments, memory 250 can store one or more training models, such as the training models 145 used during the training of a machine learning process to generate a trained prediction models, such as the prognosis prediction model 150 and the diagnosis prediction model 160 configured to generate predicted prognostic and diagnostic data, respectively, that corresponds to the ESP operational data provided to application 225. In some embodiments, memory 250 can store one or more trained models, such as the prognosis prediction model 150 and the diagnosis prediction model 160 that were similarly generated during a machine learning process and were trained to generate predicted prognostic and diagnostic data for different types of ESPs, sensors, components of the ESP, or the like based on the ESP operational data provided to the applications by a user. In some embodiments, the memory 250 can store one or more machine learning algorithms that will be used to generate one or more training models 145. In some embodiments, the memory 250 can store ESP operational data that may be received from client 105 over a period of time and can be used as a training dataset in the machine learning process in order to train a prediction model. In some embodiments, the memory 250 can store one or more trained prediction models, such as variants of the prognosis prediction model 150 and/or the diagnosis prediction model 160 that may be used to predict prognostic and diagnostic data, respectively, based on ESP operational data.
As shown in
The model training system 130 is configured to implement a supervised or unsupervised machine learning process that receives ESP operational data as training input and generates a training model that can be subsequently used to predict prognostic and diagnostic data based on ESP operational data that may be received by one or more clients 105. The components of the machine learning process operate to receive ESP operational data as training input, select unique subsets of features within the ESP operational data, use a machine learning algorithm to train a model based on the subset of features in the training input and generate a training model that can be output as a trained prediction model used for future predictions based on a variety of received ESP operational data.
As shown in
During the supervised machine learning process, the feature selector 135 provides the selected subset of features to the model trainer 140 as inputs to a machine learning algorithm to generate one or more training models. A wide variety of machine learning algorithms can be selected for use including algorithms such as long short-term memory (LSTM), Recurrent Neural net architectures (RNN), Convolutional Auto Encoders, support vector regression, ordinary least squares regression (OLSR), linear regression, logistic regression, stepwise regression, multivariate adaptive regression splines (MARS), locally estimated scatterplot smoothing (LOESS), ordinal regression, Poisson regression, fast forest quantile regression, Bayesian linear regression, neural network regression, decision forest regression, boosted decision tree regression, artificial neural networks (ANN), Bayesian statistics, case-based reasoning, Gaussian process regression, inductive logic programming, learning automata, learning vector quantization, informal fuzzy networks, conditional random fields, genetic algorithms (GA), Information Theory, support vector machine (SVM), Averaged One-Dependence Estimators (AODE), Group method of data handling (GMDH), instance-based learning, lazy learning, and Maximum Information Spanning Trees (MIST).
The remaining useful life of a particular asset is dependent on how the asset arrived at this current state. Therefore, the history of operation of the asset has to be considered to make an accurate estimate of the life consumed in order to determine an amount of remaining available life. A conventional approach is to utilize stateful LSTM models and loop through every ESP during the training process to determine the weights. This approach, can result in lower training speeds because the batching of sequences during training cannot be leveraged. The training process can be accelerated by structuring the problem in a unique way such that the stateful information is converted into multiple sequences of stateless information. For example, a machine which has operated for 100 days can be solved in a linear unfolded manner (0, 1, 2, . . . , 100) or as stateless sequences as (0-10, 0-20, 0-30, 0-40, 0-50, . . . , 0-100) that can be matched with the observed remaining useful life. Performing this new training approach using enhanced processors, such as graphical programming units (GPUs), can mitigate the need for large, expensive computational resources and memory configurations. The stateless sequences can be shuffled and batched to gain speed in the training phase. With such an improved training approach, sequences which look backwards from failure (90-100, 80-100, 70-100 etc.) can also be leveraged to train the model. The model trainer 140 evaluates the machine learning algorithm's prediction performance based on patterns in the received subset of features processed as training inputs and generates one or more new training models 145. The training phase of the machine learning process can be configured to generate stateless sequences of ESP operational data. The model trainer 140 can then iteratively loop through the operational data from each ESP to create increasingly larger sequence lengths. The stateless sequences can then be shuffled and batched for processing, for example using a graphical processing unit (GPU) to achieve faster training execution time.
The generated training models, e.g., trained prognosis prediction models 150, are then capable of receiving ESP operational data from outside of the machine learning process in which they were trained and generated to output prognostic data as predicted measurements correlating to the future operational capacity or performance of an ESP.
As shown in
As shown in
Instead, as shown in
As shown in
The training system 130 can also be configured with a machine learning process to train and output one or more prognosis prediction models 150 and diagnostic prediction models 160 that are capable of generating prognostic and diagnostic data based on historical ESP operational data which may have been provide by a user in the past and can be stored in memory 220 or memory 250. In some embodiments, the training system 130 can generate a model, such as trained prognosis prediction models 150 and the diagnostic prediction model 160 which can be capable of generating prognostic and diagnostic data when one or more features of the ESP operational data which are traditionally used to determine a particular aspect of the prognostic and/or diagnostic data are not available. For example, the prognostic and diagnostic data predicted for a specific ESP can be optimized based on the ESP operational data which may only partially identify the specific ESP, for example by a portion of time-series data or a data set including only a subset of available sensor data corresponding to a particular ESP configuration as opposed to a more complete data set of ESP operational data received for a full reporting time period or a data set including all available sensor data.
The training system 130 can also be configured with a supervised and/or unsupervised machine learning process to train and output multiple models, such as the prognosis prediction models 150 and the diagnostic prediction model 160 that have been trained in the machine learning process based on non-overlapping or partially overlapping sets of features. In some embodiments, the different sets of features that are associated with multiple models can be implemented on the prediction server 115B to create a more robust system that includes an ensemble or collection of models. In such embodiments, the prediction server 115B can predict prognostic and diagnostic data based on ESP operational data for different operators, customers, ESPs, ESP components, data sources, ESP operational data types, or other statistically correlated patterns observed in the received ESP operational data. In this way, the model or ensemble of models can be trained to generate diagnostic and prognostic data as outputs in situations when certain ESP operational data which are used in a given prediction model may be missing or incomplete.
As shown in
The servers 315A and 315B each include a communications module 240, a processor 245, and a memory 250 that includes one or more machine readable storage mediums containing program instructions for causing a computer to generate prognostic or diagnostic data based on ESP operational data. The processors 245 of the servers 315A and 315B are configured to execute instructions, such as instructions physically coded into the processors 245, instructions received from software in memory 250, or a combination of both. For example, the processor 245 of the server 315A can execute instructions to generate prognostic data based on ESP operational data that may be output to a client 105. Similarly, the processor 245 of the server 315B can execute instructions to generate diagnostic data based on ESP operational data that may be output to a client 105.
The techniques described herein may further be implemented as method(s) that are performed by physical computing device(s); as one or more non-transitory computer-readable storage media storing instructions which, when executed by computing device(s), cause performance of the method(s); or, as physical computing device(s) that are specially configured with a combination of hardware and software that causes performance of the method(s).
For example, in operation 405, a client 105 receives an input including a plurality of ESP operational data. The operational data may include voltage data, current data, frequency data, vibration data, load data, or the like associated with an operating condition of the ESP. The ESP operational data can also include ESP intake pressure data, wellhead pressure data, intake temperature data, ESP motor temperature data, ESP RPM data, pump operational status data, torque data, discharge pressure data, production flow data, and the like. The operational data may be received by the client 105 in regard to a specific operating condition including a motor failure, a pump failure, a cable or motor lead extension failure, a seal failure, a shaft and/or coupling failure, or the like. The client 105 can receive ESP operational data directly from a controller or a sensor that can be coupled to an ESP. In some embodiments, the ESP operational data can be received by a client 105 coupled to a SCADA system in which the ESP is configured. In some embodiments, a client 105 can receive the ESP operational data from a database, such as database 110. The ESP operational data may be historical ESP operational data or may be live, streaming ESP operational data that is received by the client in real-time or near real-time from the ESP.
Upon receiving the ESP operational data, the client 105 can transmit the operational data to a server, such as server 115. In some embodiments, the ESP operational data can be transmitted to the server 115 as training data 120. In other embodiments, the ESP operational data can be transmitted to the server 115 as prediction data 125. During the training phase of a machine learning process, the client 105 and/or the database 110 can transmit the input, as training data 120 to the model training server 115A of
In operation 410, the server 115 determines prognostic data. The server 115 determines prognostic data based on ESP operational data via the prognostic prediction models 150, for example a trained prediction model implementing a long short-term memory (LSTM) algorithm or a recurrent neural network architecture. When the server 115 receives prediction data 125, the server 115 can apply the trained prognostic prediction model 150 generated as a result of the training phase of the machine learning process to the transmitted inputs and can generate one or more prognosis measurements included in the prognostic data 155. The prognostic data 155 can be determined as a result of the training approach employed during the training phase where by a number of prognosis prediction models and corresponding supervised learning techniques were applied to the training data 120 so that a deployable trained prognosis prediction model 150 can be generated.
In some embodiments, the prognosis data 155 can include outputs which require further input to cause execution of executable content which can be configured on the client 105 and/or the server 115. For example, the prognosis prediction model 150 can be trained to output a uniform resource locator (URL) or “web address” requiring a user to click or otherwise select the URL in a web-based environment to cause the computing device to navigate to the content stored at the URL location. In some embodiments, execution of the executable content included in the prognostic data 155 can cause a change in operation of the ESP and/or one of its components. For example, execution of the executable content included in the prognostic data 155 can cause the ESP to cease operation or change a mode of operation.
In operation 415, the server 115 determines diagnostic data. The server 115 determines diagnostic data based on ESP operational data via the diagnostic prediction model 160. The diagnostic prediction model 160 can include an autoencoder based convolution architecture that can be optimized for anomaly detection of the ESP operational data. When the server 115 receives prediction data 125, the server 115 can apply the trained diagnostic prediction model 160 generated as a result of the training phase of the machine learning process to the transmitted inputs and can generate one or more diagnostic measurements included in the diagnostic data 165. The diagnostic data 165 can be determined as a result of the training approach employed during the training phase where by a number of prognosis prediction models and corresponding unsupervised learning techniques were applied to the training data 120 so that a deployable trained diagnostic prediction model 160 can be generated. In some embodiments, the diagnostic data 165 can include outputs which require further input to cause execution of executable content which can be configured on the client 105 and/or the server 115. For example, the diagnostic prediction model 160 can be trained to output an alert or a notification based on the diagnostic data 165. The alert or notification can include executable content requiring a user to accept or otherwise acknowledge the alert. In some embodiments, the diagnostic prediction model 160 can be trained to output a uniform resource locator (URL) or “web address” requiring a user to click or otherwise select the URL in a web-based environment to cause the computing device to navigate to the content stored at the URL location. In some embodiments, execution of the executable content included in the diagnostic data 165 can cause a change in operation of the ESP and/or one of its components. For example, execution of the executable content included in the diagnostic data 165 can cause the ESP to cease operation or change a mode of operation.
In operation 420, the server 115 transmits the prognostic data and the diagnostic data to the client 105 and/or the database 110 via the network 235. The client 105 can further provide the outputs to a user within an application from which the ESP operational data was received. In some embodiments, the client 105 can receive the prognostic and diagnostic data outputs and further transmit the outputs to the database 110 for storage, thereby reducing the amount of memory resources needed at client 105. In this way, the database 110 can include newly generated prognostic and diagnostic outputs that can be added to a production operators ESP operation and condition monitoring database which may be stored in database 110.
In operation 425, the client 105 can provide the prognostic and diagnostic data for display, such as within a GUI configured on the client 105. In some embodiments, the client 105 provide the prognostic and diagnostic data in a report, as an annotation to one or more related datasets of ESP operational data, or as an input to a modeling and simulation environment configured to model and simulate ESP operational behavior.
The GUI 500 also includes survivability data 520. The survivability data 520 displays probability data indicative of the likelihood that the ESP will remain operational for a pre-defined duration into the future and is presented with respect to a cumulative amount of elapsed operational time. The survivability data 520 also includes event data 525. The event data 525 can indicate a time period forecast into the future when the ESP is likely to fail.
The GUI 500 further includes Weibull distribution data 530 indicating the probability of failure as a function of time. The Weibull distribution data 530 can include different plots for each of the one or more components of the particular ESP. The Weibull distribution data 530 can display the probability of ESP failure for the current date or can show past and predicted dates by interacting with animation controls 535. The animation controls 535 allow a user to “play” or “stop” an animated display of the Weibull distribution 530 as time-series data. A user can further adjust the display of the Weibull distribution data 530 by interacting with a slider 540. In this way, the user can adjust the slide to show Weibull distribution data for a specific past or future time point.
The GUI 500 also includes a component diagnostic display 545 including the operational data corresponding to various components or sensors of the ESP. A component identification legend 550 provides a legend identifying each of the various ESP components including sensors which may be coupled to the ESP or ESP components. In this way, the user can view the operational data associated with one or more components of the ESP.
As further shown in
The improved ESP diagnostic and prognostic system described herein addresses the technical problem of efficiently generating diagnostic and prognostic data based on ESP operational data. The problem of determining and generating accurate, detailed, diagnostic and prognostic data for ESPs can be difficult and time-consuming, requiring significant computing resources to store multiple databases containing large libraries of operational data which must be catalogued and indexed appropriately before being useful for generating diagnostic and prognostic data. The exemplary technical effects of the methods, systems, and devices described herein include, by way of non-limiting example, generating diagnostic and prognostic data based on ESP operational data using a predictive model trained in a machine learning process. The predictive model reduces the need for significant computing resources storing large databases of ESP operational data and provides the exemplary technical effect of reducing calculation times, improving diagnostic and prognostic metric generation, and improved visualization of the generated diagnostic and prognostic data. In addition, the precision and specificity of the diagnostic and prognostic data provided by a ESP condition monitoring application or a SCADA system, can be improved such that the application or SCADA system are able to more efficiently generate precise diagnostic and prognostic metrics based on ESP operational data. Thus the system represents an improvement of computer functionality that processes ESP operational data and generates diagnostic and prognostic data corresponding to one or more operating conditions of the ESP. Additionally, the clients 105 can include an improved display or graphical user interface (GUI) that provides more efficient visualization and execution of diagnostic and prognostic data such as when responding to alerts or notifications for anomalous operating conditions, planning ESP or ESP component replacement, or managing well site production. Existing ESP condition monitoring applications typically do not include such robust interfaces to provide diagnostic and prognostic data generated by a trained prediction model. Existing applications are limited to interfaces which may provide current or historical operational data but lack diagnostic and prognostic data predicted based on ESP operational data in real time or near real-time. The improved ESP diagnostic and prognostic system provides a predictive, automatic, user-configurable system capable of generating diagnostic and prognostic data based on inputs that include minimal indications of future operating conditions in the ESP operational data.
Certain exemplary embodiments have been described to provide an overall understanding of the principles of the structure, function, manufacture, and use of the systems, devices, and methods disclosed herein. One or more examples of these embodiments have been illustrated in the accompanying drawings. Those skilled in the art will understand that the systems, devices, and methods specifically described herein and illustrated in the accompanying drawings are non-limiting exemplary embodiments and that the scope of the present invention is defined solely by the claims. The features illustrated or described in connection with one exemplary embodiment may be combined with the features of other embodiments. Such modifications and variations are intended to be included within the scope of the present invention. Further, in the present disclosure, like-named components of the embodiments generally have similar features, and thus within a particular embodiment each feature of each like-named component is not necessarily fully elaborated upon.
The subject matter described herein can be implemented in analog electronic circuitry, digital electronic circuitry, and/or in computer software, firmware, or hardware, including the structural means disclosed in this specification and structural equivalents thereof, or in combinations of them. The subject matter described herein can be implemented as one or more computer program products, such as one or more computer programs tangibly embodied in an information carrier (e.g., in a machine-readable storage device), or embodied in a propagated signal, for execution by, or to control the operation of, data processing apparatus (e.g., a programmable processor, a computer, or multiple computers). A computer program (also known as a program, software, software application, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file. A program can be stored in a portion of a file that holds other programs or data, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
The processes and logic flows described in this specification, including the method steps of the subject matter described herein, can be performed by one or more programmable processors executing one or more computer programs to perform functions of the subject matter described herein by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus of the subject matter described herein can be implemented as, special purpose logic circuitry, e.g., a GPU (graphical processing unit), an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processor of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, (e.g., EPROM, EEPROM, and flash memory devices); magnetic disks, (e.g., internal hard disks or removable disks); magneto-optical disks; and optical disks (e.g., CD and DVD disks). The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.
To provide for interaction with a user, the subject matter described herein can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, (e.g., a mouse or a trackball), by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well. For example, feedback provided to the user can be any form of sensory feedback, (e.g., visual feedback, auditory feedback, or tactile feedback), and input from the user can be received in any form, including acoustic, speech, or tactile input.
The techniques described herein can be implemented using one or more modules. As used herein, the term “module” refers to computing software, firmware, hardware, and/or various combinations thereof. At a minimum, however, modules are not to be interpreted as software that is not implemented on hardware, firmware, or recorded on a non-transitory processor readable recordable storage medium (i.e., modules are not software per se). Indeed “module” is to be interpreted to always include at least some physical, non-transitory hardware such as a part of a processor or computer. Two different modules can share the same physical hardware (e.g., two different modules can use the same processor and network interface). The modules described herein can be combined, integrated, separated, and/or duplicated to support various applications. Also, a function described herein as being performed at a particular module can be performed at one or more other modules and/or by one or more other devices instead of or in addition to the function performed at the particular module. Further, the modules can be implemented across multiple devices and/or other components local or remote to one another. Additionally, the modules can be moved from one device and added to another device, and/or can be included in both devices.
The subject matter described herein can be implemented in a computing system that includes a back-end component (e.g., a data server), a middleware component (e.g., an application server), or a front-end component (e.g., a client computer having a graphical user interface or a web browser through which a user can interact with an implementation of the subject matter described herein), or any combination of such back-end, middleware, and front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet.
Approximating language, as used herein throughout the specification and claims, may be applied to modify any quantitative representation that could permissibly vary without resulting in a change in the basic function to which it is related. Accordingly, a value modified by a term or terms, such as “about,” “approximately,” and “substantially,” are not to be limited to the precise value specified. In at least some instances, the approximating language may correspond to the precision of an instrument for measuring the value. Here and throughout the specification and claims, range limitations may be combined and/or interchanged, such ranges are identified and include all the sub-ranges contained therein unless context or language indicates otherwise.
One skilled in the art will appreciate further features and advantages of the invention based on the above-described embodiments. Accordingly, the present application is not to be limited by what has been particularly shown and described, except as indicated by the appended claims. All publications and references cited herein are expressly incorporated by reference in their entirety.
The present application claims priority under 35 U.S.C. § 119 to U.S. Provisional Application No. 62/645,126 entitled “ESP Diagnostics and Prognostics” filed on Mar. 19, 2018, which is hereby expressly incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62645126 | Mar 2018 | US |
