JP2015534179A - A logic-based approach for system behavior diagnosis - Google Patents

Abstract

Described herein is a method for evaluating system status, which includes receiving (S41) user-provided information related to the operation of the system under evaluation. Based on the received information, a dependency model of the above system is constructed (S43a / b). When it is determined that the above-mentioned user-provided information is sufficient for constructing a logical model (S42), the logical model of this system is constructed, and this is combined with the dependency model (S46). When sensor data from a sensor implemented in the system is monitored and the combined model is available, the combined model is applied to the sensor data, and the combined model is not available The dependency model is applied to the sensor data (S48). From the application of the combined model / dependence model to sensor data, a set of one or more abnormal system components is determined, and a system state is evaluated based on the determined set of abnormal system components.

Description

  The present invention relates to system behavior diagnosis, and more particularly to a logic-based approach for system behavior diagnosis.

CROSS REFERENCE TO RELATED SPECIFICATIONS The present invention is based on US Provisional Patent Specification No. 61 / 701,822, filed September 17, 2012, the entire contents of which are hereby incorporated by reference. To do.

Consideration of related technical fields Complex dynamic systems such as electromechanical devices, industrial facilities, and large-scale commercial buildings use a network of multiple sensors installed at various important points. A perspective on the operational status of the system is provided. By monitoring the function of this system, it is possible to observe various deviations from proper operation, and to perform repair actions such as maintenance, repairs and replacements in a timely manner, system uptime and reliability. Can be maximized.

  However, due to factors such as a huge set of failures, parameter drift, noise, sensor observability limits, etc., the failure can be accurately identified with sufficient time to address the problem. It is particularly difficult to diagnose.

  Thus, how to diagnose a system and predict a failure from sensor data that is far from ideal is a challenging and challenging subject in managing complex dynamic industrial assets.

Summary The system state assessment method of the present invention includes receiving user-supplied information related to system operation, and a dependency model for the system is constructed based on the received information. If the user-supplied information is sufficient to build the logical model, the logical model of the system is built and combined with the dependency model. When the combined model is available, the combined model is applied to the sensor data. When the combined model is not available, the dependent model is applied to the sensor data. Here, a set of abnormal system components is obtained from application of the combined model / dependency model to sensor data. The evaluation of the system state is obtained based on the set of abnormal system components.

  The above user-supplied information relating to the operation of the system under evaluation is expert knowledge of the fault dependency of one or more components of the system, or how the one or more components of the system fail Expert knowledge about can be included.

  The above-mentioned user-supplied information relating to the operation of the system under evaluation can be encoded in ASP (Answer Set Programming) formatting by the user or automatically based on user input.

  The constructed dependency model and / or the combined model can be expressed in ASP (Answer Set Programming) formalization.

  The above built dependency model can only describe how the fault propagates through the system under evaluation.

  The constructed logical model described above can describe complex functional interrelationships between one or more components of the system under evaluation.

  To determine whether the received user-provided information is sufficient to build the logical model of the system under evaluation, the logical model was built and this built logical model was monitored. Attempting to apply to sensor data and determining whether a meaningful result is obtained.

  The above combination of the logical model and the dependency model can be performed using an ASP (Answer Set Programming) solver.

  Application of the coupling model or dependency model to the sensor data can be performed by an ASP (Answer Set Programming) solver.

  Assessing the system state based on the determined set of one or more abnormal system components may include prioritizing the minimum solution.

  Assessing the system state based on the above determined set of one or more abnormal system components may include prioritizing the solution supported by the maximum number of sensors.

  Application of the combined or dependent model to the sensor data can include the use of non-monotonic logic.

  The present invention describes a method for evaluating system state, which includes receiving a dependency model of the system under evaluation and a logical model of the system under evaluation. Here, sensor data from one or more sensors implemented in the system under evaluation is monitored. The logical model and the dependency model are combined, and an ASP (Answer Set Programming) solver is used, and the combined model is applied to the sensor data. By applying the above combined model to the center data, a set of one or more abnormal system components is obtained. Further, an evaluation of the system state is obtained based on the determined set of one or more abnormal system components.

  Assessing the system state based on the determined set of one or more abnormal system components may include prioritizing the minimum solution.

  Assessing the system state based on the above determined set of one or more abnormal system components may include prioritizing the solution supported by the maximum number of sensors.

  The present invention further describes a computer system that implements the steps of a method for evaluating a system state by implementing a program comprising a processor and instructions executable by the processor. And a non-transitory tangible program storage medium readable by the computer system. In the above method, user provided information related to the operation of the system under evaluation is received. Here, the dependency model of the system under evaluation is constructed based on the received user-provided information. It is also determined whether the received user-provided information is sufficient to build a logical model of the system under evaluation. If it is determined that the user-provided information is sufficient, a logical model of the system under evaluation is constructed, and the logical model and the dependency model are combined. Sensor data from one or more sensors implemented in the system under evaluation is also monitored. When the combined model is available, the combined model is applied to the sensor data. When the combined model is not available, the dependent model is applied. From the application of the combined model / dependence model to sensor data, a set of one or more abnormal system components is determined. An assessment of the system state is obtained based on this determined set of one or more abnormal system components.

  The constructed dependency model can only describe how faults propagate through the system under evaluation.

  The constructed logical model can describe complex functional interrelationships between one or more components of the system under evaluation.

  The combination of the logical model and the dependency model can be executed using an ASP (Answer Set Programming) solver.

  Application of the coupling model or the dependency model to the sensor data can be executed by an ASP (Answer Set Programming) solver.

  The above evaluation of the system state based on the above determined set of one or more abnormal system components may include prioritizing the solution that is preferred by the minimum solution or supported by the maximum number of sensors. is there.

