Method and system for error cause analysis in process technology installations

Abstract

In order to perform error cause analysis in the process technology facility (1), engineering information (18) of the facility (1) containing information about the facility components and their interconnections in the facility (1) is provided in digital form to create an inference model (30) in the form of a probabilistic physical model of the facility (1) with probability distributions and prior variables. In the diagnostic mode (40) of the inference model (30), Bayesian inference of error probabilities is performed using measurement data from the facility (1).

Description

Technical Field

[0001] This invention relates to a method for performing error cause analysis in process technology facilities.

[0002] The present invention also relates to a system for performing error cause analysis in process technology facilities. Background Technology

[0003] Automation technology is used to automate technical processes. An automated system consists of facilities operating the processes, the automation system itself, and the operators. Facilities can be, in particular, process or technological facilities from the chemical, beverage and food, environmental, pharmaceutical, or natural gas and oil industries.

[0004] This type of (industrial) facility typically comprises multiple interconnected facility components. Typical facility components of a process or process technology facility are containers, reactors, pipes, fittings, etc., through which initial materials (especially fluids) flow during the manufacturing process and are thus altered or processed into the final product.

[0005] At the near-process field level of an automation system, within the scope of facility automation, local distributed, decentralized field devices perform preset functions and exchange process, facility, and / or equipment-related information with higher-level automation components of the system. Field devices include sensors (e.g., transmitters for level, flow, pressure, and temperature; analyzers for gas or liquid analysis; weighing systems) and actuators (position actuators for valves, position controllers, other decentralized controllers, and frequency converters for electric drives of pumps), which transmit process data in the form of controlled data to influence the process.

[0006] It is usually necessary to optimize the economic efficiency of such facilities and reduce the deviations of the values ​​of various process parameters from the target values ​​and, consequently, from the facility's operating time, in order to make the facility operate smoothly, better comply with quality requirements, or bring the process closer to its limits and increase output.

[0007] However, some critical deviations cannot be eliminated simply by adjusting the system; additional countermeasures are required. Failure to detect these faults in a timely manner can lead to poor product quality, or even malfunctions of facility components, parts of the facility, or the entire facility.

[0008] Automated fault diagnosis enables faster identification of errors and timely intervention, thereby reducing or even preventing downtime. Fault detection and isolation (FDI) involves both fault identification and isolation of individual fault types to narrow down the possible causes of the fault.

[0009] Fault diagnosis methods are generally divided into two categories. On the one hand, there are process model-based methods, which use measured signals and calculate characteristic values ​​in a mathematical model. On the other hand, there are signal-based data-driven methods, which create black-box models of facilities or analyze correlations based on historical data [1, pp. 5-6].

[0010] Model-based methods in state estimators, such as in the extended Kalman filter or the Unknown Input Observer (UIO) (which estimates the most likely operating or error state in the state space), fall into parity equations, which utilize the analytical redundancy of additional sensors to generate characteristic residual signatures, or into parameter estimation methods, which determine the parameter values ​​of the deviations and assign each deviation to the error source [2, p. 9].

[0011] Signal-based methods follow different approaches. For simple signals, limit tests or vibration signal models are sufficient, which individually examine deviations in the signal's value or frequency. In contrast, statistical classification methods or artificial intelligence are used for more complex systems. Static methods utilize techniques such as principal component analysis (PCA) to reduce the system's order by identifying a minimum number of independent components and then performing cluster analysis. On the other hand, machine learning algorithms optimize multiple parameters of neural networks or decision trees based on recorded training data [3, pp. 41-43].

[0012] The methods mentioned are only an overview of the subject area, as many different measures have been adopted in the literature in this field, especially in recent years. To date, no method has been shown to be superior to the others, which is why research continues in multiple directions with an increasing trend [4, pp. 4-5].

[0013] Model-based approaches require extensive systems understanding, which is often lacking in the process of methodological techniques. The processes under consideration are often nonlinear, dynamic, hybrid, and complex, which means that not only the modeling costs but also the computational costs are greatly increased, especially in large industrial facilities [1.]. Therefore, solutions from other fields cannot be simply transferred. Similarly, strong noise in measurements can distort the results.

