Knowledge-based support for event tree construction

Reliability Engineering and System Safety 30 (1990) 65-78

Knowledge-Based Support for Event Tree Construction

Roar Fjellheim

Computas Expert Systems, PO Box 410, 1322 Hovik, Norway

&

Joseph Fiksel*

Teknowledge, Inc., PO Box 10119, Palo Alto, California 94303, USA

A BSTRA CT

A prototype system called EventMAP has been developed to provide knowledge-based support for event tree construction. It comprehends an event tree model of a physical system, which represents the possible event sequences

following an initial incident. This model can be used to identify potentially hazardous accident or failure scenarios, to help in assessing the possible outcomes of an observed incident, and to support decisions about appropriate actions. It can also be used during modification to provide insights into the needs for specific safety features.

EventMAP incorporates exp6cit knowledge about safety engineering and good event tree construction practice. This assures that model building will be more systematic, and will produce more complete and correct event trees. Assumptions underlying the model are tracked explicitly, allowing 'what-if' exploration. Moreover, the safety-related design rationale will be preserved despite personnel changes over time. EventMAP incorporates knowledge about: plant structure in terms of subsystems, components, and interconnections; cause~effect relationships and other interactions among subsystems; and failure modes, including human errors. The role of EventMAP is to act as an 'intelligent assistant' for the event tree developer; it monitors the evolving model and issues suggestions and warnings to the user as appropriate.

* To whom correspondence should be addressed.

65 Reliabili O' Engineering and System Safety 0951-8320/90/$03"50 © 1990 Elsevier Science Publishers Ltd, England. Printed in Great Britain

66 Roar Fjellheim, Joseph Fiksel

1 BACKGROUND AND MOTIVATION

While modern technology has achieved a remarkable degree of reliability in the operation of complex industrial plants, several serious accidents during the last decade have highlighted the need to properly analyse and manage the 'low-probability high-consequence' risks associated with plant operations in the chemical, nuclear and other industries. Formal risk analysis methods are indispensable tools for this task, and include a number of qualitative and quantitative techniques. ~ While no truly systematic discipline exists for how and when to apply the various techniques, several useful guidelines have been published. 2

As practised today, risk analysis is mainly applied at the early design and construction stages of a plant's life cycle. More often than not, the results of risk studies at these stages are not brought forward for exploitation during subsequent plant operation, maintenance, and modification. Our firm belief is that the knowledge generated through risk analysis can be highly beneficial in these later stages, but that such use is hindered by today's relatively primitive computer tools for risk analysis. Better tools are called for, and we will argue that the technology of knowledge systems is particularly relevant for building such tools? Knowledge systems are a class of artificial intelligence systems that have the capability to store and process qualitative human knowledge, including heuristic knowledge and causal relationships. 4

While the preceding comments indicate the broader goals of our work, the present paper focuses on a particular issue: computer support for event tree construction. The event tree technique is a risk analysis method for exploring possible consequences of an undesired incident. 2 An event tree model represents the possible event sequences following the incident as a branching tree, where each branch corresponds to a set of mutually exclusive probabilistic alternatives. Such models can be beneficial at several different stages in the life of an industrial plant:

• During design of the plant, event trees can be used to identify potentially hazardous accident or failure scenarios, each of which can then be evaluated with respect to safety standards.

• During operation of the plant, an event tree may be used as a decision support tool for dynamically assessing the possible outcomes of an observed incident and taking appropriate actions (e.g. Ref. 5).

• During modification of the plant, which often involves personnel that did not participate in the initial design, an event tree can provide insights into the needs for specific safety features.

Though event trees can be valuable, building event tree models of a large industrial plant is a non-trivial task, requiring in-depth understanding of

Knowledge-based support for event tree construction 67

the plant systems and their interactions with operators and the environment. In particular, understanding how various types of event dependencies arise provides an important source of knowledge for constructing trees. Moreover, the sheer size of a realistic event tree creates a book-keeping problem, especially if the tree is to be updated as the plant is modified. For these reasons, it is highly attractive to support event tree construction with better computerized tools, specifically tools that incorporate explicit knowledge about safety engineering and good event tree construction practice. The potential advantages of a knowledge-based approach are:

• Model building will be more systematic, and will produce more complete and correct event trees.

