Method, system and computer program for preventing an electrical submersible pump failure

Abstract

The present disclosure relates to a computer-implemented method for preventing an electrical submersible pump, ESP, failure, the method comprising obtaining real-time operation sensor data from one or more sensors (110), the real-time operation sensor data being indicative of the operation of the ESP, detecting, by an abnormality detection artificial intelligence, Al, engine (220), at least one abnormality in the real-time operation sensor data (120), the abnormality indicating an abnormal event of the operation of the ESP, generating, by a physics characteristics Al engine (230), at least one operating characteristic of the ESP based at least on the abnormality and on a physical model of the ESP (130), determining, by a root cause analysis Al engine (240), at least one root cause of the ESP failure based at least on the at least one abnormality and the at least one operating characteristic (140), and generating at least one failure prevention measure to reduce the risk that the ESP failure occurs (150). In addition, the present disclosure relates to a corresponding computer system and to a corresponding computer program.

Description

[0001] December 19, 2024

[0002] MATRIX JVCO LTD trading as AIQ A1775O6WO CKA / HEP / brb

[0003] Method, system and computer program for preventing an electrical submersible pump failure

[0004] 5 Technical Field

[0005] The present disclosure relates to a computer-implemented method for preventing an electrical submersible pump failure as well as to a corresponding computer system and a corresponding computer program.

[0006] Technical background 0 Electrical submersible pumps (ESPs) have a wide range of industrial application. They are used in fields like oil and gas drilling, water supply and wastewater management. In some cases, these pumps maybe placed far below surface level, so maintenance and repair works can prove complex. Furthermore, in case of an unexpected failure, undesired leakages of the pumping fluid may occur which can cause significant damage5 to the environment and the overall safety of the pumping operation. Also, the economic costs of a pump failure during operation represents an important financial aspect. Early problem detection and scheduled maintenance may contribute to longer life cycles of a pump. It is therefore advantageous to constantly supervise the pumping operation parameters and implement mechanisms to spot latent deteriorations or impending0 malfunctions of these pumps.

[0007] Commonly, suppliers or operators of ESP set threshold values for some operation parameters. If a parameter reaches the threshold, a user-addressed warning can be issued indicating a problematic condition (these events are sometimes referred to as “trips”). However, this approach has a major drawback as it focuses on the 5 development of single parameters. It falls short when a technical problem influences the parameters such that no single parameter leaves its area of accepted values, but, collectively, the parameters represent an abnormal condition. Another important industrial development is the implementation of web-based solutions allowing for a remote monitoring of several pumps at different locations in real-time. This way,0 supervision of pumping sites may be centralized and, consequently, more powerful resources can be allocated.

[0008] It has been pointed out that detection mechanisms have traditionally been reactive, not relying on proactive predictions using sophisticated mathematical models. In this respect, WO 2017 / 161126 Al discloses a system and method for detecting, diagnosing, and correcting trips or failures of electrical submersible pumps. This method includes the steps of collecting data in real-time, manipulating historical data to determine and evaluate a plurality of decision variables, and deriving trends and patterns associated to trips or failures. The method relies on a Robust Principle Component Analysis (PCA) methodology. Ultimately, it aims to prescribe remedial action to prevent further trips or failures.

[0009] WO 2017 / 161126 Ai discloses a pre-set mathematical model to recognize patterns of normal operation and abnormal operation conditions. This model does not carry out any physical simulations of a current pumping situation, given real-time data, but it uses a purely mathematical approach to detect trends and patterns. Furthermore, the mathematical model is not adjusted or altered by user input, i.e. the mathematical algorithm is not dynamic, the method doesn’t learn from a user.

[0010] A model that takes physical simulations and specific user expertise into account would be more powerful and, thus, more effective to detect anomalies and to suggest userspecific remedies.

[0011] Summary of the invention

[0012] The present invention seeks to overcome the present drawbacks and proposes the following computer-implemented method for preventing an electrical submersible pump, ESP, failure.

[0013] A 1staspect of the invention refers to a method comprising: obtaining real-time operation sensor data from one or more sensors, the real-time operation sensor data being indicative of the operation of the ESP; detecting, by an abnormality detection artificial intelligence, AI, engine, at least one abnormality in the real-time operation sensor data, the abnormality indicating an abnormal event of the operation of the ESP; generating, by a physics characteristics AI engine, at least one operating characteristic of the ESP based at least on the abnormality and on a physical model of the ESP; determining, by a root cause analysis AI engine, at least one root cause of the ESP failure based at least on the at least one abnormality and the at least one operating characteristic; and generating at least one failure prevention measure to reduce the risk that the ESP failure occurs. This method allows for intelligently recognizing patterns and trends of ESP parameters. The invention comprises that real-time operation sensor data is obtained. In the context of the invention, real-time operation sensor data refers to parameters being acquired by the ESP sensor devices. This data can be considered as “live” data, but it is not restricted to a single measurement at a single given instance. It is possible that the real-time operations sensor data is sent in packages, or that operation sensor data is continuously transmitted. By referring to real-time operation sensor data, the invention understands that data is representative of the current functioning regime of the ESP. Real-time operation sensor data may comprise a broad range of measurements, e.g. operation sensor data several hours ago. Real-time data may be stored in a data base such as an IOT (internet-of-things data base) before being passed on to an Al engine.

[0014] The real-time operation sensor data may comprise parameters reflecting the fluid hydraulics, such as intake and discharge pressure, fluid flow etc. The real-time sensor data may also comprise parameters representing the mechanic of the pump, e.g. pump motor repetition rate, heat development, vibrations, motor torque etc. Also, the realtime operation sensor data may involve electric parameters of the ESP such as electric voltage, current, frequency and power.

[0015] The abnormality detection Al engine is configured to detect abnormalities in the realtime sensor data. This task is performed by taking real-time operation sensor data into account and analysing patterns and trends. The Al engine may comprise a memory function for real-time operation sensor data. This way, the Al engine may “remember” prior operation sensor data without necessarily having to retrieve historic data from an archive data base. By an underlying algorithm, pattern and trends representative of an abnormal operation regime may be recognized.

[0016] Abnormalities maybe the sudden or latent change of a single ESP parameter, or a sudden or latent change of a plurality of ESP parameters (no single ESP parameter may exceed its individual pre-set limits). Especially in the latter case, the Al engine may use systematic dependencies among different real-time operation sensor data to spot patterns and trends that a human operator would not be able to discern easily.

[0017] It maybe advantageous to use an auto-regressive algorithm to cast predictions of current real-time operation sensor data. This way, an abnormality detection may be expedited or corroborated. By doing so, the level of certainty of a detected abnormality can be augmented. This may remove a doubt about whether a current real-time operation sensor data (already) represents an abnormality. There may be cases when real-time operation sensor data may be out of pre-set boundaries for a short time period but subsequently returns within them. In these cases, a prediction based on an auto-regressive algorithm may help to evaluate whether a temporary deviation of realtime operation sensor data represents an abnormality of the ESP function, or not.

[0018] The present invention understands that an abnormality in the real-time operation sensor data is indicative of an abnormal event of the operation of the ESP. The abnormal event of the operation of the ESP may be happening at present or may not have happened yet. It is possible that a current abnormality in the real-time operation sensor data indicates that an abnormal event of the operation of the ESP is impending.

[0019] A mere deviation of the real-time operation sensor data may not suffice if this deviation does not indicate a present or future abnormal event of the operation of the ESP. An abnormal event has a potential influence on the functioning of the ESP. An abnormal event may be the ESP failure. By an ESP failure, the invention understands an unscheduled stoppage of the ESP or a major malfunction leading to a significant reduction of the pump’s function. Therefore, not only a total arrest of the ESP but also a significant decrease of the pumping efficiency may be an ESP failure. An undesired pump efficiency loss of more than 20 % should be considered an ESP failure in any case. An abnormal event of the operation of the ESP may also be an event which does not represent a direct ESP failure, but, in many cases, may lead to an ESP failure soon.

[0020] As will be detailed below, the abnormality detection Al engine may comprise a large language model.

[0021] This term refers to a transformative neuronal network computation. The neuronal network may comprise a plurality of computation parameters (some of which are typically referred to as “weights” and “biases”) which are set and tuned during a “training process”. During this phase, the parameters of a specific algorithm (e.g. “selfattention” algorithm) are adapted to achieve certain results which may be expected by a human operator. Deviations of an expected answer to the answer of the neuronal network may be calculated by a loss function such as the cross-entropy- relation or a comparable function. By a back-propagation method using gradient descent, parameters such as the weights and biases may be corrected. This iterative process may be carried out until the answers of the neuronal network are considered acceptable. Regularly, more comprehensive training material (and more iterations over this material, i.e. epochs) will lead to better performances of the model. After the training phase, an operational phase may follow. In this phase, the neuronal network is implemented to operate. In its capacity as an abnormality detection Al engine, the neuronal network may continuously parse real-time operations sensor data and carry out predictions. The neuronal network may solely rely on its computation parameters (which may amount to a large number, even up to more than loo billion parameters) without a separate memory to store the real-time operation sensor data. The neuronal network may use a transformative “self-attention” algorithm to determine the contextual relevance of a plurality of real-time operation sensor data. By doing so, the most probable development of the given operation sensor data can be predicted. The neuronal network may have “learned” which predictions qualify as abnormal events of the operation of the ESP, so it can draw conclusions from its predictions. This allows for distinguishing abnormal and normal events.