[0014] Since process knowledge often exists in the form of measurement data, data-driven approaches are more frequently used in process industries. Principal Component Analysis (PCA) and Latent Structure Projection (PLS) are particularly prevalent as learning methods in the context of statistical methods [5, p. 267] and artificial neural networks (ANN) and support vector machines (SVM) [6, pp. 4-5]. The advantage here is that the implementation costs are very low, and it can be used as a complete solution from measurement values ​​to error types.

[0015] However, data on error conditions is often scarce or nonexistent, and facility operators are reluctant to expose their facilities to critical situations in order to obtain such data. In such cases, purely signal-based models will fail because even if they can identify unknown errors and distinguish them from other errors, they cannot assign the errors to specific components or failures. Summary of the Invention

[0016] Therefore, the object of the present invention is to combine model-based and signal-based methods in a hybrid approach in order to maximize their advantages and reduce their disadvantages.

[0017] Therefore, the subject of this invention is a method for analyzing the causes of errors in a process technology facility, wherein engineering information of the facility, including information about the facility components and their interconnections in the facility, is provided in digital form, and an inference model in the form of a probabilistic physical model of the facility with probability distributions and prior variables is created from the engineering information, and Bayesian inference of the error probability is performed in a diagnostic mode of the inference model using measurement data from the facility.

[0018] The present invention also relates to a system for performing error cause analysis in a process technology facility, the process technology facility having a conversion module designed to create an inference model in the form of a probabilistic physical model of the facility with probability distributions and prior variables from engineering information of the facility containing information about the facility components and their interconnections in the facility. The inference model is designed to perform Bayesian inference of error probabilities in a diagnostic mode of the inference model using measurement data from the facility.

[0019] Here, engineering information refers to planning data for process technology facilities, as well as facility structure and component data, stored in facility planning software (such as COMOS) or obtainable from data tables. Engineering information can particularly be machine-readable R&I flowcharts (piping and instrumentation diagrams), which contain all relevant components of the facility and its automation as graphical objects.

[0020] In the training mode of the inference model, the estimation of model parameters is optimized by performing Bayesian inference of the inference model in the training mode of the inference model using measurement data from the facility, where the model parameters represent the priors in the inference model.

[0021] Bond graphs enable the creation of inference models from engineering information in a favorable manner. Bond graphs are suitable for analyzing electromechanical systems because they provide a unified representation across multiple technical fields. Since process technology facilities consist not only of hydraulic piping systems and mechanical actuators, but also of circuitry and information technology data flows, this representation is highly advantageous for identifying various error types. Furthermore, bond graph theory provides a formalism for the analysis of R&I flowcharts that can be used in automated systems.

[0022] First, by using templates from a model library, a meta-model of the facility can be generated from the facility's engineering information, particularly R&I flowcharts. The model library contains the code to be generated and inference variables for each component type of the facility, which require Bayesian inference. Then, for example, an inference model of the facility can be created from the meta-model using a recursive function. Attached Figure Description

[0023] The present invention will now be explained using embodiments and with reference to the accompanying drawings, which show in detail:

[0024] Figure 1 An example of a technical facility in which actuators and sensors work together is shown.

[0025] Figure 2 An exemplary flowchart of the method according to the present invention is shown.

[0026] Figure 3 The class diagram of the conversion module is shown.

[0027] Figure 4 A simplified schematic of the bond graph is shown in a block diagram.

[0028] Figure 5 The facility structure of the meta-model is shown.

[0029] Figure 6 A simplified example of a factor graph is shown.

[0030] Figure 7 The class diagram of the inference module is shown.

[0031] Figure 8 The variable types of the base class of the inference module are shown.

[0032] Figure 9 An example of model programming is shown.

[0033] Figure 10A factor graph of the facilities during inference model training is shown, and

[0034] Figure 11 A factor graph is shown in the error cause diagnosis.

[0035] The same reference numerals have the same meaning in different figures. The figures are purely schematic and do not represent any size or scale. Detailed Implementation