It is the schematic which shows WTP (Water Tank Problem) for demonstrating the Example of this invention. It is a figure explaining the simplified lubricating oil system which can apply the Example of this invention. 3 is a set of statements representing a dependency model based on the system of FIG. 2 in accordance with an embodiment of the present invention. 4 is a flowchart illustrating a hybrid approach for system diagnosis, in accordance with an embodiment of the present invention. FIG. 2A illustrates an overall architecture for system diagnosis and FIG. 2B illustrates a system architecture for monitoring and diagnosing the system, in accordance with an embodiment of the present invention. It is a figure which shows the example of the computer system which can implement | achieve said method, and the apparatus by embodiment of this invention.

  A more complete evaluation of the invention and many of the attendant aspects thereof will be better understood and readily obtained when considered in conjunction with the accompanying drawings, with reference to the following detailed description.

DETAILED DESCRIPTION OF THE DRAWINGS In the illustrative examples of the invention shown in the drawings, specific terminology is used for the sake of clarity. However, the present invention is not intended to be limited to the specific terminology so selected, and it is obvious that each specific element includes any technical equivalent that operates in a similar manner. is there.

  Some approaches to system diagnosis use computer learning to detect evidence of problems such as future failures from sensor data, but in another approach, expert knowledge of one or more human users Is used. Yet another approach combines aspects of computer learning with the use of expert knowledge. In an approach that uses expert knowledge to interpret sensor data, the above knowledge is encoded in a computer readable form, such as a logical representation, and the above system is operating normally or the system is malfunctioning. Which parts of the system are malfunctioning, what repair actions are recommended, and how much time remains to perform repair actions before a failure occurs. Used to help the diagnostic system seek.

  One approach to using expert knowledge and making a diagnosis based on sensor data is a fault-dependent model. This approach is based on the recognition that some components require other components to operate properly in order to operate properly. Since one fault can appear as multiple sensor anomaly readings, the above fault-dependent model is based on prior knowledge of what types of malfunctions tend to generate other sensor anomaly readings, Try to pinpoint the root cause of these abnormal readings.

  To help explain this diagnostic approach, consider WTP (Water Tank Problem). FIG. 1 is a schematic diagram illustrating the WTP. In this figure, there are two tanks, a left tank 10 and a right tank 11. One faucet 12 can be moved freely between each tank, so that both tanks can be filled with water. Each tank has a hole at the bottom for water leakage. The left tank 10 leaks water at a speed of v1, while the right tank 11 leaks water at a speed of v2. The faucet 12 fills both tanks at speed w. For simplicity, assume v1 = v2 = v and w> v. To move the faucet and switch tanks, a command called a “switch” can be used.

  The sensor x1 is a Boolean sensor that monitors the state of the left tank 10, whereas the sensor x2 is a Boolean sensor that monitors the state of the right tank 11. Sensors x1 and x2 record 1 when the level in the tank goes up and 0 when the level goes down.

  Here, it is assumed that the value of x1 is 1 and the value of x2 is 0 at time 1. This shows that the faucet 12 is filling the left tank 10. Assuming that the above switch command is generated between time 1 and time 2 and the values of x1 and x2 remain 1 and 0 respectively at time 2, the values of x1 and x2 are abnormal at this stage. It is thought that. This is because in this system, after the above switch, x1 is expected to be 0 and x2 is expected to be 1. In this scenario, the faucet 12 is stuck on the left tank 10 and is stuck. However, since no sensor for faucet 12 is provided, this problem cannot be observed directly and diagnosis is necessary.

  Non-monotonic logic can be used to check the state of x1 and x2 together. The fact that x2 is decreasing and not increasing may indicate that the left tank 11 has failed, for example due to leakage. However, when combined with the fact that x1 does not increase and decrease, it can be determined that the faucet 12 is malfunctioning. An example of non-monotonic logic is answer set programming (ASP) formalization. Embodiments of the present invention attempt to apply ASP to different monitoring and diagnostic systems to derive the cause of sensor anomalies where specific problems cannot be directly observed. Furthermore, ASP can be used as a unified language for integrating different inference approaches.

In embodiments of the present invention, two additional approaches can be used to infer diagnosis. The first of such approaches can be referred to as a fault dependence model. This approach uses the knowledge that one malfunction can cause another sensor to perform an anomaly reading, going back through a series of sensor anomaly readings to reach the actual cause of the defect. Applying to the WTP example described above, a fault in the faucet can lead to an abnormal condition in the left tank, starting from expert knowledge that this abnormal condition can be associated with an abnormal reading for x1. Similarly, a failure at the faucet can lead to an abnormal condition in the right tank, which can lead to an abnormal reading for x2. Therefore, this knowledge is faucet → tank 1 → x1
Faucet → Tank 2 → x2
It can be expressed as.

である。 The dependency model is that if x1 is observed to be abnormal, tank 1 and / or the faucet may be faulty, and similarly x2 is observed to be abnormal. Can be interpreted to mean that the tank 2 and / or the faucet may be faulty. The following dependency matrix can be used to represent this situation. That is,

