KR20150058343A - Logic based approach for system behavior diagnosis - Google Patents

Logic based approach for system behavior diagnosis Download PDF

Info

Publication number
KR20150058343A
KR20150058343A KR1020157009632A KR20157009632A KR20150058343A KR 20150058343 A KR20150058343 A KR 20150058343A KR 1020157009632 A KR1020157009632 A KR 1020157009632A KR 20157009632 A KR20157009632 A KR 20157009632A KR 20150058343 A KR20150058343 A KR 20150058343A
Authority
KR
South Korea
Prior art keywords
dependency
evaluated
logical
components
sensor data
Prior art date
Application number
KR1020157009632A
Other languages
Korean (ko)
Inventor
윤송 맹
단 지. 테쿠씨
Original Assignee
지멘스 코포레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US201261701822P priority Critical
Priority to US61/701,822 priority
Application filed by 지멘스 코포레이션 filed Critical 지멘스 코포레이션
Priority to PCT/US2013/060070 priority patent/WO2014043667A1/en
Publication of KR20150058343A publication Critical patent/KR20150058343A/en

Links

Images

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00Testing or monitoring of control systems or parts thereof
    • G05B23/02Electric testing or monitoring
    • G05B23/0205Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G05B23/0243Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model
    • G05B23/0245Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model based on a qualitative model, e.g. rule based; if-then decisions
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00Testing or monitoring of control systems or parts thereof
    • G05B23/02Electric testing or monitoring
    • G05B23/0205Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0259Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the response to fault detection
    • G05B23/0275Fault isolation and identification, e.g. classify fault; estimate cause or root of failure
    • G05B23/0278Qualitative, e.g. if-then rules; Fuzzy logic; Lookup tables; Symptomatic search; FMEA

Abstract

 The method for evaluating the system state includes receiving (S41) user-provided information regarding operation of the system. A dependency model of the system is constructed based on the received information (S43a / b). When it is determined that the user-provided information is sufficient to constitute the logical model (S42), the logical model of the system is configured (S43) and combined with the dependency model (S46). Sensor data from the sensors installed in the system are observed, the coupled model is applied to the sensor data when the combined model is available, and the dependency model is applied to the sensor data when the combined model is unavailable (S48). The set of abnormal system components is determined from the application to the sensor data of the combined model / dependency model, and an evaluation of the system state is determined based on the set of abnormal system components.

Description

{LOGIC BASED APPROACH FOR SYSTEM BEHAVIOR DIAGNOSIS}
<Cross reference to related application>
This application is based on U.S. Provisional Patent Application No. 61 / 701,822, filed September 17, 2012, the contents of which are incorporated herein by reference in their entirety.
<Technical Field>
The present specification relates to system behavior diagnosis, and more specifically, to a logic based approach for system behavior diagnosis.
Complex dynamic systems such as electromechanical machinery, industrial facilities, and large commercial buildings sometimes use networks of sensors installed at various key locations to provide insight into the operating state of the system. By monitoring the functions of the system, deviations from normal operation can be observed and remedial actions such as repair, repair and replacement at the right time to maximize the system's stability and uptime .
However, due to factors such as a large set of potential failures, parameter drift, noise, limited sensor observability, and the like, it is possible to accurately Diagnosis can be particularly difficult.
Therefore, how to diagnose a system from faulty sensor data and predict failure is a challenging goal in managing complex and dynamic industrial assets.
A method for evaluating a system state includes receiving user-provided information regarding operation of the system. A dependency model of the system is constructed based on the received information. When it is determined that user-provided information is sufficient to construct a logical model, the logical model of the system is configured and combined with the dependency model. Sensor data from the sensors installed in the system are observed. When a combined model is available, the combined model is applied to the sensor data, and when the combined model is unavailable, the dependency model is applied to the sensor data. From the application of the combined model / dependency model to the sensor data, a set of abnormal system components is determined. The evaluation of the system state is determined based on a set of abnormal system components.
The user-provided information regarding the operation of the system under evaluation may include expertise related to the fault dependency of one or more components of the system or the manner in which one or more components of the system fail .
The user-provided information regarding the operation of the system being evaluated may be encoded by the user or automatically in an Answer Set Programming (ASP) format based on user input.
The configured dependency model and / or coupled model may be expressed in Response Set Programming (ASP) format.
The constructed dependency model can only explain how faults propagate through the system being evaluated.
The constructed logical model can account for complex functional interdependencies between one or more components of the system being evaluated.
Determining if the received user-provided information is sufficient to construct a logical model of the system being evaluated may involve configuring the logical model, attempting to apply the configured logical model to the observed sensor data, and determining whether a meaningful result has been obtained And &lt; / RTI &gt;
The combination of a logical model and a dependency model can be performed by a Response Set Programming (ASP) solver.
Applying a model or dependency model coupled to sensor data can be performed by a Response Set Programming (ASP) solver.
Providing an assessment of system state based on a determined set of one or more abnormal system components may include prioritizing minimal solutions.
Providing an assessment of the system state based on a determined set of one or more abnormal system components may include prioritizing the solutions supported by the plurality of sensors.
Applying a coupled model or dependency model to the sensor data may involve using nonmonotonic reasoning.
A method for evaluating a system state includes receiving a dependency model of the system being evaluated and a logical model of the system being evaluated. The sensor data is observed from one or more sensors installed in the system being evaluated. The logic model is combined with the dependency model, and the combined model is applied to the sensor data using a response set programming (ASP) solver. From the application of the combined model to the sensor data, a set of one or more abnormal system components is determined. An evaluation of the system state is provided based on a determined set of one or more unusual system components.
Providing an assessment of system state based on a determined set of one or more abnormal system components may include prioritizing the minimum solutions.
 Providing an assessment of the system state based on a determined set of one or more abnormal system components may include prioritizing the solutions supported by the plurality of sensors.