[0036] Figure 1 A simplified schematic diagram illustrates an example of process technology facility 1, in which process 2 is controlled by means of automation system 3. Automation system 3 includes a planning and engineering system 4, an operation and monitoring system 5, multiple automation devices 6, 7, 8, and 9, and multiple field devices 10, 11, 12, 13, and 14. Planning and engineering system 4, operation and monitoring system 5, and automation devices 6, 7, 8, and 9 are interconnected via bus facility 15. Field devices 10, 11, 12, 13, and 14 are connected to automation devices 6, 7, 8, and 9 in various ways, such as directly via fieldbus or distributed peripheral devices, and perform preset measurement, control, and regulation functions in process 1. Field devices act as sensors to identify measured values ​​of process variables and as actuators to influence the process through regulatory intervention. Typical sensors are transmitters for level, flow, pressure, and temperature; analyzers for gas or liquid analysis; and weighing systems. Typical actuators are position actuators for valves, position controllers, other distributed controllers, and frequency converters for electric drives such as pumps, heaters, and coolers. Automation devices 6, 7, 8, and 9 read and write access to field devices 10, 11, 12, 13, and 14, and control process 2 according to the control program, which consists of multiple interactive automation function modules 16 distributed on the automation devices.

[0037] The planning and engineering system 4 includes planning and engineering software tools 17, such as Siemens AG's COMOS, which are used to create machine-readable R&I flowcharts (piping and instrumentation diagrams) 18, in which all relevant components of facility 1 and the automation unit can be identified as graphical objects. The characteristics of the objects are stored in a database 19 as attributes; similarly, the connections between objects are stored as material flows (e.g., piping) and signal flows (e.g., measurements). Furthermore, historical or simulated measurement data from the production operations of facility 1 under normal and known fault conditions are provided in a repository 20 (e.g., the cloud).

[0038] To analyze the causes of errors in process facility 1, software tool 21 automatically creates a diagnosable probabilistic model (inference model) of facility 1 from existing engineering information (i.e., facility planning data and facility structure and component data), which is stored in facility planning software or can be obtained from data tables. This inference model is able to determine the probability of occurrence of individual error causes based on facility data and identify faulty parts or components of the facility by performing Bayesian inference. Software tool 21 is part of planning and engineering system 4, but can also run in a standalone system.

[0039] exist Figure 2 The flowchart exemplarily illustrates the basic sequence of a method for analyzing the causes of errors according to the present invention. The method comprises a transformation phase in which the aforementioned inference model 30 is created, and an inference phase in which Bayesian inference is performed, in order to train the inference model on the one hand and determine the probability of occurrence of individual erroneous elements in facility 1 on the other hand, and to identify faulty facility parts and components.

[0040] During the transformation phase, transformation module 31 performs model transformation 32 on the R&I flowchart 18 of facility 1 within the inference model 30, which contains source text 33 and variable values ​​34 necessary for inference. Here, transformation module 31 reads the R&I flowchart 18 stored in the COMS database 19 and first generates a metamodel 35 of facility 1 by taking over template 36 from model library 37. Template 36 describes the behavior of various components of facility 1 (e.g., pumps, valves, tanks, pipes, etc.) and includes possible causes of error (e.g., leaks, blockages, reduced pump performance, etc.). Model library 37 contains the code to be generated for each component type and the necessary inference variables—variables needed for implementing Bayesian inference—enabling the generation of the inference model 30 of facility 1 from the metamodel 35. The inference code can be generated essentially directly and without the intermediate step of creating a metamodel.

[0041] Inference is implemented in a separate inference module 38, and it has access to, for example, the functionality of the Infer.NET framework. Infer.NET is an open-source framework written in C# that features an inference engine (“InferenceEngine”) containing several algorithms for performing inference. The fundamental principle of inference is based on Bayes' theorem:

[0042] P(A|B)=[P(B|A)·P(A)] / P(B)

[0043] A and B are events assigned to random variables in the factor graph above. Here, B is an observable effect, and A is a hidden cause whose exact probability is unknown. Therefore, P(A) is merely a prior estimate of the probability sought, which is why P(A) is called the prior probability. P(B) is the probability of observing B, which can be determined through repeated experiments. P(B|A) is the conditional probability of observing B given that A has occurred. Therefore, P(B|A) is the factor in the factor graph that determines the relationship between A and B. The result P(A|B) is the conditional probability of A occurring given that B has been observed. P(A|B) is considered a refined estimate of P(A) after one observation, which is why it is called the posterior probability of A or the posterior probability. With more observations, the posterior probability approaches the actual probability of cause A occurring. In misdiagnosis, the most likely cause of the error can be inferred by using the highest probability of occurrence.

