Can One Failure Cause the Event, or Must Two Failures Combine? Reading AND and OR in FTA
A fictional guard-and-motor example explains AND and OR in fault tree analysis, common causes, independence and the evidence behind each connection.
A failed guard sensor does not, by itself, establish that a motor will run with its guard open.
The outcome depends on whether another protective function remains available and how that function operates.
Equally, having two protective functions does not establish safety: a single cause might disable both.
Fault Tree Analysis (FTA) starts with a defined undesired event and works backward through the combinations of events that can produce it.
This article explains how to read those connections, rather than simply count failures.
It is a method explanation for medical-device development teams, not a claim that a particular regulation universally requires FTA.
[1]
Fix the boundary and assumptions first
Consider a fictional motor-driven device.
Barrier A uses a guard sensor, and a separate barrier B also interrupts motor power.
Assume that either functioning barrier can prevent power from reaching the motor.
In this example, B can detect an open guard and interrupt power without relying on A's sensor signal.
This is an explanatory architecture, not an actual wiring diagram or a recommended product design.
The fixed conditions are an open guard, an active start request and available drive power.
The top event is motor operation under those conditions.
The example does not cover the inertia of an already rotating motor, braking time or opening the guard during operation.
Defining the operating conditions prevents a premature connection between a component failure and the outcome being analyzed.
Either functioning barrier prevents motor power in this fictional architecture.
This is not a circuit diagram or a representation of actual sensor wiring.
Guard open, start request active and drive power available are fixed analysis conditions.
Here, sensor failure means a failure that causes A to miss the open guard and fail to interrupt power.
Other sensor failure modes need not have that consequence.
A failure that inhibits drive, for example, should not be grouped into the same event.
An event description such as “A fails to inhibit drive when the guard is open” is therefore more precise than simply “sensor failure.”
AND: both barriers must fail along this path
Under these assumptions, B prevents motor operation if A fails but B remains functional.
The reverse also holds.
The top event occurs when both barriers fail to interrupt power.
This relationship is represented by AND.
[1, Chapter 4]
The table below follows from the assumed architecture.
It is a logic table, not a set of test results.
It assumes that no alternative power path or omitted failure defeats the stated behavior.
| Barrier A | Barrier B | Outcome in the fictional architecture |
|---|---|---|
| Functional | Functional | Motor operation inhibited |
| Fails to inhibit | Functional | B inhibits motor operation |
| Functional | Fails to inhibit | A inhibits motor operation |
| Fails to inhibit | Fails to inhibit | Top event occurs |
This turns “there are two protective devices” into a specific design claim.
The team can ask whether B actually inhibits drive when A has failed, whether the reverse is true, and which design information and verification evidence support that behavior.
These are MedQraft's review suggestions, not instructions to perform fault-injection tests immediately.
Any testing requires a plan appropriate to the device architecture and test safety.
OR: one cause is sufficient for the defined output event
OR may appear at a different level within the same analysis.
Suppose either of two conditions is sufficient to make A fail: its sensing path fails to produce the guard-open signal, or its interrupting output remains stuck closed despite receiving that signal.
Under that assumed architecture, either condition can produce A's failure to inhibit drive.
The conditions are connected by OR, which also includes the case where both occur.
[1, Chapter 4]
The output event of that OR relationship is failure of barrier A, not motor operation for the whole device.
If B remains functional, it still inhibits drive in this example.
Keeping the event levels distinct avoids treating every component failure as an immediate device-level hazardous event.
AND requires all input events; OR requires at least one.
Q denotes the output event defined for each diagram.
The two Q labels need not represent the same physical event.
Labeled blocks simplify the logic for explanation.
AND does not establish independence
Connecting two failures with AND means both are required.
It does not establish statistical independence.
Multiplying their individual probabilities requires justification of the relevant independence assumptions.
[1, Chapter 6]
For an actual design review, consider whether the functions share a connector, processor, sensing signal, power condition or environmental exposure.
Sharing an element does not automatically prove a common-cause failure.
The team needs to identify how a specific failure of that element would cause each barrier to fail to inhibit drive.
Some power failures instead cause a safe stop, so a shared power failure should not automatically be labeled dangerous.
If one cause can disable both barriers, counting two functions does not by itself demonstrate risk reduction.
Whether cause C exists and has that effect must be supported by the actual architecture.
This diagram contains no failure-rate calculation or measured data.
Record the basis for each connection
The following is a practical way to document the fictional review.
It is not a complete risk-management form or a conformity determination.
Its purpose is to preserve the conditions that make the logic valid.
| Item to document | Example entry |
|---|---|
| Top event | Motor operation with guard open, start request active and power available |
| Analysis boundary | Power interruption at startup; residual rotation from inertia analyzed separately |
| Events A and B | Each barrier fails to inhibit drive with the guard open |
| Basis for AND | Either functioning barrier interrupts the motor power path |
| Further questions | Shared signals and components, bypass paths, and failure detection |
| Supporting information | Circuit and control-logic revisions, design-review records and verification references |
A reviewer should be able to trace the reason for AND back to the circuit and control logic.
If either input event alone is sufficient for the output event, AND is the wrong relationship.
Revisit the tree when a bypass path is identified or the design changes.
FTA describes relationships within a defined analysis boundary.
Motor operation in this example is not the same as an injury occurring.
Access to a hazardous area, exposure and the conditions leading to harm still need to be addressed in the device's risk management.
A clear fault model supports that work but does not replace the overall assessment.
Related reading
- Connecting medical-device risk-management evidence: linking analysis to design and verification evidence.
- Battery indication and power interruption in portable devices: defining review conditions in a different device scenario.
Source and scope
- NASA Office of Safety and Mission Assurance, Fault Tree Handbook with Aerospace Applications, Version 1.1, August 2002.
Chapter 4, printed pages 34 to 39: logic gates and event relationships.
Chapter 6, printed pages 75 to 76: AND and independence assumptions.
Official public document.
Relevant sections checked October 23, 2026.
The NASA reference supports the analysis method, not a medical-device regulatory obligation.
The device architecture, dialogue, logic table and three diagrams are original fictional examples prepared by MedQraft.
No source figures or tables have been reproduced.
Let's talk
Apply what you have read
to your product.
Tell us your product's current stage and the questions you need to review.
Discuss your questions ↗