[next] [prev] [prev-tail] [tail] [up]

### 2 Introduction and user interface

When developing a new technical system, authorities, regulations, standards or just corporate rules due to manufacturers liability usually request a risk assessment (or risk evaluation) to be performed. A risk assessment typically includes three stages:

1. Hazard identification 1 :

  Typical methods are to use existing lists, performing a system FMECA or just “brain storming”. However, this is out of scope of Functional Safety Suite.

2. Risk analysis:

  Determine the possible consequences of each hazard, including the severity of each consequence and its occurrence probability (given the hazard exists). Depending on the risk acceptance criteria or principle, the risk analysis often includes the judgment, whether the residual risk is acceptable or not. Non-functional risk-reduction measures might be considered in the risk analysis already. Mitigation by safety related functions shall not yet be considered in the risk analysis step, but in step 3.

3. Hazard analysis:

  Identify the causes and conditions for the occurrence of each hazard. If several sub-systems are related to the occurrence of a hazard, this analysis must be performed on overall system level and for each of the sub-systems. Note that on some sub-system level, the failure of the sub-system might not lead to the hazard directly, thus ‘hazard analysis’ should be replaced by ‘failure analysis’ in that case.

Note that the terms risk analysis and hazard analysis might be used differently in some standards and norms, however in this guide they are used as defined above, which is consistent to [EN 50126].

#### 2.1 Principles

With the aid of Functional Safety Suite risk assessment will look as follows:

1.
  Create project:
  Click File – New Project, select name and directory. Click File – Project Properties, set values according to the characteristics of the project. See section 3 for details.
2.
  Perform risk analysis for each identified hazard:
  A universal and therefore frequently used method for quantitative risk analysis is the event tree method. The event tree method is kind of a super-set of the risk graph method, i. e. each risk graph can be converted to an event tree, but not each event tree can be converted to a risk graph, since an event tree provides much more possibilities. If the risk acceptance criteria is defined as an explicit value (e. g. in terms of “damage equivalent per hour and unit”), the result of a risk analysis is a THR for each hazard. 2 See section 5 for details.
3.
  Define an architecture for the system part(s) related to each hazard or safety function:
  An architecture shall describe and define the design of the system (or the system parts) having a particular hazard (or safety function) in mind. Also non-technical elements such as a user or a physical value of a process should be mentioned in the architecture. Starting with version 6.0, Functional Safety Suite provides a graphical editor enabling you to draw architecture diagrams, which are explicitly focused on safety related function and failure analysis, see section 6. If some constraints are considered, the corresponding fault tree structure can automatically be derived from an architecture.
4.
  Perform preliminary hazard analysis and THR apportionment for each hazard:
  The preliminary hazard analysis (PHA) describes and defines the high level architecture of the system related to the hazard down to a level of still independent (or “autonomous”) elements. Also human errors and technical failures outside the technical system to be developed need to be considered. The PHA is typically performed by a fault tree analysis (FTA), see section 7 for details. The output is a set of safety functions for each sub-system, including a TPFD and/or TPFH (or TFFR) for each function.
5.
  Perform hazard analysis (or failure analysis) for each safety sub-function of each sub-system:
  Analyze the technical sub-system that shall perform a safety sub-function with respect to why it could not be able to perform it as intended. This is usually done by a combination of a fault tree analysis (top-down method) and a FMEDA or similar (bottom-up method). The fault tree analysis is a quite simple method to model the architecture of the function in sufficient detail, whereas the FMEDA is a simple and fast method of ensuring completeness of all low-level failures.
  Note: It is often said, that a fault tree wouldn’t be suitable for repairable systems. This is only partially correct. In fact, for repairable systems, the occurrence rate (also called failure frequency) of an event cannot be calculated based on the ‘failure probability’, even though many tools do this. However with some additional algorithms, a fault tree is very well suited for determination of failure frequencies of repairable systems. In Functional Safety Suite the calculation of occurrence rates is based on those algorithms and thus when using Functional Safety Suite, you are highly encouraged to use fault trees instead of e. g. (much more complicated) Markov models for repairable systems. Only in case of systems changing their architecture or major characteristics at certain instances of time (time-variant systems), a fault tree might not be suitable to model the behavior of the system in sufficient detail. In that case a Markov model might be suitable, see section 9.
  Finally each basic event of a fault tree, each block of a RBD, or edge of a Markov model is assigned a generic basic event, determined by its name and description.
6.
  Define generic basic events:
  In the next step, the generic basic events used in the fault trees, RBD’s or Markov models are quantified. For most events, one of the standard models for generic basic events will be suitable. For basic events representing failures of components with several failure modes (including time-variant failure rates), the complex component model (see section 10) can be used together with a generic basic event of type link.
  Sometimes it is useful to describe a sub-sub-system by a fault tree or Markov model of its own. Also in this case, a generic basic event of type link can be used, referring to another fault tree or Markov model, see section 2.4.
7.
  Evaluate the models, e. g. calculate the value(s) of interest, investigate the importance of basic events in order to optimize the system etc.
8.
  Create a report, summarizing all inputs and all results of the risk evaluation, including assumptions and constraints.