A computer system is a program that is readable by a non-transitory tangible computer system that implements a program of instructions executable by a processor to perform steps of a processor and a method for evaluating system state, And a storage medium. The method includes receiving user-provision information regarding the operation of the system being evaluated. A dependency model of the system being evaluated based on the received user-provided information is constructed. It is determined whether the received user-provided information is sufficient to construct a logical model of the system being evaluated. When the user-provided information is determined to be sufficient, the logical model of the system being evaluated is configured and the logical model is combined with the dependency model. Sensor data from one or more sensors installed in the system being evaluated are observed. When a combined model is available, the combined model is applied to the sensor data, and when the combined model is unavailable, the dependency model is applied to the sensor data. From the application of the combined model / dependency model to the sensor data, a set of one or more abnormal components is determined. An evaluation of the system state is provided based on a determined set of one or more abnormal components.
The constructed dependency model can only explain how faults propagate through the system being evaluated.
The constructed logical model can account for complex functional interdependencies between one or more components of the system being evaluated.
The combination of a logical model and a dependency model can be performed using a response set programming (ASP) solver.
Applying a model or dependency model coupled to sensor data can be performed by a Response Set Programming (ASP) solver.
Providing an assessment of the system state based on a determined set of one or more abnormal system components may include prioritizing the minimum solutions or prioritizing the solutions supported by the maximum number of sensors.
BRIEF DESCRIPTION OF THE DRAWINGS The present specification and its attendant advantages will be better understood by consideration of the following detailed description along with the accompanying drawings, so that a more complete appreciation of them can readily be gained.
BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a schematic diagram illustrating a water tank problem (WTP) to illustrate exemplary embodiments of the present invention.
Figure 2 illustrates a simplified oil lubricating system to which an exemplary embodiment of the present invention may be applied.
Figure 3 is a set of statements representing a dependency model based on the system of Figure 2 in accordance with an exemplary embodiment of the present invention.
4 is a flow diagram illustrating a hybrid approach for system diagnosis in accordance with an exemplary embodiment of the present invention.
5A is a diagram illustrating an overall structure for system diagnosis according to an exemplary embodiment of the present invention.
Figure 5b is a schematic diagram illustrating a structure for an observation and diagnostic system in accordance with an exemplary embodiment of the present invention.
Figure 6 illustrates an example of a computer system capable of implementing an apparatus and method according to embodiments of the present disclosure.
In describing the exemplary embodiments of the present disclosure shown in the drawings, specific terminology is used for the sake of clarity. It is to be understood, however, that the description is not intended to be limited to such selected terminology, and that each specific element includes all technical equivalents that operate in a similar manner.
Some approaches to system diagnosis involve the use of computer learning to detect evidence of problems such as future failures from sensor data, while other approaches utilize the expertise of one or more human users. Other approaches can combine the use of expertise with the aspects of computer learning. In approaches that use expertise to interpret sensor data, such knowledge may be encoded in a computer-readable format, such as a logical expression, and thereafter, when the system is operating normally, when the system malfunctions, The computerized diagnostic system can be used to help determine where the portion of the system is, what remedies are desirable, how much time remains to perform remedies before the failure occurs, and so on.
One approach to performing diagnostics based on sensor data, utilizing expert knowledge, is the fault dependency model. This approach is based on the recognition that some components themselves require normal operation of other components in order to operate normally. Since one failure can appear as a number of abnormal sensor readings, the defect dependency model is based on the prior knowledge of what kinds of malfunctions are likely to generate other abnormal sensor readings, such that the root of the abnormal readings Try to pinpoint the cause.
The water tank problem (WTP) will be discussed to help explain this diagnostic approach. 1 is a schematic diagram showing WTP. There are two tanks here, the left tank 10 and the right tank 11. A single tap 12 moves freely between each tank to fill both tanks with water. Each tank has a hole through which water is drained in the bottom. The water in the right tank 11 is discharged at the speed of v2 while the water in the left tank 10 is discharged at the speed of v1. The faucet (12) fills one of the tanks at a speed of w. For simplicity, we can assume v1 = v2 = v and w> v. An instruction called "switch" can be used to move the faucet to change the tank.
The sensor x1 is a boolean sensor for observing the state of the left tank 10 and the sensor x2 is a boolean sensor for observing the state of the right tank 11. [ Sensors x1 and x2 register 1 when the tank level is increasing and 0 when the water level is decreasing.
Now assume at time 1 that the value of x1 is 1 and the value of x2 is zero. This indicates that the faucet 12 is filling the left tank 10. Assuming a switch command between time 1 and time 2, and assuming that at time 2, the values of x1 and x2 are still 1 and 0 respectively, then the system is expected to have 0 at x1 and 1 at x2 after the switch, And the value of x2 are considered abnormal. In this scenario, the faucet 12 is in a state of being unable to move over the left tank 10. However, since there is no sensor for the faucet 12, this problem can not be directly observed and thus a diagnosis is required.
Non-linear inference can be used to investigate the states of x1 and x2 together. The fact that x2 is decreasing without increasing can indicate that the left tank 11 has failed due to leakage, for example. However, when combined with the fact that x1 increases without decreasing, malfunctioning can be determined as faucet 12. One example of non-linear reasoning is the Response Set Programming (ASP) format. The exemplary embodiment seeks to apply ASP to various observation and diagnostic systems to estimate the cause of sensor anomaly items when a particular problem is not directly observable. In addition, ASP can be used as a unifying language for integration of other inference approaches.
Exemplary embodiments of the present invention may utilize two additional approaches for inference diagnosis. This first approach can be referred to as a defect dependency model. In this approach, the understanding that an erroneous operation can cause an abnormal reading of other sensors is used to trace back a series of abnormal sensor readings to the actual cause of the failure. When applied to the WTP example described above, we can start with faults in the faucet causing an abnormal condition of the left tank, which starts with expert understanding that can lead to an abnormal reading of x1. Similarly, failure of the faucet may cause an abnormal condition of the right tank, which may lead to an abnormal reading of x2. This knowledge can be expressed as follows.
Tap -> Tank 1 -> x1
Tap -> Tank 2 -> x2
This dependency model means that tank 1 and / or faucet may be defective when x1 is observed abnormally and likewise, tank 2 and / or faucet may be defective when x2 is observed abnormally Can be interpreted. The following dependency matrix can be used to describe this situation.
Figure pct00001
As can be seen, to create a defect dependency model, the only necessary expertise is how defects propagate among the components. This knowledge can be obtained automatically from system design documents such as CAD / CAM. Other information, such as the functional aspects of the system, can be ignored. For this reason, the defect dependency model can be simple to configure and simple to use for diagnostic purposes, but this approach can have a relatively low resolution compared to other inference approaches. Therefore, for a given number of sensors, the defect dependency model may not be able to precisely refine the exact cause of the problem as compared to other inventions.
Exemplary embodiments of the present invention may also employ other approaches for diagnostic reasoning. This other approach can be referred to as a logical model approach. In this approach, complex functional interdependencies between system components can be expressed as logical expressions. This approach requires additional expertise, but a higher diagnostic resolution can be achieved, which may mean that the cause of the problem can be narrowed down more precisely for a given number of sensors.
The logical model approach can be applied to the WTP example. However, in order to make the concepts easier to understand, instead of using the "switch" command to cause a tap change, a "fill1" command with a value of 1 can be accepted as meaning that the left tank has to be filled , A value of 0 can be taken to mean that the right tank should be filled. Also, in this notation approach, the abnormal sensor readout may be expressed as "ab (<sensor name>)". Additionally, each command is associated with a state variable that describes the system state. For example, for command fill1, the state "filling1" will be true if the faucet is filling tank 1, otherwise the state "filling1" will be false. Therefore, the expertise of the WTP example can be captured by the following two rules that can also utilize the ASP modeling language.
inStatus (filling1) ← value (fill1,1), not ab (tap) (One)
not inStatus (filling1) ← value (fill1,0), not ab (tap) (2)
For these ASP rules, the right side of the rule is the proposition and it must be interpreted as conjunctions, meaning that in order for the left side to be true, all the conditions of the right side must be true. Rule (1) states that if the value of the command fill1 is 1 (filling the left tank) and the faucet is not in a fault condition, the system should be in a state where the left tank is filled. Similarly, rule (2) suggests that if the value of command fill1 is zero (does not fill the left tank) and the faucet is not in a defective state, the system suggests that the left tank should be in an unfilled state.
Logical equations can also be used to specify the relationship between sensor readings and state variables, for example:
value (x1,0) ← not inStatus (filling1), not ab (tank1)  (3)
value (x2,1) ← not inStatus (filling1), not ab (tank2)  (4)
Where rule (3) states that if the system is not filling tank1 (left tank) and tank1 is defective, x1 should not sense an increase. Rule (4) similarly suggests that if the system is not filling tank1 (left tank) and tank2 is defective, x2 should sense an increase.
If both x1 and x2 are detected to be defective, the sensor readings are:
value (fill1,0), value (x1,1), value (x2,0) (5)
From the sensor readings value (filling1,0) and rule (2), one can conclude either ab (tap) or not inStatus (filling1). From either note inStatus (filling1) and rule (3), one of ab (tank1) or value (x1,0) can be deduced as true. Since value (x1,0) collides with the sensor reading, it can be concluded as ab (tank1). Similarly, ab (tank2) can be concluded. From this, there are two minimum explanations: {ab (tap)} and {ab (tank1), ab (tank2)}. That is, the faucet is malfunctioning or both tanks are malfunctioning. If {ab (tap)} can account for the observation, the larger set {ab (tap), ab (tank1)} can also account for it, so considerations can be limited to minimum explanations. From the two minimum explanations we can find one symptom that supports ab (tank1) and ab (tank2), while finding only one symptom (x1) and ab (tank2) backing ab (tank1) , x2) can be found. Since there are many more symptoms that support each abnormality, we may prefer to choose the first minimum description {ab (tap)} here.
From the example described above, it can be seen that the logical model approach is more complex, but provides a more detailed description of the cause of the potential failure. The dependency model approach is simpler but provides less detail on the cause of the potential failure.
Exemplary embodiments of the present invention combine a dependency model approach and a logical model approach using the modeling language of ASP to provide a high resolution and possibly a hybrid modeling approach, do. When a number of potential solutions are made from this hybrid approach, the exemplary embodiments provide priority to the minimum solutions, for example given the simplest possible explanation that can account for the observed sensor readings. In addition, if there are a number of simple minimal solutions, preference is given to solutions with the greatest number of supporting evidence, for example the minimum solution with the largest number of backed up sensor observations.
Such forms can be used as a computational framework because non-hierarchical forms of response set programming (ASP) make use of non-linear inference and are well-prepared to deal with dynamic domains. This approach can be integrated with existing observation and diagnostic systems that use these sensor data.
Exemplary embodiments of the present invention are described herein with reference to a simplified lubricating oil system. It should be understood, however, that the simplified lubricating oil system is provided as an exemplary system to which the exemplary embodiments of the present invention may be applied, and that the exemplary embodiments of the present invention may be applied to any observed system.
In certain cases, it may be difficult or impossible to obtain a complete model of a complex system with all state-space equations and transitions describing the intended behavior that is the basis of a quantitative diagnostic approach. Exemplary embodiments of the present invention may rely solely on dependency models if a complete model of a complex system is unavailable or not provided.
2 is a diagram illustrating a simplified oil lubrication system to which exemplary embodiments of the present invention may be applied. The three pumps "ACPMP1" 201, "ACPMP2" 202 and "DCPMP" 203 are connected to a lubricating oil reservoir 200. The two AC pumps 201 and 202 may form a redundant / backup system and the DC pump 203 may operate on another line. In the AC tube, a cooler 204, a filter 205, and a pressure regulator valve 206 are connected in order. There are four command sensors, pump1Dmd (207), pump2Dmd (208), dcPmpDmd (209) and control valve (210). Four indicator sensors are provided. The sensors include a psvac 211 indicative of the pressure of the reservoir 200, dpsw 212 and ps 213 indicative of whether the oil flows through the two pipes and a LOPS 214 indicative of the hydraulic pressure at the terminal, ).
From this figure, a dependency model can be created. Since the dependency model only requires information on how the anomaly propagates through the system, additional expertise other than that captured in the depicted figures is not required to establish a dependency model. Figure 3 is an aggregate statement representing a dependency model based on the system of Figure 2 in accordance with exemplary embodiments of the present invention. The dependency model shown in Fig. 3 can be obtained directly from the figure of Fig.
The dependency model of FIG. 3 shows a chain of dependencies for each object in the system shown in FIG. For example, as can be seen in the first row 31, the abnormal sensor readings sensed in the lops 214 may cause problems in the lops 214, problems in the regulator valve 206, problems in the filter 205, 204, a problem in acpmp1 201, or a problem in the repository 200. [ As can be seen in the second row 32, the abnormal sensor readings sensed in the lops 214 may cause problems in the lops 214, problems in the regulator valve 206, problems in the filter 205, A problem within the acpmp2 202, or a problem within the repository 200. [ As can be seen in the third row 33, the abnormal sensor readings sensed in the dpsw 212 may be a problem in the dpsw 212, a problem in the regulating valve 206, a problem in the filter 205, A problem in the acpmp1 201, or a problem in the repository 200. [ As can be seen in the fourth row 34, the abnormal sensor readings sensed at the dpsw 212 may be a problem in the dpsw 212, a problem in the regulating valve 206, a problem in the filter 205, A problem within the acpmp2 202, or a problem within the repository 200. [ As can be seen in the fifth line 35, the abnormal sensor readings sensed in the lops 214 may be caused by a problem in the lops 214, a problem in the dcpmp 203, or a problem in the storage 200. As can be seen in the sixth row 36, the abnormal sensor readings detected at ps 213 may be caused by a problem in ps 213, a problem in dcpmp 203, or a problem in storage 200. As can be seen in the seventh column (37), the abnormal sensor readings detected in the psvac (211) may be caused by a problem in the psvac (211) or a problem in the storage (200).
This hierarchical relationship between possible causes and abnormal sensor readings is summarized in the dependency matrix given below. In this dependency matrix, the columns represent abnormal sensor readings, and the rows represent possible causes. The value of "1" indicates that the abnormal sensor readout of the column may have been caused by a failure or other malfunction in the row, while a value of "0" indicates that the abnormal sensor readout of the column is not caused by a failure or other malfunction in the row Not:
Figure pct00002
It can therefore be seen from this dependency matrix that it is not possible to fully diagnose a simplified lubricating oil system example using existing indicator sensors. For example, if both lops and dpsw are detected to be defective, it may not be possible to distinguish which component is defective based solely on dependency information. In this case, any one or more of the components may be defective.
However, as will be described below, a more insightful answer can be provided if the same set of sensor data is analyzed using a logical model approach. According to this approach, we can identify from the lubricating oil system shown in FIG. 2 that each sensor defines a system state variable. For example, when acPmp1 is not in a fault state, we can see that value (acPmp1Dmd, 1) = pumpRun, value (acPmp1dmd, 0) = not pumpRun, which means that when Pump1Dmd provides a value of 1 Knows that ACPMP1 is working, and when Pump1Dmd gives a value of 0, we know that ACPMP1 is not working. This information can be encoded using the following ASP rules:
inStatus (pumpRun1)? value (acPmp1Dmd, 1), not ab (acPmp1) (6)
not inStatus (pumpRun1) ← value (acPmp1Dmd, 0), not ab (acPmp1) (7)
As another example, the indicator sensor is value (lops, 0) = lowPress, value (lops, 1) = not lowPress. Such information can be encoded with the following ASP rules.
value (lops, 1) ← not inStatus (lowPress) (8)
value (lops, 0) ← inStatus (lowPress) (9)
The relationship between the different state variables can be encoded using the following constraints:
← not inStatus (lowpress), inStatus (flow1),
not inStatus (flow2), not ab (regulatorValve) (10)
Here, leaving the left side of the ASP rule blank indicates that the right side of the rule can not be true. This constraint states that the terminal pressure can not be low if it is in flow in tube 1, in flow in tube 2, and there is no defect in the regulator valve.
Consider a scenario where lops and dpsw are detected as defective. The sensor readings will be: value (acPmp1Dmd, 1), value (acPmp2Dmd, 0), value (dcPmpDmd, 0), value (dpsw, 0), value (ps, 1), value (lops, 0).
From the equations (6) to (9), it can be concluded that inStatus (flow1), not inStatus (flow2) and not inStatus (lowPress). As a result, from rule (10), it can be deduced that ab (regulatorValve) is true.
From the above example, it can be seen how each of the two models can be applied to the lubricating oil system example. The dependency model approach is easy to obtain, involves simple reasoning, but can provide a relatively low resolution, which can mean that the malfunction is not as narrow as when using a logical model approach for a given number of sensors. The logical model approach can provide higher resolution, which means that for a given number of sensors, the malfunction can be narrowed to a subset of potential problems. However, a logical model approach may require additional user input to establish. For example, more specialized data may be needed to produce a complete set of logical statements to understand the system.
Exemplary embodiments of the present invention seek to combine a dependency model approach with a logical model approach. 4 is a flow diagram illustrating a hybrid approach for system diagnosis in accordance with an exemplary embodiment of the present invention. First, user information can be obtained (step S41). The user information may be expertise about the system to be observed and may be related to the known ways in which problems can be observed and the normal operation of the system. Such user information may be provided, for example, via a user interface that prompts the user for the required information. Obtaining user information may also include formatting the user-provided input in a clear and convenient format.
Next, it may be determined whether the obtained user-provided information is sufficient to establish a logical model (step S42). This decision can be made automatically by asking the user manually, or by analyzing the sufficiency of the information. According to one exemplary embodiment of the present invention, the logic model may be constructed in any case, and the constructed logic model may be sufficient if the logic model can provide a meaningful result. Alternatively, a sufficient logic model may be evaluated by running simulations or by examining the interdependency of a set of logical statements to see how many different combinations of possible sensor values can be described by the model .
If the obtained user-provided information is sufficient to establish a logical model (Yes, step S42), a logical model can be created from the available information (step S43). If the obtained user-provided information is not sufficient to establish a logical model (No, step S42), a dependency model can be created from the available information (step S44a). Additionally, if a logical model is created, the dependency model can still be created (step S44b). Any time after that, additional information about the system can be obtained from the user or otherwise learned by observing the operation of the system, and when additional information is available, the logical model can be extended or lost due to lack of sufficient information If it has not been generated in step S303.
Next, dependency information may be encoded using a Response Set Programming (ASP) framework (Step Set Programming Framework) (step 45a / b). For example, connectTo (dcPmpDmd, res) can be used for dependencies between system components. For dependencies between components and indicators, associate (dcPmp, ps) can be used.
The transitive closure of a connection can be computed using the following ASP rules.
tcConnectTo (C, C1) ← connectTo (C, C1) (11)
tcConnectTo (C, C2)? tcConnectTo (C, C1), tcConnectTo (C1, C2) (12)
For each component C, if indicator I is associated with C and another component C1 is within the transition closure of C, I is also associated with C1 as follows:
associate (C1, I) ← associate (C, I), tcConnectTo (C, C1) (13)
Once the dependency model is encoded into the ASP rule, both models can be combined and executed using the ASP solver (step S46). If a logical model is not created, the dependency model can still be executed using the ASP solver (step S47).
ASP solver computation can be a particularly efficient way to determine the cause of abnormal sensor readings or otherwise diagnose potential problems.
The ASP encodings of model rules can be created manually or automatically. For example, knowledge of an ASP can be hidden from end users, and ASP encodings can be automatically generated using knowledge that the user enters in a familiar fashion. Visual modeling tools allow end-users to interact with components, commands, indicators, and state variables; Associations of instructions and indicators with components; Dependencies between components; Definition of state variables using sensor readings; Limitations; And / or &lt; / RTI &gt; expert rules.
When logical models are created, sensor data from the network of sensors installed in the system is analyzed using models to determine when maintenance and / or remediation should be done, or when to diagnose the state of the system (Step S48).
According to an exemplary embodiment of the present invention, when logic and dependency models are combined (step S46), the results of the dependency model can be used to enhance the diagnostic results of the logical model. Accordingly, previous diagnostic efforts that were performed using a dependency model may lead to a logical model approach.
As described above, after the model (s) provide diagnostic results that may include a number of possible causes for abnormal sensor data, prioritization is given to solutions with minimal solutions and a maximum of a plurality of supporting evidence (Step S49). Giving priority may involve rejecting undesirable potential results, or otherwise ordering results for prioritization indication.
The system model allows a program to automatically generate dependencies and logical models. The ASP solver can act as a diagnostic engine. 5A is a diagram illustrating the overall structure for system diagnosis according to an exemplary embodiment of the present invention.
The sensor data 501 from the system can be fed to the observation system 503, for example, periodically, e.g. daily, or continuously, to identify any abnormal behavior. The data may be validated 502 before being viewed. Data authentication can be performed to ensure that the data being viewed is meaningful.
If abnormal data is found, the observation system 503 will return a warning and activate the diagnostic system with all sensor readings and identified faulty sensors. Using this information and system models, the diagnostic engine 504 will generate a set of possible explanations using the inferences previously described, and thereby do the component diagnosis 505.
Figure 5B is a schematic diagram illustrating a structure for an observation and diagnostic system in accordance with exemplary embodiments of the present invention. This structure may be closely related to ISO 13374 (Condition Monitory and Diagnostics of Machines). The structure includes an ISO 13374 hierarchy for data acquisition 506, data manipulation 507, state detection 508, health assessment 509, prognostic assessment 510 and advisory generation 511 Lt; / RTI &gt;
Exemplary embodiments of the present invention may further utilize prognostic evaluation. Inferences about dynamics can be the basis of prognosis and planning. Dynamics can also play a role in effective diagnosis. For example, the provided rules (1) and (2) may be modified with the following dynamic rules:
(14), inStatus (filling1, T + 1) ← ¬inStatus (filling1, T)
(15), (15), (15), (15), (15)
The static relationship between indicator readings and state variables can also be similarly extended. For example, rules (3) and (4) can be replaced by the following rules.
value (x1,0, T) ← ¬inStatus (filling1, T), not ab (tank1, T) (16)
value (x2,1, T) ← ¬inStatus (filling1, T), not ab (tank2, T) (17)
Strong negativity and basic negation are not distinguished here because, unlike the static case, the rule of common sense inertia must be explicitly stated:
inStatus (S, T + 1) ← inStatus (S, T), not ¬inStatus (S, T + 1) (18)
¬inStatus (S, T + 1) ← ¬inStatus (S, T), not inStatus (S, T + 1) (19)
F has a range of all state variables. The laws indicate that system states do not change unless there is a reason for change.
For dynamic cases, diagnostic reasoning becomes more complex. Consider a scenario where the observation system detects that both x1 and x2 are defective. The sensor readings are:
value (switch, 1,0), value (x1,1,0), value (x1,1,1), value (x2,0,0), value (x2,0,1)
Values with a timestamp of 0 refer to readings in the previous step, while values with a timestamp of 1 refer to readings of the current state. Ab (tank1,1), ab (tank2,1)} from the corresponding rules for sensor readings value (x1,1,1), value (x2,0,1) and inStatus (filling1, T) Or inStatus (filling1,1). (tank1,0), ab (tank2,0)} or inStatus (filling1,0), from the same rules as value (x1,1,0), value (x2,0,0) . It can be assumed that {ab (tank1,0), ab (tank2,0)} can not be true because the power monitor has not reported any errors in the previous state. As a result, it is concluded that inStatus (filling1,0). can be concluded as {ab (tap, 1)} from inStatus (filling1,0), inStatus (filling1,1), sensor readings value (switch, 1, 0) and rule 15. The rest of the reasoning is similar to the approach described above.
The diagnostic system can be inferred about dynamics and, as a result, it may be possible to provide prognostic and planning services. To accomplish this, exemplary embodiments of the present invention may extend the diagnostic framework with the ability to infer behavior and changes. For example, going back to the WTP discussed above, if the current state is given the command value (switch, 1) and you are asked what is going to happen, the faucet still can not move, 2), and value (x2,0,2). If knowledge of the faucet repair is encoded and the system is required to restore itself to a normal state, a repair plan will be created.
Exemplary embodiments of the present invention may further utilize a higher level action language to help end users encode knowledge of dynamics. For example, instead of describing rule 14, users can encode using a more natural language approach. Rule 14 will be automatically generated from it.
value (switch, 1) causes inStatus (filling1) if ¬inStatus (filling1) (20)
Exemplary embodiments of the present invention may also enhance the system with ontology knowledge to increase diagnostic accuracy. For example, consider a lubricating oil system example. Instead of describing the defects uniformly with respect to the anomaly of the components, exemplary embodiments of the present invention may use the ontology that the abnormal sensor readings may indicate general defects or functional defects to identify defect types and their relationships have.
General faults can be matched to complete faults in a component, while functional faults can only affect their functionality. With the help of the ontology, users can specify that the low pressure in the terminal is related to the functionality of the control valve.
← not inStatus (lowPress), inStatus (flow1), not inStatus (flow2),
not functionalFault (regulatorValve) (21)
When a failure occurs, it can be assumed that a functional defect has occurred instead of a general defect if both defects can account for the observation. As a result, the exemplary embodiments of the present invention give a higher priority to functional defects when calculating minimum diagnostics. This can be described in the following ASP rules.
#minimize {functionalFault (C): components (C) @ 1} (22)
#minimize {generalFault (C): components (C) @ 2} (23)
In the scenarios discussed above, it is possible for the system to conclude {functionalFault (regulatorValve)} by the ontology and the above rules.
Exemplary embodiments of the present invention may extend the diagnostic system by adding query interfaces to the ontologies. These interfaces can help users to use their knowledge to better encode their knowledge and bolster the diagnosis of the system.
As discussed above, exemplary embodiments of the present invention calculate a minimum diagnostic to give priority to a minimal solution. Exemplary embodiments of the present invention may use meta-programming techniques to reduce the computation of the minimum diagnostic subset to the degree of computation of the response sets of other programs. Otherwise, exemplary embodiments of the present invention may extend this approach to handle arbitrary programs under stable model semantics.
One way to describe the minimum diagnosis is to refer to the circumscription. This approach can be extended to the diagnostic domain.
The approaches described above for automatic observation and diagnostic systems can be used to reduce the time and effort required for asset management and enable profitable optimization of maintenance cycles. Because of the complexity of diagnostic activities, reasoning, for example non-linear reasoning techniques, can be used. Exemplary embodiments of the present invention apply a non-linear form of ASP to the diagnosis of industrial systems. ASP solvers can then be used to solve minimal diagnostic problems within a particular domain.
Figure 6 illustrates an example of a computer system in which the methods and systems of the present disclosure may be implemented. The systems and methods herein may be implemented in the form of a software application running on a computer system, such as a mainframe, a personal computer (PC), a handheld computer, a server, or the like. A software application may be stored on a recording medium that is locally accessible to a computer system and may be stored on a network such as a local area network or a hard wired or wireless connection of the Internet Accessible.
A computer system, generally referred to as system 1000, includes, for example, a central processing unit (CPU) 1001, a random access memory (RAM) 1004, a printer interface A LAN 1010, a display unit 1011, a local area network data transmission controller 1005, a LAN interface 1006, a network controller 1003, An internal bus 1002, and one or more input devices 1009, e.g., a keyboard, a mouse, and the like. As shown, the system 1000 may be connected to a data storage device, for example, a hard disk 1008, via a link 1007.
As those of ordinary skill in the art will appreciate, aspects of the invention may be implemented as a system, method, or computer program product. Accordingly, aspects of the present invention may take the form of a complete hardware embodiment, a complete software embodiment (including firmware, resident software, micro-code, etc.), or an embodiment combining software and hardware aspects, Circuit, "" module, " or "system. &Quot; Further, aspects of the invention may take the form of a computer program product embodied in one or more computer readable media having embodied thereon computer readable program code.
Any combination of one or more computer-readable media (s) may be utilized. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. Computer-readable storage media may, for example, include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or devices, or any suitable combination of the foregoing . A more specific example (non-exhaustive list) of a computer-readable storage medium is an electrical connection, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM) , Erasable and programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, do. In the context of this document, a computer-readable storage medium can be any actual medium that can contain or store a program for use by or in connection with the instruction execution system, apparatus, or device.
The computer readable signal carrier may comprise a propagated data signal having computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such propagated signals may take any of a variety of forms including, but are not limited to, electromagnetic, optical, or any suitable combination thereof. The computer-readable signal medium is not a computer-readable storage medium but may be any computer-readable medium that can transfer, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device.
The program code embodied in the computer readable medium may be transmitted using any suitable medium including, but not limited to, wireless, wired, fiber optic cable, RF, etc., or any suitable combination of the above.
The computer program code for performing operations with respect to the aspects of the present invention may be stored in a computer readable medium including an object-oriented programming language such as Java, Smalltalk, C ++, etc., and a conventional procedural programming language such as a "C & , Or any combination of one or more programming languages. The program code may be fully executable on the user's computer as a stand-alone software package, partially on the user's computer, partially on the user's computer, partially on the remote computer, or on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network including a LAN or wide area network (WAN) (e.g., via the Internet using an Internet service provider) A connection to an external computer can be made.
Aspects of the present invention are described above with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products in accordance with embodiments of the present invention. It will be appreciated that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, may be implemented by computer program instructions. Such computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus that produces a machine, and instructions that execute via a processor of a computer or other programmable data processing apparatus may be stored in a computer- Or block diagrams provide means for implementing the functions / acts specified in the block or blocks.
These computer program instructions, which may direct a computer, other programmable data processing apparatus, or other device to function in a particular manner, may also be stored on a computer-readable medium so that the instructions stored on the computer- Or block diagrams, or instructions that implement the specified function / act in blocks or blocks.
The computer program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device such that a sequence of operation steps may be performed on the computer, other programmable apparatus, or other device to cause the computer or other programmable apparatus May cause the computer-implemented process to cause processes executing in the flowcharts and / or blocks to provide processes for implementing the functions / acts specified in the block or blocks.
The flowcharts and block diagrams in the figures illustrate the structure, functionality, and operation of possible implementations of systems, methods, and computer program products in accordance with various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of code that includes one or more executable instructions for implementing the specified logical function (s). It should be noted that, in some alternative implementations, the functions shown in the blocks may occur in an order different from the order shown in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in reverse order, depending on the functionality involved. Each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowchart illustrations, are implemented by special purpose hardware-based systems that perform specified functions or acts, or combinations of special purpose hardware and computer instructions .
The illustrative embodiments set forth herein are illustrative and various modifications are possible without departing from the spirit of the disclosure or the scope of the appended claims. For example, elements and / or characteristics of other illustrative embodiments may be inter-coupled and / or replaced with one another within the scope of the description and the appended claims.

