失效树图及系统分析

1、fault tree diagrams and system analysisblocksim 6 is available in two editions, blocksim standard and the fti (fault tree interface) edition. the fti edition includes a fault tree interface for rendering/illustrating systems. this chapter introduces basic fault tree analysis and points out the simil

2、arities (and differences) between reliability block diagrams (rbds) and fault tree diagrams. principles, methods and concepts discussed in previous chapters are utilized. this chapter includes the following sections:· fault tree analysis, reliability block diagrams and the blocksim fti edi

3、tion· basic gates· new blocksim fti gates· event classifications· comparing fault trees and rbds· using mirrored blocks to represent complex rbds as ftds· fault trees and simulation· additional fault tree topicsfault tree analysis, reliability block diagrams and th

4、e blocksim fti editionfault trees and reliability block diagrams are both symbolic analytical logic techniques that can be applied to analyze system reliability and related characteristics. although the symbols and structures of the two diagram types differ, most of the logical constructs in a fault

5、 tree diagram (ftd) can also be modeled with a reliability block diagram (rbd). this chapter presents a brief introduction to fault tree analysis concepts and illustrates the similarities between fault tree diagrams and reliability block diagrams. fault tree analysis: brief introductionbell tel

6、ephone laboratories developed the concept of fault tree analysis in 1962 for the u.s. air force for use with the minuteman system. it was later adopted and extensively applied by the boeing company. a fault tree diagram follows a top-down structure and represents a graphical model of the pathways wi

7、thin a system that can lead to a foreseeable, undesirable loss event (or a failure). the pathways interconnect contributory events and conditions using standard logic symbols (and, or, etc.). fault tree diagrams consist of gates and events connected with lines. the and and or gates are the two

8、most commonly used gates in a fault tree. to illustrate the use of these gates, consider two events (called "input events") that can lead to another event (called the "output event"). if the occurrence of either input event causes the output event to occur, then these input event

9、s are connected using an or gate. alternatively, if both input events must occur in order for the output event to occur, then they are connected by an and gate. figure 10.1 shows a simple fault tree diagram in which either a or b must occur in order for the output event to occur. in this diagram, th

10、e two events are connected to an or gate. if the output event is system failure and the two input events are component failures, then this fault tree indicates that the failure of a or b causes the system to fail. the rbd equivalent for this configuration is a simple series system with two blocks, a

11、 and b, as shown in figure 10.2. figure 10.1: fault tree where the occurrence of either a or b can cause system failure.  figure 10.2: the rbd representation of the fault tree shown in figure 10.1. basic gatesgates are the logic symbols that interconnect contributory events and c

12、onditions in a fault tree diagram. the and and or gates described above, as well as a voting or gate in which the output event occurs if a certain number of the input events occur (i.e. k-out-of-n redundancy), are the most basic types of gates in classical fault tree analysis. (note: these gates are

13、 explicitly provided for in blocksim fti and are described in this section along with their blocksim implementations. additional gates are introduced in the following sections.) and gatein an and gate, the output event occurs if all input events occur. in system reliability terms, this implies

14、that all components must fail (input) in order for the system to fail (output). when using rbds, the equivalent is a simple parallel configuration. and gate exampleconsider a system with two components a and b. the system fails if both a and b fail. draw the fault tree and reliability block dia

15、gram for the system. the next two figures show both the ftd and rbd representations.    the reliability equation for either configuration is:  or gatein an or gate, the output event occurs if at least one of the input events occurs. in system reliability terms, this imp

16、lies that if any component fails (input) then the system will fail (output). when using rbds, the equivalent is a series configuration.   or gate exampleconsider a system with three components a, b and c. the system fails if either a, b or c fails. draw the fault tree and reliability

17、block diagram for the system. the next two figures show both the ftd and rbd representations.    the reliability equation for either configuration is:   voting or gate  in a voting or gate, the output event occurs if or more of the input events occur. in

18、system reliability terms, this implies that if any k-out-of-n components fail (input) then the system will fail (output). the equivalent rbd construct is a node and it is similar to a k-out-of-n parallel configuration with a distinct difference, as discussed next. to illustrate this difference,

19、 consider a fault tree diagram with a 2-out-of-4 voting or gate, as shown in figure 10.3. in this diagram, the system will fail if any two of the blocks below fail. equivalently, this can be represented by the rbd shown in figure 10.4 utilizing a 3-out-of-4 node. in this configuration, the system wi