[0022] It should be highlighted that the neuronal network may be “static” or “dynamic”. In this invention, these terms refer to the state of the neuronal network parameters during the operation phase. A neuronal network is deemed to be static, if, during its operation phase, the parameters of its algorithms are not changed. This means that the current input data during the operation phase will not change the algorithm of the neuronal network itself. This translates to the fact that the neuronal network does not “learn” during its operation (but solely during its training phase). The computation parameters are “frozen”. Conversely, a dynamic neuronal network refers to a model with continuously varying parameters. This means that the computation parameters of the neuronal network algorithm change according to some kind of feedback given during its operation phase. This feedback may comprise validation or refusal by a human user. A dynamic approach thus offers the possibility to improve the neuronal network computation results during the course of its application in practice. Advantageously, human knowledge and experience can be amalgamated with “knowledge” and “experience” from a pre-trained neuronal network. However, in the latter case human operators should be aware that “wrong” feedback may alter the reliability of the neuronal network computation results to the worse.

[0023] The method further comprises a physics characteristics Al engine. This Al engine is configured to generate at least one operating characteristics of the ESP by taking into account the abnormality detected by the abnormality detection Al engine. It further relies on a physical model of the ESP pump. The physical model of the ESP may comprise static data about the geometry and other specifications of the pump or of the respective well of the pump (the latter does not represent data about the pump but may be important to generate a complete physical model of the ESP pump). It is important to note that different ESPs may comprise different physical models. By taking ESP- specific data on the physical model of the ESP into account, ESP-specific operation characteristics can be generated. This is a technical advantage when several different types of ESP (sites) are monitored.

[0024] Based on the respective physical models of the ESP, computational simulations may be carried out by the Al engine to generate the operating characteristics of the respective ESP. This helps to place detected abnormalities in an ESP-specific context. This way detected abnormalities in the real-time operation sensor data can be assessed and specific consequences of the abnormalities may be simulated. The operating characteristic may comprise physical data characterizing the operation of the ESP such as pump efficiency, pump performance, pressures, temperatures and the pump wear factor can be calculated. The output of the physics characteristics Al engine may be a time series of the above parameters representing the simulated development of these parameters in the future.

[0025] It is possible to further ingest real-time operation sensor data in this step, too. This may help to improve the simulation results found by the physics characteristics Al engine.

[0026] Using a physics characteristics Al engine proves highly advantageous. It may use data on abnormalities in the real-time operation sensor data that has been obtained by abstract mathematical or statistical methods. The abnormality may have been detected without knowledge about the underlying physics of the model, solely relying on numeric dependencies. In this case, the abnormality is detected by recognition of patterns or trends revealed by a mathematical model such as an auto-regressive computation. In the case of an LLM, the LLM may have been trained solely relying on generic historic operation sensor data. In this case, the training data is not ESP-specific but originates from a plurality of different ESPs. As a consequence, the abnormality detection Al engine may be unaware about physical characteristics of the ESP.

[0027] This latter approach has the advantage that, due to the lack of specificity, the abnormality detection Al engine can be trained with a variety of historic data. This may improve its abnormality detection ability significantly as more training data allows for a more precise tuning of the computation parameters of the neuronal network. The physics characteristics Al engine represents ESP-specific parameters. Based on generic data on an abnormality, this Al engine may carry out simulations and derive ESP-specific implications of the detected abnormality on parameters such as pump efficiency, pump performance, pressures, temperatures and the pump wear factor. Thus, an abnormality may be validated or refuted. Furthermore, the abnormality may be specified or classified. By doing so, some detected abnormalities in the real-time operation sensor data may be filtered.

[0028] The physics characteristics Al engine may allow for scenario simulations and what-if analysis. A human operator may adjust ESP parameters in a simulated environment to see how these changes impact the operating characteristics, including risk factors such as pump cavitation, overloading, or motor overheating. The Al engine may present the outcomes of the simulation graphically.

[0029] The physics characteristics Al engine may comprise an LLM. As for the case of the abnormality detection Al engine, static and dynamic neuronal networks may be used. In this respect, the LLM may produce simulations by learning from various principles across multiple domains (fluid dynamics, motor mechanics, electrical principles) related to the ESP physical system. With respect to fluid dynamics, the LLM may be trained on fluid dynamics principles related to ESPs, such as the Bernoulli equation, Navier-Stokes equations, and Darcy-Weisbach equation. This may provide the LLM with the knowledge of how fluids behave in ESPs under various conditions, including pressure, temperature, and flow rate.

[0030] Concerning ESP motor mechanics, the LLM may also learn from the knowledge of ESP mechanical systems, such as motor load, efficiency curves, torque, speed, and performance under varying operating conditions. These may enable the LLM to learn the interactions between motor and the fluid sub systems and how they behave under different operational loads.

[0031] With respect to electrical principles, the LLM may integrate electrical principles including power consumption, energy efficiency, and how changes in electrical parameters (e.g., voltage, current) influence the ESP operation and the hydraulic system.

[0032] Concerning multi-domain dependencies, the LLM may learn the interdependencies between fluid dynamics, motor mechanics, and electrical systems through principal equations and historical data. For example, it can learn how changes in the fluid’s viscosity or temperature might alter the motor’s efficiency or performance, or how motor load changes can influence fluid flow rates and resistance.

[0033] With respect to real-time updates, the LLM may continually update its simulation knowledge based on real-time data, such as motor load, efficiency, and system variables. If certain conditions change (e.g., motor overheating, obstruction, leakages), the LLM may adjust the simulation accordingly.

[0034] By integrating information across multiple disciplines (fluid dynamics, motor mechanics, and electrical systems), the LLM may simulate both steady-state and dynamic scenarios of ESP hydraulic and mechanical systems, providing continuous feedback on how various ESP components interact over time. This may allow to evaluate long-term ESP behaviour. Furthermore, the LLM may simulate abnormal conditions and may predict how these events might impact ESP efficiency, fluid production, and motor performance. For example, it may simulate how the ESP behaves when a motor starts drawing excessive current due to increased load or when fluid properties change due to environmental factors.

[0035] The ability to continuously update simulations using real-time data may enable the LLM to reflect current system states and predict the impact of changes instantaneously.

[0036] Traditional simulation models for physical systems often require specialized software and domain expertise. In contrast, LLMs may quickly generate simulations using high- level, domain-specific knowledge, reducing the need for labour-intensive modelling and analysis. Since LLMs are based on flexible natural language models, they can easily be customized to incorporate new equations, principles, for specific system behaviours as needed.

[0037] A further step of the method involves determining, by a root cause analysis Al engine, at least one root cause of the ESP failure based at least on the at least one abnormality and the at least one operating characteristic. This step provides a root cause of the ESP failure which may be difficult or impossible for a human operator to see.

[0038] The present invention may not only be useful to detect an abnormality in the real-time operation sensor data which may be a hidden trend or systematic alteration of dependencies of several different operation sensor data. It may also be useful to detect one or several underlying causes of the abnormality. Yet again, the Al engine may comprise a static or dynamic LLM. Thus, a trained neuronal network may “remember” patterns and trends that have led to abnormal events of the operation of the ESP or even ESP failures in the past. These patterns or trends may be very subtle but, due to the power of neuronal network algorithms comprising a large number of computation parameters, even slightest abnormalities in the real-time operation sensor data may be indicative of a specific root cause.

[0039] The root cause analysis Al engine takes the operating characteristics generated by the physics characteristics Al engine into account. By relying on both the abnormality and the physics characteristics, further patterns and trends may be found. So, the root cause analysis Al engine may “remember” which impact a certain abnormality had on a specific ESP. By drawing “analogous” conclusions, the Al engine may find root causes of ESP failures, even if the ESP failure or the abnormality historically occurred with a different type of ESP.

[0040] The root cause analysis Al engine may take the real-time operation sensor data into account, too. In this case, the reliability of the results maybe enhanced.

[0041] Another step in the method is to generate a failure prevention measure to reduce the risk that the ESP failure occurs. A prevention measure may be any reaction that a human operator or a non-human decision maker decides to take in order to prevent an ESP failure. This may comprise an unscheduled inspection for mechanical problems, a change of motor parameters or a temporary shut-down. Also, a replacement of the ESP or parts of it may be scheduled before an unforeseen unavailability of the ESP occurs.