It is.

  As can be seen, the only expert knowledge necessary to generate the above fault-dependent model is how the fault propagates between multiple components. Such knowledge can be automatically obtained from a system design document such as CAD / CAM. Other information such as the functional aspects of this system can be ignored. For these reasons, the above-described failure dependency model is easy to construct and can be used for diagnostic purposes, but this approach may have a relatively low resolution compared to other inference approaches. For this reason, for a given number of sensors, there is a possibility that the above fault dependence model cannot be pinpointed as close to the cause of the problem as another approach.

  Embodiments of the invention can also use another approach for diagnostic reasoning. This alternative approach can be referred to as a logical model approach. Here, complex functional interdependencies between system components can be expressed as logical expressions. This approach may require additional expert knowledge, but this allows higher diagnostic resolution to be achieved, which can be pinpointed closer to the cause of the problem for a given number of sensors. It can mean that you can point out.

This logical model approach can be applied to the WTP example above. However, to more easily explain the concept involved, instead of using the command “switch” to activate the faucet switching described above, the command “fill 1” means the value 1 to fill the left tank. Can be taken, whereas the value 0 can be taken to mean filling the right tank. In this notation approach, the sensor abnormality reading is represented by “ab (sensor name)”. Additionally, each command is associated with a state variable that represents the system state. For example, for the command filling 1, if the faucet is filling the tank 1, the state “filling 1” is true; otherwise, the state “filling 1” is false. Thereby, the expert knowledge of the above WTP example can be grasped by the following two rules, and the ASP model language can also be used here. That is,
inStatus (filling 1) ← value (filling 1, 1), not ab (faucet) (1)
not inStatus (filling 1) ← value (filling 1, 0), not ab (faucet) (2)
It is.

  For these ASP rules, the right side of the rule is interpreted as a logical product, which means that in order for the left side to hold, all conditions on the right side must also hold. Rule (1) states that if the value of command fill 1 is 1 (fill the left tank) and the faucet is not faulty, the system should be in a state where the left tank is filled. means. Rule (2) also means that if the command fill 1 is 0 (do not fill the left tank) and the faucet is not faulty, this system means that the left tank is not filled. .

Formulas can also be used to specify the relationship between sensor readings and state variables, for example
value (x1,0) ← not inStatus (filling 1), not ab (tank 1) (3)
value (x2, 1) ← not inStatus (filling 1), not ab (tank 2) (4)
It is.

  Here, rule (3) means that if the system is not in a state of filling tank 1 (left tank) and there is no failure in tank 1, an increase in x1 cannot be detected. Rule (4) similarly means that if the system is not in the state of filling tank 1 (left tank) and tank 2 is not faulty, a decrease in x2 should be detected.