Claims (21)

  1. CLAIMS 1. A method for evaluating a system state,
    Receiving user-provided information regarding operation of the system being evaluated;
    Constructing a dependency model of the system being evaluated based on the received user-provided information;
    Determining whether the received user-provided information is sufficient to construct a logical model of the system being evaluated;
    Constructing a logical model of the system being evaluated, and combining the logical model with the dependency model when the user-provided information is determined to be sufficient;
    Monitoring sensor data from one or more sensors installed in the system being evaluated;
    Applying the combined model to the sensor data when a combined model is available and applying the dependency model to the sensor data when the combined model is unavailable;
    Determining a set of one or more abnormal system components from application of the combined model / the dependency model to the sensor data; And
    Providing an evaluation of system conditions based on the determined set of one or more abnormal system components
    Lt; / RTI &gt;
    Wherein each of the steps is performed using one or more computer systems.
  2. The method according to claim 1,
    The user-provided information regarding the operation of the system being evaluated may be related to a fault dependency of one or more components of the system, or may be related to the expertise associated with the manner in which the one or more components of the system fail and an expert knowledge.
  3. The method according to claim 1,
    Wherein the user-provided information regarding the operation of the system being evaluated is encoded by a user or automatically in an Answer Set Programming (ASP) format based on user input.
  4. The method according to claim 1,
    Wherein the constructed dependency model or the combined model is represented in a response set programming (ASP) format.
  5. The method according to claim 1,
    Wherein the configured dependency model describes how faults are propagated only through the system being evaluated.
  6. The method according to claim 1,
    Wherein the configured logical model describes complex functional interdependencies between one or more components of the system being evaluated.
  7. The method according to claim 1,
    Wherein the step of determining whether the received user-provided information is sufficient to construct a logical model of the system under evaluation includes configuring the logical model, attempting to apply the configured logical model to the observed sensor data, Determining whether a meaningful result has been obtained.
  8. The method according to claim 1,
    Wherein combining the logical model with the dependency model is performed using an Answer Set Programming solver.
  9. The method according to claim 1,
    Wherein applying the combined model or dependency model to the sensor data is performed using a response set programming (ASP) solver.
  10. The method according to claim 1,
    Wherein providing an evaluation of system state based on a determined set of one or more abnormal system components comprises prioritizing minimal solutions.
  11. The method according to claim 1,
    Wherein providing an assessment of the system state based on the determined set of one or more abnormal system components comprises prioritizing solutions backed by a maximum of a plurality of sensor observations.
  12. The method according to claim 1,
    Wherein applying the combined model or the dependency model for the sensor data comprises using nonmonotonic reasoning.
  13. CLAIMS 1. A method for evaluating a system state,
    Receiving a dependency model of the system being evaluated and a logical model of the system being evaluated;
    Observing sensor data from one or more sensors installed in the system being evaluated;
    Coupling the logic model with the dependency model, and applying the combined model to the sensor data using a response set programming (ASP) solver;
    Determining a set of one or more abnormal system components from application of the combined model to the sensor data; And
    Providing an evaluation of system conditions based on the determined set of one or more abnormal system components
    Lt; / RTI &gt;
    Wherein each of the steps is performed using one or more computer systems.
  14. 14. The method of claim 13,
    Wherein providing an assessment of system state based on a determined set of one or more abnormal system components comprises prioritizing minimal solutions.
  15. 14. The method of claim 13,
    Wherein providing an assessment of system conditions based on a determined set of one or more abnormal system components comprises prioritizing solutions supported by a plurality of sensor observations.
  16. A processor; And
    A non-transitory, tangible computer system that implements a program of instructions executable by the processor to perform steps of a method for evaluating system state,
    The method comprising:
    Receiving user-provision information on operation of the system being evaluated;
    Constructing a dependency model of the system being evaluated based on the received user-provided information;
    Determining whether the received user-provided information is sufficient to construct a logical model of the system being evaluated;
    Constructing a logical model of the system being evaluated, and combining the logical model with the dependency model if the user-provided information is determined to be sufficient;
    Observing sensor data from one or more sensors installed in the system being evaluated;
    Applying the combined model to the sensor data when a combined model is available and applying the dependency model to the sensor data when the combined model is unavailable;
    Determining a set of one or more abnormal system components from application of the combined model / the dependency model to the sensor data; And
    Providing an evaluation of system conditions based on the determined set of one or more abnormal system components
    / RTI &gt;
  17. 17. The method of claim 16,
    Wherein the configured dependency model describes how faults are propagated only through the system being evaluated.
  18. 17. The method of claim 16,
    Wherein the configured logical model describes complex functional interdependencies between one or more components of the system being evaluated.
  19. 17. The method of claim 16,
    Wherein coupling the logic model with the dependency model is performed using a response set programming (ASP) solver.
  20. 17. The method of claim 16,
    Wherein applying the combined model or dependency model to the sensor data is performed using a response set programming (ASP) solver.
  21. 17. The method of claim 16,
    The step of providing an assessment of system conditions based on the determined set of one or more abnormal system components may include prioritizing the minimum solutions or prioritizing solutions supported by the plurality of sensor observations And a computer system.












