Safety is the only property in this row whose failures are counted in people. The other three ask how often a system breaks, how fast it comes back, and how much of the time it is fit for use; safety asks a question with a different currency entirely: of everything this system can do wrong, which outcomes are unacceptable, and what stands between the system and those outcomes? It is the property with legal force behind it, the one that puts engineers in front of inquiries, and the one whose analyses outlive every other document a programme produces.
It is also the property most often misunderstood as a synonym for reliability. It is not. A system can be extraordinarily reliable and lethally unsafe, and it can be gloriously unreliable and perfectly safe. This topic is the theory of the difference: the vocabulary of hazards and risk, the mathematics that turns severity and likelihood into a decision, the integrity ladders (DAL, SIL, ASIL) that different industries built to do the same job, the design principles that actually remove risk rather than document it, and the safety case that has to convince someone else.
What safety is
The international definitional convention (ISO/IEC Guide 51, the guide that governs how safety is written into standards) builds the whole subject from three linked terms:
| Term | Definition | Why the wording matters |
|---|---|---|
| Harm | Injury or damage to health, property or the environment | Safety is defined against consequences to people and assets, not against loss of function |
| Hazard | A potential source of harm | A hazard is a state or condition, not an event and not a failure: fuel plus ignition source, an unguarded blade, an aircraft below its terrain clearance |
| Risk | The combination of the probability of occurrence of harm and the severity of that harm | Two dimensions, always; either one alone decides nothing |
| Safety | Freedom from risk which is not tolerable | Not "freedom from risk": absolute safety does not exist, and standards that pretend otherwise cannot be complied with |
That last row is the philosophical spine of the discipline and worth dwelling on. Safety is defined relative to a tolerability judgment, which means every safety argument eventually rests on a claim that a residual risk is acceptable to someone with the authority to accept it. Engineering can reduce risk, quantify it, and evidence it; it cannot declare it acceptable. That is why the military standard practice for system safety makes formal risk acceptance by a named authority an explicit process step rather than a signature at the end, and why the civil aviation and railway frameworks anchor their numerical targets in the authorities' published frameworks (in civil aviation, the acceptable means of compliance behind the airworthiness requirement) rather than in engineering preference.
The defence vocabulary adds one more term the aviation world calls an accident: a mishap, an event or series of events resulting in unintentional death, injury, occupational illness, damage to or loss of equipment or property, or damage to the environment. The chain that safety engineering works on runs: hazard exists → some initiating event or failure occurs → the hazard is realised → a mishap results, with severity determined by the circumstances. Every technique in the methods chapter attacks a different link in that chain.
Why safety is not reliability
The confusion between the two properties is so persistent, and so consequential, that it deserves its own section:
- Reliability counts every failure; safety counts only the ones that hurt, weighted by how badly. A photocopier that jams weekly has a reliability problem. A pressure vessel that has never failed has a safety problem if its single failure mode is rupture with no protection.
- Safety cares intensely about which way a thing fails. A signal that fails to red stops trains; the identical component failing to green kills people. Reliability arithmetic is blind to this distinction; the entire concept of fail-safe design exists to exploit it.
- Safety counts failures that reliability does not count at all. Correct operation at the wrong moment, a function performing exactly as specified in a situation nobody anticipated, an operator misled by a display that is working perfectly: none of these are failures in the reliability sense, and all of them have killed people. This is the domain systemic accident models were invented to address.
- Redundancy helps reliability almost always, and safety only sometimes. Adding a channel reduces the chance of losing a function; it also adds parts, adds failure modes, adds a voting mechanism that can fail actively, and can make a system that fails dangerously rather than safely. Whether a given redundancy improves safety depends on which failure direction it protects.
- Reliability improvements are continuous; safety requirements are often threshold. Doubling the MTBF of a subsystem is a proportional benefit. Removing the last single point of failure from a catastrophic failure condition is a qualitative change of state: the design either has one or it does not, and no amount of component quality substitutes.
The relationship that does hold is one of supply: safety analyses consume reliability numbers as inputs. Failure rates from prediction populate the fault trees; failure modes from FMEA populate the hazard causes; detection coverage from testability decides which dangerous failures are announced and which lie latent; and repair and inspection intervals from the maintainability and availability work set the exposure times that turn a rate into a probability. Safety is the discipline that asks a different question of the same data.
The two faces of a safety requirement
Every safety requirement in practice is one of two kinds, and mixing them up is a classic source of failed arguments:
- "Do not do the dangerous thing." The system must not release the weapon without authority, must not open the door in flight, must not command full acceleration when the driver is braking. These are integrity requirements about not producing a hazardous output, and they are met with protection, monitoring, interlocks, and independence.
- "Do not stop doing the protective thing." The braking must remain available, the shutdown system must operate on demand, the fire suppression must discharge. These are availability requirements on a protective function, and they are met with redundancy, proof testing, and the on-demand mathematics from the availability book.
The two pull in opposite directions, and the tension is one of the central design problems of the discipline. Adding a second channel so the protective function never fails to act increases the chance that some channel acts spuriously; adding voting logic so nothing acts spuriously increases the chance that nothing acts at all. The engineering answer (which channel arrangement, which vote, which failure direction on loss of power) is settled by asking which of the two failure directions is worse, which is exactly the severity question the hazard analysis is there to answer.
Safety among R, A, M and S
Safety is the consumer of the other three properties, and each supplies it with something the safety argument cannot compute for itself:
| Relationship | What safety takes from it |
|---|---|
| From reliability | The failure rates that populate every fault tree and every quantitative target, and the failure-mode inventory the hazard causes are drawn from |
| From maintainability | Repair and restoration times, which set how long a first failure sits waiting for a second, and the maintenance actions that are themselves a hazard source |
| From availability | The proof-test and inspection intervals that bound the exposure of a dormant protective function, and the on-demand mathematics behind its probability of failing when called |
| From testability | The detection split: which dangerous failures announce themselves and which lie latent, which is the starting inventory of every hidden-failure argument |
The traffic runs one way in data and both ways in design. Safety consumes the other three properties' numbers, and in return it imposes constraints on them: a fault tree that will not close forces an architecture change, a latent-failure argument forces a monitoring requirement, and a proof-test interval derived from a safety target becomes a maintenance commitment for the life of the system.
Where the discipline came from
Safety engineering is the most accident-driven discipline in the RAMS family: nearly every framework in use today can be traced to a specific catastrophe and the inquiry that followed it. The pattern repeats across sectors: a novel technology outruns the intuitions of the people operating it, a rare combination of failures produces an outcome nobody modelled, an inquiry finds that the organisation had the information and lacked the process, and a standard is written to institutionalise the process that was missing.
The intellectual milestones matter because they still shape what practitioners are asked to produce:
| Era | What changed | What it left behind |
|---|---|---|
| 1940s–60s | Missile and aerospace programmes find that reliability engineering alone does not prevent catastrophic events; system safety emerges as a distinct discipline in US defence | The system safety programme: hazard identification, risk assessment, formal acceptance; the MIL-STD-882 lineage |
| 1960s–70s | Fault tree analysis is developed for missile launch control and adopted by the nuclear industry; probabilistic risk assessment matures | Fault trees, cut sets, quantified top events; the handbook tradition that codified them |
| 1970s–80s | Process industry disasters drive hazard-study methods and the tolerability debate | HAZOP, layers of protection, the ALARP framework in UK law and regulation |
| 1980s–90s | Aircraft become software-integrated; probability alone cannot argue software correctness | Development assurance: ARP4754 and its safety-assessment companion ARP4761, and the DAL concept |
| 1990s–2000s | Functional safety generalises across industries | IEC 61508 and its sector children: railway, process, machinery, and later automotive |
| 2000s onward | Systemic and human-factors models challenge the failure-chain view | Swiss cheese, STAMP/STPA, safety culture and safety management systems |
Two threads run through the whole history and will run through this book. The first is the steady migration from counting failures to assuring processes: as systems became software-rich, the probability of a design error stopped being computable, and the discipline responded by regulating the rigour of development instead of predicting its outcome. The second is the migration from components to systems: from "which part broke" to "how did this organisation, its automation, and its people combine to produce an outcome none of them intended." The chapters that follow take the mathematics first, then the system view, then the design and programme machinery, then the toolkit map.