What Is ASIL? A Guide to Automotive Safety Integrity Levels in ISO 26262

A modern passenger car carries more electronic control units than a commercial airliner did twenty years ago. Each new feature, from electric power steering to adaptive cruise control, runs on software that has to behave correctly under conditions the original concept never anticipated. Teams shipping those features need a way to rank which functions could hurt someone, and which can be treated as ordinary quality.

That ranking system is the Automotive Safety Integrity Level, or ASIL. ISO 26262 introduced ASIL so OEMs and Tier 1 suppliers could agree on how much process rigor a safety goal demands, from a tail light at one end to an airbag at the other. This guide covers the five classification levels, the three HARA parameters, vehicle examples, decomposition, the differences from SIL and DAL, and what audit-ready ASIL execution looks like.

What Is ASIL?

ASIL stands for Automotive Safety Integrity Level, a risk classification scheme defined inside ISO 26262, the international standard for functional safety of road vehicles. Each ASIL represents an automotive-specific, risk-based classification of a safety goal, adapted from the Safety Integrity Level model in IEC 61508. The standard was published in November 2011, refreshed in December 2018, and spans twelve parts.

The key thing up front is that an ASIL is assigned to safety goals, not to components. A safety goal is the top-level safety requirement that comes out of hazard analysis. 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 and one level below them. ASIL A is the lowest functional safety rating, ASIL D is the highest, and QM sits underneath as a fifth tier. Each level scales the rigor a team applies across requirements, design, verification, and confirmation.

QM stands for Quality Management. When a hazard analysis lands at QM, the assessed risks are tolerable and the ISO 26262 lifecycle is not triggered. ASIL A starts the safety lifecycle at minimum rigor, ASIL B and C add more independent verification and stricter coding rules, and ASIL D adds the most demanding hardware architecture metrics in the standard.

What the standard tells you to do for each level is what actually diverges:

• Notation: Informal natural-language requirements work at A and B. Semi-formal models like Stateflow or SysML are highly recommended at C and effectively required at D.
• Code coverage: Statement and branch coverage cover lower levels, and ASIL D adds Modified Condition / Decision Coverage on safety-related software.
• Hardware metrics: Single-point fault and latent fault metric thresholds tighten from B to C to D, and PMHF targets are bounded at D.
• Independence: Confirmation measures move from in-house review at A, to a separate department at C, and an independent organization at D.

Knowing what each level demands is important when a team has to assign one in the first place. ISO 26262 frames that assignment as a structured risk question that the next section unpacks.

Severity, Exposure, and Controllability (The Three HARA Parameters)

Hazard Analysis and Risk Assessment, defined in ISO 26262 Part 3, scores every hazardous event on three parameters whose scales come from the standard.

• Severity (S0 to S3): S0 means no injuries. S1 is light to moderate. S2 is severe to life-threatening with survival probable. S3 is life-threatening to fatal.
• Exposure (E0 to E4): E0 is incredibly unlikely. E1 is very low. E2 is low. E3 is medium. E4 is high and could happen under most operating conditions.
• Controllability (C0 to C3): C0 means controllable in general. C1 is simply controllable. C2 is normally controllable. C3 is difficult to control or uncontrollable.

The combination of S3, E4, and C3 yields ASIL D. Any combination that includes S0, E0, or C0 reduces the result to QM, and everything in between maps to ASIL A, B, or C.

How ASIL Is Determined Through Hazard Analysis and Risk Assessment

HARA is where the ASIL number gets fixed. The team works through the item definition, identifies hazardous events at the vehicle level, scores each on Severity, Exposure, and Controllability, and formulates safety goals that mitigate the hazards. When one safety goal covers multiple events it carries the highest ASIL among them.

The lookup is mechanical once the team agrees on S, E, and C. The ASIL falls out of a single table in ISO 26262 Part 3, with the S3 row below:

Lower severity rows shift the result down by the same logic, and any row with S0, E0, or C0 lands at QM. The output feeds the Functional Safety Concept, which allocates safety requirements into hardware and software. SAE J2980 offers additional guidance on severity, exposure, and controllability, and a disciplined risk management approach matters because these ratings drive every downstream decision.

ASIL Examples Across Real Vehicle Systems

Looking at how real systems get classified makes the framework concrete. The examples below are typical assignments, not universal rules, because ASIL on any program depends on its item definition and operational design.

• ASIL D: Airbag deployment, anti-lock braking and brake-by-wire, and electric power steering. Failure is life-threatening with limited driver controllability.
• ASIL B to C: Electronic stability control and adaptive cruise control. Most references put cruise control at ASIL C, with adaptive cruise often rating lower when supervisory features keep the driver in the loop.
• ASIL B: Headlights, brake lights, and the instrument cluster. Failure raises collision risk, but the driver typically has time to react.
• ASIL A: Tail lights for non-braking signaling and the horn. Failure can contribute to a collision, but the residual hazard is lower.
• QM: Climate control and HVAC, infotainment, and power seat adjustment. None of these directly cause injury when they fail, so Severity is S0 and the result is QM.

The misclassification that trips up newer programs is putting climate control at ASIL A. It belongs at QM, because no HVAC failure mode produces physical harm. Getting that boundary right saves hundreds of hours of unneeded rigor.