KR1020157009632A 2012-09-17 2013-09-17 Logic based approach for system behavior diagnosis KR20150058343A (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US201261701822P true 2012-09-17 2012-09-17
US61/701,822 2012-09-17
PCT/US2013/060070 WO2014043667A1 (en) 2012-09-17 2013-09-17 Logic based approach for system behavior diagnosis

Publications (1)

Publication Number Publication Date
KR20150058343A true KR20150058343A (en) 2015-05-28

Family

ID=49304325

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020157009632A KR20150058343A (en) 2012-09-17 2013-09-17 Logic based approach for system behavior diagnosis

Country Status (5)

Country Link
EP (1) EP2895927A1 (en)
JP (1) JP2015534179A (en)
KR (1) KR20150058343A (en)
CN (1) CN104756028A (en)
WO (1) WO2014043667A1 (en)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9359554B2 (en) 2012-08-17 2016-06-07 Suncoke Technology And Development Llc Automatic draft control system for coke plants
US10047295B2 (en) 2012-12-28 2018-08-14 Suncoke Technology And Development Llc Non-perpendicular connections between coke oven uptakes and a hot common tunnel, and associated systems and methods
US10760002B2 (en) 2012-12-28 2020-09-01 Suncoke Technology And Development Llc Systems and methods for maintaining a hot car in a coke plant
US9476547B2 (en) 2012-12-28 2016-10-25 Suncoke Technology And Development Llc Exhaust flow modifier, duct intersection incorporating the same, and methods therefor
US9273250B2 (en) 2013-03-15 2016-03-01 Suncoke Technology And Development Llc. Methods and systems for improved quench tower design
DE102014208034A1 (en) * 2014-04-29 2015-10-29 Siemens Aktiengesellschaft Method for providing reliable sensor data
WO2016033524A1 (en) 2014-08-28 2016-03-03 Suncoke Technology And Development Llc Improved burn profiles for coke operations
CA2972887A1 (en) 2014-12-31 2016-07-07 Suncoke Technology And Development Llc Multi-modal beds of coking material
CA3026379A1 (en) * 2016-06-03 2017-12-07 John Francis Quanci Methods and systems for automatically generating a remedial action in an industrial facility
WO2020140081A1 (en) 2018-12-28 2020-07-02 Suncoke Technology And Development Llc Systems and methods for treating a surface of a coke plant
US11021655B2 (en) 2018-12-28 2021-06-01 Suncoke Technology And Development Llc Decarbonization of coke ovens and associated systems and methods
JP6600120B1 (en) * 2019-02-06 2019-10-30 オーウエル株式会社 Management system, machine learning apparatus and management method therefor

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7260501B2 (en) * 2004-04-21 2007-08-21 University Of Connecticut Intelligent model-based diagnostics for system monitoring, diagnosis and maintenance
CN101170447A (en) * 2007-11-22 2008-04-30 北京邮电大学 Service failure diagnosis system based on active probe and its method
FR2949161B1 (en) * 2009-08-14 2011-09-09 Thales Sa Device for system diagnosis
CN101819411B (en) * 2010-03-17 2011-06-15 燕山大学 GPU-based equipment fault early-warning and diagnosis method for improving weighted association rules
US20130073271A1 (en) * 2010-05-24 2013-03-21 Nec Corporation Static fault tree analysis system and method from system models
US8645019B2 (en) * 2010-12-09 2014-02-04 GM Global Technology Operations LLC Graph matching system for comparing and merging fault models

Also Published As

Publication number Publication date
CN104756028A (en) 2015-07-01
JP2015534179A (en) 2015-11-26
WO2014043667A1 (en) 2014-03-20
EP2895927A1 (en) 2015-07-22

Similar Documents

Publication Publication Date Title
KR20150058343A (en) Logic based approach for system behavior diagnosis
Guillén et al. A framework for effective management of condition based maintenance programs in the context of industrial development of E-Maintenance strategies
Brusoni et al. A spectrum of definitions for temporal model-based diagnosis
US20140237487A1 (en) Complex event processing for dynamic data
Venkatasubramanian Prognostic and diagnostic monitoring of complex systems for product lifecycle management: Challenges and opportunities
CA2387934C (en) A process for the monitoring and diagnostics of data from a remote asset
Angeli Online expert systems for fault diagnosis in technical processes
Nunez et al. An ontology-based model for prognostics and health management of machines
EP2541358B1 (en) Method, monitoring system and computer program product for monitoring the health of a monitored system utilizing an associative memory
Arranz et al. DADICC: Intelligent system for anomaly detection in a combined cycle gas turbine plant
Karray et al. PETRA: Process Evolution using a TRAce-based system on a maintenance platform
Nuñez et al. OntoProg: An ontology-based model for implementing Prognostics Health Management in mechanical machines
Baur et al. A review of prognostics and health management of machine tools
WO2018154558A1 (en) Methods and systems for problem-alert aggregation
Hess et al. The maintenance aware design environment: Development of an aerospace phm software tool
CN104011750A (en) Processing a technical system
Escobet et al. Fault diagnosis of dynamic systems
EP2447845A1 (en) Method, system, and computer program for automated diagnostic with description logic reasoning
US8359577B2 (en) Software health management testbed
Melani et al. Mapping SysML Diagrams Into Bayesian Networks: A Systems Engineering Approach for Fault Diagnosis
Sierla et al. Safety analysis of mechatronic product lines
US9274868B2 (en) Computerized method and system for automated system diagnosis detection
Werner-Stark et al. Knowledge-based diagnosis of process systems using procedure hazid information
Tagina A novel fault detection approach combining adaptive thresholding and fuzzy reasoning
US20140297578A1 (en) Processing a technical system

Legal Events

Date Code Title Description
WITN Withdrawal due to no request for examination