Functional safety is an argument, supported by evidence, that a system's residual risk is acceptable. The engineering is in the evidence: hazard analysis that genuinely constrains the design, diagnostic coverage that is measured rather than asserted, and a qualification programme sized to the service life the product will actually have.
What can go wrong, how severely, how often, and how detectable. This produces the integrity level, and it has to influence the architecture rather than describe it after the fact.
Each hazard traced to a requirement, and each requirement traced to a design element and a verification activity. Traceability is the deliverable as much as the design is.
Where a lower integrity level plus independence achieves the same goal as a higher one — legitimate and valuable, provided the independence is real and demonstrable.
Error detection and correction, lockstep, watchdogs, redundant paths, plausibility checks, built-in self-test. Each chosen against a specific failure mode rather than added generically.
Failure modes, effects and diagnostic analysis: quantified failure rates and the fraction each mechanism actually detects. This is where diagnostic coverage becomes a number instead of a claim.
Fault injection, fault campaign coverage, and verification of the safety mechanisms themselves — because an undetected failure in a detector is worse than not having one.
Environmental, reliability and, where required, standard-specific qualification appropriate to the market and the service life.
What the integrator must do for the safety argument to hold in their system. A safe component used outside its assumptions is not safe.
Capability described here is engineering capability against these frameworks. Certifications held are confirmed at enquiry rather than claimed generically.
| Framework | Domain | What it governs |
|---|---|---|
| ISO 26262 | Automotive | Functional safety lifecycle and ASIL integrity levels A to D |
| IEC 61508 | Industrial | Functional safety and SIL integrity levels 1 to 4 |
| AEC-Q100 | Automotive | Qualification of integrated circuits for automotive use |
| IEC 62304 | Medical | Software lifecycle for medical device software |
| DO-254 / DO-178C | Airborne | Hardware and software design assurance |
| IEC 61511 | Process | Safety instrumented systems in process industries |
| EN 50128 / 50129 | Rail | Software and system safety for railway applications |
A product with a fifteen-year service life faces problems a consumer product never does. Components go end of life. Toolchains stop installing. The engineers who designed it leave. A vulnerability is discovered in a protocol stack that was current at design time.
So the reliability programme includes obsolescence monitoring rather than discovery at reorder, second sources qualified before they are needed, change control that keeps qualification valid through a substitution, archive discipline covering design data and toolchains, and a security maintenance path that remains defensible for the whole life — not just at launch.
None of this is glamorous, and all of it is cheaper designed in than retrofitted. A part that cannot be updated in year eight is a product that ends in year eight.
Achieving a safety goal with elements of lower integrity level plus demonstrated independence, rather than requiring every element to meet the highest level. It is legitimate and valuable, provided the independence is real and can be shown rather than asserted.
Failure modes, effects and diagnostic analysis quantifies failure rates and the fraction each safety mechanism actually detects. It is what turns diagnostic coverage from a claim into a number that a safety case can rest on.
The document telling an integrator what they must do for the safety argument to hold in their system — assumptions of use, required external measures and configuration constraints. A safe component used outside its assumptions is not safe.
Capability is described here against these frameworks. Which certifications are currently held is confirmed at enquiry rather than claimed generically on a website, because certification status changes and an out-of-date claim is worse than none.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.