• The system will take care of low-level organizational tasks, letting the analyst concentrate on high-level issues.

• Assumptions underlying the model will be tracked explicitly, allowing systematic 'what-if' exploration.

• With proper design, knowledge bases will be reusable in different circumstances, thereby leading to more efficient analyses.

• The safety-related design knowledge will be preserved despite personnel changes over time.

To realize the maximum benefit of a computerized support system for event tree construction, an integrated system environment is desirable. Such an environment would include other risk analysis tools, data bases of observed failure rates, simulation models, knowledge maintenance systems, and appropriate man-machine interfaces. While others have explored these broader integration issues, 6 this paper focuses on the rationale and design principles for EventMAP, a prototype knowledge-based system for event tree construction.

It is important to note that EventMAP is not an expert system in the traditional sense; rather than supplanting human expertise it facilitates the performance of a task by competent humans. Thus it falls into the class of 'intelligent support systems' which provide knowledge-based assistance to professionals. 7

2 THE ROLE OF EVENT TREES IN RISK ANALYSIS

As mentioned earlier, the event tree technique is a consequence-exploration tool. Starting from an initial trigger event, the technique is used to create a systematic mapping of possible ensuing event sequences. The result is a branching tree, where each fork represents the occurrence (or non- occurrence) of an event. The endpoints are possible final outcomes, i.e. possible scenarios. For example, in a plant the trigger event might be a pipe


rupture. Depending upon the behaviour of plant operators and various safety systems, this incident might escalate to a major accident, or might quickly be detected and contained.

The event tree technique is inherently an inductive tool, and can be contrasted with the deductively oriented fault tree technique, which for a final outcome ('feared event') analyses how it could have come about as a combination of more basic events. Together they constitute an important part of the risk analyst's tool kit for assessing failure causes and consequences, in particular in man-made and well understood systems, such as chemical process plants and power plants. The methodology of cause- consequence analysis formally combines these two techniques. A large body of literature exists that describes the techniques in detail, including formal properties, graphical notation, qualitative and quantitative evaluation, and hints for practical application. 2

Figure 1 (taken from Ref. 1) illustrates a typical event tree. It is the result of the analysis of a Loss of Coolant Accident (LOCA) at a nuclear power plant. The labels across the top of the figure are fork labels (PB -- pipe break, EP -- electric power, ECI = emergency coolant injection, etc.). At each successive level of the tree, starting from the leftmost initiating event (PB), the function corresponding to a label may succeed (upper branch) or fail (lower branch). Along some paths (e.g. ECI when EP has failed), no split is shown, because previous events have made the fork superfluous. The far-right end-tips of the tree (labeled S1, $2, etc) denote the final outcome scenarios of the analysis.

Each branch in the tree may be qualified by a probability of the corresponding event occurring. This probability will be conditional on the occurrence of the other events on the path leading from the trigger event to the event in question. Often this probability can be found by performing a fault tree analysis with the event in question as the top ('feared') event of the fault tree. (In fact, this is how event and fault trees are integrated.) The

PB, EP EC1 PARR PAHR ECR C1

Fig. 1. Example event tree,

$1 $ 2

S3 S4

$5 S6

S7 $8 $9

$10 $11

$12

$13


Event tree Scenario construction ~ Scenarios -----} assessment (EventMAP) (RiskMAP)

't Probabilities ~l, Recommendations

Fault tree Can be fed back to event/fault trees construction to try different assumptions

Fig. 2. Relationships between risk management tasks.

probability of the endpoint scenario can then be calculated as the product of the probabilities of all branches along a particular path. This information can be useful to a risk manager, for example in assessing the alternative options for risk mitigation.

Even in the absence of numerical probabilities, the risk manager will be able to use the information implicit in the event sequence leading to the scenario. That path has left a 'signature' in the form of specific system (failure) states. Assessing and comparing this state information for different scenarios can provide important decision-making input. For example, scenarios can be evaluated through the application of RiskMAP, a a system related to EventMAP which shares some of its design principles. RiskMAP was designed to provide assistance to professional risk analysts and decision-makers in diverse fields. It allows users to express their knowledge about possible risk scenarios and decision criteria. Then it can systematically screen, evaluate and compare alternative scenarios and recommend action priorities.

