# Functional Safety Suite 7.0
User’s Guide

#### 5Event trees

##### 5.1Introduction

Event tree analysis is a universal method of a quantitative risk analysis. Starting with the identified hazard, all possible direct consequences due to the possible cases of one condition are identified. Each possible case of the condition is assigned a probability. Only one case of the condition can be true at a particular time, thus one case excludes all other cases of this condition. A condition typically describes the existence of a certain constraint outside the technical system, e. g. the presence of people in the danger zone. For each case of the first condition, the subsequent consequences due to the cases of another condition are identified and so forth, up to a final consequence. This final consequence is the damage, characterized by its severity. If the consequence is “no damage”, its severity is zero.

The risk R related to a certain hazard is the sum of all n severities si multiplied by the specific probability pi of occurrence of this severity si if the hazard occurs and finally the hazard rate hhazard:

A risk graph is just a simple event tree, thus a risk graph can easily be replaced by an event tree.

Features of Functional Safety Suite related to event trees:

- • Conditions with more than two cases.

- • Several models for cases, including links to fault trees, Markov models and complex components.

- • Two evaluation modes:

  - – Calculation of the risk R, given a hazard rate hhazard

  - – Calculation of the tolerable hazard rate (THR), given a tolerable risk

##### 5.2The Event Tree Properties Panel

Properties of the overall event tree are displayed and edited in the event tree properties panel, see figure 15. All these values are stored in the event tree file (extension `.etf`).

Figure 15: The event tree properties panel

###### 5.2.1General Properties

Description: A user defined description of the event tree.

###### 5.2.2Presentation Properties

Note that in case the presentation related features don’t fulfil your needs, you can export all graphics in SVG format for further processing by vector graphics tools.

Horizontal offset: The margin between the window border and the left end of the hazard line.

Vertical offset: The margin between the window border and the first damage.

Condition width: The width of each condition column. Default is 150 pixel.

###### 5.2.3Values

Tolerable Risk: If the THR shall be calculated, here the tolerable risk is to be entered. The unit is Damage Equivalents per hour (DE/h).

Actual Hazard Frequency: If the risk shall be calculated for a given hazard frequency according to the selection in the project properties dialog, here the hazard frequency is to be entered.

##### 5.3The Condition and the Crotch Properties Panel

Each pass from one consequence to the consequence(s) of the next condition is a crotch. Each condition has as many crotchs as there are lines in the preceding condition: The first condition C1 has one crotch, since there is only one hazard. The second condition C2 has as many crotchs as the first condition has cases nC1, the third condition C3 has crotchs and so on (except if the always flag is set, see below).

A condition is always selected together with one of its crotchs and vice versa, i. e. when you click on the default case or always case. Therefore the condition properties panel and the crotch properties panel are shown at the same time.

The parameters of conditions and crotches are stored in the event tree file (extension `.etf`).

Figure 16: The condition and the crotch properties panels

###### 5.3.1Condition Properties

Name: A user defined identifier of the condition.

Description: A user defined description of the condition.

###### 5.3.2Crotch Properties

The lowest case of each crotch is usually the default case, which is the negated of all other cases of the crotch. However often due to the specific case of the previous condition, the cases of further conditions don’t matter any more. If so, select the crotch by clicking on the default case and set the always flag in the crotch properties panel on the left – the crotch will be reduced to only one case with probability p=1.0. If you de-select the flag, the crotch will be expanded again, replicating the further branch for each case of the condition.

Note that selecting a crotch by clicking on the default case or the always case will also select the related condition.

##### 5.4The Case Properties Panel

A case of an event tree consists of the reference to the generic basic event, defined by its package and name, and the properties of this generic basic event.

Figure 17: The case properties panel

###### 5.4.1Case Properties

Package: Select whether the generic basic event is in the library of the global package or of the local package.

Name: The identifier of the generic basic event. You can select a name (and by this the referred generic basic event) out of a list of the generic basic events belonging to the selected package.

###### 5.4.2Generic Basic Event

All parameters in this section belong to the generic basic event, thus they are stored in the library. Whenever one of these values is changed, this will effect also all other basic events and cases referring to this generic basic event, even in other models.

5.4.2.1General Properties

Description: A user defined description of the generic basic event.

5.4.2.2Model

The probabilistic model of the generic basic event. See section 4.3 for details.

5.4.2.3Values

