# Gate Types

For mathematical evaluation based on prime implicants (minimal cut-sets) the following gate types are supported:

- OR
- AND
- COMBINATION (M-out-of-N)
- NOT
- INHIBIT
- IF-THEN-ELSE
- REDUCED-COMBINATION
- TRANSFER-IN

For Monte-Carlo-Simulation the gate types indicated in table are available in addition. If a fault tree containing those gates is evaluated based on prime implicants instead of Monte-Carlo-Simulation, they are replaced by either the first input or by another gate type as indicated in column "replacement". The result will typically be conservative, but in some cases it might be optimistic (e. g. if basic events with decreasing failure rates are used and in case of a VOTING-AND).

Type | Restrictions | Replacement
--- | --- | ---
DIAGNOSIS | not in condition | first input only
DIAGNOSIS-INHIBIT | not in condition | AND
DIAGNOSIS-AND |  | AND
VOTING-AND |  | COMBINATION
PRIORITY-AND |  | AND
REPLACEMENT | not in replacement | first input only
DIAGNOSIS-AND-REPLACEMENT | not in condition or replacement | first input only
SEQUENTIAL | not in spare or sequential | AND
SPARE | not in spare or sequential | input only
RESTORATION-ON-SAFE-FAILURE |  | first input only

Some of these “gates” cannot be used in condition or replacement branches, see column Restrictions. Some of these “gates” influence the basic events in their branches. In that case, you might need to specify which basic events shall be affected by adding those basic events to a list, see the detailed description of each gate below.

Actually, only OR, AND, COMBINATION, NOT and IF-THEN-ELSE represent boolean combinations. The TRANSFER-IN-gate is just a structuring element not modeling any behavior of the system. All other “gates” are more semantic elements which make it possible to describe the behavior of this branch in the particular system precisely, considering operational aspects in a particular application, such as diagnosis, replacement and exact type of redundancy. These “gates” should be understood as tools to model the behavior in case of faults in the real application accurately. They will provide less conservative results compared to using boolean gates only and prevent using boolean gates in a wrong, non-conservative manner (such as misusing an AND-gate for diagnosis). In case of generic systems (element/system out of context), the assumptions leading to the usage of a specific gate type should be documented and exported as safety related application condition (SRAC).

## OR

### Characteristics

An OR-gate fails whenever one input fails (in Monte-Carlo-Simulation: only if no other input is failed already), is unavailable whenever any input is failed. |

## AND

### Characteristics

An AND-gate fails when all inputs are failed, is unavailable while all inputs are unavailable (i. e. until at least one is restored). |

## COMBINATION (M-out-of-N)

### Characteristics

A COMBINATION-gate fails if at least m inputs fail, is unavailable as long as at least m inputs are unavailable. |

In fact the COMBINATION-gate is just an abbreviation of OR-ed AND-gates according to m and the number of inputs. Therefore calculation is done as with standard OR and AND-gates. You can check that by calculating and exporting the prime implicants or by exporting the resulting fault tree by Export – Final Fault Tree. Identical events or common cause factors between basic events contained in the branches below the COMBINATION gate will be considered as if it would be one single fault tree.

## NOT

### Characteristics

A NOT-gate has one input, is unavailable while the input is ok (false), in Monte-Carlo-Simulation: a failure is counted when the input becomes false (ok), i.e. the occurrence rate is the same as the input occurrence rate, but the failure is set when the input is restored (transition from failed to ok). |

Since the complement is defined for probabilities only, but not for rates or densities, a NOT-gate cannot deliver an occurrence rate to a higher level gate. Therefore it only makes sense in the condition branch of e. g. INHIBIT-gates or the diagnosis branch of e. g. DIAGNOSIS-gates, or if the unreliability F(t) shall be calculated.

## INHIBIT

### Characteristics

An INHIBIT-gate has one input A and one condition input Cond, fails if the condition is true (failed) when the input A fails, is unavailable if it has failed until the input A is restored, (even if the condition Cond is not fulfilled any more already before). |

If the condition changes its state while the input A it still failed, the output does not change any more (i. e. if condition becomes true after the input A failed), the output will stay false (OK), and if the condition is not fulfilled any more (false, OK) while the input A is still failed, the output will stay failed until the input is restored.

Thus the INHIBIT-gate is similar to an AND-gate, except that the occurrence rate of the second input is ignored. Since the input A often describes a standard situation but not a failure, it is often a basic event marked as House Event.