ASIL Decomposition and How It Reduces Engineering Burden

ASIL decomposition, defined in ISO 26262 Part 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. Valid pairs are tighter than they look on paper:

The constraint that anchors all of this is independence. If two elements share a microprocessor, power supply, or common-cause failure path, the decomposition does not hold and each element has to meet the parent ASIL. Two software partitions on the same ECU still have to meet ASIL D hardware metrics together, even if each looks lower on paper.

ASIL vs. SIL vs. DAL Across Industries

ASIL sits in a family of safety classification schemes that look similar from a distance and behave differently up close. Suppliers selling into more than one industry tend to confuse them, and the common mistake is assuming a mapping exists where none does.

SIL under IEC 61508 runs from SIL 1 to SIL 4 and uses quantitative target failure measures (PFDavg or PFH). DAL under DO-178C and ARP4754A runs from DAL A through DAL E and is qualitative, derived from Functional Hazard Assessment. ISO 26262 provides no normative mapping between them, so a component certified at SIL 3 cannot be claimed as ASIL D without separate evidence.

Common Pitfalls When Applying ASIL on a Program

Most ASIL problems do not come from misreading the standard. They come from applying it inconsistently across the artifact chain from HARA to verification.

• Over-classifying convenience features: Putting infotainment or climate control at ASIL A pulls in process rigor the system does not need and dilutes attention from genuinely safety-critical work.
• Decomposition without independence: Splitting a safety requirement across two software components on the same microprocessor does not satisfy ISO 26262 unless hardware-level independence is also shown. Teams that skip that argument lose the decomposition benefit at audit time.
• 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 actual system drift apart, and the gap usually closes painfully right before an assessment gate.

The connecting issue is trace integrity. When HARA outputs, safety goals, derived requirements, design elements, and verification evidence are not actively linked, ASIL ratings on paper stop matching the system as built and tested.

How Jama Connect Supports ASIL Classification and ISO 26262 Compliance

Picture an ASIL D safety goal that has to be refined mid-program because integration testing reveals a hazardous event the original HARA missed. Without a live trace chain, the safety manager cannot tell which requirements, hardware items, software components, and test cases need rework before the next assessment gate. The schedule slips and the safety case loses its line of argument.

Jama Connect® keeps that trace chain live across the ASIL artifact set. HARA outputs, safety goals, the Functional Safety Concept, technical safety requirements, hardware and software allocation, and verification evidence stay connected through Live Traceability™, so when a baselined requirement changes, every downstream item is flagged as suspect. ASIL D process rigor becomes reviewable in place during an audit instead of reconstructed before one. Jama Connect was certified by TÜV SÜD up to ASIL D under ISO 26262 and SIL 3 under IEC 61508.

Building an ASIL Program That Holds Up Across Vehicle Generations

A strong ASIL program is one where the classification work done at HARA still matches reality the day the vehicle ships and the day the next platform reuses the safety case. Teams that get there treat ASIL as the spine of the safety argument, not a rating filed away after Functional Safety Concept sign-off. The difference between holding that alignment and losing it shows up as months of rework before an assessment.

Jama Connect supports this workflow with Live Traceability across HARA results, safety goals, derived requirements, and verification evidence. To see how it holds up on your own ASIL D program, start a free 30-day trial of Jama Connect today.

Frequently Asked Questions About ASIL

Who assigns ASIL ratings on a vehicle program?

OEM safety managers and hazard analysts assign ASIL at the safety goal level through HARA under ISO 26262 Part 3. Tier 1 suppliers and ECU engineers then implement and sometimes refine ASIL assignments at the element level against the safety requirements from the OEM.

What is the difference between QM and ASIL A?

QM means standard quality management applies and the ISO 26262 lifecycle is not triggered. ASIL A means the lifecycle starts at minimum rigor, so safety planning, a safety case, a Functional Safety Concept, and ASIL-specific verification become mandatory.

Can a component’s ASIL rating change during development?

It can change in two main ways during development. ASIL decomposition under ISO 26262-9 Clause 5 can apportion safety requirements across independent redundant elements at lower ASILs, and an updated HARA can revisit S, E, and C ratings when integration reveals new hazardous events.

How does ASIL relate to SIL and DAL?

SIL under IEC 61508 uses quantitative failure-rate targets across SIL 1 to SIL 4. DAL under DO-178C and ARP4754A uses Functional Hazard Assessment across DAL A to E. ASIL uses the qualitative S, E, and C model, and ISO 26262 provides no normative mapping between them.

Is ISO 26262 or ASIL legally required?

ISO 26262 is voluntary in most jurisdictions and is not directly named in EU type-approval law. The industry treats it as the state of the art for functional safety, and most OEM contracts require it. UNECE R155 on cybersecurity is the closer type-approval mandate.

Does ASIL apply to hardware, software, or both?

ASIL applies to both. The rating is set on the safety goal and inherited by every derived requirement until it lands on hardware items, software components, and verification activities. Each side has its own evidence chain, with architecture metrics on the silicon side and structural coverage and notation rules on the software side.

This article was authored by Mario Maldari and published on May 6, 2026.