Determining root cause of a fault in an industrial plant using generative machine learning

Abstract

A computer-implemented method (100) for determining a root cause (6) of a fault (2) in an industrial plant (1), comprising the steps of: • providing (110) a query (3) for a root cause of a suspected fault (2) in the industrial plant or in one of its assets, and / or a root cause of a symptom (2a) exhibited by the suspected fault (1); • processing (120) the query (3), said processing comprising determining at least a type (2b) of the suspected fault (2) and a suspected location (2c) of the fault (2) in the industrial plant (1) from the query (3); • providing (130) to a generative machine learning model GMLM (4), at least: o the query (3), o the determined type (2b) and suspected location (2c) of the fault (2), and o dynamic context information (5) about the industrial plant (1), said dynamic context (5) comprising at least state variables and / or measurements captured in the industrial plant (1) and / or its control system, thereby obtaining an output (4a) indicative of at least one candidate root cause (6); and • determining (160) the sought root cause (6) from the output (4a) of the GMLM (4).

Description

Technical Field

[0001] This invention relates to troubleshooting in industrial plants, and particularly to finding the root cause of a given problem. Background Technology

[0002] In industrial processing plants, operators must assess complex chemical processes. Depending on the purpose, the objectives of process operation can vary, such as maintaining high levels of operational safety, product quality, sustainability, or operational efficiency. Typically, the implemented process control system (PCS) can automatically handle certain deviations from the process's desired steady state. However, in some cases, deviations in one part of the process may propagate to other parts, and the PCS cannot effectively manage them. In such anomalies, the operator's task is to address the situation and resolve its underlying root causes through corrective actions.

[0003] Here, the operator's assessment must be performed promptly and based on multiple factors. That is, the operator must (i) understand the current status of the processing plant, (ii) gather information on the appropriate actions to be taken, (iii) predict the results and quantify the risks of the actions before taking them, (iv) select appropriate corrective actions and intervene in the process accordingly, (v) monitor the results of the actions taken, and (vi) may refine the assessment and implement additional / alternative interventions.

[0004] The required information may be difficult to retrieve. It is displayed on multiple screens and may originate from multiple data sources and systems. It may also be difficult to understand due to factors such as: (i) an excessive amount of available historical data; (ii) a large number of alerts that may overwhelm logs; (iii) terminology that may hinder a direct assessment of the situation; and (iv) redundant information that may lead to sensory overload. Therefore, operators may be hindered in making decisive decisions. Additionally, operators require considerable experience to understand plant conditions and comprehend causal relationships. This necessitates extensive experience. Summary of the Invention The purpose of this invention

[0005] Therefore, the object of this invention is to facilitate the identification of the root causes of industrial plant failures.

[0006] This objective is achieved by a computer-implemented method according to the independent claim. Further advantageous embodiments are described in detail in the corresponding dependent claims. The disclosure of this invention

[0007] This invention provides a computer-implemented method for determining the root cause of a failure in an industrial plant. A failure can be any deviation between the operational state of the industrial plant and / or at least one of the industrial assets comprising the industrial plant and its expected normal operating state. Specifically, failures can involve alarms triggered by individual assets, but can also involve higher-level alarms related to the entire industrial plant, such as service alarms and process alarms. For example, a service alarm may be triggered in response to an interruption or inability to start a service or operation in the industrial plant. Process alarms may indicate a problem, but they do not necessarily mean that the overall operation of the industrial plant is affected. If corrective action is taken immediately after a process alarm is triggered, the plant's operation can continue uninterrupted. However, if a service alarm is triggered, it means that some specific actions that should be performed according to process procedures cannot be performed, which may bring the entire industrial process to a halt.

[0008] This method provides queries regarding the root cause of a suspected malfunction in an industrial plant or its assets, and / or the root cause of the symptoms exhibited by that suspected malfunction. For example, the query can be generated by a process control system (such as a distributed control system, DCS) or any kind of alarm system, or by an operator seeking assistance with a malfunction. For instance, when the Apollo 13 mission went wrong, the query might be, “I just turned on the electric agitator on the liquid oxygen tank, and now we heard a bang and the MAIN B BUS UNDERVOLT alarm. What happened? What should we do?”

[0009] The "root cause" of a failure refers to the fundamental or primary reason for a malfunction or abnormal condition within an industrial plant. In other words, the root cause is the primary source of the observed deviation that triggers a series of events leading to symptoms or alarm states in the plant. Identifying the root cause is crucial for implementing appropriate remedial actions to restore normal operation.

[0010] A query is a question or prompt designed to uncover the root cause of a suspected malfunction and / or clarify the symptoms exhibited by that malfunction. Queries can originate from various sources, such as operators, alarm systems, or control systems, and typically include indications of the type and location of the suspected malfunction within an industrial plant. Processing queries narrows the scope of investigation for generative machine learning models to effectively identify one or more potential root causes.

[0011] In the next step, the query is processed. This processing includes determining at least the type of the suspected fault and its suspected location within the industrial plant based on the query. For example, the type of fault may indicate one or more categories in a classification of faults within the plant. In particular, such classification may depend on the structure of the industrial plant and / or the industrial processes performed on it. For example, there may be process alarms, service alarms, and alerts that are clearly associated with the failure of a single industrial asset. In another example, the fault may involve something that doesn't work at all, something that works but of lower quality than expected, or something that works but slower than expected. In yet another example, the type of the suspected fault may indicate whether the fault is related to an operational technology (OT) problem, an information technology (IT) problem, a hydraulic problem, a pneumatic problem, an electrical problem, or a mechanical problem. That is, the fault type may describe a category of symptoms of the fault without limiting the potential root cause. For example, a pneumatic problem could have a software crash in the central supply of compressed air as its root cause. For example, the location may indicate a section or other subdivision of the plant involved in the query. The processing of queries can narrow down the likelihood of root causes in such a way that follow-up investigations using the generative machine learning model GMLM are more likely to find solutions that point in the right direction.