Thus finally a Functional Safety Suite project is a collection of models — models of a system in its environment (event trees), models of a system with respect to a certain event or state (fault trees, reliability block diagrams, Markov models), and models of basic events (the generic basic events and complex components) — and algorithms needed for evaluation.

Often multiple elements of the same type are used in a system, so that the failure model of this type of element is needed several times in one or several models. Respecting this fact, in order to facilitate modeling, the probabilistic model of a basic event is given by a generic basic event. Each basic event used somewhere in a fault tree, reliability block diagram, Markov model or event tree is mainly a reference to a generic basic event, optionally extended by some proprietary data (see sections 7.3 for fault trees and 9.3 for Markov models). The reference is represented by the name of the basic event, which is in fact the name of the generic basic event. By this the creation and maintenance of models is significantly simplified, especially the handling of common cause failures and identical events (in [EN 61025] named ‘repeated’ or ‘replicated’ events). The basic events of fault trees are sometimes explicitly called tree basic events, whereas basic events of Markov models are typically called edges, and basic events of reliability block diagrams are called blocks.

In fault trees the combination of basic events is modeled by gates. A fault tree is in principle not suitable to describe the sequence of occurrence of events, but in fact this is not important for the big majority of systems. For the rare cases in which sequence matters, a Priority-And gate might be able to describe the behavior correctly. In Markov models the occurrence of one or multiple basic events results in different states, also depending on the sequence of occurrence.

In contrary to all other kinds of models, complex components are not based on generic basic events, since their failure modes are directly stated in the model, see section 10.

All generic basic events needed in the models of a project are collected in libraries. One library and any number of event trees, fault trees, reliability block diagrams, Markov models and complex components form a package. Any number of packages and some common data valid for all packages build the project.

#### 2.2 The Desktop

##### 2.2.1 The Main Window

The desktop has seven areas:

- The menu bar.
- The tool bar.
- The project tree (shown only if no event or other element of a model is selected).
- A properties panel related to the currently active model, showing either the properties of the model or properties of some element of the model.
- The model graphics tab pane, with the active model presented in the active tab.
- A message output window displaying hints, warnings or errors occurring during file operations and calculations.
- A status bar displaying hints, if an action could not be performed.

Figure 1: The desktop

The data displayed in the properties panel is related to the active model graphics tab.

- If no model is active, only the project tree presenting the members of the project is displayed.
- If a model is active, but no event selected (marked), in the upper section a tree presenting the members of the project is displayed, and in the lower section the model’s properties are displayed, e. g. the description, some visualization related values, some evaluation related values.
- If a complex component is active and a component event is marked, the properties of the marked component event are displayed.
- If an event tree is active and a case is marked, the properties of the marked case are displayed, including the properties of the referred generic basic event.
- If an event tree is active and a crotch including its condition is marked (i. e. a default case or always case), the properties of the marked crotch and condition are displayed.
- If an event tree is active and a damage is marked, the properties of the marked damage are displayed, including the properties of the referred generic damage.
- If a fault tree or reliability block diagram is active and a gate is marked, the properties of the marked gate are displayed.
- If a fault tree or reliability block diagram is active and a basic event is marked, the properties of the marked basic event are displayed, including the properties of the referred generic basic event.
- If a Markov model is active and a state is marked, the properties of the marked state are displayed.
- If a Markov model is active and an edge is marked, the properties of the marked edge are displayed, including the properties of the referred generic basic event.

Further parameters are accessible via dialog frames.

Results such as lists of minimal cut sets/prime implicants, lists of importancies, or graphics of time-variant values will be shown in separate windows.

##### 2.2.2 Floating Window

If you right-click in the heading of a model graphics tab, you can select to show the model graphics tab in a separate floating window. This is helpful to compare two models, in particular if you’ve got a second physical screen.

Multiple model tabs can be moved to the floating window and back again.

Note that in the floating window, not all editing functions might be available.

#### 2.3 Evaluation parameters

For each complex component, fault tree, reliability block diagram and Markov model you can select which system value shall be calculated:

- the mean unavailability Qsys
- the mean occurrence rate hsys and the mean unavailability Qsys
- the unreliability (“failure probability”) after a defined system lifetime or mission time F(T)

For each complex component, fault tree, reliability block diagram and Markov model you can select between steady-state evaluation and transient evaluation (time-dependent evaluation).

There are more parameters depending on the type of the model, see the related sections later in this user manual.

For event trees, there is only one parameter, which affects all event trees in the project, see section 3.4.3.

#### 2.4 Hierarchy of models: Links

Often it makes sense to split a large system into different modules. This is also possible for quantitative risk evaluation. Therefore each complex component, fault tree, reliability block diagram or Markov model can be used as a basic event in another fault tree, reliability block diagram, Markov model or in an event tree. The relation is created by a generic basic event of type link.

A linked model is evaluated before the higher level model makes use of it, according to its specific evaluation parameters. If the upper level model is evaluated in steady-state, a generic basic event of type link takes the unavailability Q, the occurrence rate h or the unreliability F(T) of the referred model — even if the linked model is evaluated for its transients. If the upper level model is evaluated for its transients, it asks for h(t), Q(t) or F(t). The referred model will provide either these values or the mean values instead, depending on its evaluation mode.

[next] [prev] [prev-tail] [front] [up]