EP2895927A1

EP2895927A1 - Logic based approach for system behavior diagnosis

Info

Publication number: EP2895927A1
Application number: EP13773462.0A
Authority: EP
Inventors: Yunsong MENG; Dan G. Tecuci
Original assignee: Siemens Corp
Current assignee: Siemens Corp
Priority date: 2012-09-17
Filing date: 2013-09-17
Publication date: 2015-07-22
Also published as: KR20150058343A; CN104756028A; JP2015534179A; WO2014043667A1

Abstract

A method for assessing system status includes receiving user-provided information pertaining to operation of a system (S41). A dependency model of the system is constructed based on the received information (S43a/b). A logical model of the system is constructed (S43) and combined with the dependency model (S46) when it is determined that the user-provided information is sufficient to construct the logical model (S42). Sensor data from sensors installed within the system is monitored, the combined 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 not available (S48). A set of abnormal system components is determined from the application of the combined model/dependency model to the sensor data and an assessment of system status is determined based on the set of abnormal system components

Description

LOGIC BASED APPROACH FOR SYSTEM BEHAVIOR DIAGNOSIS CROSS-REFERENCE TO RELATED APPLICATION

The present application is based on provisional application Serial No.

61/701,822 filed September 17, 2012, the entire contents of which are herein incorporated by reference. TECHNICAL FIELD

The present disclosure relates to system behavior diagnosis and, more specifically, to a logic-based approach for system behavior diagnosis. DISCUSSION OF THE RELATED ART

Complex dynamic systems such as electromechanical machinery, industrial facilities, and large-scale commercial buildings often employ networks of sensors installed at various key locations to provide insight into the state of operation of the system. By monitoring the function of the system, deviations from proper operation may be observed and remedial action such as maintenance, repairs, and replacements may be performed in a timely fashion so as to maximize uptime and reliability of the system.

However, due to such factors as the vast set of possible failures, parameter drift, noise, limited sensor observability, etc. may make accurately diagnosing a fault, with sufficient time to address the issue, particularly difficult. How to diagnose a system and predict failure from less-than-ideal sensor data therefore becomes a challenging objective in the management of complex, dynamic industrial assets. SUMMARY

A method for assessing system status includes receiving user-provided information pertaining to operation of a system. A dependency model of the system is constructed based on the received information. A logical model of the system is constructed and combined with the dependency model when it is determined that the user-provided information is sufficient to construct the logical model. Sensor data from sensors installed within the system is monitored. The combined 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 not available. A set of abnormal system components is determined from the application of the combined model/dependency model to the sensor data. An assessment of system status is determined based on the set of abnormal system components.

The user-provided information pertaining to operation of a system under assessment may include expert knowledge relating to fault dependency of one or more components of the system or relating to a manner in which the one or more components of the system fail.

The user-provided information pertaining to operation of a system under assessment may be encoded in Answer Set Programming (ASP) formalism either by the user or automatically based on user-input.

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

The constructed dependency model might only describe how failures propagate through the system under assessment.

The constructed logical model may describe complex functional

interdependencies between one or more components of the system under assessment.

Determining whether the received user-provided information is sufficient to construct the logical model of the system under assessment may include constructing the logical model and attempting to apply the constructed logical model to the monitored sensor data and determining whether a meaningful result is obtained.

The combining of the logical model and the dependency model may be performed using an Answer Set Programming (ASP) solver.

Applying the combined model or the dependency model to the sensor data may be performed by an Answer Set Programming (ASP) solver.

Providing the assessment of system status based on the determined set of one or more abnormal system components may include prioritizing minimal solutions.

Providing the assessment of system status based on the determined set of one or more abnormal system components may include prioritizing solutions supported by a greatest number of sensors.

Application of the combined model and/or the dependency model to the sensor data may include using nonmonotonic reasoning. A method for assessing system status includes receiving a dependency model of a system under assessment and a logical model of the system under assessment. Sensor data is monitored from one or more sensors installed within the system under assessment. The logical model is combined with the dependency model and the combined model is applied to the sensor data using an Answer Set Programming (ASP) solver. A set of one or more abnormal system components is determined from the application of the combined model to the sensor data. An assessment of system status is provided based on the determined set of one or more abnormal system components.