[0012] At least the following must be given: •Query, • The identified type and suspected location of the fault, and • Dynamic context information about the industrial plant, wherein the dynamic context includes at least state variables and / or measurements captured in the industrial plant and / or its control systems.

[0013] Based on this, and optional further inputs, GMLM delivers an output indicating at least one candidate root cause. The sought root cause is then determined based on this output.

[0014] This discovery enables GMLM to perform causal reasoning about possible root causes. Dynamic contextual information contains information about the possible connections between observed faults or symptoms (on the one hand) and the type and / or location of the fault (on the other hand): at the onset of the fault, a root cause exists, and the fault later manifests as observable symptoms. In particular, based on dynamic contextual information, root causes completely unrelated to the fault and / or symptoms can be ruled out. For example, if a particular stage of an industrial process utilizes only a subset of industrial assets, and the dynamic contextual information indicates that all unused assets are effectively shut down as is, these unused resources can be ruled out as possible root causes.

[0015] The search space for causal chains from possible root causes to observed failures and / or symptoms is enormous. In particular, such causal chains typically involve several elements, and the size of the search space grows exponentially with the number of elements. As the saying goes, "For want of a nail, the horseshoe was lost; for want of a horseshoe, the horse was lost; for want of a horse, the rider was lost; for want of a rider, the battle was lost; for want of a battle, the kingdom was lost—all because of a missing nail." Causal reasoning can quickly eliminate unlikely root causes, allowing this enormous search space to be reduced to a manageable size. This enables GMLM to focus on finding the actual possible root causes without "distracting" most of its attention to areas of the search space that are irrelevant anyway.

[0016] For example, by taking into account dynamic contextual information, approximately 50 potential root causes can be reduced to 3 possible root causes worthy of further investigation.

[0017] The end result is that the most likely root cause of a given fault and / or symptom can be determined automatically, much faster and easier than doing it manually. This, in turn, means that faults can be remedied more quickly. The technical process of remedying a given fault and / or symptom begins the moment the fault and / or symptom are noticed. It includes both tracing the root cause and remedying that root cause. If the tracing of the root cause is accelerated, the entire process of remedying the given fault and / or symptom also benefits accordingly. The possibility of automating root cause tracing also paves the way for automating the execution of remedies.

[0018] In a particularly advantageous embodiment, the determination of the sought root cause includes: • Based on multiple candidate root causes indicated by one or more outputs of the GMLM, determine the most probable root cause as the sought root cause; and • Determine why the root cause is considered the most likely cause.

[0019] This provides a simple way to rationalize the finally identified root cause and prevents the GMLM from exhibiting a tendency to produce "illusions"—outputs that initially seem reasonable but are actually incorrect. For example, such "illusions" can occur if the information used to train the GMLM or the context provided to it when making a query does not contain the answer to the query. "Illusions" can be detected by examining why a particular root cause is considered the most probable cause. For instance, if the GMLM outputs, "I know only this controller might be faulty because its casing is an ugly color, its fan noise drives me crazy, and the font type used on its front panel is painful," then this reasoning is unrelated to the controller's technical operation or malfunction, and the credibility of considering the controller as the root cause is very low.

[0020] In contrast, if the GMLM outputs "The reported fault requires both the pump and valve control to fail simultaneously. This could happen if neither of the attached devices is functioning. Both devices are attached to controller XYZ. Therefore, a failure in controller XYZ is most likely the root cause," then it is more likely that the controller is indeed the source of the problem. This is especially true if the reasoning is also supported by dynamic context information, which does indeed show that both devices are attached to controller XYZ.

[0021] Furthermore, the selection of the most likely root cause can be broken down into multiple smaller tasks that can be assigned to GMLM. For smaller tasks, GMLM will be much more likely to output the correct answer than for more complex tasks. This probability decreases disproportionately with the size of the task. Therefore, if a complex task is broken down into smaller tasks, the better accuracy achieved by performing each of these smaller tasks surpasses the effect of having multiple tasks instead of just one.

[0022] Therefore, in another particularly advantageous embodiment, multiple candidate root causes are provided to the GMLM and / or another GMLM to which the query is provided.

[0023] In another particularly advantageous embodiment, the determination of the sought root cause further includes, and / or precedes, the following: • Identify at least one piece of information whose knowledge indicates which of multiple candidate root causes is the most likely root cause; and • Obtain this information from automation systems or services and / or from plant operators.

[0024] In particular, if the contextual information is insufficient to answer a query and identify the root cause sought, obtaining more information and then acting upon that additional information is far more beneficial to the quality of the final result than attempting to achieve the best outcome based solely on existing information. As the Apollo 13 flight commander stated, “Let’s work with the person who has the problem. Don’t make things worse by guessing.” Obtaining additional information and identifying what might be needed next, especially in an iterative manner, is crucial. This is somewhat analogous to the diagnostic process in electronics, where the repair manual contains multiple test points for troubleshooting circuits using a multimeter.

[0025] In one example, the symptom experienced might be that a computer system becomes unresponsive. This could be caused by either a faulty fan leading to overheating, or a failure of the magnetic hard drive, as these are major components that still contain moving parts. To differentiate between these two possibilities, the operator might be asked to press their ear against the computer's casing and listen for a scraping sound that repeats rapidly several times in succession, then pauses for a few seconds before repeating several more times. This is the characteristic sound of the read head repeatedly trying to read a specific sector that is causing a read error. If this sound is heard, then the hard drive does indeed have a problem.

