- Email: [email protected]
Fault diagnosis based on hazard identification results
Proceedings of the 7th IFAC Symposium on Fault Detection, Supervision and Safety of Technical Processes Barcelona, Spain, June 30 - July 3, 2009
Fault diagnosis based on hazard identification results Erzs´ ebet N´ emeth ∗ Roz´ alia Lakner ∗∗ Ian T. Cameron ∗ Katalin M. Hangos ∗∗∗ ∗
The University of Queensland, Brisbane, Australia (e-mail: {nemethe,itc}@uq.edu.au) ∗∗ University of Pannonia, Veszpr´em, Hungary (e-mail: [email protected]) ∗∗∗ HAS Computer and Automation Research Institute, Budapest, Hungary (e-mail: [email protected]) Abstract: An intelligent diagnostic methodology is proposed in this paper that combines piping and instrumentation information with hazard analysis results. The process model is represented as a hierarchically ordered set of blended HAZOP and FMEA structures. A diagnostic reasoning method is developed over that structure that combines backward and forward reasoning to gradually improve the fault isolation based on the temporal evaluation of the observed symptoms. The method is illustrated on a simple industrially relevant case study. Keywords: Diagnosis, Fault diagnosis, Fault isolation, Reasoning, Diagnostic inference, Process systems, Large-scale systems, Hazard identification, HAZOP, FMEA 1. INTRODUCTION
Fault detection and diagnosis is a vitally important task in most complex engineering plants, including such safetycritical ones as chemical and nuclear facilities. Although a great variety of diagnostic methods has been developed for fault detection and diagnosis, the modelbased approaches are considered to be the most powerful and popular ways of performing diagnosis in most engineering fields, including process systems engineering (Venkatasubramanian et al. [2003c,a,b]). However, there is usually no relevant model available for large process plants that captures its dynamic behaviour under faulty circumstances, because the validity region of the commonly applied full-scale dynamic simulators covers only the normal operation domain. Therefore, various qualitative models, such as signed directed graphs (SDGs), different versions of Petri nets (Hangos et al. [2001], Cameron and Hangos [2001]) are applied for diagnostic purposes in process systems. A possible way of eliciting heuristic model elements from the plants to be diagnosed is to use the readily available risk and hazard analysis results that should exist for all safety-critical plants. The heuristic information can be collected with systematic identification and analysis of process hazards, as well as the assessment and mitigation of potential consequences using so-called Process Hazard Analysis (PHA). There are several methods used in PHA studies such as Failure Modes and Effects Analysis (FMEA) (Jordan [1972]), Hazard and Operability Analysis (HAZOP) (Knowlton [1989]), Fault Tree Analysis (FTA) and Event Tree Analysis (ETA).
978-3-902661-46-3/09/$20.00 © 2009 IFAC
The aim of this work is to develop a systematic and theoretically well founded way of representing the results of process hazard analysis by combining the advantages of HAZOP and FMEA, tailored to a system decomposition and to develop intelligent diagnostic methods based thereon. 2. THE BLENDED HAZARD IDENTIFICATION METHOD AND ITS OUTCOMES This section is devoted to the description of the heuristic model representation that arises as a combination of the HAZOP and FMEA results. 2.1 System decomposition and structure Large process plants are difficult to diagnose using intelligent methods because of their inherent complexity, therefore a suitable system decomposition is needed that helps focusing the diagnostic methods. A hierarchical decomposition strategy driven by the functionality of the system components is followed here that contains three levels: • component level, where the elementary “non-divisible” parts of the plant are described. The component set determines the diagnostic resolution. • subsystem level, where the set of subsystems and their causal connections are described. The functionally related components are aggregated into subsystems with clearly defined boundaries. • system level, the upper level that is subject to analysis. The causal connections between subsystems are represented using directed graphs, where the subsystems correspond to nodes and their connections to directed edges. A
1515
10.3182/20090630-4-ES-2003.0104
7th IFAC SAFEPROCESS (SAFEPROCESS’09) Barcelona, Spain, June 30 - July 3, 2009
causal connection between two subsystems is an abstract mapping of some mass, energy or information flow that connects the two subsystems. Each subsystem may have different input and output ports associated with its different in- and outflows (see in Fig. 3).
System: Secondary cleaning of the coke ovens gas (COG)
Component Solution circulation pump (P-1)
The system decomposition and structure including subsystems and their causal connections are formally described in an ontology (Gruber [1993]), called Plant Ontology (Cameron et al. [2007]) implemented in Prot´eg´e (Prot´eg´e [2008]).
Failure mode Local effects causes Casing corrosion Loss of solution failure supply Solution spill loss of Loss of solution Pump power supply stops supply
Failure mode
System effects High ammonia content in outgoing COG High ammonia content in outgoing COG
Table 2. The results of FMEA analysis
2.2 Hazard identification methods There are two fundamental classes of complementary hazard identification methods, namely the function-driven class and the component-driven class. In the first class, the design intention deviations are considered and then traced back to component failures. For the second class, component failures are traced to functional changes. HAZOP and FMEA methods are typical instances of these two classes. HAZOP The HAZOP analysis (Knowlton [1989]) is the most widely used methodology for HAZID in complex process systems, such as the chemical, petro-chemical and related industries. HAZOP is a systematic procedure for determining the causes of deviations from design intention, and their consequences. The main idea behind HAZOP is that hazards in process plants arise as a result of deviations from normal operating conditions. The results of a HAZOP analysis are collected in a table, as can be seen in Table 1.
&ĂŝůƵƌĞDŽĚĞ ĂƵƐĞƐ
ĞǀŝĂƚŝŽŶ
ŽŶƐĞƋƵĞŶĐĞ
&ĂŝůƵƌĞDŽĚĞ
>ŽĐĂů ĨĨĞĐƚƐ
^LJƐƚĞŵ ĨĨĞĐƚƐ
Fig. 1. Relating HAZOP and FMEA variables within a subsystem and on its boundary as follows. • Cause is a predicate that is defined with a variable on the inlet boundary of the subsystem. • Consequence is a predicate with a variable on the outlet boundary. • Deviation is a fault-indicative predicate with a characterizing internal variable of the subsystem. • Failure mode is the manner by which a failure is observed. It describes the way a failure occurs. Fig. 2 depicts the abstract logical cause-effect diagram of a subsystem indicating the above predicates.
System: Secondary cleaning of the coke ovens gas (COG) Process parameter: Solution spray pressure Subsystem: Secondary acid catch (SAC)
Subsystem B
deviation
Dev1 …
u ~ cause (boundary)
Guide word Deviation Possible causes Consequence Low Low pressure Solution circulation pump is Outgoing COG ammonia not operating content high
Devm
failure FM1 mode
Pipe, valve or flange failure Solution flows to the environment High pressure Sprays blocked Outgoing COG ammonia Pipe blocked content high
…
High
WŽƐƐŝďůĞĂƵƐĞƐ
~ X ~
y ~ consequence (boundary)
FMn
Table 1. The results of HAZOP analysis
Fig. 2. Abstract subsystem (symbol ∼ denotes “related to”)
FMEA The FMEA (Jordan [1972]) is a qualitative analysis method for hazard identification, that is universally applicable in a wide variety of industries. FMEA is a tabulation of each system component, noting the various modes by which the equipment can fail, and the corresponding consequences (effects) of the failures. FMEA focuses on individual components and their failure modes. An FMEA table structure is illustrated in Table 2. 2.3 Blending HAZOP and FMEA HAZOP and FMEA results contain common or similar elements through which a relationship between them can be developed. This is illustrated by Fig. 1.
2.4 The BLHAZID structure The set of Causes, Deviations, Failure modes and Consequences together with their logical relationships form the blended hazard identification description, named as BLHAZID description or BLHAZID structure of a subsystem. The formal description of the BLHAZID structure can be given by first defining its basic elements and then the possible relations between them. The basic elements of the BLHAZID structure are:
In order to make use of the subsystem decomposition, the notion of Cause, Deviation, Failure mode and Consequence has been refined taking into account the
1516
= () e.g.
7th IFAC SAFEPROCESS (SAFEPROCESS’09) Barcelona, Spain, June 30 - July 3, 2009
System Subsystem_1
Measurement
Deviation_1.1 Deviation_1.2 Measurement FM_1.1 FM_1.2 FM_1.3
Cause_1.1 Cause_1.2 Cause_1.3
Conseq_1.1 Conseq_1.2
Measurement
Cause_3.1.1 Cause_3.1.2 Measurement
Cause_2.1.1 Cause_2.1.2
Cause_2.2.1 Cause_2.2.2 Cause_2.2.3
Subsystem_2
Cause_3.2.1 Cause_3.2.2 Cause_3.2.3
Subsystem_3 Conseq_3.1.1 Deviation_3.1 Conseq_3.1.2 Deviation_3.2 Conseq_3.1.3 FM_3.1 FM_3.2 FM_3.3
Conseq_3.2.1 Conseq_3.2.2 Conseq_3.2.3
Subsystem_4 Deviation_4.1 Deviation_4.2 FM_4.1 FM_4.2 FM_4.3
Cause_4.1 Cause_4.2 Cause_4.3
Conseq_4.1 Conseq_4.2
Deviation_2.1 Deviation_2.2 FM_2.1 FM_2.2 FM_2.3
Conseq_2.1 Conseq_2.2 Conseq_2.3
Fig. 3. The blended HAZID structure over the system decomposition = () e.g. = () e.g. = () e.g. The relations between the basic elements are: related related related implies implies implies implies implies implies implies Conjunction ( [ | | ]+ ) forms implies implies In the relation description we use regular expressions, where | denotes the choice operator, + means repeating the previous item once or more. It is important to note that the majority of the relations define diagnostic rules that can be used for diagnostic reasoning.
x(i) (t + 1) = f (i) (x(i) (t), u(i) (t)), t = 1, 2, ... (i)
(i)
(i)
(i)
y (t + 1) = g (x (t + 1), u (t + 1)) (i)
(i)
(1) (2)
(i)
where x (t) is the state, u (t) is the input and y (t) is the output variable at time t. One can easily recognize the correspondence between the abstract logical cause-effect diagram of a subsystem in Fig. 2 and the discrete dynamic state-space model. Thus the ingredients of a BLHAZID description can be matched to the signals of subsystems as follows. • Input variables are the Causes, • The set of state variables are formed from the Deviations, Failure modes. • The output variables correspond to the Consequences. Now we can easily connect subsystems assuming that the connections are passive, i.e. there is simply an equality relationship between the input and output variables of the connected port. Fig. 3 shows an example of connecting subsystems, keeping in mind that the connections are directed showing the cause-effect relationships between subsystems. The connection between Subsystem 1 and Subsystem 3 gives rise to the following equalities between the corresponding input and output variables: (1)
yConseq
(3)
1.1
(1)
= uCause 3.1.1 , yConseq
(3)
1.2
= uCause 3.1.2
2.6 Diagnostic rules generated from BLHAZID structures The general form of the diagnostic rules is IF Precondition THEN Conclusion.
2.5 Structured discrete dynamic system models The decomposition of the overall system into a set of subsystems and their causal connections allows us to construct the dynamic state-space model of the system from the state-space models of the subsystems and from their connections. Because of the logical nature of the BLHAZID structures used for the diagnosis, the discrete time form of the state-space description is used here for the ith subsystem S (i) :
The rule is a datalog rule (Hangos et al. [2001]), where the Precondition is a conjunction of logical predicates, but the Conclusion must be a single predicate. If the Precondition implies more than one predicate, one should create separate rules for each implied predicate. A Precondition can be a simple predicate described by a Failure mode (FM) of a component, or a Cause, or a Deviation; or it can be formed by a conjunction of these. A Conclusion is a single predicate, either a Consequence or Deviation or Cause. Formally,
1517
7th IFAC SAFEPROCESS (SAFEPROCESS’09) Barcelona, Spain, June 30 - July 3, 2009
Precondition = FM | Cause | Deviation | Precondition ∧ Precondition
Algorithm 1: Fault isolation Input: detected symptom Result: set of root causes, set of false causes /∗ add and remove are set operators, where add (NewElement, Set): if NewElement ∈ / Set, then add NewElement to Set; remove (Element, Set): if Element ∈ Set, then remove Element from Set ∗/ begin set of further conditions:= { detected symptom } ; set of examined conditions:= ∅ ; set of false causes:= ∅ ; set of root causes:= ∅ ; for condition ∈ set of further conditions do remove (condition, set of further conditions) ; add (condition, set of examined conditions) ; if condition has related measurement then if related measurement does not show the same behaviour that condition describes then add (condition, set of false causes) ; Break ;
Conclusion = Consequence | Deviation | Cause Based on the above defined rules, a HAZOP row can be described as a regular rule. When a Precondition contains only failure mode(s) of component(s), then this rule corresponds to an FMEA row. In the general case, when the Precondition is composed of a failure mode and other predicates, the rule describes a blended HAZOPFMEA (BLHAZID) element. This way the rules generated from the BLHAZID structures are upper compatible with both the HAZOP and the FMEA rules.
switch type of condition do case cause find the “source” subsystem ; if “source” subsystem exists then equivalent condition:= corresponding consequence of condition in “source” subsystem ; if equivalent condition ∈ / set of examined conditions then add (equivalent condition, set of further conditions) ;
3. REASONING OVER THE BLENDED HAZID STRUCTURE The above BLHAZID structure combined with the equipment interconnections in the plant serves as the knowledge base (KB) of our fault diagnostic system. The structured KBs provide the basis for inferencing about “root” causes of abnormal conditions using the real-time data from the monitoring system of the plant.
else add (condition, set of root causes) ; case deviation or consequence set of preconditions:= ∅ ; foreach rule ∈ diagnostic rules do if condition = the conclusion part of rule then if the precondition part of rule = predicate then foreach predicate do add (predicate, set of preconditions) ;
The final outcomes of the reasoning process are • a set of confirmed causes that qualify as “root” causes, since those causes are present as component failure modes or as at least one malfunction of the system’s inputs; • a set of possible consequences that are due to happen.
else add (condition, set of preconditions) ; foreach predicate ∈ set of preconditions do if predicate ∈ / set of examined conditions then switch type of predicate do case Failure mode add (predicate, set of root causes) ; case Cause or Deviation add (predicate, set of further conditions) ;
3.1 Reasoning over subsystem boundaries The overall system is decomposed into a set of subsystems, and the BLHAZID analysis is done on the subsystem level. The connection between two subsystems is determined by the connection of each component pairs, where the components are located at the boundaries of adjoining subsystems. During the reasoning procedure the set of causes and consequences is defined at the subsystem boundaries. If two subsystems are connected by a directed edge, then the consequences on the particular edge in the “source” subsystem must be the causes on the edge that comes to the “sink” subsystem. Fig. 3 shows the connections between subsystems and the points where the causes and consequences are placed in this frame.
Inform the operator that: The root causes = set of root causes; end
of the possible “root” causes of the detected symptom (fault isolation phase). Thereafter forward reasoning is applied with the possible “root” causes to predict all possible consequences of these causes (prediction-based diagnosis phase). Algorithm 1 above describes the steps of the fault isolation method. The results of the backward reasoning are • the set of “root” causes, which includes the system’s input failures and component failures; • the set of false causes.
3.2 Fault isolation using backward chaining The diagnosis of process systems is usually based on symptoms. Symptoms are deviations from a well-defined “normal behaviour”, such as Tlow = (T < Tmin ) which is defined by using a measurable temperature variable T . In the case of a dynamic system the measurable variables are time-varying, so the symptoms related to these variables will also change with time. The diagnostic reasoning starts with detecting a symptom, that corresponds to a Deviation or a Cause or a Consequence in our BLHAZID framework. This initiates reasoning along the BLHAZID knowledge base to find all
3.3 Prediction-based diagnosis using forward chaining Prediction of a system’s behaviour is used for deriving the consequences of the above derived root causes. The diagnostic reasoning starts with the results of the fault isolation, and uses forward chaining for identifying their possible consequences. The steps of the forward reasoning algorithm are given by Algorithm 2 below. The results of the forward reasoning are
1518
7th IFAC SAFEPROCESS (SAFEPROCESS’09) Barcelona, Spain, June 30 - July 3, 2009
Algorithm 2: Prediction-based diagnosis Input: set of root causes, set of occurred consequences in previous diagnostic step Result: set of occurred consequences, set of possible consequences, set of false consequences /∗ add and remove are set operators, where add (NewElement, Set): if NewElement ∈ / Set, then add NewElement to Set; remove (Element, Set): if Element ∈ Set, then remove Element from Set ∗/ begin set of further conditions:= set of root causes ; set of examined conditions:= ∅ ; set of false consequences:= ∅ ; set of possible consequences:= ∅ ; for condition ∈ set of further conditions do remove (condition, set of further conditions) ; add (condition, set of examined conditions) ; if condition has related measurement then switch related measurement shows do case the same behaviour that condition describes add (condition, set of occurred consequences) ; case the normal behaviour add (condition, set of possible consequences) ; case the opposite behaviour that condition describes add (condition, set of false consequences) ; Break ;
PI
Secondary acid catch (SAC)
Coke Ovens GasIN
V-3
Coke Ovens GasOUT
System
SS1 V-4
Sulphate solution
SS2
SS4
Fume suppression
Treated effluent
V-2 V-5
Industrial water
Secondary catch tank (SCT) V-6
V-1
SS3
P-1
Sulphate solution
Fig. 4. Secondary cleaning process of coke ovens gas
switch type of condition do case consequence find the “sink” subsystem ; if “sink” subsystem exists then equivalent condition:= corresponding cause of condition in “sink” subsystem ; if equivalent condition ∈ / set of examined conditions then add (equivalent condition, set of further conditions) ;
component identifier (CID), failure modes, the inputs and outputs are stored in the Plant Ontology. The system is divided into the following four subsystems given by their component lists: SS1: SS2: SS3: SS4:
case deviation or cause or failure mode foreach rule ∈ diagnostic rules do if the precondition part of rule = condition then if the conclusion part of rule ∈ / set of examined conditions then add (the conclusion part of rule, set of further conditions) ;
SAC V-4, pipes from SAC to SCT SCT V-1, V-2, V-3, P-1, pipes from SCT to SAC
Figure 5 shows an example of how the BLHAZID structure is used to drive the HAZID causal analysis process. The symptom that initiated the reasoning process in this simple example was ”Low solution pressure” of the sulphate solution after pump P-1. The final outcome of the reasoning process is also indicated in the Figure as a set of “root” causes (denoted by triangled ”!”) and the set of possible consequences (dashed underlined).
else if the precondition part of rule = predicate ∧ condition and each predicate ∈ set of examined conditions set of root causes then foreach predicate ∈ the precondition part of rule = predicate ∧ condition do add (predicate, set of further conditions) ;
Inform the operator that: The new occurred consequences = set of occurred consequences \ set of occurred consequences in previous diagnostic step; The left off occurred consequences = set of occurred consequences in previous diagnostic step \ set of occurred consequences; The possible consequences = set of possible consequences; end
5. CONCLUSION
• the set of possible consequences, which includes the system’s output deviations and all the possible consequences through the subsystems; • the set of occurred consequences, which contains the possible consequences verified by the measurements; • the set of false consequences. 4. CASE STUDY The aim of the case study is to illustrate the diagnostic procedures on a simple but industrially relevant case study. This is a secondary cleaning process of coke ovens gas (COG) in a coke making plant. Its process flow diagram can be seen in Fig. 4. The COG flows through the secondary acid catch (SAC) where any entrained sulphate solution is removed from COG. The part of the knowledge base used for illustrating the diagnostic reasoning is described briefly below (see also Fig. 4). The components and their properties, e.g.
An intelligent diagnostic methodology is proposed in this paper that combines piping and instrumentation information with hazard analysis results. The process model is represented as a hierarchically ordered set of blended HAZID (BLHAZID) structures that are upper compatible with both HAZOP and FMEA results but with its ingredients being re-defined to reflect the subsystem decomposition and connections. A diagnostic reasoning method is developed over the BLHAZID structure that combines backward and forward reasoning to gradually improve the fault isolation based on the temporal evaluation of the observed symptoms. The method is illustrated on a simple but industrially relevant case study, on the secondary cleaning system of coke ovens gas of an industrial coke making plant. ACKNOWLEDGEMENTS The authors acknowledge the financial and professional support of BlueScope Steel, Australia and BP Refinery Bulwer Island, Australia. We acknowledge support from the Australian Research Council under Linkage Grant LP0776636.
1519
7th IFAC SAFEPROCESS (SAFEPROCESS’09) Barcelona, Spain, June 30 - July 3, 2009
Pipe leak before pump P-1 Tank SCT major leak Pipe partially blocked before pump P-1
Low input Treated effluent flowrate to SS3 AND Low input Industrial water flowrate to SS3
Low solution flowrate before pump P-1 Pipe partially blocked after pump P-1
Valve V-1 Failure mode
Low solution pressure after pump P-1 related
Pipe leak after pump P-1
No input Treated effluent flowrate to SS3 AND Low input Industrial water flowrate to SS3 Low level in tank SCT
Low input Treated effluent flowrate to SS3 AND No input Industrial water flowrate to SS3
Low solution outflow from SS3
Low solution inflow to SS4
In SS3
No input Treated effluent flowrate to SS3 AND No input Industrial water flowrate to SS3
Pump P-1 Failure mode
Measurement: Low solution pressure
Valve V-2 Failure mode
In SS4
Valve V-3 Failure mode
Backward reasoning Forward reasoning
More flow to environment in SS3
Tank SCT major leak
Low level in tank SCT
Low solution outflow from SS3
Low solution inflow to SS4
No level in tank SCT
No solution outflow from SS3
No solution inflow to SS4
Low solution pressure after pump P-1
Low solution output pressure from SS4
No solution pressure after pump P-1
No solution output pressure from SS4
Low solution flowrate before pump P-1 No solution flowrate before pump P-1
Low solution input pressure to SS1
Low solution pressure after pump P-1 No solution pressure after pump P-1
High NH3 concentration in SAC
High NH3 concentration in output COG flow
Low solution outflow from SS1
Pump P-1 Failure mode
No solution input pressure to SS1
High NH3 concentration in SAC
Low solution pressure after pump P-1
Low solution outflow from SS1
Low solution inflow to SS2
Low solution outflow from SS2
Low solution inflow to SS3
Low level in tank SCT
No solution pressure after pump P-1
No solution outflow from SS1
No solution inflow to SS2
No solution outflow from SS2
No solution inflow to SS3
Low level in tank SCT
Valve V-2 Failure mode
Low solution pressure after pump P-1 Valve V-3 Failure mode Low input Treated effluent flowrate to SS3 AND Low input Industrial water flowrate to SS3
No solution pressure after pump P-1
No level in tank SCT
Root causes
Low level in tank SCT Low solution pressure after pump P-1
Pipe leak after pump P-1 in SS4
Pipe partially blocked after pump P-1 in SS4
No solution pressure after pump P-1
No input Treated effluent flowrate to SS3 AND Low input Industrial water flowrate to SS3
Low solution pressure after pump P-1
Low input Treated effluent flowrate to SS3 AND No input Industrial water flowrate to SS3
Low level in tank SCT
No input Treated effluent flowrate to SS3 AND No input Industrial water flowrate to SS3
Low level in tank SCT
No level in tank SCT No solution pressure after pump P-1 No solution flowrate before pump P-1
Pipe leak before pump P-1 in SS4
No level in tank SCT Low level in tank SCT
No level in tank SCT
Examined before Root cause
Low solution flowrate before pump P-1 Pipe partially blocked before pump P-1 in SS4
Possible consequence
Low solution flowrate before pump P-1
implies
No solution flowrate before pump P-1 In SSx
Low solution flowrate before pump P-1
In SSy
Valve V-1 Failure mode No solution flowrate before pump P-1
Fig. 5. Backward and forward reasoning from the symptom ”Low solution pressure” This research has also been supported by the Hungarian Scientific Research Fund through grants K67625, which is gratefully acknowledged. This work is partially supported by the Control Engineering Research Group of the Budapest University of Technology and Economics. REFERENCES I.T. Cameron and K.M. Hangos. Process Modelling and Model Analysis. Academic Press, 2001. I.T. Cameron, B. Seligmann, K.M. Hangos, R. Lakner, and E. N´emeth. The P3 formalism: A basis for improved diagnosis in complex systems. In CHEMECA Conference 2007, Melbourne, Australia, page on CD, 2007. T.R. Gruber. A translation approach to portable ontology specification. Knowledge Acquisition, 5:199–220, 1993. K.M. Hangos, R. Lakner, and M. Gerzson. Intelligent Control Systems: An Introduction with Examples. Kluwer Academic Publisher, 2001. W. Jordan. Failure modes, effects and criticality analyses. In Proceedings of the Annual Reliability and Maintainability Symposium, pages 30–37. IEEE Press, 1972. R.E. Knowlton. Hazard and operability studies: The guide word approach. Vancouver: Chematics International Company, 1989. Prot´eg´e. The Prot´eg´e Ontology Editor and Knowledge Acquisition System. http://protege.stanford.edu, 2008.
V. Venkatasubramanian, R. Rengaswamy, and S.N. Kavuri. A review of process fault detection and diagnosis Part II: Qualitative models and search strategies. Computers and Chemical Engineering, 27:313–326, 2003a. V. Venkatasubramanian, R. Rengaswamy, S.N. Kavuri, and K. Yin. A review of process fault detection and diagnosis Part III: Process history based methods. Computers and Chemical Engineering, 27:327–346, 2003b. V. Venkatasubramanian, R. Rengaswamy, K. Yin, and S.N. Kavuri. A review of process fault detection and diagnosis Part I: Quantitative model-based methods. Computers and Chemical Engineering, 27:293–311, 2003c.
1520
Fault diagnosis based on hazard identification results Erzs´ ebet N´ emeth ∗ Roz´ alia Lakner ∗∗ Ian T. Cameron ∗ Katalin M. Hangos ∗∗∗ ∗
The University of Queensland, Brisbane, Australia (e-mail: {nemethe,itc}@uq.edu.au) ∗∗ University of Pannonia, Veszpr´em, Hungary (e-mail: [email protected]) ∗∗∗ HAS Computer and Automation Research Institute, Budapest, Hungary (e-mail: [email protected]) Abstract: An intelligent diagnostic methodology is proposed in this paper that combines piping and instrumentation information with hazard analysis results. The process model is represented as a hierarchically ordered set of blended HAZOP and FMEA structures. A diagnostic reasoning method is developed over that structure that combines backward and forward reasoning to gradually improve the fault isolation based on the temporal evaluation of the observed symptoms. The method is illustrated on a simple industrially relevant case study. Keywords: Diagnosis, Fault diagnosis, Fault isolation, Reasoning, Diagnostic inference, Process systems, Large-scale systems, Hazard identification, HAZOP, FMEA 1. INTRODUCTION
Fault detection and diagnosis is a vitally important task in most complex engineering plants, including such safetycritical ones as chemical and nuclear facilities. Although a great variety of diagnostic methods has been developed for fault detection and diagnosis, the modelbased approaches are considered to be the most powerful and popular ways of performing diagnosis in most engineering fields, including process systems engineering (Venkatasubramanian et al. [2003c,a,b]). However, there is usually no relevant model available for large process plants that captures its dynamic behaviour under faulty circumstances, because the validity region of the commonly applied full-scale dynamic simulators covers only the normal operation domain. Therefore, various qualitative models, such as signed directed graphs (SDGs), different versions of Petri nets (Hangos et al. [2001], Cameron and Hangos [2001]) are applied for diagnostic purposes in process systems. A possible way of eliciting heuristic model elements from the plants to be diagnosed is to use the readily available risk and hazard analysis results that should exist for all safety-critical plants. The heuristic information can be collected with systematic identification and analysis of process hazards, as well as the assessment and mitigation of potential consequences using so-called Process Hazard Analysis (PHA). There are several methods used in PHA studies such as Failure Modes and Effects Analysis (FMEA) (Jordan [1972]), Hazard and Operability Analysis (HAZOP) (Knowlton [1989]), Fault Tree Analysis (FTA) and Event Tree Analysis (ETA).
978-3-902661-46-3/09/$20.00 © 2009 IFAC
The aim of this work is to develop a systematic and theoretically well founded way of representing the results of process hazard analysis by combining the advantages of HAZOP and FMEA, tailored to a system decomposition and to develop intelligent diagnostic methods based thereon. 2. THE BLENDED HAZARD IDENTIFICATION METHOD AND ITS OUTCOMES This section is devoted to the description of the heuristic model representation that arises as a combination of the HAZOP and FMEA results. 2.1 System decomposition and structure Large process plants are difficult to diagnose using intelligent methods because of their inherent complexity, therefore a suitable system decomposition is needed that helps focusing the diagnostic methods. A hierarchical decomposition strategy driven by the functionality of the system components is followed here that contains three levels: • component level, where the elementary “non-divisible” parts of the plant are described. The component set determines the diagnostic resolution. • subsystem level, where the set of subsystems and their causal connections are described. The functionally related components are aggregated into subsystems with clearly defined boundaries. • system level, the upper level that is subject to analysis. The causal connections between subsystems are represented using directed graphs, where the subsystems correspond to nodes and their connections to directed edges. A
1515
10.3182/20090630-4-ES-2003.0104
7th IFAC SAFEPROCESS (SAFEPROCESS’09) Barcelona, Spain, June 30 - July 3, 2009
causal connection between two subsystems is an abstract mapping of some mass, energy or information flow that connects the two subsystems. Each subsystem may have different input and output ports associated with its different in- and outflows (see in Fig. 3).
System: Secondary cleaning of the coke ovens gas (COG)
Component Solution circulation pump (P-1)
The system decomposition and structure including subsystems and their causal connections are formally described in an ontology (Gruber [1993]), called Plant Ontology (Cameron et al. [2007]) implemented in Prot´eg´e (Prot´eg´e [2008]).
Failure mode Local effects causes Casing corrosion Loss of solution failure supply Solution spill loss of Loss of solution Pump power supply stops supply
Failure mode
System effects High ammonia content in outgoing COG High ammonia content in outgoing COG
Table 2. The results of FMEA analysis
2.2 Hazard identification methods There are two fundamental classes of complementary hazard identification methods, namely the function-driven class and the component-driven class. In the first class, the design intention deviations are considered and then traced back to component failures. For the second class, component failures are traced to functional changes. HAZOP and FMEA methods are typical instances of these two classes. HAZOP The HAZOP analysis (Knowlton [1989]) is the most widely used methodology for HAZID in complex process systems, such as the chemical, petro-chemical and related industries. HAZOP is a systematic procedure for determining the causes of deviations from design intention, and their consequences. The main idea behind HAZOP is that hazards in process plants arise as a result of deviations from normal operating conditions. The results of a HAZOP analysis are collected in a table, as can be seen in Table 1.
&ĂŝůƵƌĞDŽĚĞ ĂƵƐĞƐ
ĞǀŝĂƚŝŽŶ
ŽŶƐĞƋƵĞŶĐĞ
&ĂŝůƵƌĞDŽĚĞ
>ŽĐĂů ĨĨĞĐƚƐ
^LJƐƚĞŵ ĨĨĞĐƚƐ
Fig. 1. Relating HAZOP and FMEA variables within a subsystem and on its boundary as follows. • Cause is a predicate that is defined with a variable on the inlet boundary of the subsystem. • Consequence is a predicate with a variable on the outlet boundary. • Deviation is a fault-indicative predicate with a characterizing internal variable of the subsystem. • Failure mode is the manner by which a failure is observed. It describes the way a failure occurs. Fig. 2 depicts the abstract logical cause-effect diagram of a subsystem indicating the above predicates.
System: Secondary cleaning of the coke ovens gas (COG) Process parameter: Solution spray pressure Subsystem: Secondary acid catch (SAC)
Subsystem B
deviation
Dev1 …
u ~ cause (boundary)
Guide word Deviation Possible causes Consequence Low Low pressure Solution circulation pump is Outgoing COG ammonia not operating content high
Devm
failure FM1 mode
Pipe, valve or flange failure Solution flows to the environment High pressure Sprays blocked Outgoing COG ammonia Pipe blocked content high
…
High
WŽƐƐŝďůĞĂƵƐĞƐ
~ X ~
y ~ consequence (boundary)
FMn
Table 1. The results of HAZOP analysis
Fig. 2. Abstract subsystem (symbol ∼ denotes “related to”)
FMEA The FMEA (Jordan [1972]) is a qualitative analysis method for hazard identification, that is universally applicable in a wide variety of industries. FMEA is a tabulation of each system component, noting the various modes by which the equipment can fail, and the corresponding consequences (effects) of the failures. FMEA focuses on individual components and their failure modes. An FMEA table structure is illustrated in Table 2. 2.3 Blending HAZOP and FMEA HAZOP and FMEA results contain common or similar elements through which a relationship between them can be developed. This is illustrated by Fig. 1.
2.4 The BLHAZID structure The set of Causes, Deviations, Failure modes and Consequences together with their logical relationships form the blended hazard identification description, named as BLHAZID description or BLHAZID structure of a subsystem. The formal description of the BLHAZID structure can be given by first defining its basic elements and then the possible relations between them. The basic elements of the BLHAZID structure are:
In order to make use of the subsystem decomposition, the notion of Cause, Deviation, Failure mode and Consequence has been refined taking into account the
1516
7th IFAC SAFEPROCESS (SAFEPROCESS’09) Barcelona, Spain, June 30 - July 3, 2009
System Subsystem_1
Measurement
Deviation_1.1 Deviation_1.2 Measurement FM_1.1 FM_1.2 FM_1.3
Cause_1.1 Cause_1.2 Cause_1.3
Conseq_1.1 Conseq_1.2
Measurement
Cause_3.1.1 Cause_3.1.2 Measurement
Cause_2.1.1 Cause_2.1.2
Cause_2.2.1 Cause_2.2.2 Cause_2.2.3
Subsystem_2
Cause_3.2.1 Cause_3.2.2 Cause_3.2.3
Subsystem_3 Conseq_3.1.1 Deviation_3.1 Conseq_3.1.2 Deviation_3.2 Conseq_3.1.3 FM_3.1 FM_3.2 FM_3.3
Conseq_3.2.1 Conseq_3.2.2 Conseq_3.2.3
Subsystem_4 Deviation_4.1 Deviation_4.2 FM_4.1 FM_4.2 FM_4.3
Cause_4.1 Cause_4.2 Cause_4.3
Conseq_4.1 Conseq_4.2
Deviation_2.1 Deviation_2.2 FM_2.1 FM_2.2 FM_2.3
Conseq_2.1 Conseq_2.2 Conseq_2.3
Fig. 3. The blended HAZID structure over the system decomposition
x(i) (t + 1) = f (i) (x(i) (t), u(i) (t)), t = 1, 2, ... (i)
(i)
(i)
(i)
y (t + 1) = g (x (t + 1), u (t + 1)) (i)
(i)
(1) (2)
(i)
where x (t) is the state, u (t) is the input and y (t) is the output variable at time t. One can easily recognize the correspondence between the abstract logical cause-effect diagram of a subsystem in Fig. 2 and the discrete dynamic state-space model. Thus the ingredients of a BLHAZID description can be matched to the signals of subsystems as follows. • Input variables are the Causes, • The set of state variables are formed from the Deviations, Failure modes. • The output variables correspond to the Consequences. Now we can easily connect subsystems assuming that the connections are passive, i.e. there is simply an equality relationship between the input and output variables of the connected port. Fig. 3 shows an example of connecting subsystems, keeping in mind that the connections are directed showing the cause-effect relationships between subsystems. The connection between Subsystem 1 and Subsystem 3 gives rise to the following equalities between the corresponding input and output variables: (1)
yConseq
(3)
1.1
(1)
= uCause 3.1.1 , yConseq
(3)
1.2
= uCause 3.1.2
2.6 Diagnostic rules generated from BLHAZID structures The general form of the diagnostic rules is IF Precondition THEN Conclusion.
2.5 Structured discrete dynamic system models The decomposition of the overall system into a set of subsystems and their causal connections allows us to construct the dynamic state-space model of the system from the state-space models of the subsystems and from their connections. Because of the logical nature of the BLHAZID structures used for the diagnosis, the discrete time form of the state-space description is used here for the ith subsystem S (i) :
The rule is a datalog rule (Hangos et al. [2001]), where the Precondition is a conjunction of logical predicates, but the Conclusion must be a single predicate. If the Precondition implies more than one predicate, one should create separate rules for each implied predicate. A Precondition can be a simple predicate described by a Failure mode (FM) of a component, or a Cause, or a Deviation; or it can be formed by a conjunction of these. A Conclusion is a single predicate, either a Consequence or Deviation or Cause. Formally,
1517
7th IFAC SAFEPROCESS (SAFEPROCESS’09) Barcelona, Spain, June 30 - July 3, 2009
Precondition = FM | Cause | Deviation | Precondition ∧ Precondition
Algorithm 1: Fault isolation Input: detected symptom Result: set of root causes, set of false causes /∗ add and remove are set operators, where add (NewElement, Set): if NewElement ∈ / Set, then add NewElement to Set; remove (Element, Set): if Element ∈ Set, then remove Element from Set ∗/ begin set of further conditions:= { detected symptom } ; set of examined conditions:= ∅ ; set of false causes:= ∅ ; set of root causes:= ∅ ; for condition ∈ set of further conditions do remove (condition, set of further conditions) ; add (condition, set of examined conditions) ; if condition has related measurement then if related measurement does not show the same behaviour that condition describes then add (condition, set of false causes) ; Break ;
Conclusion = Consequence | Deviation | Cause Based on the above defined rules, a HAZOP row can be described as a regular rule. When a Precondition contains only failure mode(s) of component(s), then this rule corresponds to an FMEA row. In the general case, when the Precondition is composed of a failure mode and other predicates, the rule describes a blended HAZOPFMEA (BLHAZID) element. This way the rules generated from the BLHAZID structures are upper compatible with both the HAZOP and the FMEA rules.
switch type of condition do case cause find the “source” subsystem ; if “source” subsystem exists then equivalent condition:= corresponding consequence of condition in “source” subsystem ; if equivalent condition ∈ / set of examined conditions then add (equivalent condition, set of further conditions) ;
3. REASONING OVER THE BLENDED HAZID STRUCTURE The above BLHAZID structure combined with the equipment interconnections in the plant serves as the knowledge base (KB) of our fault diagnostic system. The structured KBs provide the basis for inferencing about “root” causes of abnormal conditions using the real-time data from the monitoring system of the plant.
else add (condition, set of root causes) ; case deviation or consequence set of preconditions:= ∅ ; foreach rule ∈ diagnostic rules do if condition = the conclusion part of rule then if the precondition part of rule = predicate then foreach predicate do add (predicate, set of preconditions) ;
The final outcomes of the reasoning process are • a set of confirmed causes that qualify as “root” causes, since those causes are present as component failure modes or as at least one malfunction of the system’s inputs; • a set of possible consequences that are due to happen.
else add (condition, set of preconditions) ; foreach predicate ∈ set of preconditions do if predicate ∈ / set of examined conditions then switch type of predicate do case Failure mode add (predicate, set of root causes) ; case Cause or Deviation add (predicate, set of further conditions) ;
3.1 Reasoning over subsystem boundaries The overall system is decomposed into a set of subsystems, and the BLHAZID analysis is done on the subsystem level. The connection between two subsystems is determined by the connection of each component pairs, where the components are located at the boundaries of adjoining subsystems. During the reasoning procedure the set of causes and consequences is defined at the subsystem boundaries. If two subsystems are connected by a directed edge, then the consequences on the particular edge in the “source” subsystem must be the causes on the edge that comes to the “sink” subsystem. Fig. 3 shows the connections between subsystems and the points where the causes and consequences are placed in this frame.
Inform the operator that: The root causes = set of root causes; end
of the possible “root” causes of the detected symptom (fault isolation phase). Thereafter forward reasoning is applied with the possible “root” causes to predict all possible consequences of these causes (prediction-based diagnosis phase). Algorithm 1 above describes the steps of the fault isolation method. The results of the backward reasoning are • the set of “root” causes, which includes the system’s input failures and component failures; • the set of false causes.
3.2 Fault isolation using backward chaining The diagnosis of process systems is usually based on symptoms. Symptoms are deviations from a well-defined “normal behaviour”, such as Tlow = (T < Tmin ) which is defined by using a measurable temperature variable T . In the case of a dynamic system the measurable variables are time-varying, so the symptoms related to these variables will also change with time. The diagnostic reasoning starts with detecting a symptom, that corresponds to a Deviation or a Cause or a Consequence in our BLHAZID framework. This initiates reasoning along the BLHAZID knowledge base to find all
3.3 Prediction-based diagnosis using forward chaining Prediction of a system’s behaviour is used for deriving the consequences of the above derived root causes. The diagnostic reasoning starts with the results of the fault isolation, and uses forward chaining for identifying their possible consequences. The steps of the forward reasoning algorithm are given by Algorithm 2 below. The results of the forward reasoning are
1518
7th IFAC SAFEPROCESS (SAFEPROCESS’09) Barcelona, Spain, June 30 - July 3, 2009
Algorithm 2: Prediction-based diagnosis Input: set of root causes, set of occurred consequences in previous diagnostic step Result: set of occurred consequences, set of possible consequences, set of false consequences /∗ add and remove are set operators, where add (NewElement, Set): if NewElement ∈ / Set, then add NewElement to Set; remove (Element, Set): if Element ∈ Set, then remove Element from Set ∗/ begin set of further conditions:= set of root causes ; set of examined conditions:= ∅ ; set of false consequences:= ∅ ; set of possible consequences:= ∅ ; for condition ∈ set of further conditions do remove (condition, set of further conditions) ; add (condition, set of examined conditions) ; if condition has related measurement then switch related measurement shows do case the same behaviour that condition describes add (condition, set of occurred consequences) ; case the normal behaviour add (condition, set of possible consequences) ; case the opposite behaviour that condition describes add (condition, set of false consequences) ; Break ;
PI
Secondary acid catch (SAC)
Coke Ovens GasIN
V-3
Coke Ovens GasOUT
System
SS1 V-4
Sulphate solution
SS2
SS4
Fume suppression
Treated effluent
V-2 V-5
Industrial water
Secondary catch tank (SCT) V-6
V-1
SS3
P-1
Sulphate solution
Fig. 4. Secondary cleaning process of coke ovens gas
switch type of condition do case consequence find the “sink” subsystem ; if “sink” subsystem exists then equivalent condition:= corresponding cause of condition in “sink” subsystem ; if equivalent condition ∈ / set of examined conditions then add (equivalent condition, set of further conditions) ;
component identifier (CID), failure modes, the inputs and outputs are stored in the Plant Ontology. The system is divided into the following four subsystems given by their component lists: SS1: SS2: SS3: SS4:
case deviation or cause or failure mode foreach rule ∈ diagnostic rules do if the precondition part of rule = condition then if the conclusion part of rule ∈ / set of examined conditions then add (the conclusion part of rule, set of further conditions) ;
SAC V-4, pipes from SAC to SCT SCT V-1, V-2, V-3, P-1, pipes from SCT to SAC
Figure 5 shows an example of how the BLHAZID structure is used to drive the HAZID causal analysis process. The symptom that initiated the reasoning process in this simple example was ”Low solution pressure” of the sulphate solution after pump P-1. The final outcome of the reasoning process is also indicated in the Figure as a set of “root” causes (denoted by triangled ”!”) and the set of possible consequences (dashed underlined).
else if the precondition part of rule = predicate ∧ condition and each predicate ∈ set of examined conditions set of root causes then foreach predicate ∈ the precondition part of rule = predicate ∧ condition do add (predicate, set of further conditions) ;
Inform the operator that: The new occurred consequences = set of occurred consequences \ set of occurred consequences in previous diagnostic step; The left off occurred consequences = set of occurred consequences in previous diagnostic step \ set of occurred consequences; The possible consequences = set of possible consequences; end
5. CONCLUSION
• the set of possible consequences, which includes the system’s output deviations and all the possible consequences through the subsystems; • the set of occurred consequences, which contains the possible consequences verified by the measurements; • the set of false consequences. 4. CASE STUDY The aim of the case study is to illustrate the diagnostic procedures on a simple but industrially relevant case study. This is a secondary cleaning process of coke ovens gas (COG) in a coke making plant. Its process flow diagram can be seen in Fig. 4. The COG flows through the secondary acid catch (SAC) where any entrained sulphate solution is removed from COG. The part of the knowledge base used for illustrating the diagnostic reasoning is described briefly below (see also Fig. 4). The components and their properties, e.g.
An intelligent diagnostic methodology is proposed in this paper that combines piping and instrumentation information with hazard analysis results. The process model is represented as a hierarchically ordered set of blended HAZID (BLHAZID) structures that are upper compatible with both HAZOP and FMEA results but with its ingredients being re-defined to reflect the subsystem decomposition and connections. A diagnostic reasoning method is developed over the BLHAZID structure that combines backward and forward reasoning to gradually improve the fault isolation based on the temporal evaluation of the observed symptoms. The method is illustrated on a simple but industrially relevant case study, on the secondary cleaning system of coke ovens gas of an industrial coke making plant. ACKNOWLEDGEMENTS The authors acknowledge the financial and professional support of BlueScope Steel, Australia and BP Refinery Bulwer Island, Australia. We acknowledge support from the Australian Research Council under Linkage Grant LP0776636.
1519
7th IFAC SAFEPROCESS (SAFEPROCESS’09) Barcelona, Spain, June 30 - July 3, 2009
Pipe leak before pump P-1 Tank SCT major leak Pipe partially blocked before pump P-1
Low input Treated effluent flowrate to SS3 AND Low input Industrial water flowrate to SS3
Low solution flowrate before pump P-1 Pipe partially blocked after pump P-1
Valve V-1 Failure mode
Low solution pressure after pump P-1 related
Pipe leak after pump P-1
No input Treated effluent flowrate to SS3 AND Low input Industrial water flowrate to SS3 Low level in tank SCT
Low input Treated effluent flowrate to SS3 AND No input Industrial water flowrate to SS3
Low solution outflow from SS3
Low solution inflow to SS4
In SS3
No input Treated effluent flowrate to SS3 AND No input Industrial water flowrate to SS3
Pump P-1 Failure mode
Measurement: Low solution pressure
Valve V-2 Failure mode
In SS4
Valve V-3 Failure mode
Backward reasoning Forward reasoning
More flow to environment in SS3
Tank SCT major leak
Low level in tank SCT
Low solution outflow from SS3
Low solution inflow to SS4
No level in tank SCT
No solution outflow from SS3
No solution inflow to SS4
Low solution pressure after pump P-1
Low solution output pressure from SS4
No solution pressure after pump P-1
No solution output pressure from SS4
Low solution flowrate before pump P-1 No solution flowrate before pump P-1
Low solution input pressure to SS1
Low solution pressure after pump P-1 No solution pressure after pump P-1
High NH3 concentration in SAC
High NH3 concentration in output COG flow
Low solution outflow from SS1
Pump P-1 Failure mode
No solution input pressure to SS1
High NH3 concentration in SAC
Low solution pressure after pump P-1
Low solution outflow from SS1
Low solution inflow to SS2
Low solution outflow from SS2
Low solution inflow to SS3
Low level in tank SCT
No solution pressure after pump P-1
No solution outflow from SS1
No solution inflow to SS2
No solution outflow from SS2
No solution inflow to SS3
Low level in tank SCT
Valve V-2 Failure mode
Low solution pressure after pump P-1 Valve V-3 Failure mode Low input Treated effluent flowrate to SS3 AND Low input Industrial water flowrate to SS3
No solution pressure after pump P-1
No level in tank SCT
Root causes
Low level in tank SCT Low solution pressure after pump P-1
Pipe leak after pump P-1 in SS4
Pipe partially blocked after pump P-1 in SS4
No solution pressure after pump P-1
No input Treated effluent flowrate to SS3 AND Low input Industrial water flowrate to SS3
Low solution pressure after pump P-1
Low input Treated effluent flowrate to SS3 AND No input Industrial water flowrate to SS3
Low level in tank SCT
No input Treated effluent flowrate to SS3 AND No input Industrial water flowrate to SS3
Low level in tank SCT
No level in tank SCT No solution pressure after pump P-1 No solution flowrate before pump P-1
Pipe leak before pump P-1 in SS4
No level in tank SCT Low level in tank SCT
No level in tank SCT
Examined before Root cause
Low solution flowrate before pump P-1 Pipe partially blocked before pump P-1 in SS4
Possible consequence
Low solution flowrate before pump P-1
implies
No solution flowrate before pump P-1 In SSx
Low solution flowrate before pump P-1
In SSy
Valve V-1 Failure mode No solution flowrate before pump P-1
Fig. 5. Backward and forward reasoning from the symptom ”Low solution pressure” This research has also been supported by the Hungarian Scientific Research Fund through grants K67625, which is gratefully acknowledged. This work is partially supported by the Control Engineering Research Group of the Budapest University of Technology and Economics. REFERENCES I.T. Cameron and K.M. Hangos. Process Modelling and Model Analysis. Academic Press, 2001. I.T. Cameron, B. Seligmann, K.M. Hangos, R. Lakner, and E. N´emeth. The P3 formalism: A basis for improved diagnosis in complex systems. In CHEMECA Conference 2007, Melbourne, Australia, page on CD, 2007. T.R. Gruber. A translation approach to portable ontology specification. Knowledge Acquisition, 5:199–220, 1993. K.M. Hangos, R. Lakner, and M. Gerzson. Intelligent Control Systems: An Introduction with Examples. Kluwer Academic Publisher, 2001. W. Jordan. Failure modes, effects and criticality analyses. In Proceedings of the Annual Reliability and Maintainability Symposium, pages 30–37. IEEE Press, 1972. R.E. Knowlton. Hazard and operability studies: The guide word approach. Vancouver: Chematics International Company, 1989. Prot´eg´e. The Prot´eg´e Ontology Editor and Knowledge Acquisition System. http://protege.stanford.edu, 2008.
V. Venkatasubramanian, R. Rengaswamy, and S.N. Kavuri. A review of process fault detection and diagnosis Part II: Qualitative models and search strategies. Computers and Chemical Engineering, 27:313–326, 2003a. V. Venkatasubramanian, R. Rengaswamy, S.N. Kavuri, and K. Yin. A review of process fault detection and diagnosis Part III: Process history based methods. Computers and Chemical Engineering, 27:327–346, 2003b. V. Venkatasubramanian, R. Rengaswamy, K. Yin, and S.N. Kavuri. A review of process fault detection and diagnosis Part I: Quantitative model-based methods. Computers and Chemical Engineering, 27:293–311, 2003c.
1520