A computer system includes a processor and a non-transitory, tangible, program storage medium, readable by the computer system, embodying a program of instructions executable by the processor to perform method steps for assessing system status. The method includes receiving user-provided information pertaining to operation of a system under assessment. A dependency model of the system under assessment is constructed based on the received user-provided information. It is determined whether the received user-provided information is sufficient to construct a logical model of the system under assessment. A logical model of the system under assessment is constructed and the logical model is combined with the dependency model when it is determined that the user-provided information is sufficient. Sensor data from one or more sensors installed within the system under assessment is monitored. The combined 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 not available. A set of one or more abnormal system components is determined from the application of the combined model/dependency model to the sensor data. An assessment of system status is provided based on the determined set of one or more abnormal system components.

The constructed dependency model might only describe how failures propagate through the system under assessment. The constructed logical model may describe complex functional

The applying of the combined model or the dependency model to the sensor data may be performed by an Answer Set Programming (ASP) solver.

Providing the assessment of system status based on the determined set of one or more abnormal system components may include prioritizing minimal solutions or prioritizing solutions supported by a greatest number of sensors. BRIEF DESCRIPTION OF THE DRAWINGS

A more complete appreciation of the present disclosure and many of the attendant aspects thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:

FIG. 1 is a schematic diagram illustrating a Water Tank Problem (WTP) for explaining exemplary embodiments of the present invention;

FIG. 2 is a diagram illustrating simplified oil lubricating system upon which exemplary embodiments of the present invention may be applied to;

FIG. 3 is a set of statements representing a dependency model based on the system of FIG. 2 in accordance with exemplary embodiments of the present invention;

FIG. 4 is a flow chart illustrating a hybrid approach for system diagnosis in accordance with exemplary embodiments of the present invention;

FIG. 5A is a diagram illustrating an overall architecture for system diagnosis in accordance with exemplary embodiments of the present invention;

FIG. 5B is a schematic diagram illustrating an architecture for the monitoring and diagnosis system in accordance with exemplary embodiments of the present invention; and

FIG. 6 shows an example of a computer system capable of implementing the method and apparatus according to embodiments of the present disclosure. DETAILED DESCRIPTION OF THE DRAWINGS

In describing exemplary embodiments of the present disclosure illustrated in the drawings, specific terminology is employed for sake of clarity. However, the present disclosure is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents, which operate in a similar manner.

While some approaches for system diagnosis involve the use of computer learning to detect evidence of problems such as future failures from sensor data, other approaches utilize the expert knowledge of one or more human users. Still other approaches may combine aspects of computer learning with use of expert knowledge. In approaches that use expert knowledge to interpret sensor data, this knowledge may be encoded into computer-readable form such as logical expressions and may then be used to help a computerized diagnosis system determine such things as when the system is operating normally, when the system is malfunctioning, what part of the system is malfunctioning, what remedial action is advisable, and how much time is left to perform the remedial action before failure occurs.

One approach for performing diagnosis based on sensor data, utilizing expert knowledge, is the fault dependency model. This approach is based on the realization that some components require the proper operation of other components in order to operate properly themselves. As single failure may present as multiple abnormal sensor readings, the fault dependency model attempts to pinpoint the root cause of the abnormal readings based on a prior knowledge of what sorts of malfunctions are likely to cause other abnormal sensor readings.

To help illustrate this diagnostic approach, a Water Tank Problem (WTP) will be discussed. FIG. 1 is a schematic diagram illustrating the WTP. Here there are two tanks, a left tank 10 and a right tank 11. A single tap 12 is free to move between each tank so as to fill both tanks with water. Each tank has a hole at the bottom that loses water. The left tank 10 loses water at a rate of v1 while the right tank 11 loses water at a rate of v2. The tap 12 fills either tank at a rate w. For simplicity, it may be assumed that v1=v2=v and w>v. A command called“switch” may be used to move the tap to change tanks.

Sensor x1 is a Boolean sensor monitoring the state of the left tank 10 while sensor x2 is a Boolean sensor monitoring the state of the right tank 11. Sensors x1 and x2 register a 1 when the water level in the tank is increasing and they register a 0 when the water level is decreasing.

