Failure modes, fault trees and interacting causes

Follow one mode to its effects

Failure modes and effects analysis starts with an item and a specified mode, then follows its local and system effects. A channel might deliver no data, incorrect data or delayed data; those modes can have different consequences. Record the operating state, detection method and existing controls rather than treating every component failure as the same event.

A review of individual modes helps identify vulnerable functions and evidence gaps. It can miss combinations or interactions if the analysis stops at one item failing at a time. Severity also differs from detectability: an easily detected failure can still be severe. A single combined ranking should not hide either an extreme consequence or an uncertain assumption.

Build the logic around a precise unwanted event

A fault tree begins with a defined top event and works toward contributing events. OR means at least one listed input is sufficient; AND means all the listed inputs are required. These statements describe logical conditions. Multiplication of probabilities requires additional dependence assumptions, not merely the presence of an AND label.

Specify the mission, time window and boundary before assigning probabilities. The figure’s top event is no channel delivering data, not every possible incorrect or unsafe output. A tree omits causes that were not identified or not developed. It organizes the analyst’s understanding; it cannot prove that the complete system has no other failure path.

Check what the apparent alternatives share

Two paths may share power, software, environment, maintenance or a design defect. Such dependencies can make multiplying unconditional component-failure probabilities misleading. A common cause can defeat several components together, while an explicit support dependency can remove the function of components that remain physically intact.

The appropriate response depends on the mechanism: separation, diversity, better detection or a changed service architecture can each address different problems. A second identical component is not automatically an independent protection layer. Review interfaces and changes, and test whether the implemented system actually matches the logical model.

Include the supply before multiplying channel failures

Supply a shared-supply-loss probability P(C)=0.02 for one mission. Conditional on C being absent, let residual channel-failure probabilities be 0.10 and 0.05, assumed independent in that condition. The residual both-fail probability is 0.10×0.05=0.005.

Separate the two mutually exclusive cases: supply lost, or supply healthy and both residual failures. Total probability is 0.02+(1−0.02)×0.005=0.0249, or 2.49%. The 0.005 result alone describes only the conditional residual case. These illustrative inputs exclude wrong-data modes, imperfect switching and other shared causes; they are not validated channel reliabilities.

Try the reasoning

1. Does an AND gate prove its input events are independent?

   Show the answer and reasoning

   No. It states that both are needed. Their joint probability still needs a dependence model or evidence.

2. If both recorders are intact but their shared supply is lost, has the data-service function survived?

   Show the answer and reasoning

   No. Component integrity and delivered system function are different boundaries.

3. Why define “no data” separately from “incorrect data”?

   Show the answer and reasoning

   They can have different causes, detection and consequences. A tree for one top event does not automatically cover the other.

What to carry forward

Define the function, mode and logical combinations, then justify probability assumptions and shared dependencies.