[0026] In a similar manner, in another particularly advantageous embodiment, the processing of the query may include: • Identify at least one piece of information whose knowledge indicates the type and / or location of the fault; and • Obtain this information.

[0027] Similarly, information can be obtained, for example, from automated systems or services and / or from plant operators. Furthermore, information can be obtained iteratively. Obtaining information can involve any action.

[0028] For example, potentially significant information can be identified based on a perceived lack of information in a particular area. For instance, if a pipe between two points is suspected to be faulty, and that pipe is located inside a wall, it might be necessary to pry open the wall.

[0029] For example, potentially significant information can be identified based on its availability. In a non-industrial example, if criminal investigators see a flat surface at a crime scene, that flat surface is considered a potential carrier of fingerprints, and fingerprints are scanned regularly.

[0030] In another particularly advantageous embodiment, obtaining at least one piece of information may include: • Determine the step-by-step sequence of actions to obtain this information; and • This causes the sequence of actions to be executed.

[0031] This step-by-step sequence can come from any suitable source. For example, such a sequence can be stored in a checklist triggered by certain conditions and keywords, somewhat similar to a checklist used on an airplane to solve in-flight problems. Any pre-existing knowledge can be used. If such pre-existing knowledge is unavailable, the action sequence can be obtained again from the GMLM. Obtaining this sequence step-by-step is a task that the GMLM can perform very efficiently, much like generating text piece by piece, for example.

[0032] In another particularly advantageous embodiment, the failure type includes one or more of the following: permanent failure, intermittent failure, and recurring failure. Distinguishing between these categories of failures allows for the elimination of many unlikely root causes, since most root causes only produce one type of failure among these. For example, a recurring failure depends on a condition that is met from time to time, so the root cause cannot remain constant. Similarly, if the failure is permanent, the root cause cannot be a condition that is met only intermittently. Therefore, it is worthwhile to invest some effort in determining the failure type.

[0033] In another particularly advantageous embodiment, static contextual information is provided to the GMLM, which at least indicates the structure and / or layout of the industrial plant, and / or indicates the physical, chemical, and / or biochemical information of the industrial processes performed on the industrial plant, starting from the products of these processes. This information conveys the characteristics of the industrial plant that are always present, not just those present at the time of failure. Additionally, considering this static contextual information allows for further narrowing down the range of possible root causes for a given failure and / or symptom. For example, if the static contextual information reveals that two devices that fail simultaneously are actually connected to different redundant power supplies, then simultaneous power supply failures of these two devices are unlikely to be the sought root cause.

[0034] In particular, combining the distinction between static and dynamic context information with the distinction between permanent, intermittent, and recurring failures can significantly narrow down the space of possible root causes. For example, if a failure is recurring or intermittent, conditions in the static context information (e.g., some kind of link between multiple entities) may contribute to the failure's occurrence, but are unlikely to be the root cause of that failure.

[0035] Even if the fault is permanent, it's unlikely that the root cause can be found under certain conditions that are part of a static context. The static condition persists, but the fault is unlikely to persist indefinitely. Instead, it will exist for a period of time before the fault occurs. Therefore, the static condition may again be necessary, but insufficient to cause the fault.

[0036] In a non-industrial example, a symptom that could be part of the query is water leaking from a wall in the living room. Static context information could indicate that the wall is connected to a ceiling, which in turn forms the floor above, and that central heating pipes are installed within that floor. This means that if this pipe is carrying water, it has the potential to travel by gravity to the point in the living room wall where the leak is first detected. If the dynamic context information then indicates that the central heating pipe was indeed carrying water at some point before the leak occurred, GMLM can infer that the central heating pipe is indeed the likely root cause of the leak in the living room.

[0037] In particular, static and / or dynamic contextual information can include material, informational, and / or energetic connections between a fault and / or its location (on the one hand) and at least one candidate root cause (on the other hand). This facilitates causal reasoning about which root causes are possible and which are not.

[0038] One example of a connection of materials is the supply of a medium emitted from a first entity in a plant to a second entity. For example, the medium could be a product generated by the first entity and supplied to the second entity as a segregant. In another example, the extraction of a medium from the same source by both entities can also be considered a connection of that medium between the two entities. For instance, if one entity suddenly experiences a surge in demand for the medium, and the common source cannot supply that surge quickly enough, this surge in demand from one entity could lead to a shortage of the medium at the other entity.

[0039] One example of a connection for energy is the transfer of heat between entities, whether intentional (e.g., due to a thermal medium flowing from one entity to another) or unintentional (e.g., due to waste heat radiating from one entity to another). Another example of a connection for energy is connecting two entities to a common energy source, such as electricity or natural gas. As with ordinary material sources, a sudden need for energy in one entity may prevent the supply of energy to another entity.

[0040] An example of information connectivity is multiple entities being connected to the same network. Such networks can enable entities to work together in a useful way, but they can also cause problems to spread from one entity to another.

[0041] In another example of information connectivity, a control loop controls process variables, such as pressure in a reactor. A variable manipulated by the control loop to change pressure can then be, for example, transmitted through a purge valve that is not directly connected to the reactor. The purge valve and the reactor have only an indirect material connection, but they have a direct information connection.