Now assuming at time 1 the value of x1 is 1 and the value of x2 is 0. This would indicate that the tap 12 is filling the left tank 10. Assuming the switch command is issued between time 1 and time 2, and at time 2, the values of x1 and x2 are still 1 and 0, respectively, the values of x1 and x2 are now considered to be abnormal as the system would be expected to have x1 at 0 and x2 at 1 after the switch. In this scenario the tap 12 has become stuck over the left tank 10. However, as there is no sensor for the tap 12, this problem cannot be directly observed and thus a diagnosis is needed.

Nonmonotonic reasoning may be used to examine 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 a leak. However, when combined with the fact that x1 is increasing and not decreasing, it may be determined that it is the tap 12 that is malfunctioning. One example of nonmonotonic reasoning is the Answer Set Programming (ASP) formalism. Exemplary embodiments seek to apply ASP to various monitoring and diagnostic systems to deduce a cause of sensor abnormalities where the particular problem is not directly observable. Moreover, ASP may be used as a unifying language for integrating other reasoning approaches.

Exemplary embodiments of the present invention may utilize two additional approaches for reasoning diagnosis. The first such approach may be called the fault dependency model. In this approach, the understanding that a single malfunction can cause other sensors to read abnormally is used to trace back a sequence of abnormal sensor readings to an actual cause of failure. When applied to the WTP example described above, we start with the expert understanding that a failure in the tap may lead to an abnormal state of the left tank, which may lead to an abnormal reading for x1. Similarly, a failure in the tap may lead to an abnormal state of the right tank, which may lead to an abnormal reading for x2. This knowledge may be expressed accordingly:

Tap→ Tank 1→ x1

Tap→ Tank 2→ x2

This dependency model may be interpreted to mean that when x1 is observed to be abnormal, then tank 1 and/or the tap could be faulty and similarly, when x2 is observed to be abnormal, then tank 2 and/or the tap could be faulty. The following dependency matrix may be used to describe this situation:

As can be seen, in order to generate the fault dependency model, the only expert knowledge required is how faults propagate between components. Such knowledge can be automatically obtained from system design documents such as CAD/CAM. Other information, such as the functional perspective of the system, may be ignored. For this reason, the fault dependency model may be simple to construct and use for diagnostic purposes, however, this approach may have relatively low resolution compared to other reasoning approaches. Thus, for a given number of sensors, the fault dependency model might not be able to pinpoint the exact cause of the problem as narrowly as other approaches.

Exemplary embodiments of the present invention may also use another approach for diagnostic reasoning. This other approach may be referred to as the logical models approach. Here, complex functional interdependencies between system components may be expressed as logical formulas. While this approach may require additional expert knowledge, a higher diagnostic resolution may be achieved, which may mean that for a given number of sensors, a cause of the problem may be more narrowly pinpointed.

The logical models approach may be applied to the WTP example. However, for the purposes of more easily illustrating the pertinent concepts, instead of using a “switch” command to invoke the tap switch, the command“fill1” with a value of 1 may be taken to mean that the left tank is to be filled, while a value of 0 may be taken to mean that the right tank is to be filled. Also, in the approach of this notation, an abnormal sensor reading is expressed as“ab(<sensor-name>)”. Additionally, each command is associated with a state variable that describes the system state. For example, for the command fill1, the state“filling1” will be true if the tap is filling tank 1 and the state“filling1” will be false otherwise. Thus, the expert knowledge of the WTP example may be captured in the following two rules, which may also utilize the modeling language of ASP: inStatus(filling1)← value(fill1,1), not ab(tap) (1) not inStatus(filling1)← value(fill1,0), not ab(tap) (2) For these ASP rules, the right-hand side of the rule is to be interpreted as conjunctions, meaning that for the left hand side to hold, all conditions on the right should hold as well. Here rule (1) says that if the value of the command fill1 is 1 (to fill left tank) and the tap is not in a faulty condition, then the system should be in a state that the left tank is being filled. Rule (2) holds similarly that if the value of the command fill1 is 0 (not to fill the left tank) and the tap is not in a faulty condition, then the system should be in a state that the left tank is not being filled.

Logical equations may also be used to specify the relationships between sensor readings and the state variables, for example:

value(x1,0)← not inStatus(filling1), not ab(tank1) (3) value(x2,1)← not inStatus(filling1), not ab(tank2) (4) Here rule (3) says that if the system is not in the state of filling tank1 (left tank) and tank1 is not faulty, then x1 should not detect an increase. Rule (4) similarly holds that if the system is not in the state of filling tank1 (left tank) and tank2 is not faulty, then x2 should detect an increase.