If a failure is detected in both x1 and x2, the sensor reading is
value (fill 1, 0), value (x 1, 1), value (x 2, 0) (5)
It is.

  From this value (1,0 during filling) and rule (2) read by the sensor, it is possible to conclude ab (faucet) or not inStatus (1 during filling). From not inStatus (1 during filling) and rule (3), it can be inferred that either ab (tank 1) or value (x1, 0) is true. Since value (x1,0) is inconsistent with the sensor reading above, ab (tank 1) can be concluded. This gives two minimal explanations. That is, {ab (faucet)} and {ab (tank 1), ab (tank 2)}. That is, either the faucet is malfunctioning or the two tanks are malfunctioning. The consideration can be limited to the above minimal explanation. This is because if {ab (faucet)} can explain the above observation, the larger set {ab (faucet), ab (tank 1)} can also explain this. From these two minimal descriptions, we can find two signs (x1, x2) that support ab (faucet), whereas only one sign (x1) and ab that support ab (tank 1) Only one symptom is found to support (Tank 2). With the above priority setting here, the first minimum explanation {ab (faucet)} can be selected as the diagnosis. Because there are more signs that support each anomaly.

  What can be seen from the example described above is that the more complicated explanation, the logical model approach gives a more detailed explanation of possible causes of failure. While the above dependency model approach is simpler, it provides less detail about possible causes of failure.

  In an embodiment of the present invention, the above logic model approach and dependency model approach are combined using an ASP modeling language, which is simple when necessary and has high resolution when available. A hybrid model approach is obtained. If a plurality of possible solutions are obtained from this hybrid approach, the minimum solution is given priority according to the embodiment. For example, preference is given to the simplest explanation that can take into account the observed sensor readings. Furthermore, when there are multiple simple minimum solutions, the solution with the most evidence is given priority. For example, priority is given to the minimum solution with the largest number of sensor observation values.

  The ASP (Answer Set Programming) non-monotonic logic form can be used as a calculation framework. This is because this form uses non-monotonic logic and has sufficient functionality to handle dynamic domains. This approach can be incorporated into existing monitoring and diagnostic systems that use sensor data as described above.

  Here, an embodiment of the present invention will be described for a simplified lubricating oil system. However, this simplified lubricating oil system is provided as an exemplary system to which embodiments of the present invention can be applied, and the above embodiments of the present invention are not limited to any monitoring being performed. It is clear that it can be applied to the system.

  In some cases, it may be difficult or impossible to obtain a complete model of a complex system with all state space equations and transitions representing the intended behavior, which is the basis of a quantitative diagnostic approach. Correspondingly, embodiments of the present invention can only rely on the dependency model if the complete model of this complex system is not available or otherwise provided.

  FIG. 2 is a diagram illustrating a simplified oil lubrication system to which embodiments of the present invention can be applied. Here, three pumps “ACPMP1” 201, “ACPMP2” 202 and “DCPMP” 203 are connected to the lubricating oil reservoir 200. The two AC pumps 201 and 202 can constitute a redundant / back-up system, and the DC pump 203 can operate on a separate line. In the AC pipe line, a cooler 204, a filter 205, and a pressure control valve 206 are connected in order. Here, four command sensors, ie, pump1Dmd207, pump2Dmd208, dcPmpDmd209, and controlValve210 are provided. Four instruction sensors are provided. These indicating sensors include a psvac 211 that indicates the pressure in the reservoir 200, dpsw 212 and ps 213 that indicate whether or not oil is flowing through the two pipes, and a LOPS 214 that indicates the hydraulic pressure at the end portion. .

  A dependency model can be created from this figure. Because the dependency model simply needs information related to the path through which the anomaly propagates through the system, additional expert knowledge other than the expert knowledge obtained from the diagram shown here can be used to construct this dependency model. It is unnecessary. FIG. 3 is a series of statements representing a dependency model based on the system of FIG. 2, in accordance with an embodiment of the present invention. The dependency model shown in FIG. 3 can be obtained directly from the diagram of FIG.

  The dependency model shown in FIG. 3 shows a dependency chain for each object in the system shown in FIG. For example, as can be seen from the first row (31), sensor anomaly readings detected at lops (214) are: problems at lops (214), problems at control valve (206), problems at filter (205), This can be caused by a problem in the cooler (204), a problem in acpmp1 (201), or a problem in res (200). As can be seen from the second row (32), sensor anomaly readings detected at lops (214) are: problems at lops (214), problems at control valve (206), problems at filter (205), cooler This can be caused by a problem in (204), a problem in acpmp2 (202), or a problem in res (200). As can be seen from the third row (33), sensor anomaly readings detected at dpsw (212) are: problems at dpsw (212), problems at control valve (206), problems at filter (205), cooler This can be caused by a problem at (204), a problem at acpmp1 (201), or a problem at res (200). As can be seen from the fourth row (34), sensor anomaly readings detected at dpsw (212) are: problems at dpsw (212), problems at control valve (206), problems at filter (205), cooler This can be caused by a problem in (204), a problem in acpmp2 (202), or a problem in res (200). As can be seen from the fifth row (35), the sensor anomaly reading detected at lops (214) may be caused by a problem at lops (214), a problem at dcpmp (203), or a problem at res (200). . As can be seen from the sixth row (36), the sensor anomaly reading detected at ps (213) may be caused by a problem at ps (213), a problem at dcpmp (203) or a problem at res (200). As can be seen from the seventh row (37), the sensor anomaly reading detected in psvac (211) may be caused by a problem in psvac (211) or a problem in res (200).

This hierarchical relationship of sensor anomaly readings and possible causes is summarized in the dependency matrix shown below. In this dependency matrix, columns represent sensor anomaly readings, and rows represent possible causes. A value of “1” indicates that a sensor anomaly reading in the column may occur due to a failure or malfunction indicated in the row, whereas a value of “0” indicates that an anomaly reading in the column is in the row. It indicates that it cannot occur due to the indicated failure or malfunction.

  Thus, it can be seen from this dependency matrix that the example of a simplified lubricant system cannot be fully diagnosed using existing indicator sensors. For example, if both lops and dpsw are detected to have a failure, it may not be possible to distinguish which component has a failure based solely on the dependency information. In such cases, any one or more components may have a fault.