[0044] The inference module 38 has two operating modes: training 39 and diagnosis 40, implemented in two related classes: training 41 and diagnosis 42. For both operating modes, historical measurements 43, inference source text 32, and inference variables 33 must first be imported and passed to the corresponding classes in an appropriate form. The training class 41 uses the measurements 43 to optimize the estimation of model parameters (inference parameters) for the inference model 31, which represents the prior (prior distribution). These are again stored in the inference model 30, which is why the inference variables 34 and the inference source text 33 are stored separately. In diagnosis 40, error probabilities and parameter inferences are performed instead. The results 44 are either output or stored for further processing.

[0045] Only the error causes of the individual components defined in template 36 can be automatically diagnosed. Alternatively, other more complex error causes that affect more than one component can also be added to the inference model 30; however, this requires analyzing the overall model of facility 1.

[0046] The automatic model conversion performed by conversion module 31 is explained in more detail below.

[0047] Model conversion 32 only requires one conversion of facility structure 18, therefore it can be executed offline separately from error cause analysis 39 and 40. Figure 3 The class diagram of the transformation module 31 is shown schematically. The transformation consists of the class "TransformationModule" for encapsulation and the meta-model classes "Plant", "Asset" and "Port" for facility 1, facility components and their interfaces. Component classes for various components such as pipes, process instruments, and pumps are collected in a separate "AssetLibrary" (model library 37).

[0048] The structure of the metamodel 35, established by the transformation module 31, should mimic the structure of the R&I flowchart 18 as closely as possible, thus simplifying the transformation to the inference model 30. Although the elements retrieved from the COMS database 19 via the XML export only have attributes, the classes of the metamodel 35 also contain methods for code generation and model transformation. The attributes of the metamodel 35 are also particularly suitable for use as inference variables.

[0049] Although the links between components in R&I flowchart 18 are primarily for graphical representation rather than information exchange, metamodel 35 requires links to generate inference model 30 in order to exchange inference variables. Here, according to bond graph theory, links are considered bidirectional bonds, through which any number of variables can be exchanged. Bond graphs are directed graphs that can be used to simulate energy flow. Figure 4 As shown in the schematic simplified bond diagram (left) and block diagram (right), the nodes of the diagram represent components A and B of the facility, and the edges define the energy flow by illustrating the potential variable e (cause or effect) and the flow variable f (effect or flow), which are multiplicatively bound together. The half-arrows indicate the direction of the energy flow e·f.

[0050] Metamodel 35 checks energy direction and bond type, ensuring that only ports and outputs of the same type can be connected to inputs, thus avoiding misdiagnosis. Using different methods of the metamodel class, transformed assets (parts) can be added to or removed from a facility; ports can be connected or disconnected from each other. For example, this results in… Figure 5 The facility structure of the meta-model 35 of facility 1 shown.

[0051] "Plant", "Asset", and "Port" each have a set of facility attributes that can be simultaneously converted into inference variables. Facility attributes include physical and / or geometric data of facility 1, individual components, and processed materials; measurement variables; error conditions; and variables required only for inference. For code generation, the component class receives a recursive method that runs the assets contained in model library 37 and creates corresponding code for each asset using template 36. After implementing this method, a source text file 33 exists, which is included in the inference module 38 and contains a facility-specific inference model 30. After code generation, the list of all collected facility attributes (inference variables) is sorted and exported to a separate file 34.

[0052] The variables are mathematical random variables of data types such as boolean (bool), integer (int), and double (double), depending on whether they are switching variables with two values, discrete (integer) variables, or continuous (floating-point) random variables. For each range or value that a variable can take, there is an associated probability distribution. Possible probability distributions include, for example, the Gaussian or normal distribution for continuous variables, the Bernoulli distribution for multiple measurement variables, the Beta distribution for Boolean variables that can only take two values, and the Beta distribution used to model probabilities (e.g., error probabilities), which themselves represent random variables with distribution functions. In inference model 30, random variables are interconnected through causal or correlational relationships, which can be represented using factor graphs. Figure 6 The exemplary factor graph representation shown is the line of code B = Factor(A), where the result of the operation factor on random variable A is assigned to random variable B.

