What Is ISO 26262? A Practical Guide to Automotive Functional Safety

ISO 26262 is the international standard for functional safety of electrical and electronic systems in road vehicles. First published in 2011 and revised in 2018, it applies to any system where a malfunction could cause harm to people — from brake controllers and steering actuators to battery management systems and ADAS perception stacks.

The standard is not a checklist. It is a risk-based framework. You do not prove compliance by having a document that says the right things. You prove it by showing that every safety requirement in your system was derived from a real hazard, assigned an appropriate integrity level, decomposed logically through the architecture, and verified at each level of that decomposition. That chain — from hazard to hardware test — is the spine of the whole standard. Everything else is annotation.

This article covers what engineers actually need to understand: the ASIL classification scheme, the structure of safety goals and safety requirements, how decomposition works, what V&V requires at each level, and what your requirements tooling needs to do to support all of it.

The ASIL Framework: Risk, Not Severity Alone

ASIL stands for Automotive Safety Integrity Level. There are four levels — A, B, C, D — plus a fifth category called QM (Quality Management) for items that don’t require safety measures beyond normal quality practice.

The level is not determined by how bad a failure would be in isolation. It is determined by three factors combined:

Severity (S0–S3): What is the worst-case harm to people if the hazardous event occurs? S0 is no injury; S3 is life-threatening injuries likely fatal.

Exposure (E0–E4): How often is the vehicle in the operational situation where the hazard could occur? E0 is an incredible situation; E4 is one the driver encounters continuously.

Controllability (C0–C3): Can the driver or other road users avoid the harm through their own actions? C0 means controllable in general; C3 means uncontrollable or difficult to control.

The combination of S, E, and C maps to an ASIL through a defined lookup table in Part 3 of the standard. A failure that is highly severe (S3), frequently exposed (E4), and uncontrollable (C3) yields ASIL D. A failure that is severe but rare and usually controllable might yield ASIL B or even QM.

The practical implication: ASIL is a property of a hazardous event, not of a component. You derive it from Hazard Analysis and Risk Assessment (HARA), and that HARA is the foundation document the entire safety case sits on. If the HARA is wrong or incomplete, every requirement derived from it is suspect.

Safety Goals and Functional Safety Requirements

A safety goal is a top-level safety requirement derived directly from the HARA. It describes what the item must not do (or must do) to avoid the hazardous event, and it carries the ASIL assigned during HARA.

Safety goals are intentionally abstract. An example: “The electric power steering shall not apply unintended torque in excess of X Nm while the vehicle is moving.” That goal says nothing about sensors, software states, or hardware redundancy. It just defines the boundary condition the system must never cross, and it inherits a specific ASIL — say, ASIL C.

From safety goals, you derive functional safety requirements (FSRs). These are allocated to the system concept and describe what the system must do to satisfy the safety goal: detect, respond, degrade, isolate. FSRs are still relatively abstract — they operate at the functional level, not the component level.

From FSRs, you derive technical safety requirements (TSRs). These are allocated to specific hardware or software elements. A TSR might specify a watchdog timeout, a sensor diagnostic coverage percentage, a software error detection mechanism, or a hardware redundancy topology. TSRs have to be specific enough that an engineer can implement them and a tester can verify them.

This three-tier hierarchy — safety goal → FSR → TSR — is not just an organizational preference. It is structurally required by ISO 26262. And it means your traceability cannot be a flat list. It must preserve the hierarchy.

ASIL Decomposition

ASIL decomposition is one of the most misunderstood mechanics in ISO 26262. Here is what it actually means.

If a safety goal is ASIL D, that does not necessarily mean every component in your system must be developed to ASIL D. You can decompose the ASIL across redundant channels, provided those channels are sufficiently independent — in fault causes, development processes, and physical implementation.

The standard allows specific decompositions:

  • ASIL D can decompose into ASIL B + ASIL B (written ASIL D(B+B))
  • ASIL D can decompose into ASIL C + ASIL A
  • ASIL C can decompose into ASIL A + ASIL A, or ASIL B + QM

The independence requirement is real and auditable. If two channels share a power supply, a software base, or a common manufacturing defect source, the decomposition is invalid. Auditors will look at this closely, particularly for high-ASIL items.

Decomposition has direct tooling implications. Your requirements system must track not just parent-child links between requirements, but the ASIL attribution at each level, the decomposition rationale, and which requirements belong to which channel. A spreadsheet cannot do this reliably at scale. It will drift.

The V-Model and V&V Obligations

ISO 26262 uses the V-model as its structural frame. The left side of the V defines requirements at progressively finer levels of abstraction: item definition, safety goals, FSRs, system design, TSRs, software architecture, unit design, implementation. The right side verifies each level against its counterpart on the left.

The critical implication: V&V is not a phase. It is a set of activities tied to specific requirement levels.

  • Safety goals are verified through system-level safety validation — does the system actually prevent the hazardous event?
  • FSRs are verified through integration testing of the safety mechanisms.
  • TSRs are verified through component testing, hardware-in-the-loop, software unit tests, and formal analysis depending on the ASIL level.