[0042] It is expedient to generate the failure prevention plan based on the findings of the Al engines described above. However, this is not necessary in this aspect of the present invention.

[0043] In a 2ndaspect, the step of generating a failure prevention measure further comprises generating, by a prevention plan Al engine, a failure prevention plan based at least on the root cause.

[0044] Unlike before, this step requires to take into account the root cause of the abnormality in the real-time operation sensor data. The prevention plan Al engine may take other aspect into consideration, such as the real-time operation sensor data, the abnormality in operation sensor data and the operating characteristics. A prevention plan may comprise one or several prevention measures to avoid a future pump failure. A prevention measure may take different objectives into account, such as maximizing the IO

[0045] ESP’s efficiency, maximizing its longevity or minimizing the number of shut-downs for maintenance purposes.

[0046] By using a static or dynamic LLM, the Al engine may comprise a “learning” and “remembering” capacity such as to generate the most probable prevention plan for a given root cause.

[0047] In a 3rdaspect, the step of generating a failure prevention measure further comprises generating, by an action Al engine, an action plan comprising at least one action item to be performed to minimize the risk that the ESP failure occurs based at least on the failure prevention plan.

[0048] This step generates an action plan by considering at least one failure prevention plan priorly generated by the failure prevention plan Al engine. The difference between a prevention plan and an action plan is that the latter derives a specific action item to be taken, whereas a failure prevention plan may only indicate which parameter(s) of the ESP has / have to be altered to avoid pump failure.

[0049] In a 4thaspect, generating an action plan is based, at least in part, on a target objective.

[0050] A target objective may be a user’s preference concerning the operation of the pump. A preference may be seen in optimizing a pump’s current output, maximizing its life cycle or minimizing technical shutdowns for maintenance purposes.

[0051] This Al engine may comprise a static or dynamic LLM. In this case, the Al engine may “learn” and “remember” past action plans for a given failure prevention plan and a given target objective. The advantage of using a LLM in this situation is that a possibly unlimited number of user-specific target objectives maybe combined with given failure prevention plans. The LLM maybe able to translate a new target objective by analyzing its context and drawing parallels to past situations. Also, a dynamic LLM may take user input during operation into account to adjust computation parameters and, thus, to improve the suggested action plans. This last aspect is advantageous because it allows an iterative improvement of action plan generation. This way, a user can depart from a standard trained LLM and specify its computation parameters over the course of ESP operation. This helps to make action plans more “personalized” or “individual”.

[0052] In a 5thaspect, the step of detecting at least one abnormality further comprises parsing, selecting and retrieving historical events comprising normal and abnormal operating conditions of the ESP from an ESP event data base. It has been pointed out before that the retrieval of data from any data base may be optional. However, by implementing a retriever, the output of the abnormality detection Al engine may be further improved. In this case, the Al engine may have access to a data base comprising past ESP events. This data base may include historical operation sensor data of one or several ESP of one or several types. This data base may have a large number of recorded operation sensor data reflecting ESP operation over the past, e.g. several years. This data base may comprise time stamps indicative of an abnormal event.

[0053] A retriever may parse this data base and select relevant data. This selection may be carried out according to similarities in real-time and historic operation sensor data. This retrieving method may provide the relevant data to a LLM of the abnormality detection Al engine. The advantage of this method is to provide the LLM with highly relevant contextual input which will generally enhance the reliability of the Al engine’s result. In the case of the abnormality detection Al engine, the reliability of a detected abnormality result will increase.

[0054] In a 6thaspect, the step of detecting at least one abnormality further comprises predicting a remaining operating time of the ESP.

[0055] This step may be carried out by the abnormality detection Al engine. As described above, this Al engine may comprise predictions of operation sensor data. These predictions maybe used to predict the remaining operating time of the ESP given a current ESP regime. To accomplish this task, the Al engine may comprise information about operating limits of the ESP. Another possibility is that the Al engine comprises a LLM that has been trained on data comprising historical pump failures after similar ESP operating conditions. Knowledge about the remaining operating time of the ESP proves both useful for the other Al engines such as the failure prevention plan Al engine and the action plan Al engine as well as a human operator querying this information.

[0056] In a 7thaspect, the step of generating at least one operating characteristic of the ESP is further based on the real-time operation sensor data.

[0057] As the method comprises obtaining real-time operation sensor data, it is expedient to use this data not only for the abnormality detection Al engine, but also for the physics characteristics Al engine. This may enhance the relevance and / or reliability of the Al engine’s output. In an 8thaspect, the at least one operating characteristic of the ESP comprises one or more of intake pressure, discharge pressure, motor temperature, pump efficiency, pump wear, motor torque and / or pump power.

[0058] In a 9thaspect, the physical model of the ESP comprises the well geometry and / or ESP design specifications.

[0059] In a iothaspect, the ESP design specifications comprise at least one of a choke position, a frequency and / or a voltage of the ESP. In the case of more than one ESP, the design specifications may comprise “swap pump”.

[0060] In an 11thaspect, the step of generating at least one operating characteristic of the ESP further comprises parsing, selecting and retrieving relevant information on the physical model of the ESP from an ESP physics data base.

[0061] As in the case of the ESP event data base, implementing a retriever to parse, select and retrieve information from a data base comprising historical data may be useful to further improve the physics characteristics Al engine’s output. The ESP physics data base may comprise a plurality of static information about the ESP or the ESP well. This information may comprise a large number of data representative of the geometry of the ESP. Also, the information may comprise electric or hydraulic specifications of the pump. This data base may comprise more specific data than the physics characteristics Al engine has “learned” before. Also, the data base may comprise historical operation characteristics associated to specific physical conditions of the ESP.

[0062] If the physics characteristics Al engine comprises a LLM, the contextual relevance of the output, the operating characteristic, can be significantly enhanced with carefully selected physics data from the ESP physics data base. The risk of hallucinations is thereby reduced, too.

[0063] In a 12thaspect, the step of determining a root cause of the ESP failure is further based on one or more of real-time operation sensor data, data of historical ESP failures, ESP pulling reports, and / or ESP evaluation log files.

[0064] In this example, one or more of the so far described Al engines may produce reports or log files representative of the ESP operation. These reports or log files may be dependent on a specific event or independent of a s specific event. The reports or log files may include root causes indicated by a time stamp. The reports and log files may be automatically produced or at least in part produced by a human operator. By taking into account any of the above data, the reliability of the root cause analysis may be enhanced. Also, in the case of a LLM, the contextual relevance can be enhanced.

[0065] In a 13thaspect, generating a failure prevention measure is further based on one or more of: the real-time operation sensor data, the at least one abnormality in the realtime operation sensor data, the at least one operating characteristic of the ESP, an ESP failure prevention plan and / or an ESP failure prevention intervention.

[0066] As before, by taking more data into account, the reliability of the Al engine’s output can further be improved. As real-time operation sensor data has priorly be obtained, it is expedient to use this data in the case of the failure prevention plan Al engine, too. Also, it is useful to take into consideration several or all of the other Al engine’s output. Logically, only the action plan Al engine’s output cannot be used as the latter is based on the failure prevention plan Al engine’s output. All the other Al engine’s outputs may advantageously be used.

[0067] In a 14thaspect, generating a failure prevention measure of the ESP further comprises parsing, selecting and retrieving data on relevant ESP failure prevention plans and / or ESP failure prevention interventions from an ESP failure prevention and / or failure prevention intervention data base.

[0068] This data base can be seen as a collection of one or several actions undertaken in the past to prevent a pump failure. These actions may be marked with a time stamp. A retriever may aid to find relevant interventions. Other data in the data base maybe informative of the success of a past intervention. If an ESP has functioned for a long time after a past intervention or an ESP has proven otherwise to be very performant after a past intervention, this may be considered a successful intervention. Conversely, if an ESP failed shortly after a failure prevention intervention, this may be a sign of a wrongful or erroneous intervention measure. By selecting and retrieving relevant information from the ESP failure prevention intervention data base, the reliability of a failure prevention plan can be enhanced.

[0069] In a 15thaspect, generating a failure prevention measure comprises one or more of flow rate adjustment, ESP frequency adjustment, ESP voltage adjustment, ESP component replacement, ESP component inspection, ESP component cleaning, ESP speed maintenance, ESP shutdown. This non-exhaustive list represents possible prevention measures to prevent an impending or future pump failure. As can be seen, some prevention measures may comprise parameter alterations, others comprise concrete actions such as inspections, maintenance, repair or overhaul recommendations.

[0070] In a 16thaspect, the method further comprises detecting, based on the at least one abnormality, the at least one operation characteristic, the at least one root cause and the at least one failure prevention measure, a conflict between the at least one operation characteristic, the at least one root cause and the at least one failure prevention measure; determining a conflict severity score of the conflict; and rejecting the at least one abnormality, the at least one operation characteristic, the at least one root cause and / or the at least one failure prevention measure based on the conflict severity score.

