Hazards do not live in components. A resistor is not dangerous; a resistor whose drift lets a heater run unbounded while the over-temperature channel shares its failed supply is the beginning of a hazard, and the hazard belongs to the arrangement, not to any part of it. This chapter is about that arrangement: how failures combine into hazardous conditions, what independence really requires, why fail-safe is a direction rather than a quality, and why the most instructive accidents of the past forty years involved no broken component at all.
Cut sets: the structure of a hazard
The deductive way to model a hazardous outcome is to name it as a top event and work downward through the combinations that produce it, which is the fault tree construction. The result is a logical expression whose solutions are cut sets: sets of basic events whose simultaneous occurrence causes the top event. The minimal cut sets, those with no redundant members, are the design's real vulnerability list, and their order (how many events each contains) carries more safety information than any probability attached to them:
| Cut set order | What it means | The safety verdict |
|---|---|---|
| One | A single basic event causes the hazardous outcome | A single point of failure. In civil aviation certification a catastrophic failure condition may not result from a single failure whatever its probability; other regimes do not forbid it outright but route it to the highest acceptance authority and to architectural-constraint rules |
| Two | Two events must coincide | Acceptable only if genuine independence can be argued and the exposure window is bounded |
| Three or more | Deep combinations | Usually dominated by common-cause contributions rather than by the coincidence of independent events |
The practical discipline that follows: run the qualitative analysis first and take it seriously. A list of order-one cut sets is a design finding that survives whatever the data later says, and it is available from the tree's logic long before any failure rate has been agreed. Quantification comes second, and its principal use is comparing candidate architectures and checking a target, not discovering vulnerabilities. When quantified trees do surface something new, it is usually through importance measures: which basic events and which cut sets actually drive the top-event probability, and therefore where protection buys the most risk reduction per unit of effort.
The complementary view is inductive: start from a failure and follow it forward to its effects, which is what FMEA does. The two directions catch different mistakes. Deductive analysis can miss a failure mode nobody thought to put in the tree; inductive analysis can miss the combination that only matters when two subsystems interact. Serious programmes run both and reconcile them, and the reconciliation itself is a finding: every significant FMEA effect should appear somewhere in a tree, and every basic event in a tree should trace to a real failure mode with a real rate.
Independence: the assumption everything rests on
Every probability multiplication in a safety argument encodes a claim of independence, and independence is the assumption reality attacks first. The civil aviation safety-assessment tradition institutionalised the counterattack as common cause analysis, a triad of studies that each hunt a different way for two "independent" channels to fail together:
- Zonal safety analysis asks a question about geography: for each physical zone of the vehicle or plant, what equipment lives there, what could it do to its neighbours (leakage, fire, heat, chafing, released fragments), and does the installation as built preserve the separation the drawings assumed. It is the study that finds the two redundant harnesses routed through the same conduit.
- Particular risks analysis asks about single external threats that cross zone boundaries by their nature: fire, bird strike, tyre burst, rotor burst, lightning, hail, high-energy radiated fields, flooding, dropped objects. Each is analysed as an event in its own right, tracing everything it could damage simultaneously, because such an event does not respect the architecture's channel boundaries.
- Common mode analysis asks about everything shared that is not physical: the same component type with the same defect, the same software build, the same design error in two "diverse" implementations, the same calibration procedure, the same maintenance technician performing the same task on both channels in the same shift, the same power source, the same clock.
The last of these is the most insidious because it is invisible on a block diagram. Two channels drawn as parallel boxes may share a requirements document, a compiler, a batch of parts, an installation crew, and a wrong assumption about the environment. Diversity (different designs, different suppliers, different algorithms, different technologies) is the classical defence, and it is expensive and imperfect: diverse implementations of the same misunderstood requirement fail identically, which is why requirement errors are the most feared class of common mode.
The quantitative shadow of all this is the redundancy ceiling from the reliability systems chapter: once a shared-cause fraction exists, adding channels stops helping, and the system's hazardous failure rate floors at the common-cause contribution. Safety practice therefore treats the CCA triad's findings as design requirements (separate these routes, harden against this threat, break this shared dependency) rather than as documentation produced after the architecture is frozen.
Latent failures and the exposure window
An order-two cut set is only as good as the assumption that the two failures do not accumulate quietly. When the first failure is undetected, the system runs as a single string until something reveals it, and the pair's protection is a fiction for the whole of that interval. This is the same latent-failure problem that the availability and testability books treat from their own angles, and in safety it acquires teeth because the exposure interval is a directly designed parameter:
| How the first failure is found | The exposure window | What the pair is really worth |
|---|---|---|
| Announced immediately by monitoring | The repair time | The order-two arithmetic holds as promised |
| Only at the next proof test | The test interval | The second channel's contribution follows the λT/2 average, not its instantaneous rate |
| Only at a check less frequent than the mission | The whole mission | For that mission the pair is a single string; aviation analyses carry this as an explicit average exposure time |
- Detected failures shrink the window to the repair time, and the pair behaves as the arithmetic promises.
- Undetected failures stretch the window to the proof-test interval, and the second channel's contribution is governed by the λT/2 average rather than by its instantaneous rate.
- Failures detected only at a check whose interval exceeds the mission are, for that mission, not detected at all: a pre-flight test that cannot run in flight bounds the exposure at the flight's length.
Two design consequences follow directly. Protective and standby channels need the richest monitoring in the system, because their whole value depends on their state being known. And proof-test interval is a safety parameter with the same standing as a failure rate: halving it halves the latent contribution, and stretching it for operational convenience is a change to the safety argument that must be assessed as such, not a maintenance scheduling decision.
Failure direction: fail-safe, and when there is none
Reliability arithmetic treats failure as a single event; safety treats it as a direction. The design question is not only how often a thing fails but what state it lands in, and the taxonomy is worth naming precisely because architectures are chosen against it:
| Behaviour on failure | What the system does | Where it fits |
|---|---|---|
| Fail-safe | Falls to a state known to be safe: signal to red, valve to closed, brakes applied, power removed | Available whenever a genuinely safe state exists and reaching it is not itself dangerous |
| Fail-passive | Stops contributing, without a large disturbance; control passes elsewhere | Flight control channels where a benign disconnect is acceptable |
| Fail-operational | Continues to perform the function after the failure, usually via redundancy and voting | Functions with no safe state available: flight in certain phases, life support, some autonomous driving cases |
| Fail-silent | Fails without producing wrong output; either correct or nothing | Distributed architectures where a wrong output would poison other channels |
The unifying design idea is the safe state, and the hardest safety problems are precisely those where none exists. An aircraft in flight cannot be switched off; a chemical reaction mid-exotherm cannot simply be abandoned; a vehicle in the middle lane cannot stop dead safely. Where no safe state exists, safety has to be bought with continued correct operation, which is the expensive branch: fail-operational architectures, voting, reconfiguration, and the whole apparatus of degraded modes. Two further traps deserve naming. The safe state can be dangerous in context: an emergency shutdown is safe in most process plants and hazardous in a few; brakes to full is safe at low speed and not at all safe on a motorway in traffic. And the transition can be the hazard: many accidents happen not in the failed state or the working state but during the reconfiguration between them, which is why changeover logic gets analysis attention out of proportion to its size.
The system that fails with nothing broken
Everything above assumes a hazard begins with a failure. A large fraction of real accidents do not, and the models built to explain them are part of the modern discipline rather than a soft appendix to it.
The latent-conditions view holds that organisational decisions (staffing, training, procedure design, maintenance policy, commercial pressure) create conditions that lie dormant in a system until they align with local triggering events and defensive gaps, at which point an accident passes through all the layers at once. The image of stacked defensive layers with shifting holes has become the standard shorthand, and its practical content is the instruction to look for the conditions that made an error likely rather than stopping at the error itself: the maintenance step performed wrongly on both channels because the procedure invited it, the alarm that was ignored because it had cried wolf for months, the workaround that had become normal because the sanctioned process was unworkable.
The systems-theoretic view goes further and reframes accidents as failures of control rather than chains of component failure. In this framing a system is a hierarchy of controllers, each enforcing constraints on the level below through control actions and feedback, and accidents result when the constraints are inadequate or not enforced: a control action that is unsafe in a particular context, a controller acting on a stale or wrong model of the process it is controlling, feedback that never arrives, two controllers issuing conflicting commands. Its hazard analysis technique works forward from unsafe control actions rather than backward from component failures, and it catches classes of problem the failure-based methods structurally cannot: requirements that were wrong, automation that did the specified thing at the wrong moment, and human-machine mismatches where the operator's model of the system diverged from its actual state.
| Failure-based methods | Control-based and human-factors methods | |
|---|---|---|
| The accident begins with | A component failing | A control action that was unsafe in its context |
| Strongest on | Hardware chains, quantifiable rates, certification arithmetic | Software-intensive, automated and human-in-the-loop systems |
| Structurally blind to | Requirements that were wrong; correct operation at the wrong moment | Random hardware degradation and its probabilities |
| Typical output | Cut sets, probabilities, criticality rankings | Unsafe control actions, loss scenarios, new constraints |
The mature position is not to choose. Failure-based methods are the right tool for the hardware chains that dominate mechanical and electrical hazards, and they carry the quantification the targets in the foundations chapter demand. Control-based and human-factors methods are the right tool for the software-intensive, human-in-the-loop, organisationally complex parts, where the dominant hazards are not "what broke" but "what did the system do that it should not have done, and why did that seem correct at the time." Systems that have both kinds of hazard, which is most of them, deserve both kinds of analysis.