20、ll not fail if three out of four components are operating, but will fail if more than one fails. in other words, the fault tree looks at k-out-of-n failures for the system failure while the rbd looks at k-out-of-n successes for system success. figure 10.3: illustration of a 2-out-of-4 voting or

21、 gate.  figure 10.4: equivalent representation of the 2-out-of-4 voting or gate in figure 10.3 utilizing a 3-out-of-4 node. expanding the classical voting or gateclassical voting or gates have no properties and cannot fail or be repaired (i.e. they cannot be an event themselves). in b

22、locksim fti, voting or gates behave like nodes in an rbd; thus, they can also fail and be repaired just like any other event. by default, when a voting or gate is inserted into an ftd within blocksim, the gate is set so that it cannot fail (classical definition). however, this property can be modifi

23、ed by the user to allow for additional flexibility. classic voting or gate exampleconsider a system with three components a, b and c. the system fails if any two components fail. draw the fault tree and reliability block diagram for the system. the next two figures show both the ftd and rbd rep

24、resentations.    the reliability equation for either configuration is: (1) eqn. 1 assumes a classical voting or gate (i.e. the voting gate itself cannot fail). if the gate can fail then the equation is modified as follows:  note that while both the gate and th

25、e node are 2-out-of-3, they represent different circumstances. the voting or gate in the fault tree indicates that if two components fail then the system will fail; while the node in the reliability block diagram indicates that if at least two components succeed then the system will succeed. co

26、mbining basic gatesas in reliability block diagrams where different configuration types can be combined in the same diagram, fault tree analysis gates can also be combined to create more complex representations. as an example, consider the fault tree diagram shown in figure 10.5. figure 10.5: a

27、 sample ftd utilizing different gates.  figure 10.6: rbd representation of the ftd shown in figure 10.5. discussion of basic gates and eventsa fault tree diagram is always drawn in a top-down manner and with lowest item being a basic event block. classical fault tree gates have no pro

28、perties (i.e. they cannot fail).new blocksim fti gatesin 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 s

29、ections. 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 r

30、edundancy (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 configur

31、ations (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 lo

32、ad 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. furt

33、hermore, 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,

34、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. load sharing gate examplea component has five possible failure modes, a, ba, bb, bc and c, and the modes are dependent. the system

35、 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),

36、 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 examplethe first step is to create the fault tree as shown in figure 10.7. note that bo

37、th an or gate and a load sharing gate are utilized. figure 10.7: fault tree for the example illustrating a load sharing gate. 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 di

38、fficult 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

39、 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: &#

40、160; (2)(3)  substituting 1 = 10,000 and v1 = 1 in eqn. (1) and casting it in terms of k yields: (4) 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:  this also

41、 could have been computed in reliasoft's alta software or with the load & life parameter experimenter in blocksim. this was done in the time-dependent system reliability (analytical) chapter. at this point, the parameters for the load sharing units have been computed and can be set, as

42、shown in figure 10.8. figure 10.8: 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 it

43、em. 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). · unit 1 carries or 16.6% of the total load.·

44、 unit 2 carries or 33.3% of the total load.· unit 3 carries or 50% of the total load. 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

45、 one will be  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

46、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 a

47、nd 1.5 when two worked). this is defined at the load sharing gate (container) level, as shown in figure 10.9. figure 10.9: load sharing gate properties. 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

48、.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

49、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

50、 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. standby gate exampleconsider a sy

51、stem 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: · bloc

52、k a (active):o failure distribution: weibull; = 1.5; = 1,000 hours.· block b (standby):o energized failure distribution: weibull; = 1.5; = 1,000 hours.o quiescent failure distribution: weibull; = 1.5; = 2,000 hours. determine the reliability of the system for 500 hours. standby gate e

53、xample solutionthe fault tree diagram for this configuration is shown next and r(t = 500) = 94.26%.   additional classical gates and their equivalents in blocksim ftisequence enforcing gatevarious graphical symbols have been used to represent a sequence enforcing gate. it is a variati

54、on 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

55、 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 outpu

56、t 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, con

57、sider 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

58、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.10: using an and gate to represent an inhibit relationship. figure 10.11: traditional use

59、of an inhibit gate. note that this does not differ mathematically from the representation shown in figure 10.10.   figure 10.12: including the conditional event inside the inhibit gate. blocksim fti explicitly provides an inhibit gate. this gate functions just like an and gate wi

60、th 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