[0042] In another particularly advantageous embodiment, the dynamic context information also includes a large information store from which the GMLM extracts information relevant to the query. In this way, the amount of information extracted from this large store can be focused on information relevant not only to the industrial plant but also to the specific operational state related to a given fault and / or symptom. In determining possible root causes, a large amount of less relevant information from the large information store may crowd out a smaller amount of more relevant information.

[0043] In a particularly advantageous embodiment, at least one GMLM is the base model. Examples of base models include large language models (LLMs) or small language models (SLMs), which are configured and pre-trained to take text prompts as input and repeatedly predict parts of the text. In this way, further information, such as static and / or dynamic contextual information, can be used to enhance the output of a round of the GMLM and reused for the next round of the GMLM. However, for example, GMLMs can also generate other kinds of data, such as images. For example, a GMLM can predict images showing floor plans or other layouts of industrial plants, where possible root causes are marked in any suitable manner, or at least include regions of those possible root causes. For example, the base model can be a large multimodal model that transforms between data modalities, takes multiple data modalities as input, and / or produces multiple data modalities as output. What all base models have in common is that they are trained on extensive datasets and therefore can be applied to a wide range of use cases. Typically, base models include many trainable parameters (e.g., on the order of billions), and training requires a large number of training examples to avoid overfitting.

[0044] In another particularly advantageous embodiment, a validation plan comprising one or more actions is set up, based at least in part on static and / or dynamic contextual information, and on one or both of a query and at least one candidate root cause. Of course, validation can also be related to the ultimately identified root cause, rather than just the candidate root causes. Each ultimately identified root cause is preceded by a candidate root cause. That is, "at least one candidate root cause" also includes the ultimately identified root cause.

[0045] Each action in the validation plan generates a confidence measure that indicates a reasonable tendency for the candidate root cause to be identified. The validation plan is then executed, resulting in one or more confidence measures. A confidence score is assigned to the finally identified root cause, at least in part, based on these confidence measures. In this way, the tendency of GMLM to “produce illusions,” particularly if the information provided to it is insufficient in quality and / or quantity, can be reduced. Root causes identified due to “illusions” are bad because they delay the discovery of the true root cause and, therefore, the application of any genuine remedies to eliminate the fault and / or symptoms. Furthermore, ineffective remedial actions against erroneous root causes lead to unnecessary costs, such as replacing equipment without a sufficient cause, or prying open walls or digging into the ground to find perfectly healthy pipes. The results of validation can be used as feedback to the method. In particular, this feedback can be applied to the composition of queries.

[0046] Specifically, a verification plan can include at least a set of verification questions and expected answers. Performing a verification plan can then at least include providing verification questions to a GMLM used to determine the root cause sought and / or to different GMLMs. Confidence measures can then at least include a measurement of the degree to which the answers thus obtained to the verification questions are consistent with the expected answers. The reasoning behind this is that if the GMLM is delusional in the sense of giving factually incorrect answers, it is likely to encounter inconsistencies and contradictions when asked further questions on the topic. Even deliberately attempting to establish a consistent system of lies on a particular topic is extremely difficult. For this reason, many criminals have been caught and convicted using verification questions on the aforementioned subject.

[0047] In another particularly advantageous embodiment, verifying at least one action in the plan includes assessing the extent to which: • Given static and / or dynamic context information, GMLM should be able to determine the root cause, and / or • Given static and / or dynamic contextual information, the candidate root cause and / or the ultimately determined root cause are reasonable.

[0048] In this way, it's possible to test whether the GMLM can understand the provided context information and whether the context actually contains information leading to the identified root cause. If the context information doesn't point to a specific root cause, that specific root cause may not have been identified in the expected way. For a root cause to be plausible, its origin should be clear.

[0049] In another particularly advantageous embodiment, at least one remedial action is determined, at least in part, based on the finally identified root cause. This remedial action includes changing the physical state and / or behavior of at least one asset of the industrial plant or its assets. The remedial action is then performed on the industrial plant and / or at least one asset. As discussed earlier, the method presented herein allows for faster and more accurate identification of the root cause than manual analysis. Therefore, remediation will be performed more quickly, and the likelihood of achieving the objective and actually eliminating the fault and / or observed symptoms is increased. In particular, futile remedial actions that fail to resolve the observed problem are avoided.

[0050] Favorable examples of remedial actions include: • Replace and / or repair at least one asset that is the part for which the root cause has been definitively identified; and / or • Replace at least one asset's function and / or product as the most likely root cause; and / or • Move at least one of the industrial plant and / or its assets to a state where the presence of the most likely root cause can be better tolerated.

[0051] In particular, the latter two actions can allow industrial processes to continue despite the observation of faults and / or symptoms, providing rapid repairs until the repair or replacement operation can be performed as a permanent solution.

[0052] Because it is implemented by a computer, this method can be embodied in software. Therefore, the invention also relates to a computer program having machine-readable instructions that, when executed by one or more computers and / or computing instances, cause one or more computers and / or computing instances to perform the method described above. Examples of computing instances include virtual machines, containers, or serverless execution environments in the cloud. The invention also relates to a machine-readable data carrier and / or downloadable product having a computer program. A downloadable product is a digital product having a computer program that can be sold, for example, in an online store for immediate completion and download to one or more computers. The invention further relates to one or more computing instances having a computer program and / or having a machine-readable data carrier and / or downloadable product.

[0053] This disclosure addresses the problem of assisting human operators in monitoring and evaluating industrial processes to detect process failures based on automated root cause analysis. The technical solution proposed in this invention is a framework for a software-based, data-driven, assisted model. Operators interact with the assistant through a natural language-based human-machine interface. Operators can guide the assistant in evaluating any given situation and justifying their decisions. The model can also provide operators with suggestions, justifications, and potential hazards upon request.

