Qualitative Multi-faults Diagnosis Based on Automated Planning II: Algorithm and Case Study

Transcription

1 Qualitative Multi-faults Diagnosis Based on Automated Planning II: Algorithm and Case Study He-xuan Hu, Anne-lise Gehin, and Mireille Bayart Laboratoire d Automatique, Génie Informatique & Signal, UPRESA CNRS 8021, Université des Sciences et Technologies de Lille. Address: Bat. Poly-Tech Lille, Cité Scientifique, Villeneuve D Ascq Cedex, France. {He-Xuan.Hu@eleves.polytech-lille.fr, Anne-Lise.Gehin@polytech-lille.fr, mireille.bayart@univ-lille1.fr} Abstract: This paper continues to present the qualitative multi-faults diagnosis from the preceding paper I. There are two main contributions in this part. The first one is developing a new diagnostic process for continuous and dynamic systems and its corresponding consistency-checking module. The other one is that the fault models are introduced into the consistency-checking module for preventing the impossible diagnoses. Moreover, the STRIPS can qualitatively define the fault models without requiring detail and precise knowledge about faulty components. Keywords: Qualitative, First Principles, Multi-faults Diagnosis, Automated Planning. 1. INTRODUCTION This paper reports part II of a two part effort that is intended to propose an extended qualitative multi-faults diagnosis based on the automated planning. Our work is based on model. The part I has introduced the form of model and the means of building it. The model takes the form of an automaton. It is built using a mechanism of cause effect, inspired of the STRIPS (STanford Research Institute Problem Solver) language (Fikes and Nilsson, 1971, and Ghallab et al., 2004). It is known that there are two main components (Venkatasubramanian et al., 2003) in diagnosis: (1) the type of knowledge and (2) the type of diagnostic search strategy. Diagnostic search strategy is usually a very strong function of the knowledge representation scheme which in turn is largely influenced by the kind of a priori knowledge available. Hence, the Reiter s theory (Reiter, 1987) which is based on the first principles has been chosen as the corresponding diagnostic search strategy. But this theory was only applied to diagnosing digital circuits, which are representative only of physical devices with static, persistent states. In part I, we make a necessary assumption and a formal demonstration to extend the Reiter s theory to dynamic and continuous systems. In this part, we continue to present the diagnostic search strategy and illustrate the different notions presented in part I and II by a case study. For the qualitative diagnosis, there are fundamentally two different approaches to search in fault diagnosis (Rasmussen, 1986): topographic search and symptomatic search. Topographic searches perform malfunction analysis using a template of normal operation, whereas, symptomatic searches look for symptoms to direct the search to the fault location. The Reiter s theory belongs to symptomatic search. It is called consistency-based approach. Basically, consistencybased diagnosis amounts to finding faulty device components that account for a discrepancy between predicted normal behaviour of a device and actually observed behaviour. The discrepancy is formalized as logical inconsistency; a diagnosis is established when assuming particular components to be faulty and others to be normally functioning restore consistency. It reasons about multiple faults or causes for an abnormality by testing an assumption if it leads to an inconsistency. From the definition 3 of paper I, the key step in the diagnosis process is to test the consistency of the formula, { AB c) c Δ} { AB( c c COMP Δ} SD OBS ( ), (1) in which Δ COMP is the diagnosis for system (SD, COMP, OBS where: SD, the system description, is a set of first-order sentence; COMP, the system components, is a finite set of constants; OBS, the observations of a system, is a finite set of first-order sentences and AB is a predicate indicating that a component is abnormal. As we adopted a different model form with the one adopted by Reiter, we developed a different consistency-checking module for the formula (1). Moreover, a new diagnostic process adapted to dynamic and continuous system has been developed, with respect to the one used by Reiter for digital circuits. The basic idea consistency-checking module is shown in figure 1. The consistency-checking module firstly receives the observations and hypothesis Δ (assuming particular components to be faulty and others to be normally functioning). The fault models are built by using the same means for building normal model. The difference is that the fault models use the fault and normal STRIPS actions, but the normal model only uses the normal STRIPS actions. Then the fault models produce the predictions. Finally, these predictions are compared with the observations. If they match

2 each other, the hypothesis Δ makes the formula (1) consistent, otherwise inconsistent. As the difference with the Reiter s approach, fault models are used in our diagnostic process. Reiter s approach provides an elegant and general framework for multi-fault diagnosis. However, it is lacking an important part of diagnostic reasoning: knowledge about how components may behave when they are faulty. Thus it loses the ability of generating explanations and confirming diagnosis by analyzing whether the malfunctioning of a (set of) component(s) is consistent with the observations. It may produce the impossible diagnoses as that the light of a bulb is on although no voltage is present (Struss anddressler, 1992). Matching Observations Predictions Producing Model building Fig.1: The basic idea consistency-checking module. The rest of this paper is organized as follows. The fault models are introduced in section 2. The new diagnostic process for dynamic and continuous system is presented in section 3. The consistency-checking module corresponding to our system model is described in section 4. A benchmark example used to illustrate the different notions is presented in section 5. Section 6 summarizes the work done and discusses directions for future research. 2. THE FAULT MODELS Hypothesis Fault Models A faulty component has more than one faulty behaviours, for example, a valve may be blocked in the on position (i.e., can not be closed) or be blocked in the off position (i.e., can not be opened). These different behaviours can not be described by an unique single fault model. That is the reason why the notion of fault mode is introduced in our framework. Fault modes and effects analysis is a tool originally developed by reliability engineers. It analyses potential effects caused by simple or aggregated components ceasing to behave as intended, i.e. they stop providing the service designated to the component. A fault modes and effects analysis procedure starts with listing, for each component, in which ways can this component fail. This is referred to as fault modes. The faults can be regarded as a special set of STRIPS actions. Faults happen without any precondition and can change the truth values of atoms in the system states. Some of fault modes have a precise model with clear predictable outcomes. This is the case for example of the fault event, Block-on (). Some of others have not a precise model and just have a qualitative description. This is the case for example of the fault Leakage (), the leakage in tank, where the predictions depend on an unknown parameter x. Similarly for Incorrect () and Incorrect (), as the sensors have various types and structures, the outcome faults can not be predictable if the specific fault sensor, i.e., the specific type of sensor, is unknown. The STRIPS can qualitatively describe these faults without detail numeric values and can avoid making impossible diagnoses. This is one of its advantages. We list the fault STRIPS actions for the two-tanks example which is presented in the companion of this paper: part I. Block-on () {Preconditions: ; Determin-effects: ; if (L1-30)>L2 then Rise(L2) else Fall (L2); if Off (P1) then {if L1>30 then Fall (L1) else Static (L1)} else in case {(L1-30)<15 then Rise (L1); (L1-30)=15 then Static (L1); (L1-30)>15 then Fall (L1)};} Block-off () {Preconditions: ; Determin-effects: Fall(L2) if Off (P1) then Static (L1) else Rise (L1);} Block-off (P1) {Preconditions: ; Determin-effects: ; if [(L2<L1 30 (On (V2))) ((L1-30)>0 (On ()))] then Fall (L1) else Static (L1)} Block-on (P1) {Preconditions: ; Determin-effects: ; if [(Off() Off(V2)) (Off(V2) (L1<30)) then Rise(L1); else in case {((L1-L2)>15 (L1-30) > 15) then Fall (L1); ((L1-L2)=15 (L1-30) = 15) then Static (L1); ((L1-L2)< 15 (L1-30) <15) then Rise (L1);} Incorrect () {Preconditions: ; Determin-effects: Read() L1 Read() can take any possible value except for L1.} Incorrect () { Preconditions: ; Determin-effects: Read() L2 Read() can take any possible value except for L2.} Leakage () {Preconditions: ; Determin-effects: ; if Off (P1) then Fall (L1); if On (P1) (On (V2) On()) then in case {((L1-30-x)<15 (L1-L2-x)<15) then Rise (L1); ((L1-30-x)=15 (L1-L2-x)=15) then Static (L1); ((L1-30-x)>15 (L1-L2-x)>15) then Fall (L1)}; if On (P1) (Off (V2) Off()) then in case {((L1-30-x)<15 (L1-L2-x)<15) then Rise (L1); ((L1-30-x)=15 (L1-L2-x)=15) then Static (L1); ((L1-30-x)>15 (L1-L2-x)>15) then Fall (L1)} ;}. 3. THE DIAGNOSTIC PROCESS The basic idea of fault detection in this paper is very simple: determine the current state in which the system is, predict the normal successive possible states, and compare these predictive states with those observed (these steps are all based on the normal system model generated in the

3 companion paper: part I ). If there are the differences between these effects predictive and observed, the fault symptoms are detected. Once a fault symptom is detected, the fault isolation process is an incremental procedure to continuously compute a diagnosis for a system description (SD, COMP, OBS) and its successive new observations {New-OBS} according to the proposition 1 and 2 (in the section 3 of the companion paper: part I). The entire process is illustrated in figure 2. (1) In the initialization, (SD, COMP, OBS) is the system description and the initial state is noted as s 0. The successive states will be produced as the system receives new observations and they are noted as s 1, s 2 s k. When the system detects that a fault has occurred, the complete set of system components is considered as one of the conflict sets because according to the definition of conflict set, the assumption that all the system components are normal is not consistent with the actual observations. This complete set of system components is used as the root node of the graph HS-DAG and the initial HS-DAG has only this root note. Initialization Given system description (SD, COMP, OBS), The initial state noted as s 0 The complete set of system components is one of the conflict sets and is treated as the root node of HS-DAG After receiving new observations {New-OBS}, The successive states noted as s 1, s i, Constructing current HS-DAG for each state (4) For each of the leaf nodes in the order of increasing depths, check whether there are some pruning rules applied on this leaf node to avoid doing the consistency checking. (5) If there is no available pruning rule, make a call to the consistency-checking module but use s i as the New-OBS. Wait until receive the result of the consistency-checking module and update the HS-DAG as in Reiter s algorithm. It is noted that some new nodes may be generated in this updating. (6) If there are some available pruning rules, update the HS- DAG as in Reiter s algorithm. For the new HS-DAG, all the new leaf nodes are marked as unchecked. (7) Check whether there are any un-checked nodes. If there is no un-checked node, the diagnoses are all path labels of the completed leaf nodes (which are labelled by ) in the final HS-DAG for this state. The system waits for next new observation and go to step 2 to begin a new cycle. If there are un-checked nodes, go to step 4 to continue constructing HS-DAG for this state. (8) The process will wait for new observations and will clean the conflict and non-conflict marks of all normal scenario subsets (explicated in the following part: The consistency-checking module). 4. THE CONSISTENCY-CHECKING MODULE Call the consistency-checking module for each leaf node For each of the subsets of complementary set of H(n) Receiving new observations For each of the combinations of fault modes Traversing all the leaf nodes in the last HS-DAG Using the related STRIPS actions to verify the consistency For each of the leaf nodes Can we apply any pruning rules? Update the HS-DAG and Relabel the nodes related Have new or unchecked nodes? Fig. 2: The principle diagnostic process. (2) For each of the successive states s 1,, s i, the current HS- DAG is generated based on the last graph HS-DAG. (3) Open all the leaf nodes in the last HS-DAG (mark them as yet to be explored). Wait for new observations Call the consistency-checking module for each leaf node The Principle Diagnostic Process Have un-checked combinations of fault modes? Return a conflict set Mark this leaf node Consistency? Fig. 3: The consistency-checking module. In Reiter s theory, a theorem prover serves as a consistency checker, but in this paper, the normal and faulty STRIPS actions can be used as the consistency checker. They seek to maintain a model whose state and faults (if any) reflect the current state of the physical system. Have un-checked sub-sets? Return a null sign

4 The consistency-checking algorithm is described as figure 3. It rests on the following steps: (0) Clean the set CH(n) (explicated in step 2). (1) Select a leaf node in a breadth first order and obtain the set of edge labels, H(n). (2) List all subsets of complementary set of H(n) in the order of increasing cardinal numbers except for the null set, mark them as un-checked and record them in the set CH(n). We call this type subset as normal scenario subset. As the name suggests that the components in normal scenario subset are treated as the normal component and the rest components in system are assumed to be faulty or normal as the definition of conflict set (definition 4) described. (3) Choose a normal scenario subset. An additional operation is to clean the set FMC (the un-checked fault mode combination set, explicated in step 4). (4) As a component has several different fault modes and it can not be in two or more fault modes at the same time, thus each fault component takes one of their fault modes one time. We list all the fault mode combinations of these fault components. For example, there are two fault components. The first one has two fault modes (1-1, 1-2) and its normal mode (1-N), and the second one has only one fault mode (2-1) and its normal mode (2-N). Then there will be totally six fault mode combinations for these two fault components. Finally, we mark these combinations as un-checked and record them in the set FMC. We call a fault combination as a fault scenario. (5) With the normal component set {c1,,ck} chosen in step 3 and the corresponding fault mode combination chosen in step 4, we test the consistency of SD OBS { AB ( c 1 ),..., AB( c k )} from the fault predicted observations computed by the operations issued and the fault events in the fault mode combination. If a parameter value takes on two distinct qualitative magnitudes or directions in the fault predictive observations and the observed observations, an inconsistency is detected, otherwise a sigh of consistency is returned. Finally this fault mode combination chosen is marked as checked. (6) If an inconsistency is detected, then check whether there are any un-checked fault mode combinations. If there is no un-checked fault mode combination, then return the chosen normal component set as a conflict set and mark this leaf node by this conflict set. It means that all the fault mode combinations can not explicate the conflict results between the actual observations and the assumption of the normal component set. If there are unchecked fault mode combinations, then go to step 4. (7) If a consistency is returned, then check whether there is any un-checked normal scenario subset in CH(n). If there is no un-checked subset, then return a null sign and mark this leaf node by it. It means that there is no conflict set under this leaf node and the assumption that the components in H(n) are fault can explicate the existing situation. If there are un-checked subsets in CH(n), then go to step 3. There are two ways to improve the efficiency of this algorithm. One is to reduce the number of fault combinations. A fault sign usually manifests after attempting to take the actions that the system has just issued. So the fault mode that has the same effects as the commands issued will not be considered in this state. For example, the command issued is Close, and then the fault mode Block-off () will not be considered. The other is a skill to reduce the times of checking normal scenario subsets. The consistency of SD OBS { AB( c 1 ),..., AB( c k )} is independent with the choice of set H(n). It is only decided by the given normal component set {c 1,,c k }. For example, if a normal component set {c 1,,c k } H ( n 1 ) = {} and {c 1,,c k } H ( n 2 ) = {}, then the result of checking consistency can be used not only for node n 1 but also for node n 2. So a normal scenario subset can be reused during the period between two states. That is to say that for each state, the maximal times of checking consistency is 2 n -1, the number of the proper subset of n components. 5. A CASE STUDY The chosen example has been illustrated in the companion paper: part I. We don t repeat the details of this example. The schema is illustrated as figure 4. Pump Controller C1 45~50 cm 25~30 cm Pump P1 Tank 30 cm Fig. 4: The two-tanks system. Valve Valve V2 Tank T2 Valve Controller C2 Valve out Vo We suppose that the system will receive a sequence of observations like the table 1 shown. The system will execute the diagnostic process state by state. Each time, the system produces the predictions according to the observations of current state and sends them to next state, then it compare them with the observations of next state for detecting the faults. As the table 1 shown, the values in italic and bold reveal the fault symptoms. The diagnostic process will start after that. For the state 1, the conflict between level 1 direction observed and predictive is detected, then the complete set of system components {P1,,,, } becomes a conflict set and it is the beginning node (root node) to construct the graph HS-DAG for state 1. The root node n 0 = {P1,,,, } sprout 5 child nodes, each of which is connected to its parent node n 0 with an edge labelled by one of n 0 s components. So the corresponding 5 edges are H(1) = {P1}, H(2) = {}, H(3) = {}, H(4) = {} and H(5) = {}. Let the first edge H(1) = {P1} be taken as an example. The node n 1 will be tested and marked step by step: (1) the pruning rules are checked whether they can be used to the node n 1. Apparently, there is no rule that can be applied to node n 1 as it is the first leaf node. (2) list all normal scenario subsets of

5 H(n 1 ) in the order of increasing cardinal numbers and record them in the set CH(n 1 ) as table 2 shown. (3) for the first normal scenario subset {}, it means that the rest components {P1,,, } are all faulty. As a component has several different fault modes, we list all the fault mode combinations for this normal scenario subset as table 3 shown. (4) test the consistency of SD OBS { AB() }. The commands and fault events have been all defined as the STRIPS actions and they will be used to calculate the predictive observations of the assumed normal scenario. This step is to identify the fault components. Table 1: The sequence of received observations Sensor 1 Read Level 1 Direction Sensor 2 Read Level 2 Direction State of Pump 1 State of Valve 1 Operations issued State 0 Observed On On Close State 1 Predictive 45~50, 50 Up 9~11, 9 Down On Off Observed 46 Down 9 Down On Off Open State 2 Predictive 45~50, 45 Down 11 Up On On Observed 45 Down 11 Up On On Close State 3 Predictive 50, 45~50 Up 9~11, 9 Down On Off Observed 44 Down 9 Down On Off Open State 4 Predictive 30~45, 45 Down 11 Up On On Observed 39 Down 11 Up On On Close State 5 Predictive 30~45, 45 Up 9 Down On Off 45~50 Observed 38 Down 9 Down On Off Open State 6 Predictive 30~45 Down 0~9, 9 Down On On Observed 35 Down 11 Up On On Table 2: The normal scenario subsets of H(n 1 ),,,,,,,,,,,,,,,,, Table 3: All fault mode combinations of {} Fault mode Combination P1 1 Block-off In-correct or correct rmal In-correct or correct 2 Block-off In-correct or correct Block-on In-correct or correct 3 Block-on In-correct or correct rmal In-correct or correct 4 Block-on In-correct or correct Block-on In-correct or correct 5 rmal In-correct or correct rmal In-correct or correct 6 rmal In-correct or correct Block-on In-correct or correct For the fault events, P1 (block-off), (normal), and the command issued Close, the level of tank 2 will decrease and the level of tank 1 will keep static. However, the sensor and are fault and can display arbitrary value which may be in the normal range of real value or not. As a result, the read of sensor () can explicate the observed observations. The sigh of consistency is returned and this fault combination is marked as checked. For the rest three fault combinations, SD OBS { AB() } is tested as consistent. Therefore this normal scenario subset is marked as consistent and checked. For the next normal scenario subsets {}, it is marked as consistent by the same procedure. All its successor normal scenario subsets repeat the same procedure either to find a conflict set or to continue checking these normal scenario subsets until the end of them.,, 1 P1 1 2,, P1,,,, Fig. 5: The HS-DAG after observing the state s 1. When turn to the normal scenario subset {,, }, SD OBS { AB( ), AB( ), AB( ) } is inconsistent in all the fault mode combinations (table 4). Table 4: F. mode combinations of {,, } Fault mode Combination P1 1 Block-off In-correct or correct 2 Block-on In-correct or correct 3 rmal In-correct or correct is in-correct and it can explicate all possible readings of level 1 and its change direction. If P1 is block-off (it can not open), the level 1 will not change when the valve 1 is at the closing position. The level 2 will decrease. If P1 is block-on or normal (it can not close and it is at the opening position), the level 1 will increase when the valve 1 is at the closing position. The level 2 will decrease. For the first combination, the level 1 will not change and level 2 will decrease. For the second combination, the level 1 will increase and level 2 will decrease. However, the observed level 1 is decreasing and it is inconsistent with the predictive level 1 in all fault combinations. So the normal scenario subset {,, } is a conflict set. That is to say, it is not possible that,, are all normal in the same time. The node n 1 is marked as {,, } as figure 5-(a) shown. As {,, } is a subset of the root node {P1,,,, }, the program updates the graph HS-DAG and re-labels the nodes as the figure 5-(b) shown. All its successor nodes repeat the same procedure until the end of them. The final graph HS-DAG for state 1 is displayed as the figure 5 (b). For the states following up, s 2, s 3, s 4 and s 5, the graph HS- DAG has not changed. Until the system has got into the state 6, for the first node, a conflict set {} is found as the figure 6-(a) shown. And it belongs to the conflict set {,, } previously found at the third node. The fourth and fifth node is deleted according to the pruning rules and the third node is relabelled as {}. As { S 2 } { } = {}, the second node can reuse this conflict set and it is also relabelled as {}.,, Updating 3 (a) (b)

6 For the new fourth, fifth and sixth node, each of them has been returned a null sign and is marked as and checked. The whole HS-DAG graph is updated as figure 6- (b). After obtaining the final HS-DAG graph, the set of edge labels on the path in HS-DAG from the root down to leaf node n marked as is a diagnosis for the system. For the state 6, there are three possible diagnoses, for example, the first one is that the tank 1 has a leak and the sensor is fault. The tank always has a severe leak that leads to the decline of level 1. At the same time, the sensor indicated the rising of level 2 but the level 2 was indeed dropping. The second one is that the sensor and are all faulty. This fault combination can explicate the actual observations because these two sensors can display any ranges of water level. The third one is as same as the one at the state 1 that the valve is block-on and the sensor is faulty ,,,, Fig. 6: The HS-DAG after observing the state s 6.,, 2 There is not only one diagnosis for each state but several. However, a system is only in one of these possible diagnoses. A diagnosis should be decided among them by using some rules. If there is no further information, the usual way is to use probability of each component fault to sort these diagnoses. But it is very difficult to obtain the precise probability of each component fault. In our works, we offer a similar method by using a priority parameter. A priority parameter is a number of less than 1 and it does not specify the value of number. Let it be noted as p. Each component has a priority parameter to indicate qualitatively its possibility of failure. For example, the valve has the priority parameter p and the tank has the one p. It is easily determine that p is little than p because the valve as a moving part has the major risk of failure than the tank as a stationary part. If the tank stores corrosive, high pressure or high temperature liquid, p should be improved its level of priority. In our two tanks example, the sensor has some moving parts, so its priority parameter is in the middle between the tank and the valve. For example, p <p =p <p =p P1. For the state 6, the first Updating (a) (b) diagnosis s priority parameter is p p ; the second one s is p p ; and the third one s is p p. As mentioned above, p p < p p < p p. So the most likely diagnosis is the third one, p p. The valve is blockon and the sensor always indicates the level 2 in the opposite direction. 6. CONCLUSIONS This paper continues to present the framework of multi-faults diagnosis from the preceding paper. There are two main contributions in this part. One is aimed at developing a new diagnostic process for continuous and dynamic system and its corresponding consistency-checking module. This diagnostic process and its consistency-checking module are all based on the models defined by STRIPS actions. The other is that the fault models are introduced into the consistency-checking module for preventing the impossible diagnoses. The STRIPS can qualitatively define the fault models without requiring detail and precise knowledge about faulty components. Compare to classical quantitative methods, precise and accurate models of the plant are not required. It is a real advantage when there is not information about the system. Moreover qualitative representation is easier understandable by engineers or operator than differential or other mathematical expressions. Although we have proposed several skills to improve the efficiency of our algorithm, there are still a lot of works to do in the future. The model and its building method that we used here are also used in the reconfiguration (Hu et al., 2008). We hope that this multi-faults framework and the reconfiguration can be well integrated into a supervisory control system. REFERENCES Fikes, R. E. and Nilsson, N. J. (1971). STRIPS: A new approach to the application of theorem proving to problem solving, Artificial Intelligence, Vol. 2, Issues 3-4, pp Ghallab, M., Nau, D., and Traverso P. (2004). Automated Planning: Theory and Practice, Morgan Kaufmann Publishers. Hu, H.-X., Gehin, A.-L., Bayart, M. (2008). A Formal Framework of Reconfigurable Control Based on Model Checking, In American Control Conference, Seattle, Washington, USA. Rasmussen, J. (1986). Information processing and humanmachine interaction, rth Holland, New York. Reiter R. (1987). A Theory of Diagnosis from First Principles, Artificial Intelligence, Vol.32,. 1, pp Struss, P. and Dressler, O. (1992). Physical negation: integrating fault models into the general diagnostic engine, In: Readings in Model-based Diagnosis. Morgan Kaufmann Publishers, San Mateo, CA. Venkatasubramanian, V., Rengaswamy R. and Kavuri, S. N. (2003). A review of process fault detection and diagnosis Part II: Qualitative models and search strategies, Computers and Chemical Engineering, Vol. 27, pp