Figure 2 illustrates the relationship between the various types of risk analysis tasks mentioned above, each supported by computer tools. EventMAP is used to generate scenarios for possible failure situations, which can then be evaluated by RiskMAP. Basic probability information can be provided from statistical/empirical data, or be derived from fault tree studies. There is currently no MAP companion program for the latter task, but several computer systems for assisting fault tree construction are commercially available.

3 A KNOWLEDGE-BASED APPROACH TO EVENT TREE C O N S T R U C T I O N

Constructing an event tree for a plant is clearly a knowledge-intensive activity. The types of knowledge that are required include:

• Knowledge of the plant structure, i.e. its system/subsystem decompo- sition, the characteristics of its components, and their interconnections.


• Knowledge of plant behaviour, i.e. cause/effect relationships, transport delays, and other interactions.

• Knowledge of failure modes of plant components and safety systems, as well as possible operator errors.

• Knowledge about the event tree technique itself, how to use it effectively, and its limitations (e.g. difficulty in analysing interlocking event sequences).

The EventMAP system is a knowledge system that contains an explicit representation of the kinds of knowledge listed above. The intended role of the system is to act as an intelligent assistant for the event tree developer (user), who is assumed to be acquainted with the technique, but not necessarily an expert. The knowledge base supporting the event tree construction may be input by the user, or by some other person with special expertise in the systems being studied. This is illustrated by Fig. 3.

In designing knowledge systems, selecting appropriate knowledge representation formats is a basic premise for success. The knowledge representation of EventMAP is centered around the the following formats:

• Structure: There is a format for describing system components and their interconnections.

• Events/forks: There is another format for describing events and event tree structures.

• Dependencies: Finally, dependencies between events, and between events and structures, are expressed in a third format.

For industrial plants, the main structural items to be represented are components (valves, pumps, pipes, etc.). A full formalism for plant descriptions would include the hierarchical structure of the plant, i.e. how systems are composed of subsystems down to the basic component level, and the system interconnections, e.g. component 'ports', linkages, flow direction, and physical proximity. In the EventMAP prototype this structural detail has been kept to a minimum, since all of the above can rely on well established techniques that can be included in a fielded version of the software.

Use r

Expert

Fig. 3.

Intel l igent editor

T Knowledge

base

Event trees

EventMAP

User and components of EventMAP.


evl

ev2

ev3

Fig. 4. A fork with three possible event outcomes.

An important aspect of the structural description is the notion of component state. Each component is assumed to be in a specific state at any given time. The number and identities of a component 's states are fixed by the knowledge base author. In addition to the state identifier, a state can be qualified by the values of any number of component attributes, chosen to provide sufficient information for risk analysis.

An event is an occurrence that is relevant to the risk analysis, e.g. a state change of a component or an external event (e.g. power failure, fire). Event trees are composed of events and forks, the latter denoting a branching node in the tree, as shown in Fig. 4.

The causal sequence flows from left to right, starting from the trigger event. At a fork the scenario splits into one or several alternative paths, each of which may feed into a new fork. There are several different types of forks, including failure or success of a built-in safety function, alternative operator decisions, and the occurrence or non-occurrence of an external event. In typical risk analysis applications, it is customary to consider a fixed set of forks in a fixed order along all the possible event sequences (these forks can then be listed along the header of the tree diagram). This convention is not necessarily imposed in the current work, though it is used in the example in Fig. 1.

For each fork a number of outcome events are defined, and a priori conditional probabilities may be associated with each outcome (summing to 1). In general, the actual probability of an outcome event branch will be conditional upon the events that have occurred on the path leading to that outcome event.

With respect to the third knowledge form of EventMAP, there are three basic types of dependencies addressed, as illustrated in Fig. 5 (where the second event occurs later that the first one). Each type of dependency

Event E ~ E Event \ / E ~ S S ~ E

\ / Structure

Fig. 5. Different types of dependencies.


constrains the temporal evolution of the event sequences, as opposed to the 'full' tree where any sequence of forks is possible, and all outcomes are possible at each fork. Here are some such constraints:

• A failure in one safety system may make another safety system irrelevant or superfluous, thereby making it unnecessary to consider the corresponding fork.

• A failure in one system may cause a failure in a connected system, thereby forcing the failure outcome of the corresponding fork.

• A failure in one system may disable another system (e.g. a power cut will disable EL-driven devices), again forcing a subsequent fork outcome.