[0054] This disclosure presents a framework for operator-assisted monitoring and evaluation of industrial processes to detect process failures based on automated root cause analysis. Operators are provided with a software-based assistant that implements a data-driven generative machine learning model (GMLM), such as a large language model (LLM) or other foundational model. This model is pre-trained on large-scale additional data and use cases and then tuned for specific use cases and processes of interest, or used out of the box. Operators and the model interact through a natural language-based human-machine interface, such as chat or predefined prompt styles. The model has access to optional tools, data, and information sources, which can be added or removed depending on the specific use case. Such tools may include process simulators for evaluating alternative scenarios, algorithms for performing data-driven causal estimation under anomalous conditions to better understand causal relationships between physical properties in the process, or other data preprocessing tools and additional models, such as classification models for identifying conditions or locating the most similar historical conditions. The model may utilize historical data, such as process and alarm data, real-time runtime data, process descriptions in manual form, and best practice manuals for handling and resolving conditions. Operators can guide the assistant to evaluate any given condition and justify their decisions. The model can also provide operators with advice, evidence, and potential hazards as required.

[0055] The proposed solution seeks to address a key problem in existing fault detection technologies: how can we integrate multiple data sources and data formats to enhance current fault detection classification algorithms? Clearly, we can build separate time-series (e.g., autoencoder-based) or alarm-based fault detection algorithms, but how can we create a method based on multiple data sources that do not have a uniform format and are constantly changing?

[0056] A new fault detection pipeline is proposed to address this problem. The main objective of the new pipeline is to find the causal relationship between the observed fault state (described by the operator or alarm system) and the original source of disturbance that caused the observed state, and to provide a root cause analysis of the disturbance in the processing plant. Attached Figure Description

[0057] The invention is described below with reference to the accompanying drawings, but is not intended to limit the scope of the invention. The drawings show:

[0058] Figure 1: An exemplary embodiment of the method 100 for determining the root cause 6 of fault 2;

[0059] Figure 2 An exemplary implementation of a method 100 for validating and using external data sources. Detailed Implementation

[0060] Figure 1 is a schematic flowchart of an exemplary embodiment of a method 100 for determining the root cause 6 of a fault 2 in an industrial plant 1.

[0061] In step 110, an inquiry 3 is provided regarding the root cause of a suspected failure 2 in the industrial plant or its assets and / or the root cause of the symptom 2a exhibited by the suspected failure 2. That is, the method begins with the suspected failure 2 and / or symptom 2a, which can be reported by any suitable source.

[0062] In step 120, query 3 is processed. This processing includes: determining at least the type 2b of the suspected fault 2 and the suspected location 2c of the fault 2 in the industrial plant 1 based on query 3.

[0063] According to box 121, at least one piece of information 8 can be identified that indicates the type 2b and / or location 2c of fault 2. According to box 122, this information 8 can then be obtained from any suitable source.

[0064] According to box 122a, the step-by-step sequence of actions for obtaining this information 8 can be determined. According to box 122b, this sequence of actions can be executed.

[0065] In step 130, at least •Query 3, • The identified type 2b and suspected location 2c of fault 2, and • Dynamic context information 5 regarding industrial plant 1, which includes at least state variables and / or measurements captured in industrial plant 1 and / or its control system, is provided to a generative machine learning model GMLM4. This generates indications of at least one candidate root cause 6. The output is 4a.

[0066] According to box 131, static context information 9 can also be provided to GMLM 4, which at least indicates the structure and / or layout of industrial plant 1, and / or indicates the physical, chemical and / or biochemical information of the segregated products from which the industrial process performed on industrial plant 1 begins.

[0067] According to box 132, static context information 9 and / or dynamic context information 5 may include at least one candidate root cause 6 for fault 2 and / or its location 2b (in one respect). (On the other hand) the connection of materials, information and / or energy between them.

[0068] According to box 133, dynamic context information 5 may also include a large information repository from which GMLM 4 extracts information related to query 3.

[0069] In the example shown in Figure 1, in step 140, at least one piece of information 7 can be identified, whose knowledge indicates multiple candidate root causes 6. Which candidate root cause is the most likely root cause? In step 150, this information 7 can then be obtained from the automation system or service, and / or from the operator of plant 1.

[0070] According to box 151, the step-by-step sequence of actions for obtaining this information 7 can be determined. According to box 152, this sequence of actions can be executed.

[0071] In step 160, the root cause 6 sought is determined based on the output 4a of GMLM 4.

[0072] According to box 161, multiple candidate root causes (6) indicated by one or more outputs (4a) of GMLM (4) can be identified. The most probable root cause in () is identified as the sought root cause 6. According to box 162, it can then be determined why this root cause 6 is considered the most probable cause 6a.

[0073] Specifically, according to box 161a, there are multiple candidate root causes 6 It can be provided to GMLM 4 and / or another GMLM 4 provided to query 3.

[0074] Based on box 163, at least one piece of information 7 can be identified, whose knowledge indicates multiple candidate root causes 6. Which candidate root cause is the most likely root cause? According to box 164, this information can then be obtained from the automation system or service and / or from the operator of plant 1.

[0075] In the example shown in Figure 1, in step 170, at least in part based on static and / or dynamic context information 5, query 3, and at least one candidate root cause 6 Set up validation plan 10 by selecting one or two of the following. Validation plan 10 includes one or more actions. Executing each action generates a confidence metric 11, which indicates the candidate root cause 6. Or the tendency toward the ultimately determined root cause 6 is reasonable.

[0076] According to box 171, validation plan 10 may include at least one set of validation questions and expected answers.

