Industrial & Automotive Functional Safety: ISO 26262 & IEC 61508

The Evolution Towards the “Living HARA”

The future belongs to the “Living HARA”. The hazard analysis and risk assessment must no longer be a static document. It must be treated as a continuously maintained work product, directly linked to the system model and responding dynamically to changes.

This becomes all the more important as development cycles shorten: where development is iterative and systems receive updates even after release (over-the-air), the safety assessment must continuously keep pace with every cycle, rather than being produced just once at a milestone.

The document loses its role as the single “source of truth”. It becomes instead an automatically generated view of a central model in which the actual information resides. This only works, however, if the safety artefacts are model-based and their dependencies are machine-readable. The same naturally applies to the FMEA and the FTA.

Traceability: The Digital Backbone of Safety

The backbone of this linkage is comprehensive traceability. Only a continuous derivation chain from the top-level safety goal through refined safety requirements all the way to implementation and test case makes changes manageable at all:

• When hazards change: If a hazardous event is re-assessed, the trace links immediately show which requirements, architecture elements, analyses and test cases are affected, and which remain untouched.
• Within the analyses: If an architecture element changes, the associated FMEA entries must be re-assessed. Since Failure Modes from the FMEA feed into the fault tree as Basic Events, every change propagates directly through to the FTA.

The scalability factor: Those who do not maintain these cross-references as digital trace links must laboriously reconstruct them by hand with every change. At short cycles, this does not scale: an impact analysis that costs weeks of manual work does not fit into any sprint. Without these chains, “living” merely means that a document is frequently edited, and gaps emerge in the safety evidence that only the assessor will find, when it is too late. With them, every change becomes an answerable question rather than a re-assessment from scratch.

What the Standards and Quality Models Require

The standards have long anticipated this step. Traceability between requirements, implementation and verification is required by all sector standards in one form or another: ISO 26262, IEC 62304, EN 50716 and DO-178C, which even lists trace data as a standalone work product.

And not just them: process quality models also require bidirectional traceability as a baseline practice: ISO/IEC 330xx (the standardised assessment family), Automotive SPICE (ASPICE) (as its specific industry derivation), CMMI.

The conclusion: Those who want to demonstrate process maturity cannot avoid digital traceability (just as those who want to demonstrate functional safety cannot), and this must be continuous.

How comprehensive traceability is built in practice (from tool integration to the Traceability Information Model) is covered on our Requirements Traceability page.

The present and future of functional safety does not exist in a vacuum. Every safety analysis must begin with the definition of the subject under consideration: which system is being assessed, where are its boundaries, and which interfaces are included?

Although the various sector standards use different terms and set their own emphases here, the core question is identical everywhere: What belongs to the system, and what does not?

System Boundaries Across Industries

Those who draw this system boundary too narrowly unconsciously shift safety-relevant interfaces out of their own area of responsibility, and painfully discover during the assessment that no one has taken care of them.

The Major Overlap with Cybersecurity

It is exactly at this system boundary that functional safety overlaps massively with cybersecurity (e.g. according to ISO/SAE 21434 and IEC 62443):

• The same subject, two perspectives: Hazard analysis (HARA) and threat analysis (TARA) examine exactly the same system. Safety protects the environment from the system: both from unintended malfunctions and unforeseen inadequacies. Security protects the system from the environment: specifically from deliberate, malicious attacks.
• Interactions upon changes: Every change to the system or its environment, but also every newly discovered vulnerability, potentially affects both disciplines. A security patch can alter the timing behaviour of the software and thereby endanger safety; a new safety function can open new attack vectors.

Practical conclusion: Safety engineering that ignores these interactions and works in silos is planning against reality. Only an integrated approach, based on a shared, model-based system architecture, ensures that safety and security go hand in hand.

Where does automation in safety lifecycle engineering already deliver genuine, measurable benefit today? Two concrete practical examples show the way:

1. Automated Dependent Failure Analysis (DFA)