[0053] As described above, inference is implemented in inference engine 38, which accesses the functionality of the Infer.NET framework. For this purpose, inference module 38 automatically maps inference model 30 to the factor graph of facility 1.

[0054] The reasoning module 38 will be explained in more detail below.

[0055] The inference module 38 serves as the starting point for error root cause analysis. The training of the inference model 30 and the implementation of the diagnosis 40 can be performed offline or online as needed; therefore, the overhead of generating a completed inference model 30 through a previous execution is avoided. The inference module 38 essentially consists of four classes, which... Figure 7 The class diagram is shown in detail. The class "InferenceModule" encapsulates all used functions and stores inference variables. The base class "InferenceBase" contains all inference methods and model constraints; it forms the core of Inference Module 38 and is upon which all other classes are built. The diagnostic class "InferenceDiagnosis" and the training class "InferenceTraining" inherit from this class and are modified only slightly to suit their respective tasks.

[0056] The base class contains four methods: Init(), CreateModel(), SetPriors(), and Infer(), which are implemented in that order.

[0057] The `init()` method initializes the necessary variables and the Infer.NET inference engine. It defines the model... Figure 8 The document lists several variable types that satisfy different tasks. Each variable type has a different function in training and diagnosis.

[0058] For example, the constants remain unchanged in both cases and include the natural constants and facility parameters specified for the inference run.

[0059] Model parameters are the coefficients of a programmed mathematical formula describing the normal operation of Facility 1 and are its characteristics. These parameters either have physical meaning and are therefore theoretically calculable, or they have no physical meaning and serve only as degrees of freedom. Infer.NET can perform inference regardless of the modeling type and therefore can also be used as a machine learning method. Especially in the latter case, training may be necessary using existing measurement data, as the starting values ​​are often randomly chosen, resulting in poor initial results. Inference optimizes existing estimates of the parameters during training so that they better reflect the facility's behavior after training. If the parameters are already determined and there is sufficient confidence in them, training can be omitted. The meaning of the model parameters can be freely chosen by the programmer and has no impact on the inference itself.

[0060] In contrast to model parameters, error parameters describe coefficients specific to the error. Since the same error can have varying degrees in practice, it makes sense to infer these parameters during training and diagnostics. Conversely, model parameters should remain constant during the diagnostic phase.

[0061] Each error type to be identified has its own variables and model. Unmodeled error types cannot be identified during diagnosis and may be interpreted as combinations of other error types. Each type of error has a probability that is calculated only during the diagnosis phase. During the training phase, errors are passed to the system as observed input variables because, in the case of historical data, errors that have already occurred should be identified. Otherwise, the data must be diagnosed.

[0062] In both training and diagnostics, the measurements are input as observed variables. Furthermore, the measurement accuracy of each measurement should be known, thus enabling the model to derive a Gaussian distributed random variable with the correct variance for each measurement.

[0063] Internal variables are toggle variables, integer or floating-point variables, or intermediate variables in the form of bool, int, or double. These variables are intended to serve as intermediate results or hidden variables within the model and are not directly accessible to the user. They are considered mutable during inference but do not reflect any outcome distribution.

[0064] After initialization in `Init()`, model constraint occurs in the `CreateModel()` method of the base class, where the factor graph for facility 1 is created. Model constraint can be hardcoded in a separate source text file, or created by the transformation module 31 as explained above. Source files 33 can be swapped to implement different models. Two methods for modeling can be considered, which... Figure 9 As exemplarily shown in the figure.

[0065] In the first variant, only the Boolean variable A receives the prior distribution Bernoulli(0.5). Variable B is then assigned the result of the operation factor on variable A. C is assigned the result of the factor on B. This is similar to traditional programming, but in contrast, Infer.NET allows A to be computed using this constraint if C is observed. If the relationship between A and C allows only one possible solution, then the prior has little effect on A in this case. In the second variant, this programming feature is used more strongly. A, B, and C receive the same prior distribution, therefore, there is no bias towards a particular solution. The result of the operation Factor(A) - B is then determined to be zero in the model constraint, and similarly, the same condition for C is determined in the following line. This representation is equivalent to the first variant of the inference engine and leads to similar results in both cases in both directions. However, the ability to swap lines in the second variant compared to the first variant offers a significant advantage for model transformation, as the components of the facility can thus have their code appended in any order, and it is not necessary to determine the specific algorithm used to run the facility.