Where both x1 and x2 are detected to be faulty, the sensor readings are:

value(fill1,0), value(x1,1), value (x2,0) (5) From the sensor reading value(filling1,0) and rule (2), it may be concluded that either ab(tap) or not inStatus(filling1). From not inStatus(filling1) and rule (3) it may be inferred that either ab(tank1) or value(x1,0) are true. Since value(x1,0) conflicts with the sensor reading, it may be concluded that ab(tank1). Similarly, it may be concluded that ab(tank2). From this, there are two minimal explanations: {ab(tap)} and {ab(tank1), ab(tank2)}. Which is to say, either the tap is malfunctioning or both tanks are malfunctioning. Consideration may be limited to the minimal explanations because if {ab(tap)} can explain the observation, then a larger set {ab(tap), ab(tank1)} can also explain it. From the two minimal explanations, two symptoms (x1, x2) supporting ab(tap) may be found while only one symptom (x1) supporting ab(tank1) and one supporting ab(tank2) may be found. The preference here may be to choose the first minimal explanation {ab(tap)} as the diagnosis since there are more symptoms supporting each abnormality.

From the examples described above, it may be seen that the logical models approach, while being more complex, may provide a more detailed explanation as to the cause of a potential failure. The dependency models approach is simpler but provides less detail as to the cause of a potential failure.

Exemplary embodiments of the present invention combine the logical models approach with the dependency models approach, using the modeling language of ASP, to provide a hybrid modeling approach that can be both simple, where needed, and provide high resolution, where available. Where multiple potential solutions result from this hybrid approach, exemplary embodiments give preference to those solutions that are minimal, for example, preference is given to the simplest possible explanations that can account for the observed sensor readings. Moreover, where there are multiple simples minimal solutions, preference is given to those solutions with the greatest amount of supporting evidence, for example, the minimal solution with the greatest number of supporting sensor observations.

The nonmonotonic formalism of Answer Set Programming (ASP) may be used as the computational framework as this formalism utilizes nonmonotonic reasoning and is well equipped to deal with dynamic domains. This approach may be integrated with existing monitoring and diagnosis systems that use such sensor data.

Exemplary embodiments of the present invention are described herein with respect to a simplified lubricating oil system. However, the simplified lubricating oil system is offered as an example system to which exemplary embodiments of the present invention may be applied, and it is to be understood that exemplary embodiments of the present invention may be applied to any system being monitored.

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 behaviors, which are the basis of quantitative diagnosis approaches.

Exemplary embodiments of the present invention may accordingly rely solely on dependency models where a complete model of the complex system is not available or has otherwise not been provided.

FIG. 2 is a diagram illustrating simplified oil lubricating system upon which exemplary embodiments of the present invention may be applied to. Three pumps “ACPMP1” 201,“ACPMP2” 202, and“DCPMP” 203 are connected to the 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. On the AC line, a cooler 204, a filter 205 and a pressure regulator valve 206 are connected in sequence. There are four command sensors: pump1Dmd 207, pump2Dmd 208, dcPmpDmd 209 and controlValve 210. Four indicator sensors are provided. They include: psvac 211, which indicates the pressure in the reservoir 200, dpsw 212 and ps 213, which indicate whether oil flows in the two lines, and LOPS 214, which indicates the oil pressure at the terminal.

From this diagram, a dependency model may be created. As the dependency model merely required information pertaining to the way in which an abnormality propagates through the system, no additional expert knowledge, other than what is captured from the illustrated diagram, is required to establish the dependency model. FIG. 3 is a set of statements representing a dependency model based on the system of FIG. 2 in accordance with exemplary embodiments of the present invention. The illustrated dependency model of FIG. 3 can be obtained directly from the diagram of FIG. 2.

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

This hierarchical relationship of abnormal sensor readings and possible causes is summarized in the dependency matrix provided below. In this dependency matrix, the columns represent the abnormal sensor readings and the rows represent the possible causes. A value of“1” indicates that the abnormal sensor reading in the column may be caused by a failure or other malfunction in the row while a value of “0” indicates that the abnormal sensor reading in the column may not be cause by a failure or malfunction in the row:

