New BlockSim Gates

In addition to the gates defined above, other gates exist in classical FTA. These additional gates (e.g. Sequence Enforcing, Priority AND, etc.) are usually used to describe more complex redundancy configurations and they are described in later sections. First, we will introduce two new advanced gates that can be used to append to and/or replace classical fault tree gates.

These two new gates are the Load Sharing and Standby gates. Classical fault trees (or any other fault tree standard to our knowledge) do not allow for load sharing redundancy (or event dependency). To overcome this limitation, and to provide fault trees with the same flexibility as BlockSim's RBDs, we will define a Load Sharing gate in this section. Additionally, traditional fault trees do not provide the full capability to model standby redundancy configurations (including the quiescent failure distribution), although basic standby can be represented in traditional fault tree diagrams using a Priority AND gate or a Sequence Enforcing gate, discussed in later sections.

Load Sharing Gate

A Load Sharing gate behaves just like BlockSim's Load Sharing containers for RBDs. Load Sharing containers were discussed in the RBDs and Analytical System Reliability and Time-Dependent System Reliability (Analytical) chapters. Events leading into a Load Sharing gate have distributions and life-stress relationships, just like contained blocks. Furthermore, the gate defines the load and the number required to cause the output event (i.e. the Load Sharing gate is defined with a k-out-of-n vote). (Note: Like the Voting OR gate, the vote number in a Load Sharing gate is the number of failures that cause system failure. When translated to an RBD, this number will change to the number of non-failed blocks required for system success.) In BlockSim, no additional gates are allowed below a Load Sharing gate.

Load Sharing Gate Example

A component has five possible failure modes, A, BA, BB, BC and C, and the modes are dependent. The system will fail if mode A occurs, mode C occurs or two out of the three B modes occur. Modes A and C have a Weibull distribution with β = 2 and and η = 10,000 and 15,000 respectively. Events BA, BB and BC have an exponential distribution with a mean of 10,000 hours. If any B event occurs (i.e. BA, BB or BC), the remaining B events are more likely to occur. Specifically, the mean times of the remaining B events are halved. Determine the reliability at 1,000 hours for this component.

Solution to Load Sharing Gate Example

The first step is to create the fault tree as shown in Figure 10.7. Note that both an OR gate and a Load Sharing gate are used.

The next step is to define the properties for each event block and the Load Sharing gate. Setting the failure distributions for modes A and C is simple. The more difficult part is setting the properties of the Load Sharing gate (which are the same as an RBD container) and the dependent load sharing events (which are the same as the contained blocks in an RBD). Based on the problem statement, the B modes are in 2-out-of-3 load sharing redundancy. When all three are working (i.e. when no B mode has occurred), each block has an exponential distribution with μ = 10,000. If one mode occurs, then the two surviving units have an exponential distribution with μ = 5,000.

Let's assume an inverse power life-stress relationship for the components. Then:

(2)

(3)

Substituting μ1 = 10,000 and V1 = 1 in Eqn. (1) and casting it in terms of K yields:

Substituting μ2 = 5,000, V2 = 1.5 (because if one fails, then each survivor takes on an additional 0.5 units of load) and Eqn. (4) for in Eqn. (3) yields:

At this point, the parameters for the load sharing units have been computed and can be set, as shown in Figure 10.8.

The next step is to set the weight proportionality factor. This factor defines the portion of the load that the particular item carries while operating, as well as the load that shifts to the remaining units upon failure of the item. To illustrate, assume three units (1, 2 and 3) are in a load sharing redundancy, represented in the fault tree diagram by a Load Sharing gate, with load proportionality factors of 1, 2 and 3 respectively (and a 3-out-of-3 requirement).

The actual load on each unit then becomes the product of the entire load defined for the gate times the portion carried by that unit. For example, if the load is 100 lbs, then the portion assigned to unit one will be 100 • 0.166 = 16.6.

In the current example, all units share the same load; thus, they have equal weight proportionality factors. Because these factors are relative, if the same number is used for all three items then the results will be the same. For simplicity, we will set the factor equal to 1 for each item.

The last items that need to be defined are the total load and the 2-out-of-3 redundancy. The total load is dependent on how the parameters were computed. In this case, we assumed that the total load was 3 when we computed the parameters (i.e. the load per item was 1 when all worked and 1.5 when two worked). This is defined at the Load Sharing gate (container) level, as shown in Figure 10.9.

Once the problem has been set up in BlockSim, the reliability at hours can be determined. From the Analytical QCP, this is found to be 93.87%.

Standby Gate

A Standby gate behaves just like a standby container in BlockSim's RBDs. Standby containers were discussed in the RBDs and Analytical System Reliability and Time-Dependent System Reliability (Analytical) chapters. Events leading into a Standby gate have active and quiescent failure distributions, just like contained blocks. Furthermore, the gate acts as the switch, can fail, and can also define the number of active blocks whose failure would cause system failure (i.e. the Active Vote Number required). (Note: Like the Voting OR gate, the vote number is the number of active component failures that cause system failure. When translated to an RBD, this number will change to the number of active non-failed components required for system success.) In BlockSim, no additional gates are allowed below a Standby gate.

Standby Gate Example

Consider a system with two units, A and B, in a standby configuration. Unit is active and unit is in a "warm" standby configuration. Furthermore, assume perfect switching (i.e. the switch cannot fail and the switch occurs instantly). Units A and B have the following failure properties:

Standby Gate Example Solution

The fault tree diagram for this configuration is shown next and R(t = 500) = 94.26%.

Additional Classical Gates and their Equivalents in BlockSim

