 | ||||||
| Reliability HotWire | ||||||
| Reliability Basics | ||||||
|
Overview of Fault Tree
Gates (Part II)
In addition to the basic gates defined in last month's Hotwire
article,
Overview of
Fault Tree Gates (Part I), other gates exist in classical Fault Tree
Analysis (FTA). These additional gates (e.g. Sequence Enforcing,
Priority AND, etc.) are usually used to describe more complex redundancy
configurations. However, 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. 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. Load Sharing Gate
A Load Sharing gate behaves just like a Load Sharing container in BlockSim's RBDs. 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 FTI, no additional gates are allowed below a Load Sharing gate. Additional information on Load Sharing containers can be found in the RBDs and Analytical System Reliability and Time-Dependent System Reliability (Analytical) chapters of the System Analysis online reference. 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 if two out of the three B modes occur. Modes A and C have a Weibull distribution with β = 2 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 1. Note that both an OR gate and a Load Sharing gate are utilized.
Figure 1: Fault tree diagram for Load Sharing gate example 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 a 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:
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. (3) in Eqn. (2) yields:
This also could have been computed in ReliaSoft's ALTA software or with the Load & Life Parameter Experimenter in BlockSim. This is demonstrated in the Time-Dependent System Reliability (Analytical) chapter of the System Analysis online reference. At this point, the parameters for the load sharing units have been computed and can be set, as shown in Figure 2.
Figure 2: Load sharing parameters 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 1 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 3.
Figure 3: Load Sharing gate properties Once the problem has been set up in BlockSim, the reliability at 1000 hours can be determined using the Analytical QCP. Therefore, R(t = 1000) = 93.87%. Standby Gate
A Standby gate behaves just like a standby container in BlockSim's RBDs. 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 FTI, no additional gates are allowed below a Standby gate. Additional information on standby containers can be found in the RBDs and Analytical System Reliability and Time-Dependent System Reliability (Analytical) chapters of the System Analysis online reference. Standby Gate Example Consider a system with two units, A and B, in a
standby configuration. Unit A is active and unit B 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:
Determine the reliability of the system for 500 hours. Standby Gate Example Solution The fault tree diagram for this configuration is shown next and R(t = 500) = 94.26%.
Figure 4: Fault tree diagram for Standby gate example Additional Classical Gates and their Equivalents in BlockSim FTI 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 FTI 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 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 5. Classical fault tree diagrams have the conditional event drawn to the side and the gate drawn as a hexagon, as shown in Figure 6. It should be noted that both representations are equivalent from an analysis standpoint.
Figure 5: Using an AND gate to represent an inhibit relationship
Figure 6: Traditional use of an Inhibit gate Please note that the diagram in Figure 6 does not differ mathematically from the representation shown in Figure 5. BlockSim FTI 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 5 (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 in Figure 7. Note that all three figures can be represented using a single RBD with events A, B and C in parallel.
Figure 7: Including the conditional event inside the Inhibit gate 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 FTI 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 FTI 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 FTI fault tree can be an RBD and vice versa. BlockSim FTI uses the more intuitive folder symbol to represent subdiagrams.
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, BlockSim FTI does not explicitly provide an XOR gate. | ||||||
 |
Copyright 2004 ReliaSoft Corporation, ALL RIGHTS RESERVED | |||||
|
or 16.6% of the total load
or 33.3% of the total load
or 50% of the total load