A short description of each dependency type follows:

• E ~ E: This is a 'phenomenological' type of relation, possibly based on empirical data, or used in cases where one wishes to ignore the true nature of the dependency.

• E--~ S: An event may affect a component (as stated above), causing it to fail, disabling it, or otherwise changing its state.

• S ~ E: Conversely, given information on a component 's state, it may be possible to derive or constrain subsequent event sequences.

Having these dependencies described in the system allows it to auto- matically propose or eliminate specific event sequences. Alternatively, the system can be used in training mode to validate the user's model-building choices.

4 EVENTMAP: A PROTOTYPE SYSTEM

The concepts presented in the previous section have been implemented in a prototype system, running on the IBM PC/AT. Building of practical knowledge systems is greatly facilitated by using expert system shells, 4 generic software tools that contain the necessary mechanisms for represent- ing and using various kinds of knowledge (facts, rules, procedures), ready to be filled with specific knowledge for a particular domain. For EventMAP, we chose to use the M.1 (tin) tool of Teknowledge, 9 a general-purpose, PC- based system with a logic-like knowledge representation scheme (similar to Prolog).

The EventMAP system has a menu-oriented user interface, where the functions invoked by the top level menu choices are as follows (some of the functions are only rudimentary in the prototype):

• Editing (entering, modifying and deleting) plant descriptions, i.e. components, their state attributes and their interconnection.


• Editing fork/event descriptions, including enumeration of forks and their possible outcomes (with branching probabilities).

• Editing dependency relations of the various types described earlier. This information is the key to providing high level support for event modeling.

• Intelligent prompting/editing of event trees, given a trigger event and a fork sequence (see comments below on this function).

• Scenario presentation of the final outcomes of the various event paths, i.e. the sequences themselves and the final states of involved components.

The main function of the system is event tree construction. While in this mode, the user sees at all times a screen window showing the current path he is working on, indicating all events on that path (the prototype version uses only a primitive graphic representation). At a fork node in the tree, the user may either:

• navigate, i.e. follow one of several already established branches or!back up towards the trigger event,

• ex t end the tree by adding one or more branches, or • prune the tree by deleting one or more branches.

As the user performs editing functions (extend/prune), the system monitors the evolving model to decide whether any of the dependency definitions in the knowledge base apply. If so, it generates ('posts') a constraint into a dynamic data base. The set of constraints is used by the system to issue suggestions and warnings to the user as appropriate. The user is however in charge at all times, and may choose to disregard the system's comments. Examples of proposals the system may provide, based on dependency-generated constraints, include:

• One particular outcome of a fork may be uniquely indicated, for example due to a causal relation.

• One or several outcomes may have been eliminated from consideration, narrowing down the options the user must evaluate.

• The fork may have been eliminated altogether from that particular path, allowing the system to proceed directly to the next in sequence.

• The fork sequence may have been altered (violating an event tree convention, but nevertheless quite plausible).

In each case, the knowledge contained in the knowledge base allows the system to provide guidance to the user, and more importantly, to reduce the number of alternative paths he must consider. The latter is significant, because one of the often stated objections to the event tree method is the potentially very large size of realistic trees.


Tree Sequence Event Fork Dependency Component State Exi t -- EventMAP DISPLAY

examp 1- init iator : (pb)

:pb electric_ power : (ep_su¢c0 ep-fa i l )

"ep_fail

emergency_ coola nt_ injection :( eci _fail ) :eci_fail

post .acc ident _ radioact iv i ty_ removal: ( )

Question The occurence of ep_fail at the earl ier

electric power fork caused the component

injector into state disabled, which in turn

causes parr_fail at this fork,

Aflswer Parr_fa i l

unknown

Select event Space to Mark

F2Scrol l F9Mode F lOMenus M.1 Teknowledgeinc

Fig. 6. Example of user interface screen.

CF

90

READY

