Functional Safety
Functional safety is the part of a system’s safety that depends on the correct functioning of safety-related electrical and electronic (E/E) systems. The goal is the absence of unreasonable risks caused by malfunctions. The basic standard is IEC 61508; in the automotive domain, ISO 26262 applies.
What it is about: risks caused by malfunctions
Functional safety considers hazards that arise from the misbehaviour of a system: a component fails, a signal is corrupt or a piece of software does not do what it should. A distinction is made between random hardware failures, which are assessed probabilistically and controlled through diagnostics, redundancy and degraded operating modes, and systematic faults — for example in the specification or software — which are addressed through process rigour, suitable methods and verification. The approach is risk-based throughout: what is required is not absolute freedom from faults, but the reduction of risk to an acceptable level — frequently by the system detecting faults and transitioning to a safe state. How much risk reduction is necessary is expressed by graded integrity levels: SIL 1 to 4 in IEC 61508, ASIL A to D in ISO 26262.
The standards landscape
Wherever a system failure can endanger people, safety standards exist:
| Industry | Standard |
|---|---|
| Cross-industry basic standard | IEC 61508 |
| Automotive | ISO 26262 |
| Machinery | IEC 62061 |
| Railway | EN 50716, EN 50129 |
| Agricultural machinery | ISO 25119 |
| Medical technology | IEC 62304, IEC 60601, ISO 80601 |
| Aviation | DO-178C |
Many of these sector standards are direct derivations of IEC 61508; others follow comparable fundamental principles: safety lifecycle, risk-based classification, graded method requirements and traceability between requirements, implementation and verification.
Safety vs. security
Functional safety and cybersecurity look at exactly the same system from two angles: safety protects the environment from the system — from unintended malfunctions and insufficiencies. Security protects the system from the environment — from intentional, malicious attacks. Methodologically, hazard analysis (HARA, ISO 26262) and threat analysis (TARA, ISO/SAE 21434) face each other. Both disciplines influence each other: a security patch can change the timing behaviour of the software and thereby endanger safety; a new safety function can open new attack vectors. Safety engineering that ignores these interactions and works in silos plans past reality.
What functional safety does not cover
Functional safety addresses malfunctions. There are, however, hazards in which nothing fails: the system works exactly as specified, but the specification or the performance is simply not sufficient for the real situation — for example when a camera does not detect an obstacle in low sun. For this class, ISO 21448 (SOTIF — Safety of the Intended Functionality) applies in the automotive domain. Passive safety (such as seat belts and crumple zones) and electrical safety are also to be considered separately.
Functional safety in practice
In practice, functional safety is above all evidence work: for each safety goal, it must be demonstrated without gaps how it has been implemented through safety requirements, architecture and implementation all the way into testing — bundled in the safety case. The backbone of this evidence is end-to-end traceability across tool boundaries. The shorter the development cycles become and the more frequently systems receive updates even after release, the less the frozen safety document holds up: the safety assessment must run continuously, instead of being produced once at a milestone.