However, as will be shown below, when analyzed using the logical model approach described above, the same series of sensor data as described above provides an answer that can be further determined. According to this approach, it can be identified from the lubricating oil system shown in FIG. 2 that each sensor defines a system state variable. For example, if acPmp1 is not in a fault state, it can be seen that value (acPmp1Dmd, 1) = pumpRun, value (acPmp1Dmd, 0) = not pumpRun, that is, if Pump1Dmd supplies a value of 1, ACPMP1 operates. When Pump1Dmd supplies a value of 0, it can be seen that ACPMP1 is not operating. This information can be encoded using the following ASP rules: That is,
inStatus (pumpRun1) ← value (adPmp1Dmd, 1), not ab (acPmp1) (6)
not inStatus (pumpRun1) ← value (acPmp1Dmd, 0), not ab (acPmp1) (7)
As another example, the above-mentioned indicating sensor, that is, value (lops, 0) = lowPress, value (lops, 1) = not lowPress. This information can be encoded into the following ASP rules: That is,
value (lops, 1) ← not inStatus (lowPress) (8)
value (lops, 0) ← inStatus (lowPress) (9)
The relationship between different state variables can be encoded using the following constraints: That is,
← not inStatus (lowPress), inStatus (flow 1),
not inStatus (flow 2), not ab (control valve) (10)
It is.

  Here, the left side of the ASP rule is left blank, indicating that the right side of this rule is not valid. This constraint means that if there is a flow in line 1 and there is a flow in line 2 and there is no failure in the control value, the pressure at the end cannot be low.

  Consider a scenario where a failure in lops and dpsw is detected. The sensor reading value is value (acPmp1Dmd, 1), value (acPmp2Dmd, 0), value (dcPmpDmd, 0), value (dpsw, 0), value (ps, 1), value (lops, 0).

  It is inStatus (flow 1), not inStatus (flow 2), and not inStatus (lowPress) that can be concluded from the above expressions (6) to (9). As a result, it can be inferred from the rule (10) that ab (control valve) is true.

  From the above example, it can be seen how each of the two models can be applied to the example of the lubricating oil system. The dependency model approach described above is easy to create and reasoning is simple, but only provides a relatively low resolution. This can mean that for a given number of sensors, malfunctions cannot be narrowed down as when using the logical model approach. A higher resolution can be obtained by a logical model approach. This means that for a given number of sensors, malfunctions can be narrowed down to a smaller subset of possible problems. However, this logical model approach may require additional user input to build it. For example, more expert data may be needed to build a complete set of logical statements to understand the above system.

  In the embodiment of the present invention, the above-described dependency model approach is combined with the logical model approach. FIG. 4 is a flowchart illustrating a hybrid approach for system diagnosis in accordance with an embodiment of the present invention. First, user information is acquired (step S41). This user information can be expert knowledge about the system being monitored and can relate to a known path through which correct operation of the system and problems can be observed. This user information can be supplied, for example, via a user interface that prompts the user to input desired information. Obtaining this user information may include formatting the input supplied by the user into an unambiguous and convenient format.

  Next, it is determined whether or not the acquired user-supplied information is sufficient to construct a logical model (step S42). This determination can be made manually by asking the user or automatically by analyzing whether the information is sufficient. According to one embodiment of the present invention, a logical model can be built at any event, and whether the logical model being built is sufficient can provide meaningful results. It can be determined by whether or not. Alternatively, whether this logical model is sufficient can be evaluated by performing simulations, or the interdependencies of a set of logical statements can be verified and several different combinations of sensor values that can occur. Can be evaluated by making sure that can be explained by this model.

  If the acquired user-provided information is sufficient to build a logical model (Yes, step S42), a logical model can be generated from the available information (step S43). If the acquired user-provided information is not sufficient to build a logical model (No, Step S42), a dependency model can be generated from the available information (Step S44a). In addition, when the above-described logical model is constructed, the above-described dependency model can be further constructed (step S44b). If at any later time additional information about the system can be obtained from the user or otherwise learned and monitored by monitoring the operation of the system, the logical model described above is obtained. Or a logical model can be generated even if it was not previously generated due to lack of sufficient information.

  The dependency information can then be encoded using an ASP (Answer Set Programming) frame (step 45a / b). For example, for dependencies between system components, the following can be used: That is, connectTo (dcPmpDmd, res) can be used. For dependencies between components and indicators, the following can be used: That is, associate (dcPump, ps) can be used.

The transitive closure of a connection can be calculated by using the following ASP rule: That is,
tcConnectTo (C, C1) ← connectTo (C, C1)
(11)
tcConnectTo (C, C2) ← tcConnectTo (C, C1), tcConnectTo (C1, C2)
(12)
It is.

For each component C, if an indicator I is associated with C and another component C1 is in C's transitive closure, then I is also associated with C1 as follows: Ie
associate (C1, I) ← associate (C, I), tcConnectTo (C, C1)
(13)
It is.

  Once the dependency model is encoded with ASP rules, the two models can be combined and executed by an ASP solver (step S46). Even when the logical model is not configured, the above dependency model can still be executed by the above ASP solver (step S47).

  The ASP solver calculation can be a particularly efficient way to determine the cause of sensor anomaly readings or to diagnose problems that may otherwise occur.

  The ASP encoding of the above model rules can be described manually or automatically. For example, ASP knowledge can be hidden from the end user, and ASP encoding can be automatically generated using knowledge entered in a form familiar to the user. Visual modeling tools can be used to let the end user specify the following information: Components, commands, indicators and state variables, and relationships between commands and indicators and components, as well as dependencies between components, and state variables that use sensor readings and constraints, and / or Visual modeling tools can be used to specify information such as expert rules.

  Once the above logical model is generated, the above model can be used to analyze sensor data obtained from a network of multiple sensors implemented in the system, thereby maintaining and / or repairing work. Is determined or otherwise a diagnosis regarding the state of the system is made (step S48).

  According to an embodiment of the present invention, when the logical model and the dependency model are combined (step S46), the result of the dependency model can be used to improve the result of the logical model. Thus, the previous diagnostic effort performed using the dependency model can be carried over to the logical model approach.

  After the model (s) provide a diagnostic result that can include multiple possible causes for sensor outliers, the solution with the most minimal and supporting evidence can be prioritized. This is as described above (step S49). Setting preferences may include rejecting results that are not preferred and can occur, or otherwise setting the order of results according to this preference setting for display.

  According to the system model described above, the dependency model and the logical model can be automatically generated by the program. An ASP solver can be used as a diagnostic engine. FIG. 5A is a diagram illustrating the overall architecture for diagnosing a system according to an embodiment of the present invention.

  The sensor data 501 obtained from the above system can be supplied to the monitoring system 503 periodically or continuously, for example, every day, thereby identifying any abnormal behavior. This data can be validated 502 before monitoring. Data validation can be performed to ensure that the monitored data is meaningful.

  If abnormal data is found, the monitoring system 503 returns a warning and activates the diagnostic system with all sensor readings and the identified faulty sensor. Using this information and system model, the diagnostic engine 504 uses the inferences described in the previous paragraph to generate a series of possible explanations, resulting in component diagnostics 505.

  FIG. 5B is a schematic diagram illustrating an architecture for a monitoring and diagnostic system in accordance with an embodiment of the present invention. This architecture may be consistent with ISO 13374 (machine condition monitoring and diagnostics). This architecture may include an ISO 13374 layer for data acquisition 506, data manipulation 507, status detection 508, normality assessment 509, predictive assessment 510, and advice generation 511.

