So far in this *Fault Tree Friday* series *( 1 2 3 4 5 )* I’ve only dealt with AND and OR logic gates. Over the years engineers have occasionally seen a need to use other logical relationships, such as NOR, NAND (NOT AND), Exclusive OR, etc. While these are essential for designing circuits, I have never had occasion to use them in fault trees, and I sense that few others do. I recently spoke with a Systems Safety engineer at Boeing who suggested that if you need them, you’ve structured your fault tree wrong.

Two additional gate types that do appear fairly often are the Inhibit gate and the Combination gate. The inhibitor (*Inhibit* gate, not to be confused with *initiator*, a basic event), usually diagrammed as a point-down hexagon, is logically identical to an AND gate with two children. It is used to clearly signify that one of the children is not a fault, per se, but some sort of qualifying condition that must be satisfied for the inhibitor gate’s other child event to produce the condition named by the inhibitor gate. The non-fault event beneath an Inhibit gate is shown with a special symbol (often an oval) and is called a Conditioning Event.

Some regulations or standards include provisions that no single failure regardless of probability shall have catastrophic results (e.g., AC 25.1309-1). Use of Inhibit gates in fault trees under such constraints will usually be scrutinized, so the conditioning event must represent an uncommon state. My favorite example is a rejected take-off. It’s not a fault. It’s uncommon but not extremely rare. And to be of consequence it has to occur at high speed. I’ve seen rates in the range of 1E-4 or 1E-5 per takeoff used in the past. Whether the Inhibit gate is justified for low-temperature launch in modeling O-ring failure in the Challenger situation is debatable.

A standard graphical representation of the rejected takeoff scenario, in which an independent loss of braking or reverse thrust capability might be of interest, appears below.

The Combination Gate, usually represented by a flat-bottom hexagon, is a modeling device that eliminates repetition of similar branches in situations where, for example, two of four redundant paths must be failed to produce the condition named by the Combination gate.

Note that true redundancy may not exist in all such situations. In the above aircraft braking example, all brakes are applied together, but some fraction of them – half, for example, may be sufficient to avoid a hazardous state if they are functional. For a six-wheeled aircraft, the Combination gate lets us specify the number of failures within a group of logical branches that will result in the relevant condition. In the case of three-of-six, the Combination gate is shorthand for an OR gate with ten AND gates beneath it, one for each combination of three, e.g., {1,2,3; 1,2,4; 1,2,5; 1,2,6; 1,3,4; 1,3,5; 1,3,6; etc.}.

The two shorthand (stripped-down to show only the logic and event types) fault trees above and below the green line in the image below are logically equivalent. Each models the case where two of four initiator events must exist to produce the top event.

The Combination gate is not merely handy but is in practice a necessity for cases where the number of combinations is large. While two-of-four has only six possible combinations, the ten-of-twenty case, which might occur in a fault tree for the Airbus A380, would require two million events and gates to diagram without the Combination gate.

If you’re curious about how to enumerate the possible results of a combination gate, the relevant area of mathematics is called combinatorics. The specific rules that apply here are that order is not important (thus, this is literally a combination and not a permutation) and repetition is not allowed. This means that {a,b} and {b,a} represent the same real-world situation, so we’re only concerned with one of them. Likewise, {a,a} is not allowed, since event “a” can only occur once. Reliability engineers often call this a “r of n” situation. Since “R” is often used to represent failure rate in the fault-tree world, users of fault trees sometimes call this a “m of n” scenario. The formula for the number of combinations is:

c = n! / ( m! * (n – m)! )

For the two-of-four case:

c = 4 x 3 x 2 / ( 2 * 2) ) = 6

For any value of n the maximum value of c occurs when m equals n/2, which, coincidentally, is often the case being modeled, as with the ten-of-twenty case example I described above:

c = 2,432,902,008,176,640,000 / (670,442,572,800 * 670,442,572,800 ) = 184,756

In the above example there are 184.756 cut sets, each composed of ten independent initiator events. While and AND of ten events likely has a very low probability, the combination of all such AND gates will be about six orders of magnitude more probable.

This possibly unintuitive result is yet another reason that fault tree analysis belongs in the preliminary design of systems.

– – –

.

*Though a good deal is too strange to be believed, nothing is too strange to have happened.* – Thomas Hardy

Hey Bill, would you have a FTF full series white paper / book prepared, or do I still need to print-to-PDF every post one by one ;-[ …?

Would definitely [ buy the book AND spread some word ] XOR [ receive a free copy for review AND definitely spread the Word.

LikeLike

Hi Jurgen. Given current trends in risk management (risk registers and the belief that FMEA is risk analysis, along with equation risk management and compliance) I’m not sure there’s much of an audience. But I’m thinking about it and using these posts as a place to get some preliminary thoughts in print.

Bill

LikeLike

Agree and check. Personally, I’m more on the Fuzzy Logic track qua formulas (see e.g., my “15.5 risk” post and others – I’ve developed ideas further) — if only we could band together with (others as well) The Alternatives, *that* would give proper modelling … (?) 😐

LikeLike