[0077] According to box 172, verifying at least one action in plan 10 may include evaluating to what extent: • Given static context information 9 and / or dynamic context information 5, GMLM 4 should be able to determine the root cause 6, and / or • Given static context information 9 and / or dynamic context information 5, candidate root cause 6 And / or the final identified root cause 6 is reasonable.

[0078] In step 180, the validation plan 10 is executed. This yields one or more confidence metrics 11.

[0079] According to box 181, performing the validation plan 10 may at least include providing validation questions to the GMLM 4 and / or different GMLMs used. According to box 182, the confidence measure 11 may then at least include a measure of the degree to which the answers thus obtained for the validation questions are consistent with the expected answers.

[0080] In step 190, a confidence score 12 is assigned to candidate root cause 6, at least in part based on confidence metric 11. And / or the final identified root cause 6.

[0081] In the example shown in Figure 1, in step 200, at least one remedial action 13 is determined, at least in part based on the finally determined root cause 6, which includes changing the physical state and / or behavior of industrial plant 1 or at least one of its assets.

[0082] According to box 201, remedial action 13 may include one or more of the following: • Replace and / or repair at least one asset that is part of the final identified root cause 6; and / or • Replace the function and / or product of at least one asset that is part of the root cause identified as 6; and / or • Move industrial plant 1 and / or at least one of its assets to a state where the existence of the ultimately identified root cause 6 can be better tolerated.

[0083] In step 210, at least one remedial action 13 is performed on industrial plant 1 and / or at least one asset.

[0084] Figure 2 Another exemplary implementation of a method 100 for validating and using external data sources is shown.

[0085] The new framework involves the use of a trained or fine-tuned GMLM 4 and integration with external data sources and systems. This framework is triggered by either a text-based operator problem description (e.g., a safety-related operator problem) or by an automated alarm system trigger (e.g., a system warning) displayed as (I1.1). For example, this could include fault 2 and / or noticeable symptoms 2a of fault 2. In the first step (I1.1), GMLM 4 extracts the intent of the input and preprocesses the initial request. This information is provided in the final prompt to guide the expected outcome. This corresponds to step 120 of method 100. The preprocessed problem description (I2) includes the type 2b and / or location 2c of fault 2.

[0086] To create a framework that can understand the root causes of process failures, it is necessary to interpret and combine multiple domain-specific data sources. In this ID, we introduce the concepts of static contextual data (I1.3) and dynamic external data (I1.5). The data sources and formats of static and dynamic data are similar, but they will be used differently in this process. Static data is defined as data that does not change during the process (e.g., plant structure, chemical and biochemical information). On the other hand, dynamic external data is primarily operational data that changes over time (e.g., time series data) or large volumes of data (e.g., fact sheets, research papers, or textbooks). By integrating these external static and dynamic information sources into the framework, GMLM 4 will be able to more accurately understand process failures and provide operators with recommendations for optimizing the current state of the plant.

[0087] After defining the static context data and dynamic external data in the background, the GMLM can be initialized and provided with static information sources. Static context setup (O1.2) involves three main steps: (i) advance cues within format and style involve providing an initial framework to guide argumentation techniques (e.g., ReAct) and causal information (e.g., text-based causal information, causal graphs), and (ii) the optimal presentation of results. This is particularly powerful when tailored to the audience's knowledge level, such as simplifying information for new employees (e.g., explaining to a 5-year-old). This customization enhances understanding and engagement, makes problem-solving more efficient, and is domain-specific. (iii) Advance cues utilizing contextual information (I1.3) are crucial for GMLM 4 because they establish a knowledge base that helps the model accurately understand and respond. This context ensures coherent, fact-based, and context-relevant responses.

[0088] Context information (I1.3) may include static context information 9. Dynamic external data (I1.5) may include dynamic context information 5.

[0089] In Section O1.3, several information retrieval tools based on dynamic information retrieval are added to GMLM. This approach enables the model to query the correct information to solve the problem stated at the outset. Retrieval methods are categorized based on the underlying data source and type, such as distributed control systems with operator or recipe actions, setpoint changes and operating modes, alarm management databases, time-series databases, or text and document databases. These retrieval methods, with additional filtering methods, are used to preprocess the data to make it easily understandable to GMLM. This approach not only aids in semantic understanding but also allows for the integration of automated processes to retrieve the correct data. Data processing and indexing play a crucial role in the step of retrieving the correct data, retrieving the correct data in the correct preprocessed form, which GMLM would otherwise be unable to understand. This involves adding indexing methods (e.g., based on vector databases, graph databases, or document databases), appropriate matching algorithms (e.g., time-series-based univariate and multivariate matching algorithms or text-based embedding algorithms), and filtering algorithms (e.g., window-based) to minimize false alarms retrieved. These preprocessing pipelines can also be performed by GMLM in the future.

[0090] Dynamic information retrieval O1.3 may correspond to or include step 130 of method 100. The output 4a of GMLM 4 can then indicate at least one candidate root cause 6. .

[0091] In addition to preprocessed databases and data sources, we envision including external tools that can create on-demand information that is too data- or computationally intensive to be seamlessly integrated into static or dynamic data sources (O1.4). These tools can be executed upon request. The first group of external tools consists of math-based tools that can add mathematical understanding to the data (e.g., calculators, statistical, causal, linear correlation tools). The second group includes clustering-based tools to compare the current period with previous periods and create similarity scores that can help to understand the current period in more detail by providing a more detailed understanding of the most similar previous periods or batches (e.g., k-means clustering). The third group consists of simulation-based tools. These digital twins can then be used to try different initial conditions and the results that might lead to some kind of alarm (added to root cause analysis). Another option for using simulation-based tools is to try certain actions in the process to resolve the current suboptimal state.