[0066] The SetPriors() method sets all prior distributions based on past training runs or facility data. Figure 8 The table illustrates which parameters are assigned at which stage. Types marked "constant" are declared as observations in the `SetPriors()` method because observed variables become constants during inference (see 2.3.3). Marking them as "observed" means that such variables were entered into the facility shortly before the inference request in the `Infer()` method. These variable types are re-observed with each `Infer()` call, while the constants determined in `SetPriors()` remain unchanged for each inference request, i.e., they provide constant observations. Furthermore, `SetPriors()` sets the prior distribution of the model and error parameters to a Gaussian distribution created by the facility properties and sets the precision parameter.

[0067] Many tasks in inference model 38 are implemented in the base class. However, training and diagnostics differ from each other in the prior allocation and model creation phases; therefore, each implements its own `CreateModel()` and `SetPriors()` methods. At the beginning of `CreateModel()`, the base class's initialization method is implemented, then their own variables are initialized and prior distributions are allocated. Finally, the base class's `CreateModel()` method is implemented. Besides the `ModelParameter` and `FaultParameter` arrays, the training class has an `ModelPriors` array, the base class has an `FaultPrior` array, and the diagnostic class has an `FaultProbs` array. The reason for this division is based on... Figure 8 The table shows that error probabilities exist only during diagnosis because errors are observed during training. Inferences about error probabilities during training only reflect the relative frequency of errors during training. However, this is not important, which is why probabilities are not derived for training. Similarly, the prior distribution of model parameters exists only during training because the model parameters are determined during diagnosis. Both phases require prior distributions of error parameters, therefore inferences about these parameters are performed in the base class.

[0068] Figure 10 The factor plot of Facility 1 during training is shown. Observed variables are marked in gray, while variables marked in white are those whose values ​​can change during inference. Each quantity in the factor plot represents a set of variables of the same type. Random variables are created using Variable.Random based on the priors of the model and error parameters; although they are based on prior values, they can be freely adjusted by the algorithm. Observed errors are input into the model as FaultFlags. Errors that have occurred are assigned the value true, and errors that have not occurred are assigned the value false. The factor plot of the facility is created in the CreateModel() method of the base class, which contains the inference code created by the transformation module 31. This code can only access the variables specified here, so the system properties in metamodel 35 are assigned fixed variable types and no new variables are created.

[0069] Figure 11The factor plot of Facility 1 during diagnosis is shown, during which model parameters are observed compared to training and cannot be adjusted by the inference engine. Errors, on the other hand, have their own model. These are treated as random variables with a Bernoulli distribution of probabilities FaultProbs. As mentioned above, the probabilities themselves are determined to be beta distributions and have fixed priors. For example, before each diagnosis, all probabilities are reset, and the inference engine is used to correct these probabilities in one direction or the other. The error condition can be inferred from the difference in corrections over time intervals. Therefore, it makes sense that, to record this variation, all probabilities are initially treated as uniformly distributed. The greater the correction along the 0 or 1 direction, the more reliable the conclusion about whether an error has occurred. If the probability remains at 0.5, the engine cannot draw any conclusions about the error, or the presence of this error has no impact on the observations made.

[0070] The `Infer()` method performs inference for inference model 30. As a transfer, this method receives a data structure with measurements and timestamps. The measurements, sampling time, and number of measurements are input as observations of the corresponding model variables. In the case of training, errors that have occurred are also observed. The base class "InferenceBase" performs inference for error parameters, the training class performs inference for model parameters, and the diagnostic class performs inference for error probabilities. The results are then returned as an `InferenceParameterSet`. After training, the optimized parameters are stored in the variable database 24.

[0071] During diagnosis, the probabilities of all error causes are re-estimated. All error causes with a significantly increased probability are considered actual causes. Since there are often many causes, but only a few measured variables are compared, it is generally meaningful to output a few causes. After diagnosis, the results (44) are output either via the console or in tabular format.