At ASIL C and D, the standard specifies which verification methods are “recommended” versus “highly recommended” versus “mandatory” — and it does so per requirement level. Fault injection testing, formal verification, and back-to-back testing of model-generated code all appear on those lists for high-ASIL software.

What this means for tooling: your requirements system needs to carry not just the requirement text and its ASIL, but the associated verification method and the verification status. A requirement that exists but has no assigned verification method is an open finding in an audit.

What Requirements Tooling Needs to Support

Traditional document-based tools — and this includes Word-based workflows with Excel traceability matrices — break down in the ISO 26262 context for predictable reasons.

First, they cannot enforce hierarchical integrity. If someone modifies a TSR in a way that no longer satisfies its parent FSR, there is no automatic signal. The broken link is invisible until a human reviews it — if a human reviews it.

Second, they cannot track ASIL attribution through the hierarchy. ASIL is a property that must be preserved and visible at every level. A column in a spreadsheet is not the same as a structural constraint.

Third, document-based tools make ASIL decomposition opaque. Decomposition creates parallel requirement branches that must be maintained in sync. Without a graph model, that structure has to be manually reconstructed every time someone asks “why does this component have ASIL B?”

Fourth, they cannot generate meaningful traceability reports for audits. ISO 26262 auditors want to see coverage in both directions: every safety goal traces down to at least one FSR, every FSR traces to at least one TSR, and every TSR traces to at least one verification activity. Generating that from a document system requires manual extraction — which means it’s usually out of date.

How Modern Tools Handle ISO 26262 Workflows

This is where the tooling market has genuinely improved in the last several years. Dedicated requirements management platforms have moved from storing requirements to modeling them.

Tools like IBM DOORS Next and Polarion have built-in traceability features and have long histories in automotive safety programs. They can enforce link types, generate compliance reports, and integrate with test management systems. Their strength is depth of integration into large-program workflows and familiarity in Tier 1 supplier environments. Their limitation is that they are fundamentally document-centric systems with traceability added on top — the graph is implicit rather than structural.

Jama Connect takes a more structured approach and has purpose-built workflows for ISO 26262, including ASIL tagging and coverage reporting. It is used across medical and automotive domains and is solid for mid-size programs. Codebeamer, now part of PTC, goes further with its integrated ALM model, combining requirements, tests, and change management in a single platform — relevant for teams that need to tie safety requirements to software change control directly.

Flow Engineering (flowengineering.com) takes a different architectural approach that is particularly well-suited to ISO 26262 workflows. It is built natively on a graph model, which means the hierarchical structure of safety goals → FSRs → TSRs is a first-class data model, not a workaround inside a document store. ASIL attribution is tracked as a property of each node in the graph, decomposition relationships are explicit edges, and broken trace links are surfaced automatically rather than requiring manual audits.

Where Flow Engineering is particularly strong is in the AI-assisted workflows that help engineers navigate the derivation process — flagging when a new TSR lacks a clear parent FSR, or when an ASIL assignment at a child level appears inconsistent with its parent. For teams doing new vehicle programs from scratch, or integrating novel architectures like zonal E/E designs or software-defined vehicle stacks, that kind of active assistance during authoring is more valuable than comprehensive reporting after the fact.

Flow Engineering is purpose-built for systems engineering teams rather than program management workflows, which means large enterprises managing multi-thousand-requirement programs across multiple suppliers may need to evaluate how it integrates into their existing supplier data exchange processes. That is a deliberate product focus, not a gap in capability.

Practical Starting Points for ISO 26262 Programs

If you are starting or inheriting a functional safety program, here is how to sequence the work:

1. Anchor everything to the HARA. Every requirement in your system should be traceable to a hazardous event and a safety goal. If you cannot trace a requirement to an ASIL-bearing safety goal, you do not know how rigorously to manage it.

2. Use the three-tier hierarchy explicitly. Maintain a clear boundary between safety goals, FSRs, and TSRs. Mixing levels in a single flat list is the fastest way to create an unmaintainable safety case.

3. Assign verification methods at authoring time, not during test planning. If a TSR does not have an assigned verification method when it is written, it will not have one when testing starts either. The tool you use should enforce this.

4. Model decomposition as structure, not commentary. ASIL decomposition should be represented as an explicit relationship with a justification for independence. “See design document” is not a decomposition rationale.

5. Plan for change. ISO 26262 programs run for years. Requirements change. When a safety goal changes, every FSR and TSR derived from it is potentially affected. Your tooling needs to propagate change impact analysis automatically, not via email.

Honest Assessment

ISO 26262 is demanding not because its paperwork requirements are complex, but because it forces engineering rigor on the full derivation chain from hazard to verified requirement. Teams that treat it as a documentation exercise will spend enormous effort producing artifacts that do not reflect the actual system — and will discover that gap during audit, or worse, during a field failure analysis.

The standard rewards teams that model their safety architecture honestly, trace requirements structurally, and verify at each level of decomposition. Modern graph-based tools make that tractable in a way that document-based approaches simply do not. Choosing your tooling infrastructure early in a program — before the safety case has grown to thousands of requirements — is one of the few decisions in automotive engineering where the upfront investment almost always pays off.