A prime example is the Dependent Failure Analysis. Those performing an ASIL decomposition (for example, splitting an ASIL-B target into two times ASIL A(B)) must demonstrate the strict independence of the decomposed elements. In practice, this proof (for example, for the independence of power supplies or memory areas) is one of the most demanding tasks of all.

Here, engineering knowledge can be brought into a machine-verifiable form in conjunction with modern AI:

• The ontology as a rule set: The underlying independence rules of the standards are defined as an unambiguous ontology.
• Continuous checking: The system model is checked automatically and continuously against the rules. Violations become immediately apparent when they arise, not months later in a review.
• LLM support as an accelerator: We use suggestions generated by Large Language Models (LLMs) to map the expert knowledge encoded in the ontology precisely to the domain- and customer-specific entities in the system.

The effect: This does not replace full formal verification, but it drastically reduces the manual review effort. This pattern (formalising expert knowledge as verifiable rules and running them continuously against the central model) is naturally transferable to further safety requirements.

2. Semi-Automatically Generated Redundancy in the Toolchain

A further powerful principle breaks with an old dogma: redundancy was previously an extremely expensive means of error prevention in the final product. Through partial automation, it becomes an affordable, highly efficient means of error detection in the development process.

The principle in vertical systems and software engineering:

1. Independent toolchains: Two mutually independent, semi-automated toolchains (regardless of whether these work in a partially agentised, i.e. AI-supported, manner or in a classically rule-based way) derive the same engineering artefacts.
2. The comparison: If contradictory results arise during subsequent testing, this discrepancy becomes an extremely valuable signal.
3. Error detection: Errors in the toolchains or misunderstandings in the specifications become immediately visible.

With this approach, development teams gain double assurance without double the manual effort.

Everything said so far concerns hazards arising from malfunctions: a component fails, a signal is corrupt, or software does not do what it is supposed to do.

There is, however, a second class of hazards in which absolutely nothing fails. The system operates exactly as specified, and yet a dangerous situation arises. The specification or the physical performance of the function is simply insufficient for the real-world situation:

• The classic example: A camera fails to detect an obstacle in low sun or heavy snowfall.
• The cause: The system is intact, but the scenario was not considered during design, or the sensor technology reaches its physical limits.

For this class, ISO 21448 (SOTIF, Safety of the Intended Functionality) is the relevant standard in the automotive domain.

In a nutshell: Classical functional safety asks: What happens if the system does not do what it is supposed to do? SOTIF asks: Is what the system is supposed to do sufficient in every conceivable situation?

A Separation with Real Consequences, Not an Academic One

Those who conflate these two disciplines will inevitably reach for the wrong toolbox in engineering. The challenges could not be more different:

Teams without a clear distinction quickly treat a performance limit as a malfunction. They produce expensive measures that do not address the actual problem at all, while hazards without a clear fault signal remain completely invisible in a purely fault-oriented analysis (such as a classical FMEA).

Not a Footnote, but a Necessary Complement for Modern Systems

For the question of where functional safety engineering is heading, SOTIF is far more than a footnote. The underlying idea is known in other industries under different names:

• Aviation has for decades examined the operating context at system level.
• Medical technology evaluates risks of the intended purpose independently of device failures.
• Machinery includes foreseeable misuse in the risk assessment.

What is new in ISO 21448, however, is the strict systematic approach for performance limits of complex perception functions: the mathematical-methodological division into known/unknown and safe/unsafe scenarios.

This systematic approach is gaining massive importance across industries as learning components (AI / Machine Learning) increasingly enter safety-relevant functions.

The reason: Machine learning functions have no specification in the classical sense. Their weaknesses are performance limits inherent to their design principles, not malfunctions. The weight of safety work is thus shifting inexorably in all domains from pure fault containment towards the systematic assurance of the intended function.

DISCLAIMER: The statements on this page refer to the following standards: IEC 61508 (second edition, 2010), ISO 26262:2018 (second edition), ISO 21448, ISO 12100, IEC 62304, IEC 60601, ISO 80601, ISO 25119, IEC 62061, EN 50716, EN 50129, and DO-178C including the supplement DO-331. This page does not replace normative reading and does not constitute certification advice.