[0092] The integration of static and dynamic data sources (O1.4) corresponds to steps 140 and 150 of method 100 and generates additional information 7, whose knowledge indicates multiple candidate root causes 6. Which candidate root cause is the most likely root cause?

[0093] In the penultimate stage of the framework construction, the key step is answer extraction (O1.5). This crucial process involves a natural language inference engine (e.g., based on operator actions, cause-effect graphs, warnings, and problem descriptions) and fault detection with root cause detection (based on the inference framework, e.g., inference chains). This step is critical because the answer performs root cause analysis. This stage corresponds to step 160 of method 100 and generates the sought root cause 6.

[0094] The final part is the verification engine (O1.6), which serves as a crucial final component. It thoroughly evaluates the framework's performance and output, ensuring it meets established quality standards and operates accurately. If the verification engine detects a problem (e.g., based on classification metrics, output resolution, clarity) or if an operator interacts with the system (e.g., providing additional information, refactoring the problem, or requesting more information), the framework can revert to the problem handling phase (O1.1) to modify the problem settings and repeat fault detection using different settings for dynamic information retrieval or external tools. This corresponds to steps 170 to 190 of method 100 and assigns a confidence score 12 to the finally identified root cause 6.

[0095] Human operators can access GMLM 4 via a human-machine interface or predefined prompt patterns, thus creating a mechanism to check if other companies are already using similar solutions. Plant assessments and recommendations can be directed to human operators monitoring designated process segments or the entire industrial plant from a (centralized) control room, as overlays displayed directly on the control screens of the process control system. Typically, these screens implement process flow diagrams of the underlying industrial processes and display relevant process variable values ​​and time trends, such as tank levels or reactor temperatures. Operators will be able to access GMLM 4 in chat-based windows, which can be attached to the system control screen or any component seen on a separate screen. Plant components can be color-coded to indicate that GMLM 4 has detected a suboptimal state. This can trigger a new chat-based interface with the operator. During in-depth analysis, additional information, including the type of assessment, can be provided on the operator screen in a dedicated chat.

[0096] Similar visualizations can also be used in discrete manufacturing, where responsible engineers, service personnel, and others can use existing human-machine interfaces (HMIs) between production robots and human operators to understand suboptimal states and alerts. These HMIs include portable information devices, such as tablets with dedicated software and visualizations, field computer screens, or centralized control rooms, providing an overview of all production robots. Here, assessments and recommendations can be combined to indicate to individual or multiple robots which sensor signals exhibit these suboptimal states, and whether different robots are affected by the same or similar suboptimal states. List of reference symbols: 1 Industrial factory 2. Fault Symptoms of Fault 2a 2b Type of Fault 2 2c Location of fault 2 3. Query 4. Generative Machine Learning Models, GMLM 4a GMLM 4 output 5. Dynamic Context Information 6. Root cause of fault 2 6a Root cause 6 Why is the most likely reason? 6 root cause of the candidate 7. Significant information regarding which root cause is most likely 8. Significant information regarding the type 2b and location 2c of fault 2. 9. Static Context Information 10. Verification Plan 11. Validate the confidence metrics generated in the planning process. 12. Regarding (candidate) root causes 6, 6 Confidence score 13 Remedial Actions 100 Methods for determining the root cause of failure 2 110 provides query 3 120 processed 3 queries 121 Identification Information 8 122 Information obtained 8 122a Determine the step-by-step sequence of actions 122b Execute a step-by-step sequence of actions 130 provides data to GMLM 4 131 also uses static context information 9 132 Connection information as context information 133. Use large information storage databases 140 Identification Information 7 150 Information obtained 7 151. Determine the step-by-step sequence of actions. 152 Execute a step-by-step sequence of actions 160. Based on output 4a, determine the root cause 6. 161. The fundamental reason for selecting several candidates (6) One of the candidate root causes 161a Using GMLM 4 for selecting the most likely root cause 162. Determine the cause 6a 163 Identification Information 7 164 Information obtained 7 170 Set up verification plan 10 171 Using Validation Planning with Validation Problems 10 172 Consider verifying the contextual information 5 and 9 in Plan 10. 180 Execution Verification Plan 181. Query verification question 182. Check and verify the answers to the questions. 190 Assign a confidence score of 12 to (candidate) root cause 6, 6 200 Determine remedial actions 13 201 Specific Remedial Actions 13 210 Implement remedial action 13 I1.1 Operator or System Problem Description I1.2 Problem Description of Preprocessing I1.3 Reasoning Frame and Static Context The GMLM described in I1.4 I1.5 External Data I1.6 Summary of Dynamic Real-Time and Historical Data I1.7 The stated GMLM with tool access rights I1.8 Root Cause Fault Detection I1.9 Empirical Fault Detection with Root Causes O1.1 Problem Handling O1.2 Static Context Settings O1.3 Dynamic Information Retrieval O1.4 External Tool Settings O1.5 Answer Extraction O1.6 Validation Loop

Claims

1. A computer-implemented method (100) for determining the root cause (6) of a failure (2) in an industrial plant (1), comprising the following steps: • Provide (110) the root cause of the suspected failure (2) of the industrial plant or one of its assets, and / or the root cause of the symptoms (2a) exhibited by the suspected failure (2); • Processing (120) the query (3), the processing including determining at least the type (2b) of the suspected fault (2) and the suspected location (2c) of the fault (2) in the industrial plant (1) based on the query (3); • Provide at least (130) to the generative machine learning model GMLM(4): o The query (3) mentioned above. o The determination of the type (2b) and the suspected location (2c) of the fault (2), and o Dynamic context information (5) regarding the industrial plant (1), the dynamic context (5) including at least state variables and / or measurements captured in the industrial plant (1) and / or its control system, This provides an indication of at least one candidate root cause (6) The output of ) (4a); and • The root cause (6) sought is determined (160) based on the output (4a) of the GMLM (4).

