What Is an Automotive Safety Integrity Level (ASIL)?

ASIL ratings attach to safety goals. Put one on a component instead and everything downstream inherits the mistake. The rating ends up pinned to a box on a schematic, and then a change lands that nobody traces through to the hardware. The safety case still reads correctly, and it no longer describes the vehicle.

ISO 26262 introduced ASIL so that OEMs and Tier 1 suppliers could agree on how much process rigor a given safety goal earns. Getting the assignment right is the first half of that work, and keeping it true is the second. This guide covers how a rating is determined through hazard analysis, what each level from QM through ASIL D demands of a team, and what holds a rating together from the safety goal down to verification evidence.

What Is ASIL?

ASIL stands for Automotive Safety Integrity Level, the risk classification scheme ISO 26262 uses to rank safety goals in road vehicles, adapted from the Safety Integrity Level model in IEC 61508. ISO 26262 is the international standard for automotive functional safety. Its first edition was published in November 2011, and its second, in December 2018, spans twelve parts.

A safety goal is the top-level safety requirement that comes out of hazard analysis, which is where the rating attaches. Each derived requirement inherits its parent goal’s ASIL unless decomposition applies, and that rating carries from system architecture down through hardware, software and verification evidence.

The Five Classification Levels From QM Through ASIL D

ISO 26262 defines four ASILs, from ASIL A at the lowest to ASIL D at the highest, with QM underneath as a fifth tier. Each level scales the rigor a team applies across requirements, design, verification and confirmation. QM stands for Quality Management, and a hazard analysis that lands there has found the risk tolerable enough that the ISO 26262 lifecycle is not triggered at all. ASIL A starts the lifecycle at minimum rigor, ASIL B and C add independent verification and stricter coding rules, and ASIL D adds the most demanding hardware architecture metrics in the standard.

What the standard asks for at each level diverges in four places:

• Requirements notation: Informal natural language passes at ASIL A, and semi-formal models like SysML or Stateflow are recommended more strongly as the rating rises.
• Structural coverage: The software coverage measures the standard recommends escalate the same way, with Modified Condition / Decision Coverage at the top of that scale.
• Hardware metrics: The single-point fault metric, the latent fault metric and the Probabilistic Metric for random Hardware Failures all tighten at the higher ASILs.
• Independence: How independent a reviewer, auditor or assessor must be from the people who did the work is set by ASIL too, and strictest at D.

None of that rigor is chosen. The rating dictates it, and a structured risk assessment dictates the rating.

How ASIL Is Determined Through Hazard Analysis and Risk Assessment

Hazard Analysis and Risk Assessment (HARA) is where the rating gets fixed, and ISO 26262-3 sets out how. The team works from the item definition, identifies hazardous events at the vehicle level, scores each on three parameters, and writes safety goals against them. A safety goal covering several events carries the highest ASIL among them.

Each parameter has a defined scale:

• Severity, S0 to S3: how badly someone gets hurt. S0 is no injuries, S1 light to moderate, S2 severe with survival probable, S3 life-threatening or fatal. The judgement rests on the harm, whatever fault produced it.
• Exposure, E0 to E4: how much of the vehicle’s operating life is spent where the hazard can occur. A hazard that exists only during a gearbox downshift scores lower than one present whenever the car moves.
• Controllability, C0 to C3: whether the driver or another road user can act to avoid the harm once the failure happens. Teams argue about this one most, because it rests on assumptions about an attentive driver.

Once those three are agreed the lookup is mechanical, and ISO 26262-3 carries the grid:

Severity	Exposure	C1	C2	C3
S1	E1	QM	QM	QM
S1	E2	QM	QM	QM
S1	E3	QM	QM	A
S1	E4	QM	A	B
S2	E1	QM	QM	QM
S2	E2	QM	QM	A
S2	E3	QM	A	B
S2	E4	A	B	C
S3	E1	QM	QM	A
S3	E2	QM	A	B
S3	E3	A	B	C
S3	E4	B	C	D