In an embodiment of the present invention, predictive evaluation can additionally be used. Inference about dynamics can be the basis for prediction and planning. Dynamicity can also play a role in effective diagnosis. For example, the above rules (1) and (2) can be modified into the following dynamic rules. That is,
inStatus (filling 1, T + 1) ← ¬inStatus (filling 1, T), value (switch, 1, T + 1), not ab (faucet, T + 1) (14)
¬inStatus (filling 1, T + 1) ← inStatus (filling 1, T), value (switch, 1, T), not ab (faucet, T + 1) (15)
It is.

The static relationship between indicator readings and state variables can be extended as well. For example, rules (3) and (4)
value (x1, 0, T) ← ¬inStatus (filling 1, T), not ab (tank 1, T) (16)
value (x2,1, T) ← ¬inStatus (1T during filling), not ab (tank 2, T) (17)
Replaced by

Negation ¬ and default negation are not distinguished here. This is because, unlike the static case, the general law of inertia must be specified explicitly. That is,
inStatus (S, T + 1) ← inStauts (S, T), not ¬inStatus (S, T + 1) (18)
¬inStatus (S, T + 1) ← ¬inStauts (S, T), not inStatus (S, T + 1) (19)
And F moves all state variables. This law shows that the system state does not change without a cause for change.

  Diagnostic reasoning is more sophisticated in the dynamic case. Consider a scenario where both x1 and x2 are detected to be faulty by the above monitoring system. The above sensor reading values are value (switch, 1, 0), value (x 1, 1, 0), value (x 1, 1, 1), value (x 2, 0, 0), value (x 2, 0, 1 ).

  A value having a time stamp 0 is a read value in the previous step, whereas a value having a type stamp 1 is a read value in the current state. From the rules for sensor reading value (x1,1,1), value (x2,0,1) and the corresponding inStatus (filling 1, T), {ab (tank 1,1), ab (tank 2, 1)} or inStatus (1,1 during filling) can be concluded. From value (x1,1,0), value (x2,0,0) and the same rule as above, {ab (tank 1,0), ab (tank 2,0)} or inStatus (filling 1,0) ) Can be concluded. It can be assumed that {ab (tank 1, 0), ab (tank 2, 0)} cannot be true because the power monitor does not report any errors in the previous state. . This results in inStatus (1,0 during filling). {ab (faucet, 1)} can be concluded from inStatus (filling 1,0), inStatus (filling 1,1), sensor reading value (switch, 1, 0) and rule (15) . The rest of the reasoning is similar to the approach described above.

  The above diagnostic system can make inferences about dynamics and, as a result, can provide forecasting and planning services. To accomplish this, embodiments of the present invention can extend the diagnostic framework to have the ability to infer about behavior and changes. For example, returning to the WTP discussed above, if the system asks what happens when given the command value (switch, 1) in the current state, the system will use the value ( x1,1,2) and value (x2,0,2) can be predicted. If knowledge about fixing the faucet is encoded and the system is asked to return itself to a normal state, a repair plan is generated.

Embodiments of the present invention can additionally utilize a higher level action language to make it easier for the user to encode knowledge about dynamics. For example, instead of writing rules (14), the user can encode using a more natural language approach. The rule (14) is automatically generated from there.
In the case of ¬inStatus (filling 1), value (switch, 1) causes inStatus (filling 1) (20)
It becomes.

  Also, embodiments of the present invention can enhance the system with ontology knowledge to increase diagnostic accuracy. For example, consider an example of a lubricant system. Rather than describing failures uniformly in terms of component anomalies, embodiments of the present invention utilize the ontology that sensor anomaly readings can represent general or functional failures, and , And their relationship can be specified.

A general failure can correspond to an overall failure of a component, while a functional failure can only affect its function. With the aid of the above ontology, the user can specify that the low pressure at the termination is related to the function of the control valve. That is,
← not inStatus (low pressure), inStatus (flow 1), not inStatus (flow 2), not functionalFault (control valve) (21)
It is.