2. The method (100) of claim 1, wherein the determination (160) of the sought root cause (6) comprises: • Multiple candidate root causes (6) indicated by one or more outputs (4a) of the GMLM (4). ) Identify (161) the most probable root cause as the root cause sought (6); and • Determine (162) why the stated root cause (6) is considered the most likely cause (6a).

3. The method (100) according to claim 2, wherein the plurality of candidate root causes (6) (161a) is provided to the query (3) and provided to the GMLM (4) and / or another GMLM (4).

4. The method (100) according to any one of claims 2 to 3, wherein the determination (160) of the sought root cause (6) further comprises and / or precedes the following: • Identifiers (140, 163) contain at least one piece of information (7), whose knowledge indicates the multiple candidate root causes (6). Which candidate root cause is the most likely root cause? • Obtain this information (7) from the automation system or service and / or from the operator of the plant (150, 164).

5. The method (100) according to any one of claims 1 to 4, wherein the processing (120) of the query (3) comprises: • Identify (121) at least one piece of information (8) whose knowledge indicates the type (2b) and / or location (2c) of the fault (2); and • Obtain (122) this message (8).

6. The method (100) according to claim 4 or 5, wherein obtaining (150, 164, 122) the at least one piece of information (7, 8) comprises: • Determine (151, 164a, 122a) the step-by-step sequence of actions to obtain this information (7, 8); as well as • This causes the action sequence described in (152, 164b, 122b) to be executed.

7. The method (100) according to any one of claims 5 to 6, wherein the at least one piece of information (8) is obtained from an automation system or service and / or from the operator of the plant (1).

8. The method (100) according to any one of claims 1 to 7, wherein the type (2b) of the failure includes one or more of the following: permanent failure, intermittent failure, and recurring failure.

9. The method (100) according to any one of claims 1 to 8, wherein static context information (9) is provided (131) to the GMLM (4), the static context information (9) indicating at least the structure and / or layout of the industrial plant (1), and / or indicating physical, chemical and / or biochemical information of the precipitates from which the industrial processes performed on the industrial plant (1) originate.

10. The method (100) according to claim 9 and any one of optional claims 1 to 8, wherein the static context information (9) and / or the dynamic context information (5) comprises (132) for the fault (2) and / or its location (2b) on one side and at least one candidate root cause (6) on the other side. The connection of materials, information and / or energy between ( ).

11. The method (100) according to any one of claims 1 to 10, wherein the dynamic context information (5) further includes (133) a large information store, from which the GMLM (4) extracts information related to the query (3).

12. The method (100) according to any one of claims 1 to 11, wherein at least one GMLM (4) is a base model.

13. The method (100) according to any one of claims 1 to 12, further comprising: • Based at least in part on the static and / or dynamic context information (5), the query (3), and at least one candidate root cause (6) One or two of the following, establish (170) a verification plan (10) comprising one or more actions, wherein performing each action produces a confidence metric (11), the confidence metric (11) indicating the candidate root cause (6) The tendency to do so is reasonable; • Perform the verification plan (10) described in (180) to obtain one or more confidence metrics (11); as well as • At least in part based on these confidence measures (11), a confidence score (12) is assigned to the candidate root cause (6) as stated in (190). (6) and / or the root cause that was finally determined.

14. The method (100) according to claim 13, wherein • The verification plan (10) includes at least (171) a set of verification questions and expected answers; • Executing the verification plan (10) includes at least (181) providing verification questions to the GMLM (4) used and / or to different GMLMs (4); and • The confidence measure (11) includes at least (182) a measure of the degree to which the answer thus obtained for the verification question is consistent with the expected answer.

15. The method (100) according to any one of claims 13 to 14, wherein at least one action in the verification plan (10) includes (172) assessing the extent to which: • Given the static context information (9) and / or the dynamic context information (5), the GMLM (4) should be able to determine the root cause (6), and / or • Given the static context information (9) and / or the dynamic context information (5), the candidate root cause (6) (6) and / or the finally determined root cause is reasonable.

16. The method (100) according to any one of claims 1 to 15, further comprising: • Based at least in part on the finally determined root cause (6), determine (200) at least one remedial action (13) including altering the physical state and / or behavior of at least one of the industrial plant (1) or its assets; and • Perform (210) the at least one remedial action (13) on the industrial plant (1) and / or the at least one asset.

17. The method (100) of claim 16, wherein the remedy (13) comprises (201) one or more of the following: • Replace and / or repair at least one asset that is part of the finally identified root cause (6); and / or • Replace the function and / or product of at least one asset that is part of the finally determined root cause (6); and / or • Move the industrial plant (1) and / or at least one of its assets to a state in which the existence of the finally determined root cause (6) can be better tolerated.

18. A computer program comprising machine-readable instructions that, when executed by one or more computers and / or computing instances, cause the one or more computers and / or computing instances to perform the method (100) according to any one of claims 1 to 17.

19. A non-transitory machine-readable data carrier and / or download product having the computer program according to claim 18.

20. One or more computers and / or computing instances having a computer program as described in claim 18 and / or a machine-readable data carrier and / or downloadable product as described in claim 19.

Images