Each step up in exposure or controllability moves the rating one level, and each step down in severity moves it one level the other way. Any event scoring S0, E0 or C0 leaves the ISO 26262 lifecycle entirely. The result feeds the Functional Safety Concept, which allocates safety requirements into hardware and software, and from there into every risk management decision the program makes. For motion control systems, SAE J2980 publishes worked ASIL results narrowed to collision-related hazards, and is worth reading alongside the standard.

ASIL Examples Across Real Vehicle Systems

The assignments below are typical rather than universal, since ASIL depends on a program’s item definition and operational design. Two teams can rate the same component differently and both be right, so the reasoning matters more than the list.

• ASIL D: Airbag deployment, anti-lock braking and brake-by-wire, electric power steering. Failure is life-threatening and the driver has little control over the outcome.
• ASIL B to C: Electronic stability control and adaptive cruise control. Cruise control commonly lands at ASIL C, adaptive cruise sometimes lower where supervisory features keep the driver in the loop.
• ASIL B: Headlights, brake lights, instrument cluster. Failure raises collision risk, but the driver usually has time to react.
• ASIL A: Tail lights for non-braking signaling, and the horn, where a failure can contribute to a collision at a lower residual hazard.
• QM: Cabin comfort, infotainment, power seat adjustment. No injury follows directly from their failure, so severity lands at S0.

The misclassification that trips up newer programs is rating a whole subsystem instead of a function. Cabin comfort belongs at QM, but windshield defrost and demist, run by the same hardware, does not. Losing forward visibility is a hazard in its own right, and it is the subject of Federal Motor Vehicle Safety Standard 103. The item definition sets the rating, whatever box the function ships in.

ASIL Decomposition and Its Independence Requirement

ASIL decomposition, defined in ISO 26262-9 Clause 5, lets teams split a high ASIL safety requirement across two redundant, sufficiently independent elements at lower ASILs that together meet the parent rating. The notation is ASIL X(Y), where Y is the original safety goal ASIL and X is the reduced ASIL of the decomposed element. The permitted pairs are narrow:

Parent ASIL	Allowed decomposition pairs
ASIL D	D(D) + QM(D), C(D) + A(D), B(D) + B(D)
ASIL C	C(C) + QM(C), B(C) + A(C)
ASIL B	B(B) + QM(B), A(B) + A(B)

Independence is what makes any of it hold. If two elements share a microprocessor, a power supply, or a common-cause failure path, the decomposition collapses and each element has to meet the parent ASIL on its own. Two software partitions on one electronic control unit (ECU) are the case teams get wrong most often. Partitioning software does nothing about the silicon underneath, so the hardware still answers to the parent rating however the software is split.

Common Pitfalls When Applying ASIL on a Program

Most ASIL problems are not disagreements about a rating. They come from applying a rating inconsistently across the artifact chain from HARA to verification, and three cases account for most of it:

• Over-classifying convenience features: Rating infotainment or cabin comfort at ASIL A pulls in rigor the system does not need and takes review attention off the functions that do.
• Decomposition without independence: Teams show the software split and stop there, so the hardware independence argument waits for an assessor to ask, which is the worst moment to find out it was never made.
• Treating HARA as a one-time deliverable: New hazardous events surface during integration testing and field trials. When the original HARA is not revisited, the safety case and the system drift apart, and the reconciliation lands as unplanned work right before an assessment gate.

None of the three is a classification mistake. Each is a maintenance mistake that the classification work then inherits, which is why they survive a HARA review that looks clean on the day.

Keeping ASIL Ratings True From Safety Goal to Verification Evidence

Set once on a safety goal, a rating has to survive every hand-off after it, into the Functional Safety Concept, the technical safety requirements, the hardware and software allocations they split across, and the verification evidence proving each was met. Nothing in the standard holds that chain together, and no tool holds it unattended.

Hardware and software inherit one rating and then develop on different cadences, so a change accepted in a two-week software sprint can invalidate a hardware assumption baselined months earlier. A safety goal refined after an integration test does not announce which of the forty requirements beneath it are suspect. Decomposition makes this harder, because the independence argument that justified the split has to still hold at the end of the program.