It may therefore be seen from this dependency matrix that the simplified lubricating oil system example is not fully diagnosable using the existing indicator sensors. For example, if both lops and dpsw are detected to be faulty, it may not be possible to distinguish which component is faulty based on dependency information alone. In such a case, any one or more components could be faulty.

However, as will be shown below, the same set of sensor data, if analyzed using the logical model approach may provide a more insightful answer. According to this approach, we can identify from the lubricating oil system illustrated in FIG. 2 that each sensor defines a system state variable. For example, when acPmp1 is not in faulty condition, we know that: value(acPmp1Dmd,1) = pumpRun,

value(acPmp1Dmd,0) = not pumpRun, which is to say, we know ACPMP1 is running when Pump1Dmd provides a value of 1 and we know ACPMP1 is not running when Pump1Dmd provides a value of 0. This information may 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: value(lops,0) = lowPress, value(lops,1) = not lowPress. This above information may be encoded in the following ASP rules:

value(lops,1) m not inStatus(lowPress) (8) value(lops,0)← inStatus(lowPress) (9) The relationship between different state variables can be encoded using the following constraints:

← not inStatus(lowPress), inStatus(flow1),

not inStatus(flow2), not ab(regulatorValve) (10)

Here, having the left-hand side of the ASP rule left blank implies that the right-hand side of the rule cannot hold. The constraint says that if line 1 is flowing and line 2 is flowing and regulator value is not faulty, then the terminal pressure cannot be low.

Considering a scenario such that lops and dpsw are detected to be faulty. The sensor readings would be: value(acPmp1Dmd,1), value(acPmp2Dmd,0),

value(dcPmpDmd,0), value(dpsw,0), value(ps,1), value(lops,0).

From expressions (6)– (9), it may be concluded that inStatus(flow1), not inStatus(flow2) and not inStatus(lowPress). As a result, from rule (10) it may be inferred that ab(regulatorValve) is true.

From the above example, it may 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 and involves simple reasoning but may provide relatively low resolution, which may mean that for a given number of sensors, a malfunction cannot be narrowed down as well as when using the logical model approach. The logical model approach may provide the higher resolution, which may mean that for the given number of sensors, a malfunction can be narrowed down to a smaller subset of potential problems. However, the logical model approach may require additional user input to establish. For example, more expert data may be required to build a complete set of logical statements for understanding the system.

Exemplary embodiments of the present invention seek to combine the dependency model approach with the logical model approach. FIG. 4 is a flow chart illustrating a hybrid approach for system diagnosis in accordance with exemplary embodiments of the present invention. First, user information may be obtained (Step S41). The user information may be expert knowledge about the system being monitored and may pertain to the proper operation of the system and the known ways in which problems may be observed. This user information may be provided, for example, via a user interface that prompts the user for the desired information.

Obtaining the user information may also include formatting the user-provided input into a format that is unambiguous and convenient.

It may then be determined whether the obtained user-provided information is sufficient to establish a logical model (Step S42). This determination may be made either manually, by putting the question to the user, or automatically by analyzing the sufficiency of the information. According to one exemplary embodiment of the present invention, a logical model may be constructed in either event and the sufficiency of the constructed logical model may be determined by whether the logical model is able to provide a meaningful result. Alternatively, the sufficiency of the logical model may be assessed by running simulations or by examining the interdependence of the set of logical statements to see how many different combinations of possible sensor values can be explained by the model.

If the obtained user-provided information is sufficient to establish a logical model (Yes, Step S42) then the logical model may be generated from the available information (Step S43). If the obtained user-provided information is not sufficient to establish a logical model (No, Step S42) then a dependency model may be generated from the available information (Step S44a). Additionally, in the event that the logical model is built, the dependency model may still be built (Step S44b). At any point thereafter, additional information about the system may be obtained from a user or otherwise learned by monitoring operation of the system and when additional information is obtained, the logical model may be expanded, or created if it had not previously been created due to lack of sufficient information.

The dependency information may then be encoded using an Answer Set Programming (ASP) framework (Step 45a/b). For example, for dependencies between system components, the following may be used: connectTo(dcPmpDmd,res). For dependencies between the components and indicators, the following may be used: associate(dcPmp,ps).

