Safety has the largest toolkit of any property in this row, because it must attack the hazard chain at every link: before the design exists, while it is being architected, once it is detailed, and after it is flying. This chapter maps the tools, shows how they hand work to one another across the lifecycle, records where the RAMSynapse platform runs them, and closes with how the emphasis shifts by industry.
The safety toolkit
| Method | The question it answers | Typical phase | Read more |
|---|---|---|---|
| Preliminary hazard identification and analysis | What hazards does this concept bring with it, before anything is designed? | Concept | Within the FHA family of hazard studies |
| Functional Hazard Analysis | What are the failure conditions of each function, how severe, and what integrity does each demand? | Concept and requirements | Topic planned |
| FMEA / FMECA | Inductively: what does each failure mode do, and how critical is it? | Design | Topic planned |
| Fault Tree Analysis | Deductively: what combinations produce this hazardous outcome, and how probable is it? | Design | Topic planned |
| Common cause analysis (zonal, particular risks, common mode) | Does the claimed independence actually hold? | Design | Within the FHA and FTA practice |
| Event tree and layer-of-protection analysis | Forward from an initiating event: which protection layers hold, and what outcomes remain? | Design, process sectors | Within the FTA practice |
| HAZOP and guideword studies | What deviations from design intent are possible at each point of the process? | Design, process sectors | Within the FHA family of hazard studies |
| Markov and state modelling | What happens when repair, detection and reconfiguration couple the states? | Design | Within the RBD family |
| System-theoretic process analysis | Which control actions are unsafe in which context, and why would a controller issue them? | Concept through operation | Within the FHA family of hazard studies |
| Reliability Prediction | The rates that quantify every tree and every target | Design | Full topic published |
| Testability | Which dangerous failures announce themselves, and which stay latent between proof tests | Design | Full topic published |
| FRACAS and mishap investigation | Is the safety argument holding in service? | Operation | Topic planned |
The toolkit divides along the two axes this book has used throughout. Inductive against deductive: FMEA and event trees work forward from causes to consequences, fault trees and hazard analyses work backward from consequences to causes, and mature programmes run both because each catches what the other structurally misses. Failure-based against control-based: the classical methods assume a hazard begins with something breaking, while the systems-theoretic methods assume it can begin with everything working as specified, and software-intensive, human-in-the-loop systems need the second kind alongside the first.
How the methods chain together
- Classification comes first. Functional hazard analysis enumerates functions and their failure conditions, classifies each by severity, and derives the safety targets and assurance levels. Everything downstream is measured against this output, which is why an error here (a mis-classified failure condition) propagates further than any other mistake in the chain.
- The architecture is tested on paper. Preliminary assessment builds fault trees on candidate architectures to check whether the targets are reachable and whether any order-one cut sets survive; common-cause studies attack the independence the trees assume; the results feed back as architectural requirements rather than as findings.
- Detail supplies the evidence. FMEA produces failure modes and effects with rates from the prediction; testability supplies the detection split that sets latent exposure; development assurance supplies the process evidence for the systematic side.
- The assessment consolidates. The system safety assessment gathers the quantitative results, the qualitative structure, the common-cause findings and the assurance evidence into the argument the safety case presents, with the hazard log carrying every hazard's status from identification to acceptance.
- Service feeds back. Mishaps, near misses, observed rates and every change are assessed against the argument, and the hazard log is updated rather than archived.
The chain's characteristic failure is the same one this knowledgebase keeps finding, with higher stakes: stale inputs. A fault tree quantified with superseded failure rates, a classification never revisited after the function's scope grew, an independence argument written before the installation moved two cables into the same conduit. Because the safety case is a claim about a specific configuration, the configuration management of its inputs is part of the safety argument, not administration around it.
Where RAMSynapse runs them
Every module in the platform's safety domain is built, and the safety chain also draws on built modules from the reliability and risk domains; they sit exactly where this chapter's chain puts them. Functional Hazard Analysis carries the failure conditions, their severity classification and the assignment of development assurance levels, implementing the ARP4754 and ARP4761 practice described throughout this topic (the module's registry standard names ARP4754A and ARP4761; both were revised in December 2023 as ARP4754B and ARP4761A). Fault Tree Analysis builds quantitative trees on the shared system model, computing cut sets, top-event probabilities and importance measures, with failure rates arriving as live links from Reliability Prediction and failure-mode rates from FMEA / FMECA rather than as retyped tables. The allocation of budgets into the tree comes from Reliability Allocation, and the detection coverage that decides which dangerous failures stay latent comes from Testability, driven by the same FMECA modes. The live module ring shows this flow as it runs: hazards and assurance levels from FHA into the fault trees, mode rates from FMECA, and system rates from the reliability chain, all on one model.
What that buys, in the terms of this chapter, is configuration integrity: when a failure rate changes upstream, the trees that depend on it are not silently stale, which is the single most common way a safety argument quietly stops being true between design reviews.
Industry lenses
| Industry | What safety work typically looks like |
|---|---|
| Defence and aerospace | System safety programmes in the MIL-STD-882 tradition: hazard tracking, risk assessment codes, formal risk acceptance; on the civil side, the ARP4754 and ARP4761 development and assessment chain against certification requirements |
| Space systems | Range safety and mission assurance, single-point-failure elimination under mass constraints, probabilistic risk assessment for crewed missions |
| Railway | The EN 50126 lifecycle with tolerable hazard rates apportioned down the system, SIL-assigned signalling functions, independent safety assessment and the safety case as a formal deliverable |
| Nuclear | Probabilistic risk assessment at the deepest level practised anywhere: defence in depth, common-cause analysis to regulatory depth, protection-system proof testing as an availability instrument |
| Energy and resources | HAZOP and layer-of-protection analysis, safety instrumented functions specified and verified to SIL, functional safety management across the plant lifecycle |
| Automotive | ISO 26262 hazard analysis and risk assessment producing ASILs, decomposition across independent elements, and the safety-of-the-intended-function questions raised by driver assistance and automation |
| Medical devices | Risk management integrated with the quality system, use-related hazards and usability engineering, benefit-risk determination as a regulated judgment |
| Electronics and high tech | Product safety compliance, functional safety of components supplied into safety-critical systems, and the safety element out of context argument for reusable parts |
The constant across all eight is the one the overview began with: the analyses differ, the standards differ, and the underlying obligation does not. Identify what could harm people, understand how it could happen, remove what can be removed, control what remains, evidence the argument, and keep it true for as long as the system exists.