Sequence Enforcing Gate

Various graphical symbols have been used to represent a Sequence Enforcing gate. It is a variation of an AND gate in which each item must happen in sequence. In other words, events are constrained to occur in a specific sequence and the output event occurs if all input events occur in that specified sequence. This is identical to a "cold" standby redundant configuration (i.e. k units in standby with no quiescent failure distribution and no switch failure probability). BlockSim does not explicitly provide a Sequence Enforcing gate; however, it can be easily modeled using the more advanced Standby gate, described previously.

Inhibit Gate

In an Inhibit gate, the output event occurs if all input events occur and an additional conditional event occurs. It is an AND gate with an additional event. In reality, an Inhibit gate provides no additional modeling capabilities but it is used to illustrate the fact that an additional event must also occur. As an example, consider the case where events A and B must occur as well as a third event C (the so-called "conditional" event) in order for the system to fail. One can represent this in a fault tree by using an AND gate with three events, A, B and C, as shown in Figure 10.10. Classical fault tree diagrams have the conditional event drawn to the side and the gate drawn as a hexagon, as shown Figure 10.11. It should be noted that both representations are equivalent from an analysis standpoint.

Figure 10.11: Traditional use of an Inhibit gate. Note that this does not differ mathematically from the representation shown in Figure 10.10.

BlockSim explicitly provides an Inhibit gate. This gate functions just like an AND gate with the exception that failure/repair characteristics can be assigned to the gate itself. This allows the construction shown in Figure 10.11 (if the gate itself is set to not fail). Additionally, one could encapsulate event C inside the gate (since the gate can have properties), as shown Figure 10.12. Note that all three figures can be represented using a single RBD with events A, B and C in parallel.

Priority AND Gate

With a Priority AND gate, the output event occurs if all input events occur in a specific sequence. This is an AND gate that requires that all events occur in a specific sequence. At first, this may seem identical to the Sequence Enforcing gate discussed earlier. However, it differs from this gate in the fact that events can occur out of sequence (i.e. are not constrained to occur in a specific sequence) but the output event only occurs if the sequence is followed. To better illustrate this, consider the case of two motors in standby configuration with motor A being the primary motor and motor B in standby. If motor A fails, then the switch (which can also fail) activates motor B. Then the system will fail if motor A fails and the switch fails to switch, or if the switch succeeds but motor B fails subsequent to the switching action. In this scenario, the events must occur in the order noted; however, it is possible for the switch or motor B to fail (in a quiescent mode) without causing a system failure, if A never fails. BlockSim does not explicitly provide a Priority AND gate. However, and like the Sequence Enforcing gate, it can be easily modeled using the more advanced Standby gate.

Transfer Gate

Transfer in/out gates are used to indicate a transfer/continuation of one fault tree to another. In classical fault trees, the Transfer gate is generally used to signify the continuation of a tree on a separate sheet. This is the same as a subdiagram block in an RBD. BlockSim does not explicitly provide a Transfer gate. However, it does allow for subdiagrams (or sub-trees), which provide for greater flexibility. Additionally, a subdiagram in a BlockSim fault tree can be an RBD and vice versa. BlockSim uses the more intuitive folder symbol to represent subdiagrams.

As an example, consider the fault tree of the robot manipulator shown in Figure 10.13. Figure 10.14 illustrates the same fault tree with the use of subdiagrams (Transfer gates). The referenced subdiagrams are shown in subsequent figures. Note that this is using multiple levels of indenture (i.e. the subdiagram has subdiagrams and so forth).

Figure 10.13: A sample fault tree for a robot manipulator, showing all items in a single tree.

Figure 10.14: The fault tree of Figure 10.13 using subdiagrams (Transfer gates). The subdiagrams are shown in Figures 10.15 and 10.16.

Figure 10.15: The fault tree of the robot arm mechanism. This subdiagram is referenced in Figure 10.14.

Figure 10.16: The fault tree for the arm jams/collides event. This subdiagram is referenced in Figure 10.14. It also includes a subdiagram continuation to Figure 10.17.

Figure 10.17: The brake shutdown event referenced from Figure 10.16. It also includes a subdiagram continuation to Figure 10.18.

Figure 10.18: The watchdog ESD fails event referenced from Figure 10.17. It also includes a subdiagram continuation to Figure 10.19.

The RBD representation of the fault tree shown in Figure 10.13 is given in Figure 10.20. This same RBD could have been represented using subdiagrams, as shown in Figure 10.21. In this figure, which is the RBD representation of Figure 10.14, the subdiagrams in the RBD link to the fault trees of Figures 10.16 and 10.15, and their sub-trees.

Figure 10.20: This RBD equivalent of the complete fault tree of Figure 10.13.

Figure 10.21: The RBD representation of Figure 10.14 with the subdiagrams in the RBD linked to the fault trees of Figures 10.16 and 10.15, and their sub-trees.

XOR Gate

In an XOR gate, the output event occurs if exactly one input event occurs. This is similar to an OR gate with the exception that if more than one input event occurs then the output event does not occur. For example, if there are two input events then the XOR gate indicates that the output event occurs if only one of the input events occurs but not if zero or both of these events occur. From a system reliability perspective, this would imply that a two-component system would function even if both components had failed. Furthermore, when dealing with time-varying failure distributions, and if system components do not operate through failure, a failure occurrence of both components at the exact same time (dt) is an unreachable state; thus an OR gate would suffice. For these reasons, an RBD equivalent of an XOR gate is not presented here and BlockSim does not explicitly provide an XOR gate.