[0071] This aspect aims at removing any conflict among the abnormality detection, the physics characteristics, the root cause analysis and the failure prevention plan Al engines prior to the operation of the action plan Al engine. This way, a conflict detection mechanism acts as a filter refusing conflicting input of the action plan Al engine. An operator may be able to influence a threshold value for the conflict severity score. A higher conflict severity score threshold may improve the input of the action plan Al engine, thus possibly improving its output, too. On the other hand, a high threshold may require the other Al engines to perform several computation cycles before reaching non-conflicting results. In some cases, a very high threshold may paralyze the overall method as no acceptable input for the action plan Al engine may be generated. This mechanism may be used to find an acceptable compromise which, on the one side, enhances Al engine’s reliability and possibly avoids hallucination, and on the other side, guarantees fast computation times.

[0072] In a 17thaspect, the method comprises obtaining input data from a user-machine interface and determining a contextual relevance between data obtained from a usermachine interface and an output of at least one of the Al engines by an Al engine.

[0073] The input of a user, such as an ASCII-text representing instructions or a question, may be entered by a keyboard. Via a conversational layer, the text is translated to machine readable instructions or a question. By use of an Al engine and a suitable algorithm such as the cross-entropy-algorithm, the contextual relevance of the output of one of the Al engines can be determined. This approach aids to detect machine hallucination. If hallucination is found, the Al engines or their respective LLM may be re-triggered. In an 18thaspect, the method comprises obtaining natural language input data from a user-machine interface and producing, by at least the abnormality detection Al engine, the physics characteristics Al engine and the root cause analysis Al engine and a conversational layer Al engine, a natural language answer to a user-machine-interface.

[0074] This aspect translates the chatbot functionality of the present disclosure. Via the usermachine-interface such as a keyboard and the conversational layer, instructions or questions can be entered. The Al engines may carry out the method of this invention. After this task has been completed, the conversational layer re-translates the relevant output to a natural language answer. It is expedient to implement a LLM to perform this task as transformative neuronal networks a highly performant on creating content which human users will likely find acceptable. A side of the mentioned Al engines, other Al engines may participate in creating the desired output. As a human operator may be interested in specific actions to carry out in order to eliminate an abnormality in the real-time operation sensor data or to prevent an impending pump failure, it is useful to include the failure prevention plan Al engine and the action plan Al engine in the above scheme.

[0075] It should be highlighted that this aspect of the present disclosure is advantageous because it provides a human user a powerful tool for troubleshooting purposes. In fact, a human operator may engage in a conversation with the Al engines to combine human experience with performant machine computation skills. A human operator may continuously specify contextual relevance and give real-time feedback to intermittent answers of the Al engines. This way, a process of mutual enlightenment may expedite the troubleshooting. If one or several of the Al engines comprise dynamic LLMs, they will learn from this human-machine-interaction. In this case, however, the human operator should be aware of the inputs they are providing the Al engines.

[0076] In an 19thaspect, the method comprises obtaining at least one operation log from at least one Al engine, determining, based on the at least one operation log, by a failed service Al engine, whether an Al engine has failed, and re-triggering, by a triggering Al engine, a failed Al engine.

[0077] This aspect covers another two Al engines that act in a supervision and / or regulating role. By examining operation logs, the failed service Al engine may determine if another Al engine has failed. The failed service Al engine may “remember” past failures because it may have been trained to detect failures based on historic data on service failures. If a service has failed, which maybe the case if the Al engine’s output cannot be used or can only be used with significant restrictions, then another Al engine, the triggering Al engine, may re-trigger the respective service. This is a closed-loop system which allows for an iterative process. If the failed Al engine comprises an LLM, the Al engine may “learn” from a past failure and choose a different approach. This procedure may be repeated several times until the Al engine reaches an acceptable result. In this case, the failed service Al engine will no further detect the failure of the corresponding service.

[0078] In a 20thaspect, at least one Al engine comprises at least a large language model (LLM), and / or a retriever.

[0079] As already described, LLM and retriever expedite output computation of the respective Al engines.

[0080] In a 21thaspect, detecting at least one abnormality in the real-time operation sensor data, generating at least one operating characteristic of the ESP, determining at least one root cause of the ESP failure and / or generating at least one failure prevention measure further comprises determining, based on a target objective, the relevancy to the target objective of the at least one abnormality in the real-time operation sensor data, the at least one operating characteristic of the ESP, the at least one root cause of the ESP failure and / or the at least one failure prevention measure; computing, based on the relevancy to the target objective, by a grader, a grade score; and re-invoking, based on whether the grade score reaches a first confidence threshold, the LLM and / or the retriever of at least one of the Al engines.

[0081] One or several Al engines comprise a grader which assesses the relevancy of an LLM’s output given a target objective and, according to whether the relevancy meets a first confidence threshold or not, accepts the output or re-invokes the respective LLM. This internal control cycle routine is aimed at enhancing the contextual relevance of the respective LLM and avoid hallucinations.

[0082] In a 22thaspect, the method comprises determining, by one of the Al engines, based on data obtained from at least one further Al engine, a relevancy to the at least one further Al engine of the at least one abnormality in the real-time operation sensor data, the at least one operating characteristic of the ESP, the at least one root cause of the ESP failure and / or the at least one failure prevention measure; computing, based on the relevancy to the at least one further Al engine, by a cross expert validator, a validation score; and re-invoking, based on whether the validation score reaches a second confidence threshold, the LLM and / or the retriever of at least one Al engines.

[0083] Unlike the prior graduation routine, the validation procedure is external, so the contextual relevance of an Al engine’s output is not compared to an intrinsic target objective, but to other Al engine’s output. This validation method proves to harmonize the different Al engine’s outputs and shares some similarity with the conflict detection method described above.

[0084] In a 23rdaspect, the method further comprises obtaining input data from a usermachine interface; and dynamically adapting at least one of the LLM according to the input data.

[0085] Another aspect translates the priorly described dynamic LLM, their computation parameters being sensitive to user input and feedback during the operation phase of the respective Al engine. This property enables an Al engine to “learn” during the course of its operation. It is important that a user be aware of the input to Al engine as any input may alter the computation parameters of the LLM. In some cases, user input may deteriorate the Al engine’s reliability. However, if the input is carefully chosen, an Al engine comprising an LLM will improve over time.

[0086] A 24thaspect of the present disclosure refers to a computer system comprising a processing unit and a computer-readable memory adapted to carry out the preceding methods. This device may be any computer, micro-processor, or a plurality of computers, such as a server landscape of distributed systems.

[0087] In a 25thaspect, the disclosure refers to a computer program comprising instructions, which when executed by a computer, causing the computer to carry out the methods as outlined above.

[0088] Brief description of the Figures

[0089] Fig. 1 illustrates a method according to aspects of the present disclosure.

[0090] Fig. 2a illustrates overview of Al engines according to aspects of the present disclosure.

[0091] Fig. 2b illustrates overview of Al engines and a validation logic of Al engine’s output according to aspects of the present disclosure. Fig. 3 illustrates a generic workflow of an Al engine according to aspects of the present disclosure.

[0092] Fig. 4 illustrates a workflow related to the abnormality detection Al engine according to aspects of the present disclosure.

[0093] Fig. 5 illustrates a workflow related to the physics characteristics Al engine according to aspects of the present disclosure.

[0094] Fig. 6 illustrates a workflow related to the root cause analysis Al engine according to aspects of the present disclosure.

[0095] Fig. 7 illustrates a workflow related to the failure prevention plan Al engine according to aspects of the present disclosure.

[0096] Fig. 8 illustrates a workflow related to the action plan Al engine according to aspects of the present disclosure.

[0097] Fig. 9 shows an overall orchestration of the Al engines including a re-triggering mechanism according to aspects of the present disclosure.

[0098] Detailed description of embodiments

[0099] Fig. i illustrates the method of obtaining real-time operation sensor data from one or more sensors, the real-time operation sensor data being indicative of the operation of the ESP (no); detecting at least one abnormality in the real-time operation sensor data, the abnormality indicating an abnormal event of the operation of the ESP (120); generating at least one operating characteristic of the ESP based at least on the abnormality and on a physical model of the ESP (130); determining at least one root cause of the ESP failure based at least on the at least one abnormality and the at least one operating characteristic (140); and generating at least one failure prevention measure to reduce the risk that the ESP failure occurs (150).