If both a general failure and a functional failure can explain the above observation when a failure occurs, it can be assumed that a functional failure has occurred rather than a general failure. As a result, in embodiments of the present invention, a higher priority is given to functional impairment when calculating the minimum diagnosis. This can be described by the following ASP rule. That is,
#minimize {functionalFault (C): components (C) @ 1} (22)
#minimize {generalFault (C): components (C) @ 2} (23)
It is.

  Using the above ontology and the above rules, in the scenario discussed above, the system can conclude {functionalFault}.

  In embodiments of the invention, the diagnostic system can be extended by adding an inquiry interface to the ontology. Such an interface allows the user to better encode that knowledge and use it to enhance the diagnosis of the system.

  As described above, in the embodiment of the present invention, the minimum diagnosis is calculated in order to give priority to the minimum solution. In embodiments of the present invention, metaprogramming techniques can be used, which reduces the computation of a minimal diagnostic subset to the computation of a set of responses of another program. Alternatively, embodiments of the present invention can extend this approach so that it covers any program under the stable model semantics described above.

  One way to account for minimal diagnosis is to refer to a circumscription. This approach can be extended to the diagnostic area described above.

  The approach described above for automated monitoring and diagnostic systems can be used to reduce the time and effort required for asset management and optimize the maintenance cycle to be profitable. Due to the complexity of diagnostic work, reasoning, for example, non-monotonic logic techniques can be used. In an embodiment of the present invention, non-monotonic logic formalization of ASP is used for industrial system diagnosis. In this case, the ASP solver can be used to solve minimal diagnostic problems in a particular field.

  FIG. 6 shows an example of a computer system capable of implementing the method and system of the present invention. This system and method of the present invention can be implemented in the form of a software application running on a computer system such as a mainframe, personal computer (PC), handheld computer, server, etc. The software application can be stored on a recording medium that is locally accessible by the computer system described above, and the software application can be via a wired or wireless connection to a network such as a local area network or the Internet. Is accessible.

  The 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 1010, a display unit 1011 and a local area network. A (LAN) data transmission controller 1005, a LAN interface 1006, a network controller 1003, an internal bus 1002, and one or more input devices 1009 such as a keyboard, a mouse, etc. may be included. As shown, the system 1000 can be connected to a data storage device 1008 such as a hard disk via a link 1007.

  As will be apparent to those skilled in the art, aspects of the present invention can be implemented as a system, method or computer program product. Accordingly, aspects of the present invention may be implemented entirely in hardware, fully software (including firmware, resident software, microcode, etc.), or a combination of software and hardware aspects. These can all take the form and these can all be generally referred to in the present invention as “circuits”, “modules” or “systems”. Further, aspects of the present invention may take the form of a computer program product implemented on one or more computer readable media that implements computer readable program code.

  Any combination of one or more computer readable media may be utilized. The computer readable medium can be a computer readable signal medium or a computer readable storage medium. The computer readable storage medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus or device, or any suitable combination thereof. Not. More specific examples of the above-described computer readable storage media (but not an exhaustive list) may include: Electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), An optical fiber, portable compact disk read only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof may be included. In this specification, a computer-readable storage medium may be any tangible medium that contains or stores a program used by or associated with an instruction execution system, apparatus or device.

  A computer readable signal medium may include a data signal with which computer readable program code is implemented and propagated, for example, as part of a baseband or carrier wave. Such propagated signals can take any of a wide variety of forms. This includes, but is not limited to, electromagnetic, optical, and any suitable combination thereof. The computer readable signal medium is not a computer readable storage medium and is any computer readable medium that can communicate, propagate, or transmit a program used by or associated with an instruction execution system, apparatus, or device. be able to.

  Program code embodied on a computer readable medium can be transmitted using any suitable medium, including wire, fiber optic cable, RF, etc., or any suitable combination thereof. However, it is not limited to this.

  Computer program code for performing operations on aspects of the present invention includes object oriented programming languages such as Java, Smalltalk, C ++ or the like, and "C" programming languages or similar programming languages. Can be written in any combination of one or more programming languages, including conventional procedural programming languages such as The above program code may be executed entirely on the user's computer as a stand-alone software package, partially executed on the user's computer, partially executed on the user's computer and partially on the remote computer Or run entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer via any number of types of networks including a local area network (LAN) or a wide area network (WAN), or externally. A connection can be established to a computer (eg, via the Internet using an Internet service provider).

  Aspects of the present invention are illustrated herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products described in embodiments of the invention. It will be appreciated that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions are supplied to a general purpose computer, an application specific computer or another programmable data processing device to configure the machine and executed via the processor of the above computer or another programmable data processing device. These instructions may form means for implementing the functions / actions shown in one or more blocks of the flowcharts and / or block diagrams above.

  These computer program instructions may also be stored on a computer readable medium, such that the computer readable medium instructs a computer, another programmable data processing device, or another device to perform a special function. Instructions, whereby instructions stored on the computer-readable medium constitute a manufacturer's product that includes instructions that implement the functions / actions shown in one or more of the flowcharts and / or block diagrams above It is also possible to do.

  The above computer program instructions are loaded into a computer, another programmable data processing apparatus or device, and a series of calculation steps are executed by the above computer, another programmable data processing apparatus or device, and realized in the computer. Processes are formed, whereby the functions / actions shown in one or more blocks of the flowcharts and / or block diagrams described above are implemented by instructions executed on the computer or another programmable device. It is also possible to provide a process for doing so.

  The flowcharts and block diagrams in the above figures illustrate the architecture, functionality, and operation of possible implementations of multiple systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram above may represent a module, segment, or portion of code that includes one or more executable instructions for implementing a specified logical function. Note also that, depending on alternative implementations, the functions shown in the above blocks may appear in a different order than shown in the figure. For example, two blocks shown in succession may actually be executed substantially simultaneously, or multiple blocks may be executed in reverse order depending on the function required. Each block of the block diagrams and / or flowcharts above, and combinations of blocks of the block diagrams and / or flowcharts, are either by application-specific hardware-based systems that perform the specified functions or actions described above, or Note that it can be implemented by a combination of application specific hardware and computer instructions.

  The embodiments shown herein are for illustrative purposes, and many changes can be made without departing from the spirit of the disclosure or the scope of the appended claims. For example, elements and / or features of different embodiments may be combined with each other and / or replaced with each other within the scope of this disclosure and the appended claims.