The values needed by the model of the generic basic event. See section 4.3 for details.

##### 5.5The Damage Properties Panel

The final consequence is called damage, even if the severity is 0 (“no damage”). Typically several paths (via different cases) will lead to the same final scenario. Each possible scenario is called generic damage, describing its severity. The list of generic damages is part of the event tree and therefore stored in the `.etf` file. For each path, the severity can be selected out of the list of generic damages.

Figure 18: The damage properties panels

###### 5.5.1General Properties

Name: A user defined identifier of the generic damage. Since damages with same name refer to the same generic damage, all other damages with the same name will be changed too whenever a property belonging to the generic damage is changed in the damage properties panel.

You can select a name (and by this the referred generic damage) out of a list of the generic damages already created for this event tree.

Description: A user defined description of the generic damage.

###### 5.5.2Values

The damage equivalent, indicating the severity of the damage.

##### 5.6Editing of Event Trees

After creation of a new event tree by File – New Event Tree a most simple event tree is shown.

The hazard is represented by the leftmost horizontal line. I can be selected by clicking on this line or somewhere above or below. If the hazard is selected, it is marked by a thicker, blue line and the event tree properties panel is shown on the left.

The damage is shown as rectangle on the right, including its name (“Default”) and its severity in units of Damage Equivalents (DE). The name is given by the underlying generic damage. It is selected by clicking on it. If selected it is marked by a thick, blue border and the damage properties panel is shown on the left.

Usually there is not only one single, immediate consequence if the hazard occurs, but also other consequences leading to different damages, due to one or multiple conditions. A new condition is created and inserted by selecting the hazard (or a previous condition, see below) and Edit – Add Condition.

Each condition can take one or multiple cases. Each case has a certain probability that it is true when the hazard occurs. The sum of the probabilities of all cases of one condition must be equal to 1. Thus there is a default case, that applies if no other case is true. When a new condition is created, only the default case is created.

A condition is selected by clicking anywhere in the column belonging to the conditionexcept on a line representing a specific case. If a condition is selected, its name and description is shown in blue text and the condition properties panel is shown on the left (see figure 16), so that name and description can be edited.

After selecting a condition, a case can be added to the condition by Edit – Add Case. Each case refers to a generic basic event, which determines its probability. Typically the immediate event model is used, allowing to directly enter the probability p. But also all other models that deliver a unavailability can be used, including links. When adding a case, the new case will refer to the last generic basic event in the local library.

A case is selected by clicking on one of the lines representing it. If selected it is marked by a thick, blue line and the case properties panel is shown on the left (see figure 17). Here you can change the generic basic event the case refers to. A new generic basic event is created by Library – New Generic Basic Event.

An event tree that has not been saved after the latest modification is marked with an asterisk ‘*’ in its title.

##### 5.7Hints and Recommendations

If there are (multiple) conditions that must be fulfilled such that a (severe) damage can occur, the definition of the hazard is not unambiguous. For example think about a fire in a plane. You can define the burning paper in the toilet as a hazard, but you could also define the burning toilet room as a hazard, or you could consider all kinds of fire in other hazards, like loss of control equipment, loss of clean cabin air or loss of structural stability. Therefore you should clearly describe the relation between the identified hazards, thus that the sum of all hazard analyses has neither gaps nor significant overlaps. In particular, you should verify, that all identified hazards are “on the same level”, i. e. that not one “hazard” is in fact just one basic event for another already defined “real” hazard.

In addition, depending on the definition of the hazard(s), the border between risk analysis and hazard analysis will shift significantly. As a general rule, you should never model barriers in an event tree, that rely on the correct function of technical elements (“active barriers”, barriers that can fail on demand, i. e. PFD>0) that are part of the system under assessment, but only barriers that either exist independently of the system under assessment or that cannot fail on demand (PFD=0, i. e. “passive barriers”). That means, that the hazard should be defined in that way, that it includes the failures of all technical elements (as for example smoke detection and fire suppression systems).

If you — for whichever reason — consider active barriers in an event tree anyhow, it is mandatory to limit the PFD’s to values, that reflect the systematic capabilities of the active barrier. E. g. for a barrier developed according to [EN 61508] for a safety integrity of SIL 2, its unavailability must not be set to values less than 1e-3 even its calculated PFD (by FTA or Markov model) is less. In addition, absence of common cause failures to the hazard or other barriers must be proven.