Safety analysis produces knowledge; only design produces safety. The distinction matters because the discipline has a chronic failure mode of its own: a programme that generates immaculate hazard analyses, assigns integrity levels correctly, quantifies its fault trees, and changes nothing about the machine. This chapter is about the part that changes the machine, and about the programme machinery that forces the change to happen while it is still cheap: the mitigation hierarchy, safety requirements, architectural means, development assurance, the hazard log, and the safety case that has to persuade somebody else.
The order of precedence
The single most important design principle in the discipline is an ordering, and every major framework states some version of it. The defence standard practice sets it out as a strict order of decreasing effectiveness:
| Rank | Measure | Why it sits here |
|---|---|---|
| 1 | Eliminate the hazard by design selection | If the energy, the substance or the mechanism is not there, no failure can release it. Nothing else is this robust |
| 2 | Reduce risk by design alteration | Change the design so the hazard's severity or likelihood drops: lower the stored energy, remove the exposure, reduce the pressure |
| 3 | Incorporate engineered features or devices | Interlocks, guards, relief valves, protection channels: they interrupt the mishap sequence, but they are additions that can themselves fail |
| 4 | Provide warning devices | Detection and annunciation only work if someone notices, understands and acts in time |
| 5 | Signage, procedures, training and personal protective equipment | Depends entirely on human compliance, in every instance, forever |
Two things about this list are load-bearing. The first is that it is an order, not a menu: a lower measure is only legitimate once the higher ones have been shown to be infeasible, and "we added a warning" is not an answer to a hazard that could have been designed out. The second is the standard's explicit caution that for the most severe categories, relying on the bottom rung as the only risk reduction should be avoided: a catastrophic hazard controlled solely by a placard and a procedure is not controlled. The same logic appears across sectors under different names (inherently safer design in the process industries, the hierarchy of controls in occupational safety), and it is the reason the earliest design phases are where safety engineering has the most leverage: elimination and design alteration are only available while the architecture is still soft.
From hazards to requirements
The bridge between analysis and design is the safety requirement, and its quality determines everything downstream. A hazard analysis that concludes "the control unit shall be reliable" has produced nothing; a hazard analysis that concludes "loss of the braking command shall be detected within 200 ms and shall command the fallback brake" has produced a testable design constraint with a verification obligation attached.
Good safety requirements share a shape: they name the hazardous condition to be prevented or controlled, they state the required behaviour including its timing, they state the integrity demanded (the target rate, the assurance level, the independence needed), and they carry a traceable link back to the hazard and forward to the evidence that will satisfy them.
| Element | Missing | Present |
|---|---|---|
| Hazardous condition | "The control unit shall be reliable" | "Loss of the braking command shall not propagate to the wheel actuators" |
| Behaviour and timing | "Faults shall be detected promptly" | "The fault shall be detected and the fallback brake commanded within 200 ms" |
| Integrity | Unstated, so the designer guesses | "...at the assurance level assigned to the catastrophic failure condition, with the detection channel independent of the command channel" |
| Verification | "Shall be tested" | "Demonstrated by fault injection on the integration rig, evidence recorded against hazard H-14" |
One category deserves particular vigilance: derived requirements, the constraints that emerge from design decisions rather than from the level above (a watchdog timeout, a data-refresh rate, an assumption about input ranges). They have no parent requirement to justify them and are therefore invisible to a top-down review, yet they frequently carry real safety content. The development-assurance frameworks make handling them an explicit obligation precisely because they are where safety requirements go missing.
Architectural means
Where hazards cannot be eliminated, architecture is the instrument that keeps their probability and their propagation bounded. Each means attacks a different failure class, which is why an architecture that leans on only one of them is fragile:
| Architectural means | The failure class it attacks |
|---|---|
| Independence and segregation | Common cause: shared space, supply, environment |
| Protection layers | Single-layer failure, whatever its origin |
| Monitoring and comparison | Dangerous undetected failures: converts latent to announced |
| Partitioning | Propagation from lower-criticality functions on shared resources |
| Dissimilarity | Shared systematic design and implementation errors |
| Simplicity | The unverifiable remainder: what cannot be understood cannot be assured |
- Independence and segregation. Physical separation of channels and routes, electrical isolation, separate power sources, and separation of protection from control so that the thing being watched cannot disable its watcher. The CCA triad from the systems chapter is the audit of whether the claimed independence survives the installation.
- Protection layers. Distinct, independent layers each capable of preventing or mitigating the hazardous outcome, so that the argument does not depend on any one of them: the design condition, the control system, the alarm and operator response, the automatic protective function, the physical relief, the containment. Counting layers only counts if the layers are genuinely independent, which is the whole point of the previous bullet.
- Monitoring and comparison. Self-checking, cross-channel comparison and plausibility checks convert dangerous undetected failures into detected ones, which is the transformation with the largest single effect on the latent-failure arithmetic.
- Partitioning. Where functions of different criticality share a processor, a network or a power supply, partitioning that is robust in space and time is what prevents a low-criticality function from corrupting a high-criticality one; without it, everything on the shared resource inherits the highest integrity level, with all the cost that implies.
- Dissimilarity where systematic failures dominate. Different implementations, teams or technologies for functions whose principal threat is a shared design error, accepting that dissimilarity is costly and never complete.
- Simplicity. The most underrated safety property: a function that can be understood completely can be verified completely. Complexity is the enemy of assurance, and architectural choices that reduce the amount of code and logic that must be trusted (small, well-isolated safety kernels rather than diffuse safety responsibility) buy more assurance than most added mechanisms.
Development assurance: rigour instead of probability
For systematic failures there is no probability to design against, so the frameworks substitute process rigour proportional to consequence, and the mechanism is the assurance level from the foundations chapter. What a level actually buys, in every framework that has one, is some combination of: how completely requirements must be captured and validated; how thoroughly verification must cover requirements, architecture, design and code; how much of that verification must be performed by someone independent of the people who did the work; how rigorously configuration and change must be controlled; and how much of it must be evidenced rather than asserted.
The design lever that follows is the one worth knowing: architecture can lower the assurance level a given item must carry. If a function's failure condition is catastrophic, the naive answer is to develop everything in its implementation to the highest level. If instead the architecture provides independent members, each capable of preventing the failure condition alone, the required assurance can be distributed between them, and the members individually carry a lower level than the function as a whole. The same idea appears in the automotive world as decomposition of an integrity level across sufficiently independent elements. The condition attached is always the same and always the hard part: the members must be genuinely independent, and the argument for that independence is exactly the common-cause work the previous chapter described. Assurance-level decomposition without a defensible independence argument is the most expensive mistake in functional safety, because it produces a system built to a lower standard than its consequences require, with paperwork that says otherwise.
The safety programme
The lifecycle shape is common to every sector, whatever it is called locally:
| Phase | The question | The activities |
|---|---|---|
| Concept and requirements | What must never happen, and how badly? | Preliminary hazard identification; functional hazard assessment; severity classification; safety targets and assurance levels allocated |
| Architecture | Does this architecture make the targets achievable? | Preliminary system safety assessment; fault trees on candidate architectures; independence and partitioning decisions; assurance-level assignment and any decomposition |
| Detailed design and implementation | Is the design meeting its safety requirements? | FMEA and detailed fault trees; common cause analyses; development assurance activities per level; safety requirement verification |
| Verification and validation | Can we demonstrate it, to someone who did not build it? | System safety assessment consolidating all evidence; test and analysis against every safety requirement; independent review |
| Acceptance | Is the residual risk acceptable, and who says so? | Formal risk acceptance by the designated authority; regulatory approval where applicable; the safety case submitted and defended |
| Operation and change | Is the argument still true? | Hazard log maintained; in-service monitoring and mishap investigation; every change re-assessed against the safety case |
Two artefacts run the length of the spine. The hazard log (in defence practice a closed-loop hazard tracking system) is the programme's spine of record: every identified hazard with its causes, its initial and target risk, the mitigations selected, the verification that they were implemented and effective, and the formal acceptance of what remains. It is a live control instrument rather than a report, it survives into operation, and an inquiry will read it before anything else. The safety case is the argument built on top of it: a structured demonstration that the system is acceptably safe for a defined application in a defined environment, made explicit as a claim, the argument that supports it, and the evidence the argument rests on. Its discipline is that all three parts must be visible: evidence without an argument is a pile of documents, and an argument without evidence is an opinion.
The third obligation is the one programmes most often skip: safety must be accepted by someone who did not build the thing. Independent review, independent safety assessment, and formal acceptance authority exist because the people closest to a design are the least able to see what it takes for granted. Framing that independence as a bureaucratic imposition rather than an engineering instrument is itself a warning sign, and it is one accident inquiries have named many times.
Operation: the argument has a shelf life
A safety case is a statement about a configuration, an environment and a set of assumptions, and all three drift. Components are superseded, software is patched, the operating profile changes, maintenance intervals are stretched under commercial pressure, a workaround becomes routine, an alarm that fires too often gets suppressed. Every one of those is a change to the safety argument, and the mechanism that keeps the argument alive is unglamorous: change control that routes modifications through safety assessment, in-service monitoring that watches for hazards materialising at rates the analysis did not predict, and mishap and near-miss reporting that is used rather than filed.
The feedback loop is the same FRACAS machinery the rest of this knowledgebase describes, with two safety-specific demands. Near misses count: an event that could have been an accident but was not is the cheapest information a system will ever produce about its own hazards, and organisations that only investigate outcomes learn nothing until the outcome is bad. And assumptions must be registered and revisited: every safety argument rests on assumptions about how the system will be used, maintained and staffed, and those assumptions are conditions of the argument's validity, not background context. Writing them down where the operator can see them, and reviewing them when the world changes, is what separates a safety case that remains true from one that was true when it was signed.