So the working test is one question a safety manager should answer without a week of archaeology. For this ASIL D safety goal, what implements it, what verifies it, and what has changed since either was approved? A program that can answer has a reviewable safety case. A program that cannot has documents that agreed with each other at some point in the past, and an assessment is where that shows.

Read the Apex AI Story

How Jama Connect Supports ASIL Classification and ISO 26262 Compliance

Jama Connect® answers that question by keeping the chain live, so it is not rebuilt for each assessment. Its pre-built automotive framework carries a Traceability Information Model laid out for ISO 26262 HARA workflows, so hazardous events, safety goals and the Functional Safety Concept sit inside the trace chain itself. The same framework carries TARA templates and reports for ISO/SAE 21434, so the cybersecurity case runs from item definition through TARA to cybersecurity goals, with impact analysis when a threat or risk treatment changes midstream. Coverage Gap Detection surfaces safety requirements with no linked verification, and suspect links mark downstream artifacts when an upstream item changes.

The cadence problem gets its own answer. Each team works against a baseline, a point-in-time snapshot of the items and their relationships at a milestone, and comparing two baselines shows exactly what changed between the one hardware signed off against and the one software is building to now: added and removed items, modified fields, new and broken relationships. Jama Software is also bringing Parallel Development into the product, starting in November 2026. It is not yet generally available, and it will let hardware and software each branch from the system baseline, work to its own schedule, and merge at integration with the rating intact. Jama Connect is itself TÜV SÜD validated for safety-related development.

Keeping ASIL Decisions Aligned Across Vehicle Generations

The next platform is where ASIL work either pays off or gets done twice. A safety case whose ratings still reconcile to the system as built is an asset the following program inherits, and one whose HARA has quietly diverged is a reconstruction job disguised as reuse. Which you get was decided years earlier, by whether the trace chain was kept live or assembled for each assessment.

Jama Connect supports that workflow by keeping requirements traceability current across HARA results, safety goals, derived requirements and verification evidence as they change, the approach Jama Software calls Live Traceability™. If your team is spending more of an assessment reconstructing the chain than reviewing it, you can start a free 30-day trial today.

Automotive Development

Frequently Asked Questions About ASIL

Who assigns ASIL ratings on a vehicle program?

OEM safety managers and hazard analysts own it, because the assignment happens at the safety goal level and safety goals come from the vehicle-level HARA. Tier 1 suppliers inherit those ratings contractually and refine them at the element level, and that interface is where most disputes start. Settling in writing what an inherited ASIL D obliges is most of what automotive requirements management is for.

Can a component’s ASIL rating change during development?

Yes, in two directions. Decomposition under ISO 26262-9 apportions a requirement across independent redundant elements at lower ASILs, lowering what each one carries. An updated HARA moves a rating the other way when integration surfaces a hazard the original assessment missed, and that is the case that hurts, because the new rating reaches everything already built against the old one. Run a change impact analysis before accepting the change.

How does ASIL relate to SIL?

They rank the same thing in two industries, and they do not convert. An ASIL comes from the severity, exposure and controllability judgement above, which is an argument about one hazardous event. SIL under IEC 61508 is set instead from quantitative target failure measures for a safety function. The inputs and the units differ, so an ASIL D element is not a SIL 3 element, and a supplier selling into both industries needs an evidence set built for each. Safety integrity levels sets out where the schemes diverge.

Is ISO 26262 or ASIL legally required?

ISO 26262 is voluntary, and it is not named in Regulation (EU) 2019/2144, the EU type-approval framework for vehicle general safety. Contracts make it effectively mandatory, since OEMs require it of suppliers and an assessment is how a supplier proves competence. Where vehicle regulation bites directly is automotive cybersecurity. There, UN Regulation No 155 ties type approval to a certified cybersecurity management system, and Jama Connect carries frameworks for both regimes.

If I want to learn more about ASIL, what else should I read?

Hazards that come from performance limits rather than faults are the subject of SOTIF and ISO 21448. For the process assessment that runs beside ISO 26262, read our guide to Automotive SPICE 4.0.

This article was authored by Mario Maldari and updated on October 9, 2026.