Docsity
Docsity

Prepare-se para as provas
Prepare-se para as provas

Estude fácil! Tem muito documento disponível na Docsity


Ganhe pontos para baixar
Ganhe pontos para baixar

Ganhe pontos ajudando outros esrudantes ou compre um plano Premium


Guias e Dicas
Guias e Dicas


FTA - A Knowledge Engineering Approach, Notas de estudo de Engenharia Civil

Análise da Árvore de Falha.

Tipologia: Notas de estudo

2011

Compartilhado em 05/07/2011

thalles-morais-4
thalles-morais-4 🇧🇷

2 documentos

1 / 9

Toggle sidebar

Esta página não é visível na pré-visualização

Não perca as partes importantes!

bg1
IEEE
TRANSACHONS ON RELIABILITY, VOL. 44, NO.
1,
1995
MARCH
37
Fault-Tree Analysis: A Knowledge-Engineering Approach
Jose Antonio Bogarin Geymayr
Nelson Francisco Favilla Ebecken
Federal University
of
Rio de Janeiro, Rio de Janeiro
Federal University
of
Rio de Janeiro, Rio de Janeiro
Key
Words
-
Fault tree, Expert system, Knowledge engineer-
ing, Fuzzy set
Reader
Aids
-
General purpose: Present an expert system for fault-tree analysis
Special math needed for explanations: None
Special math needed to use results: None
Results useful
to:
Reliability engineers, Knowledge engineers, Fault-
tree researchers.
Summary
&
Conclusions
-
This paper deals with the applica-
tion of knowledge-engineering and a methodology for the assess-
ment
&
measurement of reliability, availability, maintainability,
and safety of industrial systems using fault-tree representation. Ob-
ject oriented structures, production rules representing the expert’s
heuristics, algorithms, and database structures are the basic
elements of the system. The blackboard architecture of the system
supports qualitative
&
quantitative evaluation of the fault tree.
A
fuzzy
set
approach analyzes problems with few failure data
or
much
fuzziness
or
imprecision.
Fault-tree analysis is a knowledge acquisition structure that
has been extensively explored by knowledge engineers. Reliability
engineers can apply the techniques developed by this area of com-
puter science to:
1)
improve the data acquisition process;
2)
ex-
plore the benefits of object oriented expert systems for reliability
applications; 3) integrate the several sources of knowledge into a
unique system;
4)
explore the approximate reasoning to handle
uncertainty; and
5)
develop hybrid solution strategies combining
expert heuristics, conventional procedures, and available failure
data.
1.
INTRODUCTION
Fault tree analysis (FTA) is a formal deductive procedure
for determining combinations of component failures and human
errors that could result in the occurrence of specified
undesired
events
at the system level. This method can be used to analyze
the vast majority of industrial system reliability problems. Fault-
tree analysis is based on the idea that:
a failure in a system can trigger other consequent failures,
a problem might be traced backwards to its root causes [8].
The identified failures can be arranged in a tree structure in such
a way that their relationships can be characterized
&
evaluated.
Procedural programming has frequently been used to im-
plement algorithms for fault-tree evaluation. However the pro-
cedural approach suffers from the lack of support for many
or conversely,
phases of the software life-cycle,
eg,
program maintenance.
Amongst other features, the procedural approach can lead to
re-writing almost the entire program in case of a module addi-
tion or deletion.
Object oriented programming (OOP) frameworks for FTA
have been described by Patterson-Hine and Koen
[l].
In the
object oriented approach to software development, the applica-
tion is developed as a collection of modules; each module im-
plements an object which can be a system resource, a data struc-
ture, or anything similar. The basic OOP concepts are classes
of objects with methods and inheritance which leads to infor-
mation hiding. The internal representation of objects is not
available to procedures that want to access a particular object.
The information contained in the object is accessed only by a
set of operations that are encapsulated within the object. Each
object belongs to a given class which determines the type of
object. Individual objects are therefore instances of some type.
A hierarchy of object classes which enables an object to inherit
properties (operations) of its parent class or classes can be defin-
ed. Program modifications are local to detectable classes and
their methods, therefore avoiding side effects along the program
(encapsulation). The object oriented approach is especially suited
for program maintenance and code reutilization due to its en-
capsulation properties.
The success of a reliability analysis depends both on the ex-
perience of the reliability engineer and the process-specific
knowledge
[
131. The performance of non-experts at using con-
ventional tools is undesirable since neither the procedural nor the
object oriented approach provides mechanisms to represent
&
pro-
cess the expert’s knowledge which is required for the analysis.
In recent years, numerous attempts have been made to app-
ly knowledge-based fault-tree expert systems to the tasks of pro-
cess fault detection
&
diagnosis [9-121 and reliability analysis
[2-51. Rule-based knowledge representation has been propos-
ed in the literature; this approach, however, suffers from a lack
of generality (they contain a great deal of process-specific
knowledge), poor handling of novel situations (they are likely
to fail under unanticipated circumstances), and a lack of
transparency since they are difficult to maintain
&
validate
[5].
Many researchers in expert systems for process fault
diagnosis have concluded that some combination of rule based
and object oriented programming must be used as a compromise
between processing efficiency and qualitative performance
[7].
This paper extends the referred assumptions to reliability
engineering expert systems. Some of the expert shells that im-
plement production rules
in
an object oriented data structure
are Gensym’s real-time G2, System
X-I,
and Design-Kit [18].
This paper describes the architecture of the Fault Tree
Analysis Expert System designed to:
Explore the characteristics of object oriented structures, en-
capsulation, polymorphism, and inheritance, to represent the
fault-tree domain with classes, objects and properties.
0018-9529/95/$4.00 01995
IEEE
pf3
pf4
pf5
pf8
pf9

Pré-visualização parcial do texto

Baixe FTA - A Knowledge Engineering Approach e outras Notas de estudo em PDF para Engenharia Civil, somente na Docsity!

IEEE TRANSACHONS ON RELIABILITY, VOL. 44, NO. 1 , 1995 MARCH^37

Fault-Tree Analysis: A Knowledge-Engineering Approach

Jose Antonio Bogarin Geymayr

Nelson Francisco Favilla Ebecken

Federal University of Rio de Janeiro, Rio de Janeiro

Federal University of Rio de Janeiro, Rio de Janeiro

Key Words - Fault tree, Expert system, Knowledge engineer-

ing, Fuzzy set

Reader Aids - General purpose: Present an expert system for fault-tree analysis Special math needed for explanations: None Special math needed to use results: None Results useful to: Reliability engineers, Knowledge engineers, Fault- tree researchers.

Summary & Conclusions - This paper deals with the applica- tion of knowledge-engineeringand a methodology for the assess- ment & measurement of reliability, availability, maintainability, and safety of industrial systems using fault-tree representation. Ob- ject oriented structures, production rules representing the expert’s heuristics, algorithms, and database structures are the basic elements of the system. The blackboardarchitectureof the system supports qualitative & quantitative evaluation of the fault tree. A fuzzy set approach analyzes problems with few failure data or much fuzziness or imprecision. Fault-tree analysis is a knowledge acquisition structure that has been extensively explored by knowledge engineers. Reliability engineers can apply the techniques developed by this area of com- puter science to: 1) improve the data acquisition process; 2) ex- plore the benefits of object oriented expert systems for reliability applications; 3) integrate the several sources of knowledge into a unique system; 4) explore the approximate reasoning to handle uncertainty; and 5 ) develop hybrid solution strategies combining expert heuristics, conventional procedures, and available failure data.