The transitive closure of 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 an indicator I is associated with C and another component C1 is in the transitive closure of C, then I is also associated with C1 as follows:

associate(C1,I)← associate(C,I), tcConnectTo(C,C1)

(13)

Once the dependency model is encoded in ASP rules, the two models may be combined and executed using ASP solvers (Step S46). Where no logical model has been built, the dependency model may still be executed using the ASP solver (Step S47).

The ASP solver computation may be a particularly efficient way to determine the cause of abnormal sensor readings or to otherwise diagnose a potential problem.

The ASP encodings of the model rules may be written either manually or automatically. For example, the knowledge of ASP may be hidden from the end users and ASP encodings may be automatically generated using the knowledge that users input in a familiar form. Visual modeling tools may be used for end users to specify information such as: components, command, indicators, and state variables;

association of components with commands and indicators; dependency between components; definition of state variables using sensors readings; constraints; and/or expert rules.

When the logical models have been generated, sensor data from a network of sensors installed within a system may be analyzed using the models to determine when maintenance and/or remedial action should be taken or to otherwise render a diagnosis as to the condition of the system (Step S48). According to exemplary embodiments of the present invention, when the logical and dependency models are combined (Step S46), the results of the

dependency model may be used to enhance the diagnostic results of the logical model. Accordingly, previous diagnostic efforts performed using the dependency model may be carried over to the logical model approach.

After the model(s) provide the diagnostic results, which may include multiple possible causes for abnormal sensor data, preference may be given to minimal solutions and those solutions with the greatest amount of supporting evidence, as described above (Step S49). Preference may include rejecting potential results that are not preferential or otherwise ordering the results for display in accordance with preference.

With the system model from above, a program may generate dependency and logical models automatically. An ASP solver may serve as the diagnostic engine. FIG. 5A is a diagram illustrating an overall architecture for system diagnosis in accordance with exemplary embodiments of the present invention.

Sensor data 501 from the system may be fed into the a monitoring system 503, for example, periodically, such as daily, or continuously, to identify any abnormal behavior. The data may be validated 502 prior to being monitored. Data validation may be performed to ensure that the data being monitored is meaningful.

If abnormal data is found, the monitor system 503 will return a warning and activate the diagnostic system with all sensor readings and the identified faulty sensors. Using this information and the system models, the diagnostic engine 504 will generate a set of possible explanations using the reasoning explained in the previous sections and therefore render a component diagnosis 505.

FIG. 5B is a schematic diagram illustrating an architecture for the monitoring and diagnosis system in accordance with exemplary embodiments of the present invention. This architecture may be coherent with ISO 13374 (Condition Monitory and Diagnostics of Machines). The architecture may include ISO 13374 layers for data acquisition 506, data manipulation 507, state detection 508, health assessment 509, prognostic assessment 510, and advisory generation 511.

Exemplary embodiments of the present invention may additionally utilize prognostic assessment. Reasoning about dynamicity may be the basis for prognosis and planning. Dynamicity may play a role in effective diagnosis as well. For example, rules (1) and (2) provided above may be modified as the following dynamic rules:

inStatus(filling1,T+1)← ¬inStatus(filling1,T), value(switch,1,T), not ab(tap,T+1) (14)

¬inStatus(filling1,T+1)← inStatus(filling1,T), value(switch,1,T), not ab(tap,T+1) (15)

Static relations between indicator readings and state variables can be similarly extended. For example, rules (3) and (4) may be replaced by

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 negation and default negation not are distinguished here because unlike in the static case, the commonsense law of inertia needs to be stated explicitly: 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) where F ranges over all state variables. The laws indicate that system states do not change unless there is a cause for a change.

Diagnostic reasoning becomes more sophisticated in the dynamic case.

Consider the scenario that the monitoring system detects both x1 and x2 are faulty. The sensor readings are

value(swtich,1, 0), value(x1,1,0), value(x1,1,1), value(x2,0,0), value(x2,0,1) The values with timestamp 0 refer to the readings in the previous step while the ones with timestamp 1 refer to the readings in the current state. From the sensor reading value(x1,1,1), value(x2,0,1) and corresponding rules for inStatus(filling1,T), it may be concluded that either {ab(tank1,1), ab(tank2,1)} or inStatus(filling1,1). From value(x1,1,0), value(x2,0,0) and the same rules, it may be concluded that either {ab(tank1,0), ab(tank2,0)} or inStatus(filling1,0). Since the power monitor did not report any error in the previous state, it may be assumed that {ab(tank1,0), ab(tank2,0)} cannot be true. As a result, inStatus(filling1,0) follows. From inStatus(filling1,0), inStatus(filling1,1), the sensor reading value(swtich,1, 0) and rule (15), it may be concluded that {ab(tap,1)}. The rest of the reasoning is similar to the approach described above.