[0100] Fig. 2a shows the abnormality detection (220), the physics characteristics (230), the root cause analysis (240), the failure prevention plan (251) and the action plan Al engine (256), each of them acting as experts and giving exemplary output. To each of Al engines 220, 230, 240, 251, 256 is represented by a box. These boxes are interconnected by black arrows. Abnormality detection Al engine 220 comprises an arrow pointing to physics characteristics Al engine 230. Physics characteristics Al engine 230 points towards root cause analysis Al engine 240. Root cause analysis Al engine 240 points towards failure prevention plan Al engine 251 and the latter comprises an arrow pointing toward action plan Al engine 256. The arrows are indicative of the chronology of the workflow. In general, the workflow starts by detecting an abnormality in the real-time sensor data which will trigger the next Al engine and so forth. However, this is only an exemplary embodiment, so other chronological orders or the omission of certain Al engines remains possible.

[0101] Each of the described Al engines 220, 230, 240, 251, 256 comprises a respective speech bubble. In any of these speech bubbles, the output of the respective Al engine is shown. In this exemplary embodiment, abnormality detection Al engine 220 acts in its capacity as “expert 1” and produces the event start time, the event end time and the abnormality score of the abnormality in the real-time operation sensor data. Physics characteristics Al engine 230 acts as “expert 2” and produces a fluid flow, a mechanical stress and an electrical power simulation. These simulations are representative for the operating characteristics of the ESP. Furthermore, root cause analysis Al engine 240 represents “expert 3” producing possible outcomes shown in the respective speech bubble such as “spike events representing electrical issue”, “step events representing frequency change”, “transient increasing trend representing electrical leakages”, “transient decreasing trend representing production losses” and “frequent shutdowns causing integrity issue”. “Expert 4” is represented by failure prevention plan Al engine 251. Possible outputs shown in the respective speech bubble are “adjust flow rate”, “adjust frequency”, “change ESP voltage by 100V” or “recommend component replacement”. Finally, action plan Al engine 256 acts as “expert 5”. In this capacity, action plan Al engine 256 makes the following exemplary suggestion: “In order to minimize the risk of ESP failure, it is highly recommended to shutdown the pump, followed by tubing inspection and cleaning. The future forecasts on sensor abnormalities show that if the current operating conditions sustain for another 10 days, an imminent mechanical is highly likely to occur.”

[0102] In this exemplary workflow, Al engines 220, 230, 240, 251 and 256 cooperate in their capacities as experts. A following Al engine may use the results of preceding Al engines. Thus, action plan Al engine 256 may make a very educated suggestion to a human user. Hereafter, some exemplary answers of this Al engine workflow are presented. Note that in this exemplary embodiment, the user may have addressed a natural language question to the group of Al engines. The communication between a human user and the machine may be carried via a conversational layer. The conversational channel may be implemented by a mobile phone, a table, computer etc. The conversation may pass through a network-based cloud.

[0103] In a first case, the human operator may have asked what the current efficiency of pump in well A was. The answer given by the Al engines may be as follows:

[0104] “Pump A is operating at 88% efficiency, which is slightly below the historical average of 92% for this well. Over the past week, efficiency has shown a gradual decline of 4%, indicating a possible reduction in pump performance. I recommend monitoring the flow rate and pressure to ensure there are no significant obstructions or increased wear in the pump components.”

[0105] Other examples of question-answer couples are presented below:

[0106] Question: What is the current GOR for well B and how does it affect pump performance?

[0107] Answer: The current GOR is 530 scf / stb. This level is higher than the usual range 450 - 480 scf / stb for this well. An increased GOR can lead to a higher risk of cavitation, reducing pump efficiency and increasing the likelihood of gas locking. I suggest reviewing separator performance and inflow conditions to ensure the gas is being effectively managed.

[0108] Question: Is there any sign of mechanical wear or increased vibration in well C?

[0109] Answer: Yes, I have detected a slight increase in the pump vibration levels. The current vibration reading is above the normal threshold, this could indicate potential mechanical wear or an imbalance in the pump components. Possible causes include impeller erosion or a misalignment issue. I recommend scheduling a vibration analysis and inspecting for any loose fittings or worn-out components.

[0110] Question: What are the top contributors to declining production in well D? Answer: After analysing production data, I identified 3 key contributors to declining production. 1) increased water cut from 15% to 22% over the past month. 2) The efficiency of the ESP has declined 5%, possibly due to mechanical wear or increased gas interference 3) There has been a gradual drop in reservoir pressure from 1600 psi to 1450 psi indicating decrease in inflow potential.

[0111] Question: Are there any recent electrical faults detected in well E?

[0112] Answer: Yes, I detected a phase imbalance in the electrical readings. The current on Phase B has consistently been 7% lower than the other phases for the last 12 hours. This could indicate a potential issue with the power supply or an electrical cable connection.

[0113] I recommend checking the connections and monitoring the motor windings for any irregularities.

[0114] Question: Is there any indication of an electrical short circuit risk in well F?

[0115] Answer: There have been several instances of high leakage current in the past 48 hours, with the current readings showing leakage increase of 15% compared to normal levels. This may indicate a potential insulation failure or worn electrical cables. Immediate inspection of the cable insulation and motor wiring is recommended to prevent short circuits.

[0116] Fig. 2b shows the same contents as Fig. 2a. Additionally, however, Fig. 2b comprises arrows from each Al engine 220, 230, 240, 251 and 256 pointing to a box named “validation score”. Cross expert validator Al engine 203 (represented by a box below the validation score) validates (or refuses) Al engine’s 230, 240, 251 and 256 output by calculating a respective validation score. For any of Al engines 230, 240, 251 and 256, their respective predecessors’ output(s) may be examined. This is represented by boxes below the representations of Al engines 230, 240, 251 and 256. In the case of physics characteristics Al engine 230, cross-expert validator 203 may validate or refuse a given abnormal event and a physics simulation.

[0117] In the case of physics characteristics Al engine 230, cross-expert validator 203 may validate or refuse a given abnormal event and a physics simulation. In the case of root cause analysis Al engine 240, cross-expert validator 203 may validate or refuse a given abnormal event, a physics simulation and a given root cause analysis. In the case of failure prevention plan Al engine 251, cross-expert validator 203 may validate or refuse a given abnormal event, a physics simulation, a given root cause analysis and a failure prevention plan. Finally, in the case of action plan Al engine 256, cross-expert validator 203 may validate or refuse a given abnormal event and a physics simulation. In the case of root cause analysis Al engine 240, cross-expert validator 203 may validate or refuse a given abnormal event, a physics simulation, a given root cause analysis, a failure prevention plan and an action plan.

[0118] Cross-expert validator 203 may use an independent LLM-based method to estimate a validation score for the input data. For this, it may produce an objective such as: “Given the output from an expert, compute the relevancy of the outputs with respect to the outputs from other experts and produce a validation score”.

[0119] If the validation score is lesser than a specified confidence threshold, the system may re-invoke the retriever to repeat the process. This process maybe repeated until an output is produced with a validation score greater than the set confidence threshold. The motivation behind using information from multiple Al engines is to ensure that the output is relevant with respect to the target domain and therefore also act as a guard rail for the overall system.

[0120] As indicated by three diamonds in the bottom left corner of the figure, the validation may comprise a pattern check, a logic check and a data check.

[0121] Fig. 3 illustrates a generic workflow of an Al engine. Each step in the figure is represented by a box. The boxes are interlinked with arrows. Starting from a user in the top left corner, the workflow is indicated by the arrows in clockwise direction.

[0122] First, a user may set an objective. This objective is used for retriever 304 and LLM 301. Retriever 304 may retrieve information from (vector) database 305 that is relevant to the target objective. The retrieved contents may be ranked with respect to their relevancy scores and verified for relevancy with respect to the target objective through embedding-based matching methods. Example of retrievers include keyword-based retrievers, dense embedding based retrievers, sparse embedding based retrievers (SPLADE), filter-retriever, elastic search-based retrievers, and ensemble-based retrievers.

[0123] Relevant data is passed to LLM 301. LLM 301 may take an input objective, and the data retrieved from retriever 304 and may produce an output. After computation, LLM 301 passes its results to grader 302. Grader 302 may start with generating an objective such as: “Given the output from an Al engine, compute the grade score of the outputs in terms of relevancy to the target objective.”

[0124] Grader 302 may compute a grade. Grader 302 may use a LLM-based model. If the grading score is less than a confidence threshold, the system may reinvoke the LLM to re-generate outputs. This process is repeated until an output with a grade greater than the confidence threshold is produced. In this exemplary embodiment, according to whether the grade is higher or lower than the exemplary threshold of 0.9, the result of LLM 301 is passed forward to cross-expert validator 303. If the grade is below the threshold value, the grading process is repeated. This procedure maybe carried out as long as the grade is below the threshold value.

[0125] Cross-expert validator 303 may start with generating an objective such as: “Given the output from an Al engine, compute the relevancy of the outputs with respect to the outputs from other Al engines and produce a validation score.”

[0126] Subsequently, cross-expert validator 303 may compute a validation score. If the latter is above the exemplary threshold value of 0.8, the final output is reported to the user. If the threshold value of the validation score is not reached, the process may be repeated as long as the threshold value is not attained.