1. INTRODUCTION

Fault tree analysis (FTA) is a formal deductive procedure for determining combinations of component failures and human errors that could result in the occurrence of specified undesired events at the system level. This method can be used to analyze the vast majority of industrial system reliability problems. Fault- tree analysis is based on the idea that: a failure in a system can trigger other consequent failures,

a problem might be traced backwards to its root causes [8].

The identified failures can be arranged in a tree structure in such a way that their relationshipscan be characterized & evaluated. Procedural programming has frequently been used to im- plement algorithms for fault-tree evaluation. However the pro- cedural approach suffers from the lack of support for many

or conversely,

phases of the software life-cycle, eg, program maintenance. Amongst other features, the procedural approach can lead to re-writing almost the entire program in case of a module addi- tion or deletion. Object oriented programming (OOP) frameworks for FTA have been described by Patterson-Hine and Koen [l]. In the object oriented approach to software development, the applica- tion is developed as a collection of modules; each module im- plements an object which can be a system resource, a data struc- ture, or anything similar. The basic OOP concepts are classes of objects with methods and inheritance which leads to infor- mation hiding. The internal representation of objects is not available to procedures that want to access a particular object. The information contained in the object is accessed only by a set of operations that are encapsulated within the object. Each object belongs to a given class which determines the type of object. Individual objects are therefore instances of some type. A hierarchy of object classes which enables an object to inherit properties (operations) of its parent class or classes can be defin- ed. Program modifications are local to detectable classes and their methods, therefore avoiding side effects along the program (encapsulation). The object oriented approach is especially suited for program maintenance and code reutilization due to its en- capsulation properties. The success of a reliability analysis depends both on the ex- perience of the reliability engineer and the process-specific knowledge [ 131. The performance of non-experts at using con- ventional tools is undesirable since neither the procedural nor the object oriented approach provides mechanisms to represent & pro- cess the expert’s knowledge which is required for the analysis. In recent years, numerous attempts have been made to app- ly knowledge-based fault-tree expert systems to the tasks of pro- cess fault detection & diagnosis [9-121 and reliability analysis [2-51. Rule-based knowledge representation has been propos- ed in the literature; this approach, however, suffers from a lack of generality (they contain a great deal of process-specific knowledge), poor handling of novel situations (they are likely to fail under unanticipated circumstances), and a lack of transparency since they are difficult to maintain & validate [ 5 ]. Many researchers in expert systems for process fault diagnosis have concluded that some combination of rule based and object oriented programming must be used as a compromise between processing efficiency and qualitativeperformance [7]. This paper extends the referred assumptions to reliability engineering expert systems. Some of the expert shells that im- plement production rules in an object oriented data structure are Gensym’s real-time G2, System X-I, and Design-Kit [18]. This paper describes the architecture of the Fault Tree Analysis Expert System designed to:

Explore the characteristics of object oriented structures, en- capsulation, polymorphism, and inheritance, to represent the fault-tree domain with classes, objects and properties.

0018-9529/95/$4.00 01995 IEEE

38

Control the knowledge application sequence by meta-

Integrate the multiple sources of knowledge (procedures,

Process uncertainty & vagueness with a fuzzy set approach. Increase the productivity of non-expert users for industrial

FTAES was developed on a Digital workstation, within the Gensym G2 environment [6]. The knowledge base assists engineers at many stages of fault-tree evaluation: fault-tree con- struction & simplification, minimal cut set evaluation, impor- tance &^ common-cause analysis, and failure-data manipulation.

knowledge.

heuristics, databases).

FTA applications. 4

Acronyms' & Abbreviations FTA fault-tree analysis FTAES Fault-Tree Analysis Expert System KS knowledge source MCS minimal cut set OOP object oriented programming PLC programmable logic controller.

2. FTAES ARCHITECTURE

The FTAES knowledge base was structured into a blackboard architecture. The blackboard architecture provides a framework for: integrating knowledge from several sources representing multiple levels of problem decomposition [ 181. A blackboard system consists of several KS that communicate through a blackboard and are controlled by an inference mechanism. The KS are independent chunks of knowledge and do not communicate with each other directly. Instead, they participate in problem solving by creating entries in a global database, the blackboard. Each KS knows: which type of objects on the blackboard it is interested in, how to determine if it wants to update the blackboard, how to update the blackboard. The blackboard has two partitions: control and domain. The domain partition is divided into levels; each level holds solu- tion information at a different level of abstraction. The control partition manages the data flow between KS. The inference mechanism of the blackboard has two main components: agen- da and monitor. The agenda keeps track of all the events in the blackboard and calculates the priority of execution for KS. The monitor takes the element with the highest priority and ex- ecutes it. Figure 1 shows the FTAES architecture. The system blackboard contains the object definition and the control strategies required for FTA. The KS^ are divided into two levels:

IEEE TRANSACTIONS ON RELIABILITY, VOL. 44, NO. 1, 1995 MARCH

'The singular & plural of an acronym are always spelled the same.

Mm

Figure 1. FTAES Architecture

Specialist. Contain the set of rules acquired from the experts to analyze various levels of abstraction. For FTAES they are: fault-tree-construction, tree-simplification, impor- tance-analysis, and common-cause-analysis. Zntelface. Contain the control rules for the interaction between the blackboard, the databases, and the algorithms. For FTAES

they are: plant-editing , data-base-handler, and com-

moruause-analysis.. 4

Procedures, such as minimal cut set evaluation, are hypotheses and are defined as methods or instances of Boolean objects. An hypothesis can be evaluated anytime or anywhere. The results of the evaluation are stored as data in a database structure (par- ticular domain) or at the blackboard object definition (public domain). The database stores any useful information about previous- ly analyzed systems and failure data. The inference mechanism of G2 processes the high-level code, passes instructions to the computer, and controls the data flow between the knowledge sources, procedures, and databases. The user inter$ace includes interactive menus, graphics editors of plant diagrams and fault- tree layouts, explanation facilities, and report generation. The blackboard manages the knowledge sources according to a specific problem solution strategy. The agenda orders the rule and object inference priority. Public domain information is stored at the blackboard for common use. Individual KS are loaded, executed, and unloaded from the blackboard.

3. REPRESENTING THE FAULT-TREE DOMAIN

WITH OBJECTS

A fault tree is a combination of terminal & intermediate events. An intermediate event can be further decomposed into events. A terminal event can not be resolved further into its causes. The correspondence between a fault-tree structure and the object oriented modeling facilities is striking. Figure 2 shows some FTAES class definitions. Each class is defined with its particular properties, icons, and procedures. Objects belonging

(^40) IEEE TRANSACTIONS ON RELIABILITY, VOL. 44, NO. 1, 1995 MARCH

  1. Load the related KS to the blackboard; 2. Evaluate the set of rules of the current hypothesis; 3. Unload the KS from the blackboard. The value of the hypothesis is stored at the blackboard and re- mains available for further evaluation. The KS minima-cutset contains the control rules that select & evaluate the appropriate minimal cut set procedure for the current application. Number of events, repeated events, and the dimension of probability and error rates are analyzed to select the best methodology for MCS evaluation. The procedures were developed as G2 environment methods accordingto the follow- ing well-known minimal cut set algorithms [13,15]: Boolean algebra method, combination testing method, prime number method, and binary bit string method. In order to increase the speed of calculation, the inference mechanism can select dif- ferent procedures to solve sub-trees of the same system. Con- trol rules are used to modify the agenda of the inference mechanism or to force the evaluation of sets of rules or methods. Table 2 shows the syntax of a control rule that selects the prime number method for minimal cut set evaluation.

TABLE 2 Control Rule for Minimal Cut Set Evaluation

If repeated-events. number is “high” then evaluate prime-methodW E , MCS)

The method primemethod is a procedure developed by the pro- grammer based on the prime method methodology for minimal cut set evaluation. The property repeated-events. number analyses the number of repeated events of the tree according to the expert point of view. The object W E stores the selected tree definition to be evaluated by the method. The object MCS stores the object definition of the resulting minimal cut set evaluation. The KS common-cause-analysis interacts with the user to identify potential mechanisms that can cause more than one failure or degrade the performance of system components. The KS identifies the common causes and their domains, the ter- minal events susceptible to the common causes, the common- cause candidates, the prime common-cause candidates, impor- tant common-causes, and partially affected minimal cut sets. Qualitative & quantitative analyses are performed at this stage. Table 3 shows the rule “earthquakes” and its influence over the object definition of the blackboard. The KS Importancecanalysis executes the Vesely-Fussell measure of importance for minimal cut sets and terminal events [14]. Since the KS are independent chunks of knowledge, any other importance measure methodology can be defined by the programmer according to user needs.

judgement holds a central position in all safety analyses of com- plex systems because:

It is necessary to collect lots of data to estimate failure & er- ror rates. In practice, since sample data collection is often not possible, failure & error rates are assessed by experts bas- ed on their engineering judgement. Reliability is affected by many factors: the environment in which equipment is operated, the environmental task condi- tion, psychological stress of a human operator, etc. In con- ventional reliability analysis, the basic error & failure rates are adjusted by experts, based on experience & judgment, to include the effect of many external & operational factors on reliability.

TABLE 3 Common-Cause Analysis Rule Definition KS: common-cause-analysis Hypothesis: Earthquakes For any pumps P; If the uffecred-location of earthquake is equal to the locution of P and the magnitude^ of^ earthquake^ is greater than^^5 then connect^ P^ to^ earthquake Blackbord

PUMPS

ocatm-’Roan C l 1 -

Although rules can be used within an expert system to code the required heuristics to adjust &^ process failure^ &^ error data, it is not easy to handle & process uncertainty with the tradi- tional approach. f i s k^ is afuuy concept in the sense that a single risk score, such as the probability of failure of the top event on FTA, cannot summarize all the hazard implications. The degree of uncertainty, whether caused by equipment failure or human error can lead to a system accident. The rela- tion between reliability and factors affecting it are difficult to express clearly using traditional formulations. However, it is comparatively easy to express this kind of uncertainty

  1. HANDLING & PROCESSING UNCERTAINTY qualitatively. The fuzzy set approach offers a qualitative methodology to represent and reason with uncertain, vague, or fuzzy information. The calculus of fuzzy sets is well developed, with various applications in engineering, such as the application

Failure rates (in equipment reliability) and error rates (human reliability) are important variables. However, human

GEYMAYR/EBECKEN: FAULT-TREE ANALYSIS: A KNOWLEDGE-ENGINEERING APPROACH

~

41

of fuzzy sets to engineering design [19], structural optimiza- tion [20], structural damage assessment [21], safety failure analysis [22], risk analysis [23], and fault-tree analysis, [24]. Controversial publications [25] have also been reported com- paring probabilistic with the possibilistic (fuzzy) approaches. The authors of this work believe that the selection of an ap- propriate methodology for a FTA application depends on data availability and the process specific knowledge. When the uncer- tainty involved is low, the traditional approach seems to be more applicable. Otherwise, the fuzzy approach might be more desirable. The central concept in fuzzy set theory is the membership function, which numerically represents the degree to which an element belongs to a set. The question is how to assess these grades of membership. Zadeh [ 171 states that people are more efficient in qualitative rather than quantitative analyses. The use of linguistic variables and fuzzy logic is suggested to explain the human ability to summarize information for problem resolu- tion. Linguistic variables play the same role as numerical variables in a conventional mathematical model, but take on words or sentences in a convenient language, eg, “old”, “very- true”, “around-lo”, as their values. The numeric values representing the linguistic variables are then assigned with ap- propriate fuzzy sets. The assignment of the membership func- tion to fuzzy sets is subjective. Arbitrary assignment is not per- missible. As stated [23], the verbal model with linguistic variables and verbally formulated relations between the variables can be very useful in system safety and risk analysis. They sug- gest the use of membership functions for the linguistic represen- tation of risk factors, as shown in table 4. The membership func- tions take values between [0,1]. The higher the membership value of an element, the more it belongs to the set.

TABLE 4 Membership Functions for Linguistic Representation of the Risk Factor

Fuzzy linquistic variables

~~

Membership function high medium low unknown undefined more or less high very high likely unlikely not likely

~~ 0 0 0.1 0.3 0.7 0. 0 0.2 0.7 (^1) 0.7 0. 1 0.9 0.7 0.3 (^) 0.1 0 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0.3 0.5 0.70 0. (^0 0 0) 0.1 0.5 0. 0 0.1 0.5 0.7 0.9 1 1 1 0.9 0.8 0.5 0 1 1 0.5 0.3 0.1 0.

~ 1 0 0 1 0 1 1 1 0 0

rules in terms of the linguistic variables and their associated membership function. The implication component is the result of the expert definition for the failure of event G1. The premise components are the known facts provided by the user. The risk of failure of the terminal events is defined as possibility of failure with linguistic variables, according to table 4. The action com- ponent is responsible for the fuzzy calculation to determine risk possibility of event G2. Theorems & definitions related to fuz- zy algebra are omitted from this paper. Table 5 shows only the macro of the fuzzy calculation.

TABLE 5 Approximate Reasoning With Fuzzy Sets

Implication (de$ned by the exper?): “If the risk of failure of E l is high OR the risk of failure of E2 is high, then the risk of failure of G1 is high.” Premise (provided by the user) : The actual risk of failure of E l is medium and the actual risk of failure of E2 is low.” What is the actual risk of failure of GI? Action: Evaluate fuzzyjnference (implication, premise, result) and the risk of failure of GI is equal to “result”

The fuzzy mechanism of inference is represented as the fizy-inference method with 3 components: implication, premise, and result. The variable “result” stores the approx- imate linguistic variable related to the risk of failure of the analyzed event (defuzzification). Table 6 shows the calculation of G1 = E l U E2 for both Boolean and fuzzy modes.

TABLE 6 Probabilistic vs Fuzzy Analysis

Bolean mode Probability of event required for calculation Output: P(G1) =0. Fuzzy mode

Probability not required Fuuy Implication: Instead, Use linquistic variables

Input: P(E1) =O.O0245, P(E2) =O.O Calculation: P(Gl)=P(El)+P(E2)

Input: P(El)=“medium”, P(E1) = “low”

If El =“high” then GI =“high R E I =

If E2 = “high” then G1 =“high RE, =

F u u y Premise If E l =“medium” and E2’=‘‘low” then G1=? Fuuy Calculation GI =(E1’oREI) U (E2’oRE2) Fuuy Result: pGI={O 0 0.1 0.3 0.7 0.7 0.7) Defuu$cation: P(Gl)=“more or less high”

EloGl

E20G

The KS data-baseAandler is responsible for data manage- ment and helps the user select the logic mode (traditional or fuzzy) to solve the problem. The traditional Boolean mode uses the probability of failure of the basic events acquired from the database or provided by the user. In the fuzzy approach, the risk of failure of G1 is evaluated with approximate reasoning-

6. GRAPHICAL REPRESENTATION OF OBJECTS

Figure 3 shows the user interface for plant editing. The object definition for plant editing was designed for oil production plants installed in offshore platforms. Units and

GEYMAYRIEBECKEN: FAULT-TREE ANALYSIS: A KNOWLEDGE-ENGINEERING APPROACH

helps to reduce uncertainty of failure data and adjust probability and error rates based on the real situation of the monitored plant.

Fault-tree Construction

The plant diagram of figure 4 was defined with the FTAES graphic user-interface (figure 3). A functional decomposition of each “equipment” and “connection” of the diagram is per- formed by the system. In order to mount the fault tree, the user is asked to eliminate unit functions not required for the current application, as shown in figure 5.

Figure 5. Functional Decomposition of HTX-

The FTAES user-interface was designed for non-expen users. The complete sequence of questions might be boring for

experienced reliability engineers, but necessary for beginners. The

“monitored” fault-tree construction can be ignored during this phase by selecting the F-TREE option. This resource allows the experienced user to build the fault tree with no interference From the system inference. The final object definition representing the fault tree is stored at the blackboard database for common use or further development. Figure 6 shows the final tree layout of the oil plant production system of figure 4.

Determination of Failure & Error Rates The failure & error rates of FTAES are estimated accord- ing to data availability. In this example, the database integra- tion facilities of FTAES allow the user to search & select data from structures developed at different platforms: a mainframe database system and a microcomputer database system. The risks of failure of basic events are evaluated & classified into “generic”, “local”, and “fuzzy” rates. The “generic” rate is retrieved from the available generic databases for similar equipment. The “local” rate is calculated by FTAES based on the fre- quency distribution of failures acquired from the real time fault and diagnostic system [7]. Local rates are only available when FTAES is connected to a real-time diagnosis system.

III^ I^ II^ I

I I 1

G1: Undesired Oil Production range G2: Undesired 1st stage separation G3: Oil heating system failure G4: Undesired 2nd stage separation G5: Abnormal well production G6: Abnormal separation at SEP- G7: Excessive oil production G8: Reduces oil production G9: Failure at SDV- G10: Abnormal pressure in SEP- G l l : Abnormal level at SEP-

1

(312: Leakage of SEP-I G13: Failure on PIC-1 system G14: Failure of PCV-1 system G15: Failure at outlet pipeline of SEP- G16: Failure of LIC-1 system E17: Uncorrect set point value at PIC- E18: Failure of PIC-1 controller E19: Failure of PT- E20: Failure of PCV-1 controller E21: Failure of the hydraulic system of PCV-I E24: Uncorrect set point of LIC-

E25: Failure of LIC- E26: Failure of LT-I E15-1: HV-1 fails opened E15-2: Failure of hydraulic system of LCV-I E15-3: Mechanic failure of LCV-I E15-4: Failure of FILTER-I E30: Fluid leak at HTX- G3 1 : Abnormal oil Temparature at HTX- 1 E40: Oil leakage in SEP- G41: Abnormal level at SEP- G42: Abnormal pressure in SEP- Figure 6. Gas-Oil Separation System in Offshore Platforms

44 IEEE TRANSACTIONS ON RELIABILITY, VOL. 44, NO. 1, 1995 MARCH

TABLE 9 Probability Rates of Basic Events of G

FAILURE

LOCAL DATA PROBABILITY RATE GENERIC RATE FREQUENCY FUZZY RATE SUGGESTED BY FTAES

EIS-I HV-I opened

0.245 x 10-04 0.78 “Reasonably probable” 0.

EIS-2 unknown Hydraulic system of LCV-I

0.0 ‘Extremely remote” 0. 3 4 4 ~

E15-3 0. 9 8 8 ~10-O5 0.0 “remote Mechanic failure of LCV-

0.988 x 10 - 0 5

E15+ Maintenance of FILTER-I

0 .oo 1 05 0.22 “frequent’ ’ 0 .OO 105

A “fuzzy” rate is defined with linguistic variables to qualify the “generic” rates. In the absence of “numeric” prob- abilistic rates, the user selects the appropriate fuzzy variables for the basic events. 4

The “local” rates are used to modify the state of “generic” or “fuzzy” information based on the “deep knowledge” of the plant. Table 9 shows the influence of local data on the final prob- ability rates of the components of Event G15 “Failure of the outlet pipe of SEP- 1 ”. In the specific case of event E15-2, where no “generic” data was found, the user establishes the possibility of failure with a fuzzy evaluator: “Extremely remote”. A fuzzy logic analysis is performed by FTAES to infer the probability of failure. Data inconsistencies were also found by the system between events E15-1 (‘reasonably probable”) and E15-4 (‘frequent”). The local rate of E15-1 (0.78) is higher than the local rate of E15- (0.22). The generic data disagrees with the corresponding fuz- zy rates. A warning message is shown to the user, in order to correct the inconsistencies or accept the system suggestions. In this case, the system is responsible for the probability distribu- tion arrangements. FTA expert systems gather, into a single program, experts’ experience, available algorithms, and the databases required for FTA, in order to improve the user’s productivity and the quali- ty of results. The primary benefit of structuring FTAES into a blackboard architecture is the potential use of multiple experts for various stages of the FTA. This architecture can accept any knowledge type, and seems to be a reliable mechanism to in- tegrate databases and procedures with the knowledge base. A fuzzy methodology for fault-tree evaluation seems to be an alternative solution to overcome the drawbacks of the con- ventional approach (insufficient information concerning the relative frequencies of hazard events). To improve the quality of results, the membership functions must be approximated based on heuristic considerations. Process fault-diagnosis systems can be included as knowledge sources of the FTAES blackboard to update automatically the failure database of the system. Conventional algorithms for MCS were represented with object-oriented programming. No further developments were made to improve the efficiency of such procedures. The pur-

pose of this work is to describe the knowledge engineering ap- proach, directed to integrate the various sources of knowledge involved in a FTA. Future developments foresee automatic fault-tree genera- tion. The fault tree can be automatically created from the sub- trees stored at the FTAES database.

REFERENCES

[I] F.A. Patterson-Hine, B.V. Koen, “Direct evaluation of fault trees^ us- ing object-oriented programming techniques”, IEEE Trans. Reliability, vol 38, 1989 Jun, pp 186.192. S. Garriba, E. Guagnini, P. Mussio, “An expert system for tree con- struction”, Proc. Ann. Reliability & Maintainability Symp, 1985, pp 82-88. K.M. Kurzawinski. R. Smurthwaite, “Automated fault tree analysis via AIIES”, Proc. Ann. Reliabiliw & Maintainability Symp, 1988, pp 331-335. [4] A. Poucet, “STARS - Knowledge based tools for safety and reliability analysis”, Reliability Engineering and Safety. vol 30, num 1, 1990, pp 379-397.

[2]

[3]

I

I

M. Elliot, “Knowledge-based systems for reliability analysis”, Proc. Ann. Reliability & Maintainability Symp, 1990, pp 481-489. Gensym Corporation, “G2 Reference Manual for G2 V2.0”. 1990; Cam- bridge, MA. Teixeira, Kaszkurewicz, Bhaya, Ebecken, Filho, Bogarin, Xerez, “A knowledge-based system for fault detection and diagnosis in oil produc- tion plants in offshore platforms”, I11 World Congress International Federation of Automatic Control, vol 5, 1993, pp 279-282; Sydney, Australia. D.M. Himmelblau, “Fault detection and diagnosis in chemical and petrochemical processes”, Chemical Eng. Mon, vol 8, 1978. I.S. Kim, M. Modarres, “Application of goal tree - success tree model as the knowledge-base of operator advisory systems”, Nuclear Eng. and Design, vol 104, 1987, pp 67-81. L.W Chen, M. Modarres, “Autonomous decision making expert system for fault administration”, Published G2 Success Stories, 1990; Gensym Corporation. R.P. Patton, R. Clark, Fault Diagnosis in Dynamic Systems: Theory and Applicarions, 1989; Prentice Hall. P.S. Dhurjati, Preprints of the IFAC Symposium on On-line Fault Detec- tion and Supervision in the Chemical Processes Industries, 1992; Univ. of Delaware, Newark. C. Sundararajan, Guide to Reliability Engineering, 1991; Van Nostrand Reinhold. D. Blockley, Engineering Safety, 1992; McGraw-Hill. R. Ramakumar, Engineering Reliability: Fundamentals and Applications, 1993; Prentice Hall. Neuron Data, ‘“EXPERT OBJECT V2.0 Programmers Reference Manual”, 1991; Palo Alto, CA.