The diagnosis system may be able to reason about dynamicity and, as a result, may be able to provide prognosis and planning services. To accomplish this, exemplary embodiments of the present invention may extend the diagnostic framework with the ability to reason about actions and changes. For example, returning to the WTP discussed above, if it is asked what would happen if a command value(switch,1) is given in the current state, the system would be able to predict that value(x1,1,2), value(x2,0,2) since the tap is still stuck. If the knowledge about fixing the tap is encoded and the system is asked to restore itself to normal status, then a repair plan would be generated.

Exemplary embodiments of the present invention may additionally utilize a higher level action language to help end users to encode the knowledge about dynamicity. For example, instead of writing the rule (14), the users can encode using a more natural language approach. Rule (14) will be generated automatically therefrom.

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 the Lubricating Oil System example. Instead of describing faults uniformly in terms of abnormality of components, exemplary embodiments of the present invention may specify the fault types and their relations using the ontology that an abnormal sensor reading can be indicative of a general fault or a functional fault.

General faults may correspond to the total failures of components while functional faults might only affect the functionality of them. With the help of the ontology, the users are able to specify that low pressure in the terminal is related to the functionality of regulator valve

← not inStatus(lowPress), inStatus(flow1), not inStatus(flow2),

not functionalFault(regulatorValve) (21)

When a failure happens, it may be assumed that a functional fault happened instead of general faults, where both can explain the observation. As a result, exemplary embodiments of the present invention give functional faults greater priority when computing a minimal diagnosis. This can be written in the following ASP rules:

#minimize {functionalFault(C) : components(C) @ 1} (22)

#minimize {generalFault(C) : components(C) @ 2} (23)

With the ontology and the above rules, in the scenario considered above, the system may be able to conclude that {functionalFault(regulatorValve)}.

Exemplary embodiments of the present invention may extend the diagnostic system by adding query interfaces to ontologies. Such an interface may help the users to better encode their knowledge and use it in bolstering the diagnosis of the system.

As discusses above, exemplary embodiments of the present invention compute minimal diagnosis in order to prioritize the minimal solutions. Exemplary

embodiments of the present invention may use meta-programming techniques to reduce computation of subset minimal diagnosis to the computation of answer sets of a different program. Alternatively, exemplary embodiments of the present invention may extend this approach to cover arbitrary program under the stable model semantics.

One way of explaining minimal diagnosis is to refer to circumscription. This approach may be extended to the diagnostic domain.

The above-described approaches for automatic monitoring and diagnosis systems may be used to reduce the time and efforts required in asset management and enable a profitable optimization of maintenance cycles. Due to the complexity of diagnostic activities, reasoning, for example, nonmonotonic reasoning techniques may be used. Exemplary embodiments of the present invention apply the nonmonotonic formalism of ASP to the diagnosis of industrial systems. ASP solvers may then be used to solve the minimal diagnostic problem in the specific domain.

FIG. 6 shows an example of a computer system which may implement a method and system of the present disclosure. The system and method of the present disclosure may be implemented in the form of a software application running on a computer system, for example, a mainframe, personal computer (PC), handheld computer, server, etc. The software application may be stored on a recording media locally accessible by the computer system and accessible via a hard wired or wireless connection to a network, for example, a local area network, or the Internet.

The computer system referred to generally as system 1000 may include, for example, a central processing unit (CPU) 1001, random access memory (RAM) 1004, a printer interface 1010, a display unit 1011, a local area network (LAN) data transmission controller 1005, a LAN interface 1006, a network controller 1003, an internal bus 1002, and one or more input devices 1009, for example, a keyboard, mouse etc. As shown, the system 1000 may be connected to a data storage device, for example, a hard disk, 1008 via a link 1007.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product.

Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a“circuit,”“module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read- only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of

manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted 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 the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Exemplary embodiments described herein are illustrative, and many variations can be introduced without departing from the spirit of the disclosure or from the scope of the appended claims. For example, elements and/or features of different exemplary embodiments may be combined with each other and/or substituted for each other within the scope of this disclosure and appended claims.

Claims

What is claimed is: 1. A method for assessing system status, comprising:

receiving user-provided information pertaining to operation of a system under assessment;

constructing a dependency model of the system under assessment based on the received user-provided information;

determining whether the received user-provided information is sufficient to construct a logical model of the system under assessment;

constructing a logical model of the system under assessment and combining the logical model with the dependency model when it is determined that the user- provided information is sufficient;

monitoring sensor data from one or more sensors installed within the system under assessment;

applying the combined model to the sensor data when the combined model is available and applying the dependency model to the sensor data when the combined model is not available;

determining a set of one or more abnormal system components from the application of the combined model/dependency model to the sensor data; and

providing an assessment of system status based on the determined set of one or more abnormal system components,

wherein each of the above steps is performed using one or more computer systems. 2. The method of claim 1, wherein the user-provided information pertaining to operation of a system under assessment includes expert knowledge relating to fault dependency of one or more components of the system or relating to a manner in which the one or more components of the system fail. 3. The method of claim 1, wherein the user-provided information pertaining to operation of a system under assessment is encoded in Answer Set Programming (ASP) formalism either by the user or automatically based on user-input. 4. The method of claim 1, wherein the constructed dependency model or the combined model is expressed in Answer Set Programming (ASP) formalism. 5. The method of claim 1, wherein the constructed dependency model only describes how failures propagate through the system under assessment. 6. The method of claim 1, wherein the constructed logical model describes complex functional interdependencies between one or more components of the system under assessment. 7. The method of claim 1, wherein determining whether the received user- provided information is sufficient to construct the logical model of the system under assessment includes constructing the logical model and attempting to apply the constructed logical model to the monitored sensor data and determining whether a meaningful result is obtained. 8. The method of claim 1, wherein the combining of the logical model and the dependency model is performed using an Answer Set Programming (ASP) solver. 9. The method of claim 1, wherein applying the combined model or the dependency model to the sensor data is performed by an Answer Set Programming (ASP) solver. 10. The method of claim 1, wherein providing the assessment of system status based on the determined set of one or more abnormal system components includes prioritizing minimal solutions. 11. The method of claim 1, wherein providing the assessment of system status based on the determined set of one or more abnormal system components includes prioritizing solutions supported by a greatest number of sensor observations. 12. The method of claim 1, wherein application of the combined model or the dependency model to the sensor data includes using nonmonotonic reasoning. 13. A method for assessing system status, comprising:

receiving a dependency model of a system under assessment and a logical model of the system under assessment; monitoring sensor data from one or more sensors installed within the system under assessment;

combining the logical model with the dependency model and applying the combined model to the sensor data using an Answer Set Programming (ASP) solver; determining a set of one or more abnormal system components from the application of the combined model to the sensor data; and

wherein each of the above steps is performed using one or more computer systems. 14. The method of claim 13, wherein providing the assessment of system status based on the determined set of one or more abnormal system components includes prioritizing minimal solutions. 15. The method of claim 13, wherein providing the assessment of system status based on the determined set of one or more abnormal system components includes prioritizing solutions supported by a greatest number of sensor observations. 16. A computer system comprising:

a processor; and

a non-transitory, tangible, program storage medium, readable by the computer system, embodying a program of instructions executable by the processor to perform method steps for assessing system status, the method comprising:

providing an assessment of system status based on the determined set of one or more abnormal system components. 17. The computer system of claim 16, wherein the constructed dependency model only describes how failures propagate through the system under assessment. 18. The computer system of claim 16, wherein the constructed logical model describes complex functional interdependencies between one or more components of the system under assessment. 19. The computer system of claim 16, wherein the combining of the logical model and the dependency model is performed using an Answer Set Programming (ASP) solver. 20. The computer system of claim 16, wherein the applying the combined model or the dependency model to the sensor data is performed by an Answer Set Programming (ASP) solver. 21. The computer system of claim 16, wherein providing the assessment of system status based on the determined set of one or more abnormal system

components includes prioritizing minimal solutions or prioritizing solutions supported by a greatest number of sensor observations.