Since the condition is quantified by a probability only (no occurrence rate), the basic events of the branch connected to the condition input should be marked with the modifier Condition Event.

There are two special cases related to the condition input of an INHIBIT-gate:

- If a generic basic event of type immediate is connected to the condition input and the parameter probability is set to zero, the branch topped by the INHIBIT-gate is completely ignored.
- If a generic basic event of type immediate is connected to the condition input and the parameter probability is set to one, the condition input is ignored.

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. You can check the effect if you export the final fault tree by Export – Final Fault Tree.

An INHIBIT-gate is not allowed in the condition branch of a higher level gate.

### Use Case

An INHIBIT-gate is appropriate

- when the failure of the input A only matters if a (typically external) condition is (fulfilled)
- to reduce the effective failure rate and the unavailability by the probability of the condition being true (failed)

## IF-THEN-ELSE (MUX)

### Characteristics

An IF-THEN-ELSE-gate has two inputs A and B and one condition input Cond, if the condition is true (failed) input A is considered for occurrence rate and unavailability, if the condition is false (OK) input B is considered for occurrence rate and unavailability, the condition is only considered at the time the input fails (i. e. a later change of the condition has no effect), only the input selected by the condition is considered, i. e. a change of the other input has no effect (even it is the one that has led to the failure of this gate before). |

The gate’s occurrence rate and unavailability are input A times the probability Q of Cond, plus those of input B times the complementary probability 1–Q of Cond.

Note that due to the intended purpose of the gate, the two inputs A and B are mutually exclusive per definition, i. e. the combination of the two inputs is not included in the list of prime implicants.

Note that the use of this gate will form a non-coherent fault tree, including all the inconveniences non-coherent fault trees bring along (such as non-unique prime implicants or non-conservativeness even all failure rates are conservative).

## DIAGNOSIS

### Characteristics

A DIAGNOSIS-gate has one input A and one diagnosis input Diag, fails when the input A fails, is unavailable as long as the input A is failed (detected or undetected), if the input A fails while the diagnosis input is OK (false), some basic events will immediately set to repair state (or OK if trep=0), see below. |

The failures of the following basic events will detected and the basic event sent to repair state (or to OK state directly if trep=0):

- if the input A is a basic event of type repairable or non-repairable, it will go to repair state, i. e. after trep it will be in OK state again,
- if the input A is a gate the user has to select the generic basic events whose failure will be detected out of a list containing all generic basic events of type repairable or non-repairable in branch A.
- if the diagnosis is failed (diagnosis input true), the gate has no effect, i. e. the failures below input A will remain undetected until end of lifetime (for non-repairable) or until detected by the next periodic test (for repairable).

### Use Case

- independent and immediate diagnosis when input A fails
- reduce unavailability due to sleeping faults
- diagnostic coverage may be less than 100%, i. e. not all basic events below input A can be detected

Note: This gate has no effect on failure frequency, i. e. the gate will fail with the same frequency as the input A. Only the unavailability of input A will be reduced due to the detection. If the failure of input A is not dangerous at all if is detected, the DIAGNOSIS-INHIBIT-gate might be the model of choice, see next section.

## DIAGNOSIS INHIBIT

### Characteristics

A DIAGNOSIS-INHIBIT-gate has one input A and one diagnosis input Diag, fails if the diagnosis is failed when the input A fails (as for INHIBIT gate), is unavailable if it has failed until the input A is restored (as for INHIBIT gate), if the input A fails while the diagnosis input is false (OK), some basic events will immediately set to repair state (as for DIAGNOSIS gate, see there). |

### Use Case

- independent immediate (=within PFTT) diagnosis when input A fails
- reduce unavailability due to sleeping faults
- only if the failure of the input A is safe if diagnosis is OK, i. e. system is forced to a safe state if detection is OK

Note: All failures of branch A must be detectable by the diagnosis if the diagnosis part is OK (false)! Failures not detectable by the diagnosis must be modeled in a parallel branch, connected by an OR-gate above this gate.

## DIAGNOSIS-AND

### Characteristics

A DIAGNOSIS-AND gate has an arbitrary number of inputs A, B etc., fails if all inputs fail at the same time (either by the same basic event or by different basic events sharing a common cause) or when the last remaining input fails while the other inputs are still unavailable (i. e. the failure cannot be detected by another channel or still being repaired), is unavailable while all inputs are failed (i. e. until at least one is repaired), some basic events will immediately set to repair state if at least one input is OK (see below). |