Claims (21)

In a method for assessing system state,
The method
Receiving user-provided information related to the operation of the system under evaluation;
Building a dependency model of the system under evaluation based on the received user-provided information;
Determining whether the received user-provided information is sufficient to build a logical model of the system under evaluation;
If it is determined that the user-provided information is sufficient, constructing a logical model of the system under evaluation and combining the logical model and the dependency model;
Monitoring sensor data from one or more sensors implemented in the system under evaluation;
Applying the combined model to the sensor data if the combined model is available, and applying the dependency model to the sensor data if the combined model is not available;
Determining a set of one or more abnormal system components from the application of the combined model / dependence model to the sensor data;
Evaluating a system state based on the determined set of one or more abnormal system components,
Each said step is performed using one or more computer systems.
A method for assessing system state, characterized in that The method of claim 1, wherein
The user-provided information related to the operation of the system under evaluation includes expert knowledge about fault dependencies of one or more components of the system, or about how the one or more components of the system failed Contains expert knowledge of the
A method characterized by that. The method of claim 1, wherein
The user-provided information related to the operation of the system under evaluation is encoded in ASP (Answer Set Programming) formatting, either by the user or automatically based on user input.
A method characterized by that. The method of claim 1, wherein
The constructed dependency model or the combined model is expressed in ASP (Answer Set Programming) formalization.
A method characterized by that. The method of claim 1, wherein
The constructed dependency model only describes how faults propagate through the system under evaluation.
A method characterized by that. The method of claim 1, wherein
The constructed logical model describes complex functional interrelationships between one or more components of the system under evaluation;
A method characterized by that. The method of claim 1, wherein
To determine whether the received user-provided information is sufficient to construct the logical model of the system under evaluation, constructing the logical model; and Including attempting to apply to the monitored sensor data and determining whether a meaningful result is obtained,
A method characterized by that. The method of claim 1, wherein
Using an ASP (Answer Set Programming) solver to perform the combination of the logical model and the dependency model;
A method characterized by that. The method of claim 1, wherein
Applying the combined model or the dependency model to the sensor data by an ASP (Answer Set Programming) solver;
A method characterized by that. The method of claim 1, wherein
The evaluation of the system state based on the determined set of one or more abnormal system components includes prioritizing a minimum solution.
A method characterized by that. The method of claim 1, wherein
The step of evaluating the system state based on the determined set of one or more abnormal system components includes prioritizing a solution supported by a maximum number of sensor observations.
A method characterized by that. The method of claim 1, wherein
Application of the combined model or the dependency model to the sensor data includes the use of non-monotonic logic.
A method characterized by that. In a method for assessing system state,
Receiving a dependency model of the system under evaluation and a logical model of the system under evaluation;
Monitoring sensor data from one or more sensors implemented in the system under evaluation;
Combining the logical model and the dependency model and applying the combined model to the sensor data using an ASP (Answer Set Programming) solver;
Determining a set of one or more abnormal system components by applying the combined model to the center data;
Evaluating a system state based on the determined set of one or more abnormal system components;
Performing each said step using one or more computer systems;
A method characterized by that. The method of claim 13, wherein
Evaluating the system state based on the determined set of one or more abnormal system components includes prioritizing a minimum solution;
A method characterized by that. The method of claim 13, wherein
Evaluating the system state based on the determined set of one or more abnormal system components includes prioritizing a solution supported by a maximum number of sensor observations;
A method characterized by that. A computer system,
The computer system includes
A processor;
A non-transitory tangible program storage medium readable by the computer system for executing the steps of the method for evaluating a system state by implementing a program comprising instructions executable by the processor. In a computer system,
The method includes:
Receiving user-provided information related to the operation of the system under evaluation;
Building a dependency model of the system under evaluation based on the received user-provided information;
Determining whether the received user-provided information is sufficient to build a logical model of the system under evaluation;
If it is determined that the user-provided information is sufficient, constructing a logical model of the system under evaluation and combining the logical model and the dependency model;
Monitoring sensor data from one or more sensors implemented in the system under evaluation;
Applying the combined model to the sensor data if the combined model is available, and applying the dependency model if the combined model is not available;
Determining a set of one or more abnormal system components from the application of the combined model / dependence model to the sensor data;
Evaluating a system state based on the determined set of one or more abnormal system components;
A computer system characterized by that. The computer system of claim 16, wherein
The constructed dependency model only describes how faults propagate through the system under evaluation.
A computer system characterized by that. The computer system of claim 16, wherein
The constructed logical model describes complex functional interrelationships between one or more components of the system under evaluation;
A computer system characterized by that. The computer system of claim 16, wherein
The combination of the logical model and the dependency model is performed using an ASP (Answer Set Programming) solver.
A computer system characterized by that. The computer system of claim 16, wherein
Application of the combined model or the dependency model to the sensor data is performed by an ASP (Answer Set Programming) solver.
A computer system characterized by that. The computer system of claim 16, wherein
The assessment of system state based on the determined set of one or more anomalous system components includes prioritizing a minimum solution or a solution supported by a maximum number of sensor observations.
A computer system characterized by that.

Images