Each basic event — a basic event of a fault tree, a block of a reliability block diagram as well as an edge of a Markov model — refers to a generic basic event. A generic basic event has a unique name, a description, a type and several values needed to determine the actual values of e. g. occurrence rate h(t) or unavailability Q(t). Also each case of an event tree refers to a generic basic event, even though this is not a real “basic event” logically but a constraint, characterized by its probability p = Q.
Libraries are just collections of generic basic events. Each package has a library of its own. The name of the library is identical to the package and cannot be changed. You can import generic basic events from other libraries, see section 11.4.
The generic basic events in a library can be referred by all models in the package. The generic basic events in the global library can be referred by all models in all packages. In case there is a generic basic event in the global library with the same name as in the local library, a local model will use the generic basic event in the local library.
Due to the existence of generic basic events it is on the one hand safeguarded, that all models use the same data for identical or similar basic events, on the other hand you only have to change a basic event property at one position and all other usages are automatically updated, too. In addition, common cause factors can be handled very efficiently: In fault trees all basic events with the same names share the common cause factor (β-factor, see [EN 61508]) of the generic basic event— even if they are located in sub-trees referred by transfer-in gates.
Note that if you add an event tree, fault tree or Markov model from another project (by using File – Add Fault Tree etc.), the data of the related generic basic events is not copied since they are not stored in the .etf, .ftl, .rbd or .mdg file. Instead either a generic basic event of the local or global library of the new project is referenced (if there exists one with the given name stated in the model file), or a new generic basic event with this name is created in the package into which the existing model is imported (with default probabilistic data). Of course you can import the data of all generic basic events of the old project by using Library – Import GBEs from other Library or Project, see section 11.4. This avoids duplication of logically (but by accident not namely) identical basic events, resulting in wrong calculations due to lost common cause relations.
The content of the library is displayed as a table by double-clicking on the library’s name in the project member’s tree, see figure 7.
You can sort the list of generic basic events in alphabetic order or by their model type. Unused values of each event are shown in light grey. All generic basic events not used in any model of the project are displayed with grey background, or not displayed at all if deselected in the control panel on the left.
In the Library View, you can create new generic basic events, import generic basic events from another library or export all data to a .csv file, see section 11.4.
When a generic basic event is selected by clicking the table row, all its properties are displayed in the properties panel on the left, where they can be edited also. The selected generic basic event can be deleted, cut, copied, renamed, duplicated or moved to another package. Note that some actions can only be performed if some constraints are fulfilled, e. g. that the generic basic event is not used currently.
To show the project member’s tree and the library properties again, deselect the generic basic event by clicking somewhere above the table.
Name: A user defined identifier of the generic basic event and at the same time the name of all basic events (incl. cases) referring to it. The name must be unique within the library.
Description: A user defined description of the generic basic event and therefore identical for all basic events referring to this generic basic event.
Condition If the condition event flag is set, the occurrence rate h is set to 0. Thus only the unavailability Q or Q(t) is considered in evaluations.
In fault trees a condition event is visualized by an ellipse instead of a circle. A condition event should always be connected to an inhibit gate, except if the overall fault tree is evaluated for unavailability Q only.
In Markov models a condition event will create an instantaneous transition, see section 9.1.3.
A case of a condition in an event tree is always a probability (no rate), independent of the condition event flag being set or not. However it should be set.
There are two special cases related to the condition event flag in fault trees or reliability block diagrams:
These rules might be useful in order to adapt the structure of a (generic) fault tree to different specific applications, i. e. to simplify the re-use of a fault tree for different projects.
House This modifier is only a marker with no effect to the evaluation. In fault trees the basic event is visualized by a “house” instead of a circle, this is where the name comes from. It indicates an event, that will occur in certain intervals for sure, not related to failures. The rate is often greater than 1/h.
House events must be described by the immediate model, requiring an occurrence rate h and optionally an unavailability Q, or by the cyclic model.
Non-developed This modifier is only a marker with no effect to the evaluation. In fault trees the basic event is visualized by a rhombus instead of a circle. It is typically used to mark an event, that is out of scope or neglected.
No contribution to occurrence rate If this modifier is selected, a basic event in a fault tree referring to this generic basic event will be ignored in the calculation of the occurrence rate. For fault trees this means, that the occurrence rate of each gate will be determined as if the basic event would be removed from the fault tree. It is also considered when a gate is converted to a Markov model.
The modifier might make sense if you want to describe a generic component, that is used in different systems, in some of which the fault modeled by the event effects the unavailability of ‘low demand mode’ safety functions, but is not dangerous for ‘continuous mode’ safety functions since it is detected within the ‘process safety time’ and leads to the EUC shutting down safely. This is the operation assumed in the formulas stated in [EN 61508-6].
However it is advised to use different models for different safety functions or operation, in particular if you want to convert it to a Markov model.
The unavailability Q is not affected by this tag.
The probabilistic failure characteristics of a component (such as the failure rate or the failure detection time) may significantly depend on the particular application. E. g. the failure rate of a relay will depend on the voltage and current (wear of contacts) as well as on the cycles per time and the overall system life time. The failure rate of a semiconductor will depend on the temperature etc. Therefore the failure rates of components of the same type may differ by multiple orders of magnitude depending on their function also within the same product. This is in particular true if the critical failure modes differ between the functions. If this is the case, different generic basic events should be created even for the same type of component, reflecting the different environments, operating conditions or critical failure modes of the components. The common cause factor β must be modeled manually in this case (explicit basic events referring to a generic basic event with the occurrence rate of the common cause). The same applies if components of the same type are checked in different intervals.
All data must be adopted to the defined safety function in a specific application, since the safe failure fraction and the fault detection time might be completely different. Imagine a computer: In one application a fault of the microprocessor might not be hazardous as long as it is detected, since the machinery (EUC) can enter a safe state. In another application there is no safe state (of the EUC), therefore a fault of the microprocessor is hazardous even if it was detected immediately. For this reason a THR or TFFR must always be defined in combination with a well described hazard/failure — a component as such has no “hazard rate” .
The following models are available to describe the occurrence rate, the unavailability and unreliability of a generic basic event.
Important note: The naming of the failure models is not harmonized. Thus, there might be fault tree evaluation programs that define the “repairable” or “dormant failure” model and the “non-repairable” model in different ways, in particular with respect to when the overall “system lifetime” or “mission time” is used and when an explicit test interval Tcheck is used for evaluation. The following subsections provide all information that enables you to select the suitable model. Note that in Functional Safety Suite the system lifetime (“mission time”) stated in the project properties dialog should always be set to the (maximum) system lifetime – any test intervals should be considered in the Tcheck parameter of the Repairable failure mode model, as described in section 4.3.1.
Using this model, the following failure scenarios can be modeled:
These failure scenarios are the most common ones, and therefore this model is the one needed for most failures in machinery, as for example failures of an electric or electronic component, as well as failures of complex mechanical components such as pneumatic or hydraulic valves.
In Functional Safety Suite the occurrence rate h consists of two parts for convenience
![]() | (1) |
where D is the duty cycle (0 < D ≤ 1) , λop is the failure rate in operation (0 < λop [1/h]) and λsb is the failure rate in standby (0 ≤ λsb [1/h]). If there is only a single mode of operation, set D = 1.0 and λsb = 0.0.
The mean unavailability is calculated by
![]() | (2) |
with the test interval Tcheck (0 ≤ Tcheck [h]) and the mean repair time Trepair per failure (0 ≤ Trepair [h]).
For Tcheck → 0, equation (2) tends to
![]() | (3) |
For Trepair → 0, equation (2) tends to
![]() | (4) |
The mean occurrence density w is given by
![]() | (5) |
The restoration rate μ used in Markov models in steady-state evaluation is given by
![]() | (6) |
In transient evaluation, if Tcheck is greater than 10 times the step time tstep, the current unavailability Q(t) is given by
![]() | (7) |
with t0 being the time to the first test (the “phase shift” of the test) and Qrepair
the (mean) unavailability due to the repair time Qrepair = :
![]() | (8) |
The occurrence density w(t) is given by
![]() | (9) |
In Markov models the restoration to the origin state is performed cyclically at times ti = n ⋅ Tcheck + t0 + Trepair.
Note that t0 is the same for all basic events referring to this generic basic event, it is not possible to assign different values to them. This is intended since in practice, all tests related to a sub-system will be performed at the same time. Of course there might be two sub-systems of the same type (and thus referring to the same generic basic events), but if they are in fact tested at different times, they are usually not related to each other, so that one can assume, that they won’t be affected by common cause failures. In that case, the sub-system should be modeled by a completely separate model, that is linked to the overall system model by a Link event.
The maximum unavailability Qmax is given by equation (8) with t = Tcheck:
![]() | (10) |
Often there is no defined test or inspection interval (“proof test interval”), but a component’s fault will be detected during normal operation in an uncritical situation. In that case this time can be used as Tcheck. If the component is never tested (thus a fault will not be detected until the hazard occurs), the test interval Tcheck must be set to the component’s mean lifetime or the non-repairable model must be used.
This failure model can be used as condition event, see section 4.2.1.1.
Using this model, the following failure scenarios can be modeled:
In contrary to the “Repairable” model explained in the previous section, this model is only suitable, if the failure is very unlikely to occur at all during system lifetime. If the failure is likely to occur at least once in system lifetime, you should use the “Repairable” model in order to get realistic results.
Most non-repairable events can be modeled with sufficient accuracy by a Weibull distribution. The density function f(t) of a Weibull distribution is given as
![]() | (11) |
and the distribution function is given as
![]() | (12) |
The exponential distribution (constant failure rate) is included as special case (k = 1).
In Functional Safety Suite the failure rate λ consists of two parts for convenience
![]() | (13) |
where D is the duty cycle (0 < D ≤ 1), λop is the failure rate in operation (0 < λop [1/h]) and λsb is the failure rate in standby (0 ≤ λsb [1/h]). Of course this splitting only makes sense for k = 1 (constant failure rates), and only in this case λ is actually a ‘failure rate’.
If k≠1, the occurrence rate is time variant, given by
![]() | (14) |
The mean occurrence rate is a function of the lifetime T, given by
![]() | (15) |
with T being the component lifetime. If no component lifetime is stated in the properties explicitly, the global system lifetime (mission time) is used. The same applies if the stated component’s lifetime is greater than the system lifetime (mission time). If the component is changed in certain intervals preventative, the component’s lifetime is shorter.
For non-repairable, not preventative changed components the unavailability Q(t) is identical to the unreliability F(t):
![]() | (16) |
If the component is changed preventative, the unreliability F(t) is only identical to the unavailability Q(t) for t < T.
The mean unavailability over lifetime Q(T) is given by
![]() | (17) |
whereas the maximum unavailability Qmax is given by the unavailability at the end of the component’s lifetime Q(T)
![]() | (18) |
The mean occurrence density w is given by
![]() | (19) |
and the actual occurrence density in transient evaluation w(t) is given by
![]() | (20) |
This model is only applicable, if the assumption, that the component has no fault at t = 0, is valid.
This failure model can be used as condition event, see section 4.2.1.1.
Specifics for Markov models: The steady-state of a Markov model is the state for which all transition rates are zero. This means that there must be an equilibrium between forward transition rates and return transition rates. A non-repairable element obviously has no return rate, thus the steady-state evaluation of a Markov model including one or several non-repairable events will always result in an accumulation of the probabilities in final states, what in turn will always result in Q = Q = 1 and w = w = 0. This is equivalent to Q(t →∞) and w(t →∞), what is in fact the only true steady state. Nevertheless what shall be calculated typically is a “pseudo steady-state”, where all repairable events are in a steady state, but not the non-repairable events. Therefore for steady-state evaluation of Markov models an equivalent return rate μ is defined as
![]() | (21) |
resulting in an unavailability at the end of the component’s lifetime Q(T) (as if it would have been calculated by equation 17).
As the name says, this model is suitable for elements, that are only needed rarely, i. e. in case of the failure of another element or the occurrence of a rare environmental condition. The interesting value is the probability, that the element is (not) available, when it is needed (on demand): the unavailability Q. Since its failure doesn’t trigger a hazard, the occurrence rate h is zero. In other terms, this model is similar to the ‘repairable’ model, with the restriction to the unavailability as the interesting value. The overall unavailability of those elements can typically be modeled by four parts:
The constant unavailability resulting from parts two to four is approximately given by
![]() | (22) |
All values may be zero, resulting in Qconst = 0.
In transient evaluation, if Tcheck is greater than 10 times the iteration time Tstep, the overall current unavailability Q(t) is given by
![]() | (23) |
Both λsb and Tcheck must be positive values.
The overall mean unavailability is given by
![]() | (24) |
This failure model always represents a condition event, see section 4.2.1.1.
A (cold standby) emergency generator has a probability that it won’t start when it is needed (given either by its failure rate in power-off state λsb and the test interval Tcheck or directly a probability γ), and a probability that it fails after successful start, but before the normal electricity is available again (given by λop and top).
If an element is needed in certain intervals over the system’s lifetime, or a certain number of times (once, twice,…) within a mission independent of the length of the mission, this model might be useful.
If N > 0 the mean occurrence rate is given by
![]() | (25) |
with γ being the probability of failure per demand, N being the number of demands within the system’s lifetime (or per mission) and T being the system’s lifetime (or mission time). The cycle interval is Δt = T∕N in this case.
If N ≤ 0 the mean occurrence rate is given by
![]() | (26) |
with γ being the probability of failure on demand and Δt the cycle interval in hours.
If N > 0 the maximum unavailability is given by
![]() | (27) |
or by
![]() | (28) |
if N ≤ 0 respectively.
Note that always the maximum unavailability is used instead of a mean unavailability in steady-state calculation, in order to be on the safe side in any case. If this seems to be not adequate or too conservative, please use transient evaluation instead.
The mean occurrence density w is given by
![]() | (29) |
whereas the occurrence density w(t) in transient evaluation is given by
![]() | (30) |
respectively.
In case of transient evaluation, if the cycle interval Δt is greater than 10 times the iteration time, the transition(s) described by this basic event model are executed at discrete times ti = n⋅ Δt + t0 with n ∈ IN0 and t0 being an offset for the first transition. For transient evaluation, in addition a return delay can be modeled: If the return delay is greater than 0, the target state is left towards the source state at discrete times ti = n ⋅ Δt + t0 + Tdelay.
Note that the densities and rates f(t), w(t) and h(t) are in fact Dirac impulses, which will for finite integration steps scatter to rectangular impulses, whose heights will depend on the integration step size. Therefore the densities and rates calculated at the steps where the cyclic events appear, are meaningless.
This failure model cannot be used as condition event, since this doesn’t make sense.
Imagine the events, that the brake pipe is closed when starting a train run, that the gear of a plane doesn’t lower before landing, that the brake parachutes of the space shuttle don’t open or the engine of a spacecraft doesn’t restart on demand: In all these cases the mission will fail at a certain time independent of its (planned) duration.
It is also obvious, that defining THRs as safety targets doesn’t make much sense for problems, that significantly depend on those events (the longer the mission the lower the failure rate gets!). Instead, the definition of a tolerable mission failure probability (mission unreliability) seems more adequate for those problems. This is also the reason why [NASA] always talks about probabilities instead of occurrence rates, in contrary to e. g. [NUREG].
According to [NUREG] it’s implicitly assumed, that an element is unavailable if it had a failure before. Therefore the unavailability Q(t) is linked to the occurrence rate h(t) and the test interval. For many basic events this assumption is not fulfilled, but the unavailability is independent of the occurrence of another event. To be able to model also those elements, the unavailability Q(t) = Q, the occurrence rate h(t) = h and the restoration rate μ can be assigned explicitly (“immediately”) to a generic basic event.
The occurrence density is
![]() | (31) |
This failure model can be used as condition event, see section 4.2.1.1. In that case, the probability p = Q must be > 0, the occurrence rate h and the restoration rate μ are ignored.
By links an event tree, fault tree or Markov model can use the result of the evaluation of another fault tree, Markov model or complex component. Thus several models of the project can be combined. This might be useful due to the following reasons:
The referred model is defined by its name.
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.
Obviously, the linked model must calculate the values required by the upper level model:
Table 2 provides an overview about which values are required by which kind of link.
Upper level model type | Calculation of1 | Condition2 | Required value(s) | Lower level calculation value(s) |
Fault tree, RBD | * | yes | Q | Q or h and Q |
Fault tree, RBD | Q | * | Q | Q or h and Q |
Fault tree, RBD | h and Q | no | h and Q | h and Q |
Fault tree, RBD | F (direct)3 | no | F | F |
Fault tree, RBD | F (via h and Q)3 | no | h and Q | h and Q |
Markov model | * | yes | Q | Q or h and Q |
Markov model | * | no | h | h and Q |
Event tree | n/a | (yes) | Q | Q or h and Q |
An asterisk ‘*’ in table 2 means any value (“don’t care”). See section 7.5.1.1 for fault trees or section 9.5.1.1 for Markov models for how to set the correct calculation values.
Note that the higher level model gets no information about the structure of the linked model, thus if basic events in the higher level model and in the linked model refer to the same generic basic event, no common cause factor is considered. This behavior is typically useful, but sometimes not correct. Therefore also a generic basic event of type link can be assigned a common cause factor just as for all other types of generic basic events. This common cause factor is considered between all basic events referring to this generic basic event within a fault tree or reliability block diagram, and also within fault trees connected by transfer-in gates (since fault trees connected by transfer-in gates are treated as one fault tree in evaluation, see section 7.5).
In any case, the model using the link gets no information of the structure of the referred model(s). Thus common cause factors defined for basic events of the referred models are not considered in the higher level model. Nevertheless sometimes it is useful to define a common cause factor between modules of a system. This is possible by setting a common cause factor here.
Note that you can open/jump to the linked model by double-clicking the case, the basic event or the edge.
Specific for Markov models: Only the forward direction of the transition can be defined by a link. But in fact, sometimes also a transition back to the source state exists and thus needs to be modeled. For steady-state evaluation an equivalent restoration rate μ is calculated as
![]() | (32) |
In transient evaluation this is not possible since h(t) has no relation to Q(t). Therefore it is possible to define a restoration rate in the same manner as for a repairable element by setting a test interval Tcheck > 0 and optionally in addition a repair time Trepair and the offset (phase shift) t0 of the test.