[0072] The method according to the invention has several advantages, combining model-based and signal-based diagnostic approaches. Model-based methods, therefore, require very high model quality, which is difficult to achieve in complex process facilities. Similarly, they typically require very high measurement accuracy, which increases costs and is one reason why these methods may yield incorrect results if measurements are inaccurate. In the method according to the invention, modeling costs are relatively low and can be further reduced by training data or modifying the model. Probabilistic programming allows measurement accuracy to be incorporated into diagnostics with minimal cost, thus enabling high diagnostic accuracy despite a small database. Similarly, it can identify concurrent faults and faults without historical records, which is impossible with signal-based methods. Generally, the method used requires far less historical data compared to similar signal-based methods (e.g., neural networks).

[0073] Modeling costs are thus reduced, primarily because it's unnecessary to precisely measure, compute, or otherwise determine model parameters. Instead, setting an inaccurate initial estimate at the correct order of magnitude is sufficient. Very precise process parameters are then found through several training iterations using the measured data. Furthermore, Infer.NET specifically deals with random variables, thus eliminating the need for additional modeling of measurement errors as required by other methods. By including all possible error states in the model, new or multiple errors can be identified.

[0074] It can program a separate category for unknown errors. This method requires less historical data than machine learning methods because it has fewer degrees of freedom and is often able to determine good approximations.

[0075] This article cites the following publications:

[0076] [1.]M. Sayed-Mouchaweh, ed., Fault Diagnosis of Hybrid Dynamic and Complex Systems, Douai: Springer International Publishing AG, 2018

[0077] [2.]SXDing, Model-based Fault Diagnosis techniques, Duisburg: Springer-Verlag Berlin Heidelberg, 2008

[0078] [3.]G.Niu, Data-Driven Technology for Engineering System HealthManagement, Shanghai: Springer Nature, 2017

[0079] [4.] C.Aldrich and L.Auret, Unsupervised Process Monitoring and FaultDiagnosis with Machine Learning Methods, Stellenbosch: Springer LondonHeidelberg New York Dordrecht, 2013

[0080] [5.)R.Isermann,Fault-Diagnosis System,Darmstadt:Springer-VerlagBerlin Heidelberg,2006

[0081] [6.]C.Aldrich and L.Auret,Unsupervised Process Monitoring and FaultDiagnosis with Machine Learning Methods,Stellenbosch:Springer LondonHeidelberg New York Dordrecht,2013

Claims

1. A method for performing error root cause analysis in a process technology facility (1), wherein, The engineering information of the facility (1) is provided in digital form, including information about the facility components in the facility (1) and the interconnections of the facility components. An inference model (30) in the form of a probabilistic physical model of the facility (1) with probability distributions and prior variables is created from the engineering information, and Bayesian inference of error probability is performed in the diagnostic mode of the inference model (30) using measurement data from the facility (1). A meta-model (35) of the facility (1) is first generated from the engineering information of the facility (1) by adopting a template (36) of a model library, the engineering information including piping and instrumentation diagrams. The model library contains code to be generated and inference variables to be used for implementing the Bayesian inference for each component type of the facility (1), and the inference model (30) of the facility (1) is created from the meta-model (35), wherein the template (36) of the model library describes the behavior of each facility component and includes possible causes of error, and wherein the inference variables represent variables to be used for implementing the Bayesian inference.

2. The method according to claim 1, characterized in that, Using the measurement data from the facility (1), Bayesian inference of the inference model (30) is performed in the training mode of the inference model (30), wherein the estimation of the prior model parameters in the inference model (30) is optimized.

3. The method according to claim 1 or 2, characterized in that, The inference model is created from the engineering information using a bond graph (30).

4. A system for performing error cause analysis in a process technology facility (1), the facility (1) having a conversion module and an inference module, the conversion module being designed to create an inference model (30) from engineering information of the facility (1) in the form of a probabilistic physical model of the facility (1) with probability distributions and prior variables, wherein, The engineering information includes information about facility components in the facility (1) and the interconnections of the facility components. The inference module is designed to perform Bayesian inference of error probabilities in the diagnostic mode of the inference model (30) using measurement data from the facility (1). The system is designed to implement the method according to any one of claims 1 to 3.

5. The system according to claim 4, characterized in that, The inference module is also designed to perform Bayesian inference of the inference model (30), wherein the estimation of prior model parameters in the inference model (30) is optimized.

6. A computer program product, the computer program product being loaded into the memory of a computer and comprising software code segments, wherein when the computer program product is run on the computer, the software code segments are used to implement the method according to any one of claims 1 to 3.

Images