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 :
-
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.
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.
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.