An example of how the prototype system appears to the user is shown in Fig. 6. (The upper, larger window contains vertically a crude representation of one path through the tree; the leftmost bottom window is the system's display/prompt area; and the rightmost bottom window is a menu selection area). The user has entered the initial parts of an event tree (the same as was shown in Fig. 1), and is about to expand the post_accident_radioactivity_ removal fork. The system detects that since electric_power previously failed on the current path, the injector component is disabled, and the only possible choice to consider is injection failure.

Before ending this section, we provide a brief glimpse of the knowledge base implementation. A powerful unifying idea in knowledge representation is to classify the various entities occurring in a domain in separate classes (which may have subclasses), and define the various attributes that will be used to describe all member instances of that class. Having built such a classification scheme, one can then use it as a common 'vocabulary' in all the

class = C. A I ( C ) = T 1 . A2(C) = T2.

etc.

member(C) = M. A l o f M = V 1 .

Fig. 7.

Define C as a class Members of C have attribute AI , A2, etc. Values constrained by value type TI , T2, etc.

M is a member of the class C. The value of attribute A1 of member M is VI

Format for describing classes, attributes and members.


class = dependency. dependency_type(dependency) = [cause, enable,

prevent, ignore_fork]. source_fork(dependency) = fork. source_event(dependency) = event. targeLfork(dependency) = fork. targeLevents(dependency) = [event]. category(dependency) = [common_cause, functional_dependency,

shared_equipment, physical_interaction, human_interaction].

member(dependency) = ep_eci. dependency_type of ep_eci = cause. source_fork of ep_eci = electric_power. source_event of ep_eci = ep_fail. target_fork of ep_eci = emergency_coolant_injection. targeLevents of ep_eci = [eci_fail]. category of ep_eci = functional_dependency.

Fig. 8. Example of a class and member definition.

processing to be done by the system. Classes~are not an inherent facility of M.1, but a sufficient version of the facility can easily be built using M.1 primitives. In our case, the notat ion shown in Fig. 7 is used (in actual fact, a slightly more verbose form is required).

The type definition of an attribute may indicate that the value should be a number, a specific symbol selected from a list, reference to a member of another class, any value, or a list of one of these possibilities. As an example of how this is used, the definitions listed in Fig. 8 describe the concept of a dependency (of the event =:, event type) and one instance of that class.

The knowledge representation form is quite readable, but not the one the user is expected to employ in the editor functions of the system. These are based on prompting and menu selection. Of course, if the user had to enter detailed dependency information of the kind shown above for each individual event tree, little effort would be saved compared to building the tree directly. Our claim is that it is possible to create generic knowledge bases for classes of components/plants, in such a way that reuse from one model to another is possible. Without such reuse, the benefit o f an EventMAP system will be in quality and completeness, but not in productivity.

5 R E L A T E D W O R K A N D F U T U R E D IR E C T IO N S

The utilization of computer tools in risk analysis has largely been restricted to the analysis of risk models, such as the cut set and probability calculations of fault trees. More recently, tools have begun to appear that also support


the synthesis of risk models. Most commercially available systems are data entry and checking systems, often combined with graphical presentation of fault and/or event tree structures. Useful as such systems no doubt are, they do not claim to give qualified support to the more conceptual aspects of model building.

Going one step further, some systems have been reported that aim at higher-level support, even automation, of risk model construction, in particular fault trees. 1 o A common trend in these attempts is to move from early reliance on 'mini fault trees' or model fragments that could be joined together in larger systems, towards a more fundamental attempt to derive risk models directly from the structure of the plant under investigation. An interesting example of this is the GO-method;1 ~ which basically translates a plant flow diagram into a corresponding risk model. An objection to automating the model building is that it does not encourage the risk analyst to creatively think through possible failure mechanisms. In general, the systems that have been built to automate this task paper appear to date to have met with limited success, and none are in widespread use.

We have claimed in this paper (and we are not alone, see for example, Ref. 12) that artificial intelligence, and in particular knowledge systems, offers a fresh set of tools for attacking risk management problems. It is interesting to note that the trend mentioned above, towards reliance on plant descriptions as sources for risk models, closely parallels a development in the field of artificial intelligence. So-called deep models and qualitative reasoning 13 provide concepts and inference procedures for describing the behaviour of systems (e.g. machines) in terms that resemble those used by humans when reasoning about the same objects. Having a library of such models available would be a tremendous source of information for event tree construction. Unfortunately, the research in this area is not yet sufficiently mature for widespread use.

Related developments of equal interest t o designers of intelligent risk analysis tools include work on constraint-based, causal and temporal reasoning. The first of these allows expression of, and computation with, various forms of relations that must remain true in for example a design effort. The relevance to our use of dependency information is evident. Causal reasoning is defined in Ref. 14 as consisting of 'inferences about the behaviour of systems or mechanisms for the purpose of explaining past observations or predicting future events'. This usually involves con- ceptutalizing events, states, causal links, etc., as we have done in EventMAP. More recent research also considers continuous systems; 15 reprinted in Ref. 13. Intertwined with this research is work on representation of temporal phenomena, also of great interest to risk analysis. Some elements of a system that manages temporal information is reported in Ref. 16.


Extending the work reported in this paper, and drawing upon research and established results in the two areas of risk analysis and artificial intelligence/knowledge systems, we believe substantial progress can be made in several promising directions:

• With richer models of the plant structure and behaviour, even more qualified support to event tree generation can be provided, including partial automation of the process.

• In order to ensure reusability of results, efforts should be made to clearly progressively structure knowledge bases working from generic layers to industry-specific layers to plant-specific layers, thereby mini- mizing the marginal cost of new risk analysis projects.

• Transforming event tree structures to a form that can support real-time decision-making in emergency response situations is of strong interest, but may require further work in the area of temporal logic, as well as face efficiency issues.

In addition to these research directions, substantial software engineering effort will go into making EventMAP a truly useful tool to risk analysis professionals. Finally, we reiterate the need to integrate the event tree technique and other methods in more comprehensive systems for risk management.

A C K N O W L E D G E M E N T S

This work was conducted while Mr Fjellheim was a visting scientist at Teknowledge, Inc. It was partially supported by NSF Grant No. PRA- 8512977.

REFERENCES

1. McCormick, N. J., Reliability and Risk Analysis. Academic Press, New York, 1981.

2. PRA Procedure Guide, A Guide to the Performance of Probabilistic Risk Assessments for Nuclear Power Plants. US Nuclear Regulatory Commission, 1983.

3. Fiksel, J., The impact of artificial intelligence on the risk analysis profession, Guest Editorial. Risk Analysis, 7(3) (1987) 277-80.

4. Hayes-Roth, F., Waterman, D. A. & Lenat, D. B., Building Expert Systems. Addison-Wesley, New York, 1983.

5. Touchton, R. A., Gunter, A. D. & Subramanyan, N., Automated reasoning with dynamic event trees: a real-time knowledge-based decision aide. Reliability Engineering and System Safety, 22 (1988) 333-53.

78 Roar Fjellheirn, Joseph Fiksel

6. Fedra, K., Advanced decision-oriented software for the management of hazardous substances: A prototype demonstration system. Technical Report, IIASA, Laxenburg, Austria, 1985.

7. Fiksel, J. & Hayes-Roth, F., Knowledge systems for planning support. IEEE Expert (Fall 1989).

8. Fiksel, J., Potential applications of knowledge system technology to biotechnology safety assurance. In Safety Assurance for Environmental Introductions of Genetically-Engineering Microorganisms. Springer-Verlag, Berlin, 1988.

9. M.11Reference Manual, Version 2.1. Teknowledge, Inc., 1986. 10. Taylor, J. R., An algorithm for fault-tree construction. IEEE Transactions on

Reliability, R-31(2) (June, 1982). 11. E1 International, Inc., GO Software Version 3.0. Technical Report NP-5656-

CCM, EPRI, Palo Alto, CA, 1988. 12. Avouris, N. H., Van Liedekerke, M. H. & Argentesi, F, An intelligent

information system for management of chemical emergencies. Technical Report, Commission of the European Communities, Joint Research Centre, Ispra, Italy, 1988.

13. Bobrow, D. G. (ed.), Qualitative Reasoning about Physical Systems. MIT Press, Cambridge, MA, 1985. Reprints contents of Journal of Artificial lntelligence, 24 (1984).

14. Shapiro, S. C. & Eckroth, D. (eds), Encyclopedia of Artifical Intelligence. John Wiley, New York, 1987.

15. Forbus, K. D., Qualitative process theory. Journal of Artificial Intelligence, 24 (1984) 85-168.

16. McDermott, D. & Charniak, E., Introduction to Artificial Intelligence, Addison- Wesley, New York, 1985, Chapter 7.4, pp. 416-33.

Documents

Knowledge-based support for event tree construction