If at least one input is OK (false), any failures of the following basic events below failed inputs will detected and the basic event sent to repair state (or to OK state directly if trep=0):

- if a failed input is a basic event of type repairable or non-repairable, it will go to repair state, i. e. after trep it will be in OK state again,
- if a failed input is a gate the user has to select the generic basic events whose failure will be detected out of a list containing all generic basic events of type repairable or non-repairable in all branches. Note: even no specific basic events but only generic basic events are selected for detection in the list, only failed basic events below a failed input of the DIAGNOSIS-AND gate will be detected, not below any (non-failed) input of the DIAGNOSIS-AND gate or somewhere else in the overall fault tree.

### Use Case

- multiple channels with cross-wise immediate (=within PFTT) diagnosis (with a DC less than 100%
- reduce unavailability due to sleeping faults

## VOTING AND

### Characteristics

A VOTING-AND gate has an arbitrary number of inputs, fails if at least 50% of the available inputs fail at the same time, is unavailable after failure until more than 50% inputs are available again, some basic events might immediately be set to repair state if at least one input is OK (as for DIAGNOSIS-AND gate, see there). |

### Use Case

This gate can be used if

- the majority of channels decide what is correct in case of discrepancy between channels,
- there is no safe state of the system (fail active operational design),
- there is no specific diagnosis in each channel, i. e. “diagnosis” is only comparison of the results and assumption that majority of outputs will be correct,
- optional: each channel can raise a failure information in some way in order to start the restoration.

## REPLACEMENT

### Characteristics

A REPLACEMENT-gate has one input A and one replacement input R, the basic events of type standby repairable in the replacement input R are activated when input A fails, the basic events of type standby repairable in the replacement input R are deactivated when input A is OK again, the gate fails (gets true), if the replacement R fails at activation or while the input A is still failed, the gate is unavailable after failure until input A changes to OK (false). |

### Use Case

- for component(s) in cold standby, that can fail at activation or during operation
- no diagnosis/complex activation to be modeled (e. g. detection of failure of A is guaranteed)

## DIAGNOSIS REPLACEMENT

### Characteristics

A DIAGNOSIS-REPLACEMENT-gate is a combination of DIAGNOSIS / DIAGNOSIS-INHIBIT and REPLACEMENT, has one input A, one replacement input R and one diagnosis input Diag, fails if the diagnosis or the replacement R is failed when input A fails, fails if the replacement R fails at activation or while input A is still unavailable, is unavailable if it has failed until input A is restored, the basic events of type standby repairable in the replacement input R are activated when input A fails, the basic events of type standby repairable in the replacement input R are deactivated when input A is OK again, if input A fails while diagnosis is OK, some basic events of input A are immediately set to repair state (or OK if trep=0). |

### Use Case

This gate describes a system with

- component(s) in cold standby, that can fail at activation or during operation,
- where the component(s) in cold standby are only activated if the diagnosis is working,
- with complex diagnosis containing many components that can fail as well or depend on further conditions.

## PRIORITY AND

### Characteristics

A PRIORITY-AND-gate fails if the first input A failed before the second input B, the second before the third input C etc. until all inputs have failed (and not been restored before failure of the last input), is unavailable as long as no input is restored, if one input is OK (false) – no matter whether it has never failed yet or has been restored –, some basic events of all failed inputs on the right of this input are immediately set to repair state (or OK if trep=0), see below. |

Example: Assume input A failed first, then input B. After that input A has been restored (due to some periodic test and restoration or exchange). Now that input A is OK while input B is failed, the failure of input B will be detected as for a DIAGNOSIS-AND gate:

- if the input B is a basic event of type repairable or non-repairable, it will go to repair state, i. e. after trep it will be in OK state again,
- if the input B is a gate the user has to select the generic basic events whose failure will be detected out of a list containing all generic basic events of type repairable or non-repairable in any branch (A, B and C). Note: even no specific basic events but only generic basic events are selected for detection in the list, only failed basic events below a failed input of the PRIORITY-AND gate will be detected, not below any (non-failed) inputs of the PRIORITY-AND gate or somewhere else in the overall fault tree.

### Use Case

- If the top failure only occurs if the inputs fail in a specific sequence.

## SEQUENTIAL

### Characteristics

A SEQUENTIAL-gate has one active input at any time, in the beginning the first input A is considered only, it is the active input, when the active input fails, the next input is activated and considered from now on, when the last (the rightmost) input fails, the gate fails, basic events of type non-repairable will be activated at t=0, basic events of type non-repairable spare and standby repairable will be activated when the particular input becomes the active one (i. e. cannot fail before the input is the active one). |

### Use Case

- If there are alternative (typically degraded) operating modes in case the main component (main mode) fails.
- Similar to SPARE, but with different spare components.
- Typically the unreliability F is to be quantified for these kind of systems/applications.

## SPARE

### Characteristics:

A SPARE-gate has one input A, which indicates m elements of the same type, fails if its input failed more than m-spare times, Note: m=1 means, there is one spare, i. e. the gate fails when the input fails for the 2nd time, remains failed after it fails until end of lifetime, basic events of type non-repairable will be activated at t=0, basic events of type non-repairable spare and standby repairable will be (re-)activated after each failure. |

### Use Case

- If there is only a limited number of spare parts available during the mission.
- Similar to SEQUENTIAL, but with identical spare components.
- Typically the unreliability F is to be quantified for these kind of systems/applications.

## RESTORATION ON SAFE FAILURE

### Characteristics:

A RESTORATION-ON-SAFE-FAILURE-gate has two inputs: input D contains the dangerous failures, input S contains the safe failures S, fails when input D fails, is unavailable as long as the input D is failed, certain basic events are restored when the safe input S fails. |

When the safe input S fails, any failures of the following basic events below failed inputs will detected and the basic event sent to OK state (trep=0 assumed):

- if the input (D or S) is a basic event of type repairable or non-repairable, it will go to OK state,
- if the input (D or S) is a gate the user has to select the generic basic events whose failure will be restored out of a list containing all generic basic events of type repairable or non-repairable in both input branches

### Use Case

Most components or modules include many failure modes. Many of them directly lead to a safe state of the EUC, and need to be repaired before the EUC can be operated at all, therefore. Those failure modes (and only those!) are called ‘safe’ failures. The repair is often a replacement of a bigger module or assembly, thus undetected dangerous (‘dormant’) faults will be eliminated as well, even they haven’t been detected at all. Other dangerous (‘dormant’) faults might be detected (and corrected) in a mandatory commissioning test after repair. In effect, safe failures often lead to (known or unknown) elimination of dangerous faults in particular for components, that typically failing safely before or more often than failing dangerously. This effect can be modeled with a RESTORATION-ON-SAFE-FAILURE gate.

Note: In contrary to dangerous basic events, the rates of safe failures should be intentionally selected too low in order to get a conservative overall model.

## REDUCED COMBINATION

### Characteristics:

A REDUCED-COMBINATION-gate has one graphically displayed input, which symbolizes n elements of the same type, no common cause failure considered between the n elements, number of elements n is limited to 170. |

The output of a REDUCED-COMBINATION gate is true (faulty), if at least m out of the n inputs are true (faulty).

In contrary to all other gates, REDUCED-COMBINATION gates numerically evaluate the input event (they calculate the unavailability Qin and occurrence rate hin or unreliability Fin of the connected input before evaluation of the fault tree containing the REDUCED-COMBINATION gate). Unavailability Qg and occurrence rate hg or unreliability Fg of the gate are then calculated as function of n, m, Qin and occurrence rate hin or unreliability Fin and stored in a new temporary generic basic event, referred by a new temporary (internal) basic event of type Link. The formulas used to calculate higher gates only consider this basic event and thus do not get information of the structure below the REDUCED COMBINATION gate.

The suffix of the temporary (internal) basic event can be set to ‘#’ in order to create multiple instances of the element described by the REDUCED COMBINATION gate in higher level fault trees. This is achieved by adding an ‘#’ at the end of the name of the REDUCED COMBINATION gate.

### Use Case

- When there is a large number of similar items, that fail independent of each other.

## TRANSFER-IN

A TRANSFER-IN gate is a reference to another event defined by the name of the referred fault tree and the name of an event in the referred fault tree. The referred fault tree must either be a member of the same package or of the global package. The referred event can be any basic event or gate in the tree, not only the top event. The referred fault tree cannot be the tree the TRANSFER-IN gate belongs to. Regarding calculations, sub-trees referred by TRANSFER-IN gates are treated as if they would be stated directly in the higher level tree. Therefore you can split trees wherever you want. |

Note the possibilities for handling of basic event names and common cause factors.