[0127] For any of the Al engines depicted in Fig. 3 (generic Al engine 300 as well as retriever 304, LLM 301, grader 302 and cross-expert validator 303, LLama, GPT3 and comparable models maybe used as baseline models.

[0128] Fig. 4 shows abnormality detection Al engine 420. From a well site on the left side of the figure, real-time sensor data is obtained. This real-time operation sensor data is represented in a box comprising motor vibrations (ESP_Vibration), electric current (ESP_Current), voltage (ESP_Voltage), intake pressure (ESP_Intake_Pres), discharge pressure (ESP_Discharge_Pres) and frequency (ESP_frequency). The real-time operation sensor data may comprise other ESP-related or well-related paramerts. An arrow pointing from the well site to the real-time operation sensor data box indicates that this data is obtained from the well site. More precisely, the data may be obtained from sensors located within the pump or the within the well. This real-time operation sensor data may be stored in a data base or directly transmitted to abnormality detection Al engine 420. Based on the real-time operation sensor data, time to failure predictions (TTF predictions) may be carried out using an LSTM regressor (long short- time memory regressor, this It is a type of recurrent neural network architecture designed to handle sequential data), a graph regressor, a transformer or a U-net regressor (The U-Net is a convolutional neural network architecture with a characteristic "U" shape). Together with a 1TF prediction, other useful output such as a sensor percentage change, ESP trips, ESP frequency changes, sensor statistics (mean, std), sensor errors and remaining useful life estimation may be inferred from the realtime operation sensor data. In Fig. 4, the TTF prediction and the outputs are represented by grey boxes. The real-time operation sensor data box, the TTF prediction box, the outputs box and the abnormality detection Al engine 420 box are respectively connected by an arrow indicative of the chronology of the workflow. In this specific embodiment, the TTF prediction and the outputs are not determined by the abnormality detection Al engine 420. However, in other embodiments, the abnormality detection Al engine 420 may carry out the step of the TTF prediction and the determination of the further exemplary output.

[0129] The abnormality detection Al engine 420 workflow may be directed by the objective of detecting abnormal events. In Fig. 4, this is represented by a box above abnormality detection Al engine 420 comprising “Objective Generation for abnormal event detection”.

[0130] A possible objective generation may be: “Given the real-time data for an event, prediction data from ML models, and historical data comprising ESP normal and abnormal events, produce a list of timestamps which represent abnormalities in the sensors data. Further, analyse the event in terms of severity of the abnormality. “

[0131] An arrow points from the objective generation box to the box representing abnormality detection Al engine 420.

[0132] In this embodiment, an ESP events data base (425) is shown below abnormality detection Al engine 420. By an embedding generation mechanism (represented by “<...>” to the left of ESP events data base 425), a natural language query maybe embedded into an embedding vector space. This embedding mechanism may be implemented by a conversational layer LLM, by a retriever and / or a LLM within abnormality detection Al engine 420. Subsequently, the most relevant events maybe extracted from ESP events data base 425 and considered for abnormality detection in the real-time operation sensor data. This mechanism is indicated by a black arrow showing from ESP events data base 425 to abnormality detection Al engine 420. The consideration of events from ESP events data base 425 is only exemplary in this embodiment. Abnormality detection Al engine 420 may also work without any historical events from ESP events data base 425.

[0133] One an abnormality in the real-time operation sensor data is detected, the start time, the end time and the severity of the abnormality (indicated by a severity score) may be stored to a IOT storage device (460). This step is indicated by a box on the right of Fig.

[0134] 4 comprising “Abnormality detection: - start time of event; - end time of event; - severity of abnormality”. From this box, an arrow shows toward IOT storage 460. In general, the final storage of event data is optional.

[0135] The abnormality detection Al engine’s answer to the objective may be: “Two abnormal events were detected with a severity of 90% and 70% for a duration of 7 days and 10 days, respectively”.

[0136] In order to provide a practical overview over the most relevant information during abnormality detection and other steps, a collection of visual analytics dashboards may be comprised. These represent an intuitive and dynamic interface for monitoring and managing ESP systems. Dashboards may be designed to display real-time performance metrics, operational data, and predictive insights in a user-friendly format. They may comprise real time data collected from a variety of sensors and data streams related to ESPs operations. Some of this information may be pump efficiency, output relative to energy consumption ratio, fluid production rates (oil, water and gas), pump pressure and temperature, downhole conditions that may impact performance, electrical parameters (such as voltage, current, power) and motor load. They may also comprise vibration and wear indications, mechanical integrity and potential signs of deterioration. Predictive insights may comprise failure predictions (e.g.: expected motor breakdown in 72 hours based on current conditions). Abnormalities in the realtime operation sensor data (e.g: an unexpected pressure drop in the well) may be flagged on the dashboard.

[0137] Fig. 5 illustrates a workflow related to the physics characteristics Al engine.

[0138] As in Fig. 4, Fig. 5 features a representation of the well site and a box comprising abnormality detection Al engine 520. These two elements deliver input for physics characteristics Al engine 530 (represented by a “+” and three arrows pointing towards physics characteristics Al engine 530). As before, a box comprising objective generation for physics simulation placed above physics characteristics Al engine 530 points towards the latter. Physics-based features like well geometry and ES P design specifications (represented by a box below physics characteristics Al engine 530) points toward ESP physics data base 535. The latter points towards physics characteristics Al engine 530. Yet again, a symbol representing the embedding generation is placed left and a symbol representing “extract most relevant data” is placed to the right of ESP physics data base 535. In the same manner as before, the output of physics characteristics Al engine 530 is represented on the right side of Fig. 5 by a box which comprises physics-based features including fluid flow features, mechanical stress features and electrical power features. An arrow points towards IOT storage 560.

[0139] It should be clarified that physics-based input features such as well geometry or ESP design specifications need not necessarily be retrieved from ESP physics data base 535. It may also be possible that a LLM method of physics characteristics Al engine 530 inherently “memorizes” the relevant features (this information may be comprised in the numerous weights and biases). In this respect, the example of Fig. 5 is non-exhaustive.

[0140] The operation of physics characteristics Al engine 530 may start with the generation of an objective such as: “Given the real-time data for an event, and static data comprising ESP and well specifications, generate simulated data that represents normal operating conditions for fluid flow characteristics (intake and discharge pressures), heat transfer characteristics of the ESP motor (temperatures), mechanical stress (pump efficiency, pump wear), and electrical power characteristics (motor torque, pump power) of the ESP.”

[0141] Using the above objective, physics characteristics Al engine 530 may search for the most relevant information in ESP physics data base 535, may retrieve the relevant data, may invoke an LLM with the objective and the retrieved data. The LLM may produce simulated data that represents fluid flow characteristics, mechanical stress characteristics, and electrical power-based features. These outputs may be graded and verified using the grading method and the physics-based physical model of ESP.

[0142] An exemplary answer to the above question may be: “Two abnormal events were detected with a severity of 90% for a duration of 7 days, based on the normal conditions that were generated for mechanical stress and electrical power related characteristics”.

[0143] Physics characteristics Al engine 530 also allows for simulations of operating characteristics by carrying out scenario simulation and what if analysis. Operators may adjust key parameters (e.g. pump speed, fluid flow rate) in a simulated environment to see how those changes might impact overall performance or contribute to risk factors like pump cavitation, overloading, or motor overheating. The system may present the outcomes of these simulations graphically.

[0144] Fig. 6 shows an exemplary workflow of root cause analysis Al engine 640. As before, well site 610, abnormality detection Al engine 620 and physics characteristics Al engine 630 are depicted. These elements deliver input to root cause analysis Al engine 640 (represented by arrows and a “+”). Again, a box indicating “objective generation for root cause analysis” figures above root cause analysis Al engine 640 and pointing toward the latter. Below root cause analysis Al engine 640, a box comprising failure logs / reports is shown. This box points towards a representation of ESP failure data base 645 which is, once again, placed in between “embedding generation” and “extract most relevant causes”. An arrow pointing from ESP failures data base 645 to root cause analysis Al engine 640 indicates that, in this specific embodiment, the root cause analysis Al engine 640 is based, at least in part, on failure logs / reports retrieved from ESP failures data base 645. This retrieval maybe effectuated by a retriever, by a root cause analysis Al engine’s 640 LLM or by another Al engine. The output box placed to the right of root cause analysis Al engine 640 contains root cause analysis results such as electrical issues, abnormalities in pressures, frozen data etc. These results may be stored in IOT storage device 660.

[0145] The operation of root cause analysis Al engine 640 may start with the generation of an objective such as:

[0146] “Given the real-time ESP sensors data for an event, data from physics simulations, and historical data from failure events, produce the root cause analysis of the detected event in terms of electrical issues, mechanical issues, and their potential implications in the future”.

[0147] Using the above objective, root cause analysis Al engine 640 may retrieve relevant information from the database and invokes an LLM to produce the desired root cause information including: spike events representing electrical issue, step events representing frequency change, transient increasing trend representing electrical leakages, transient decreasing trend representing production losses, frequent shutdowns and ESP trips representing integrity issue, leakages in electrical signal representing electrical issues, abnormalities in pressures and temperatures representing mechanical issues, well not flowing representing shutdowns, frozen data representing sensor failures. These outputs may be graded and verified using a grading method.

[0148] An exemplary answer to the above question may be: “Event 1 shows transient increasing trends in electrical leakages, followed by spikes in motor vibration and a consistent increase in differential pressures. This may lead to production losses. The potential cause could be fluid leakage from the motor or blockage in casing”.

[0149] The root cause analysis may be displayed on a dashboard or on any other user-oriented output device.

[0150] Fig. 7 comprises on the left side well side 710, abnormality detection Al engine 720, physics characteristics Al engine 730 and root cause analysis Al engine 740. Indicated by arrows and a “+” sign, these elements provide input for the central failure prevention plan Al engine 751. From ESP failure prevention plans and interventions data base 755 (which is accompanied by an embedding generation mechanism to its left and most relevant plans to its right), failure prevention plan Al engine 751 retrieves ESP failure prevention plans and ESP failure prevention interventions (indicated by a box below ESP failure prevention plans and interventions data base 755 pointing upwards). It should be recalled that the retrieval from a data base is non-exhaustive. It would also be possible that failure prevention plan Al engine 751 has “memorized” the necessary parameters inherently, e.g. by numerous weights and biases of a LLM. The result of failure prevention plan Al engine 751 is represented to its right by a box comprising failure prevention plans such as “adjust flow rate”, “adjust frequency”, “maintain speed”. These plans maybe stored in IOT storage device 760. A storage of the plans as implemented in this embodiment is not strictly necessary.

[0151] The operation of failure prevention plan Al engine 751 may start with the generation of an objective such as: “Given the real-time ESP sensors data for an event, it’s associated root cause analysis produced by Expert 3, and data for historical failure prevention strategies, generate a failure prevention plan that minimizes the severity of the current abnormal event”.

[0152] Using the objective, failure prevention plan Al engine 751 may retrieve relevant information from ESP failure prevention plans and interventions data base 755 and may invoke an LLM to produce a failure prevention plan which, inter alia, may comprise: adjust flow rate parameters, adjust frequency parameter, adjust ESP voltage parameter, recommend a component replacement, recommend a component cleaning, recommend an equipment shutdown, these outputs are graded and verified using the grading method.

[0153] An exemplary answer to the above question may be: “There were two events detected which showed mechanical issues with the ESP. It is recommended to shut down the well and inspect the motor housing for tube leakage, corrosion, or motor burnt wiring”.

[0154] Fig. 8 comprises abnormality detection Al engine 820, physics characteristics Al engine 830, root cause analysis Al engine 840 and failure prevention plan Al engine 851. These elements are respectively represented by boxes on the left side of the figure.

[0155] Their respective outputs enter into a box named conflict detector 870 (represented by arrows and a “+” sign). Another arrow points from conflict detector 870 to action plan Al engine 856. The latter points towards a box comprising action plans such as voltage maintenance or shut down. From this box, an arrow points towards well site 810 in the bottom of the figure. Additionally, the arrow is marked with “action deployment”.

[0156] Action plan Al engine 856 may have access to IOT storage device 460 (comprising time series events produced by abnormality detection Al engine 420), to IOT storage device 560 (comprising physics-based simulation data produced by physics characteristics Al engine 530), to IOT storage device 660 (comprising root cause analysis data generated by root cause analysis Al engine 640) and to IOT storage device 760 (comprising storage failure prevention plans generated by failure prevention plan Al engine 751 and well intervention logs / reports). Storage devices 460, 560, 660, 760 are not represented in Fig. 8.

[0157] Action plan Al engine 856 may also have access to ESP design specifications and based on the type of the ESP (single ESP with fixed drive, variable speed ESP, or twin ESP configuration), the control variables may automatically be selected by the system to achieve a target objective.

[0158] Action plan Al engine 856 may also have access conflict detector 870 which detects conflicts between the outputs of abnormality detection Al engine 820, physics characteristics Al engine 830, root cause analysis Al engine 840 and failure prevention plan Al engine 851. For each conflict, the method may compute a conflict severity score, may rank the conflicts with respect to their severity scores, and may filter the conflicts based on a threshold on the severity. Finally, outputs from abnormality detection Al engine 820, physics characteristics Al engine 830, root cause analysis Al engine 840 and failure prevention plan Al engine 851 with high conflict severity are rejected and not analyzed by action plan Al engine 856.

[0159] The operation of action plan Al engine 856 may start with the generation of an objective such as: “Given a target objective by the user and data that constitutes realtime events, their associated root cause analysis, and failure prevention plans, find the best action to achieve the target objective”.

[0160] Using the objective, action plan Al engine 856 may retrieve relevant information from storage devices 460, 560, 660, 760 and may invoke an LLM to produce an action plan in terms of specific actions which are finally executed on the well site.

[0161] The outputs of action plan Al engine 856 may be graded and verified using a validation system.

[0162] Below are exemplary answers given by action plan Al engine 856. If a user has priorly set the target to avoid pump failure, the answer maybe: “To minimize the risk of ESP failure, the ESP voltage should be dropped by 500 Volts for a duration of 2 days. Meanwhile the oil production should be monitored for any losses.”

[0163] However, if a user has priorly set the target to avoid production loss, the answer may be: “To minimize production losses, the ESP voltage should be increased by 500 Volts for a duration of 10 hours. Meanwhile the electrical power and pump mechanical wear should be monitored for any surge.”

[0164] Action plans may be displayed on a dashboard or on any other user-oriented output device.

[0165] Fig. 9 shows an overall orchestration framework for the Al engines 920, 930, 940, 951 and 956. On the left side of the figure, well sites 911, 912 and 913 are depicted.

[0166] Indicated by an arrow, they provide real-time operations sensor data to IOT data device 910. This data and historical data from historical data device 905 is forwarded (indicated by arrows) to a graph data platform and, subsequently, forwarded (indicated by another arrow) to service orchestrator 906 in the top of Fig. 9.

[0167] Service orchestrator 906 may trigger Al engines 920, 930, 940, 951 and 956. This effect is represented by respective arrows pointing toward the Al engines 920, 930, 940, 951 and 956. Each of these Al engines may record their actions in operation logs 907. This action is indicated by five arrows pointing toward the symbolic representation of operation logs 907 in the middle of the figure.

[0168] An arrow pointing toward failed service Al engine 980 indicates that operations logs 907 are passed to the latter Al engine. Another arrow pointing to re-triggering Al engine 990 indicates that, if a service of one of Al engines 920, 930, 940, 951 and 956 has been detected, re-triggering Al engine 990 may re-trigger the respective Al engine by informing service orchestrator 906. This last step is shown by another arrow. A repeat sign in the middle of the figure clarifies that the depicted orchestration framework is a closed-loop mechanism. Failed services maybe re-triggered as often as they fail. Many iterations maybe necessary until the service in question runs successfully.

[0169] For real -world deployment, an embedded computer with an onboard GPU device may host the mixture of Al engines 920, 930, 940, 951 and 956. The latter communicate with storage devices 440, 540, 640 and 740 (not represented) and with IOT data device 910 that comprises real-time sensors data received from the ESP sensors from well sites.

[0170] Each well may be deployed with one set of the proposed mixture of Al engines 920, 930, 940, 951 and 956. The mixture of Al engines may be well specific and therefore automatically adapt to the specific operating conditions of the ESPs. This enables the proposed system to automatically adjust to specific characteristics of the reservoir and produce actions that are optimal with respect to well characteristics.

[0171] The conversational layer may comprise an included dashboard. The dashboard may be tailored to operator needs, allowing users to configure custom views. For example, a field operator may want to focus on specific metrics like pump pressure and vibration, while a production engineer may prioritize production flow rates and efficiency trends. Also, the system may generate customizable alerts, sending notifications via the dashboard (or other channels like email / SMS) when key metrics reach predefined thresholds.

[0172] Operators may ask specific questions through the human-machine-interface and the system may pull relevant data from the dashboard and present a clear answer. More than answering questions, the conversational layer may also provide recommendations. For example, if an anomaly is detected in motor performance, the system may suggest adjusting pump speed or scheduling a maintenance check. Furthermore, an operator can engage with the system to conduct a guided root cause analysis. For example, if an operator notices a performance drop, they may ask the system to investigate. The conversational layer may guide them step by step, explaining each factor that may be contributing to the problem - whether it is related to electrical load, fluid dynamics, or mechanical wear. The operator may continue asking follow-up questions to drill deeper into the data until they reach a satisfactory explanation. Also, operators may access critical data on the go through mobile devices or even via voice commands.

[0173] The methods according to the present invention may be implemented in terms of a computer program which may be executed on any suitable data processing device comprising means (e.g., a memory and one or more processors operatively coupled to the memory) being configured accordingly. The computer program may be stored as computer-executable instructions on a non-transitory computer-readable medium.

[0174] Embodiments of the present disclosure may be realized in any of various forms. For example, in some embodiments, the present invention may be realized as a computer- implemented method, a computer-readable memory medium, or a computer system.

[0175] In some embodiments, a non-transitory computer-readable memory medium may be configured so that it stores program instructions and / or data, where the program instructions, if executed by a computer system, cause the computer system to perform a method, e.g., any of the method embodiments described herein, or, any combination of the method embodiments de-scribed herein, or, any subset of any of the method embodiments described herein, or, any com-bination of such subsets.

[0176] In some embodiments, a computing device may be configured to include a processor (or a set of processors) and a memory medium, where the memory medium stores program instructions, where the processor is configured to read and execute the program instructions from the memory medium, where the program instructions are executable to implement any of the various method embodiments described herein (or, any combination of the method embodiments described herein, or, any subset of any of the method embodiments described herein, or, any combination of such subsets). The device may be realized in any of various forms.

[0177] Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the present disclosure, even where only a single embodiment is described with respect to a particular feature. Examples of features provided in the disclosure are intended to be illustrative rather than restrictive unless stated otherwise. The above description is intended to cover such alternatives, modifications, and equivalents as would be apparent to a person skilled in the art having the benefit of this disclosure.

[0178] The scope of the present disclosure includes any feature or combination of features disclosed herein (either explicitly or implicitly), or any generalization thereof, whether or not it mitigates any or all of the problems addressed herein. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the appended claims.

Claims

December 19, 2024MATRIX JVCO LTD trading as AIQ A1775O6WO CKA / HEP / brbClaims1. A computer-implemented method for preventing an electrical submersible5 pump, ESP, failure, the method comprising: obtaining real-time operation sensor data from one or more sensors, the realtime operation sensor data being indicative of the operation of the ESP; detecting, by an abnormality detection artificial intelligence, Al, engine (220), at least one abnormality in the real-time operation sensor data, the abnormality 0 indicating an abnormal event of the operation of the ESP; generating, by a physics characteristics Al engine (230), at least one operating characteristic of the ESP based at least on the abnormality and on a physical model of the ESP; determining, by a root cause analysis Al engine (240), at least one root cause of5 the ESP failure based at least on the at least one abnormality and the at least one operating characteristic; and generating at least one failure prevention measure to reduce the risk that the ESP failure occurs. 0 2. The computer-implemented method of claim 1, wherein the step of generating a failure prevention measure further comprises: generating, by a prevention plan Al engine (251), a failure prevention plan based at least on the root cause.

53. The computer-implemented method of claim 2, wherein the step of generating a failure prevention measure further comprises: generating, by an action Al engine (256), an action plan comprising at least one0 action item to be performed to minimize the risk that the ESP failure occurs based at least on the failure prevention plan.

4. The computer-implemented method of claim 3, wherein generating an action plan is based, at least in part, on a target objective.

5. The computer-implemented method of any one of the preceding claims, wherein the step of detecting at least one abnormality further comprises: parsing, selecting and retrieving historical events comprising normal and abnormal operating conditions of the ESP from an ESP event data base (425).

6. The computer-implemented method of any one of the preceding claims, wherein the step of detecting at least one abnormality further comprises: predicting a remaining operating time of the ESP.

7. The computer-implemented method of any one of the preceding claims, wherein the step of generating at least one operating characteristic of the ESP is further based on the real-time operation sensor data.

8. The computer-implemented method of any one of the preceding claims, wherein the at least one operating characteristic of the ESP comprises one or more of: intake pressure, discharge pressure, motor temperature, pump efficiency, pump wear, motor torque, pump power.

9. The computer-implemented method of any one of the preceding claims, wherein the physical model of the ESP comprises: a well geometry and / or ESP design specifications.

10. The computer-implemented method of claim 9, wherein the ESP design specifications comprise at least one of: a choke position, a frequency, a voltage, a swap ESP.

11. The computer-implemented method of any one of the preceding claims, wherein the step of generating at least one operating characteristic of the ESP further comprises: parsing, selecting and retrieving relevant information on the physical model of the ESP from an ESP physics data base (535).

12. The computer-implemented method of any one of the preceding claims, wherein the step of determining a root cause of the ESP failure is further based on one or more of:- real-time operation sensor data,- data of historical ESP failures,- ESP pulling reports, and / or- ESP evaluation log files.

13. The computer-implemented method of any one of the preceding claims, wherein generating a failure prevention measure is further based on one or more of: the real-time operation sensor data, the at least one abnormality in the real-time operation sensor data, the at least one operating characteristic of the ESP, an ESP failure prevention plan, an ESP failure prevention intervention.

14. The computer-implemented method of any one of the preceding claims, wherein generating a failure prevention measure of the ESP further comprises: parsing, selecting and retrieving data on relevant ESP failure prevention plans and / or ESP failure prevention interventions from an ESP failure prevention and / or failure prevention intervention data base (645).

15. The computer-implemented method of any one of the preceding claims, wherein generating a failure prevention measure comprises one or more of:flow rate adjustment, ESP frequency adjustment, ESP voltage adjustment, ESP component replacement, ESP component inspection, ESP component cleaning, ESP speed maintenance, ESP shutdown.

16. The computer-implemented method of any one of the preceding claims, further comprising: detecting, based on the at least one abnormality, the at least one operation characteristic, the at least one root cause and the at least one failure prevention measure, a conflict between the at least one operation characteristic, the at least one root cause and the at least one failure prevention measure; determining a conflict severity score of the conflict; and rejecting the at least one abnormality, the at least one operation characteristic, the at least one root cause and / or the at least one failure prevention measure based on the conflict severity score.

17. The method of one of the preceding claims, further comprising: obtaining input data from a user-machine interface; and determining a contextual relevance between data obtained from a user-machine interface and an output of at least one of the Al engines by an Al engine.

18. The computer-implemented method of any one of the preceding claims, further comprising: obtaining natural language input data from a user-machine interface; and producing, by at least the abnormality detection Al engine (220), the physics characteristics Al engine (230) and the root cause analysis Al engine (240) and a conversational layer Al engine, a natural language answer to a user-machine-interface.

19. The method of one of the preceding claims, further comprising: obtaining at least one operation log (907) from at least one Al engine (220, 230, 240, 251, 256); determining, based on the at least one operation log, by a failed service Al engine (980), whether an Al engine has failed; and re-triggering, by a triggering Al engine (990), a failed Al engine (220, 230, 240, 251, 256).

20. The computer-implemented method of one of the preceding claims, wherein at least one Al engine comprises at least a large language model, LLM (301), and / or a retriever (304).

21. The computer-implemented method of claim 20, wherein detecting at least one abnormality in the real-time operation sensor data, generating at least one operating characteristic of the ESP, determining at least one root cause of the ESP failure and / or generating at least one failure prevention measure further comprises: determining, based on a target objective, the relevancy to the target objective of the at least one abnormality in the real-time operation sensor data, the at least one operating characteristic of the ESP, the at least one root cause of the ESP failure and / or the at least one failure prevention measure; computing, based on the relevancy to the target objective, by a grader (302), a grade score; and re-invoking, based on whether the grade score reaches a first confidence threshold, the LLM (301) and / or the retriever (304) of at least one of the Al engines (220, 230, 240, 251, 256).

22. The computer-implemented method of claim 20 or 21, further comprising:determining, by one of the Al engines (220, 230, 240, 251, 256), based on data obtained from at least one further Al engine (220, 230, 240, 251, 256), a relevancy to the at least one further Al engine (220, 230, 240, 251, 256) of the at least one abnormality in the real-time operation sensor data, the at least one operating characteristic of the ESP, the at least one root cause of the ESP failure and / or the at least one failure prevention measure; computing, based on the relevancy to the at least one further Al engine, by a cross-expert validator (203, 303), a validation score; and re-invoking, based on whether the validation score reaches a second confidence threshold, the LLM (301) and / or the retriever (304) of at least one Al engine (220, 230, 240, 251, 256).

23. The method of one of claims 20 - 22, further comprising: obtaining input data from a user-machine interface; and dynamically adapting at least one of the LLM (301) according to the input data.

24. A computer system comprising a processing unit and a computer-readable memory adapted to carry out the method of any one of the claims 1-23.

25. A computer program comprising instructions, which when executed by a computer, causing the computer to carry out the method of any one of the claims 1-23.

Images