ASIL - Automotive Safety Integrity Level

ASIL as a Driver of Effort and Evidence Depth

In project discussions, ASIL is often treated as a simple classification question: this function is ASIL B, that one is ASIL D. Behind the classification, however, are concrete consequences for effort, methods, reviews, and depth of evidence - and therefore for schedules, budgets, and the later argumentation in the safety case.

ASIL stands for Automotive Safety Integrity Level. In ISO 26262, ASIL is not a decorative label for a system, but a risk classification and control concept. It indicates how strictly and thoroughly functional safety measures must be implemented, verified, and evidenced in order to avoid unreasonable safety risk.

ASIL describes the required safety integrity level of a safety goal. The higher the ASIL, the more depth, rigor, independence, and evidence scope are expected for the safety-relevant development activities.

This practical consequence makes ASIL highly relevant for project planning and architecture decisions. A classification influences, among other things:

• which reviews must be performed independently,
• which analyses are necessary,
• how much traceability is expected,
• how tool confidence is evaluated,
• how robustly verification must be documented.

What ASIL Means: QM to ASIL D

The HARA can lead to QM or to ASIL A, B, C, or D. QM means that no further functional safety activities according to ISO 26262 need to be continued for the safety goal under consideration; classic quality measures remain relevant. ASIL A is the lowest ASIL level, ASIL D the highest.

A rough practical picture helps with orientation:

• QM: standard quality development without continued functional safety activities for this safety goal,
• ASIL A/B: focused additional effort, often perceived as a lean safety path,
• ASIL C: significantly increased systematics, stricter reviews, and more formal evidence,
• ASIL D: maximum rigor, comprehensive assurance, high independence, and especially robust evidence.

ASIL says nothing about performance, comfort, or general product quality. An ASIL D safety goal does not mean that a system inherently carries a higher residual risk than another system. It means that a specific risk must be controlled with particularly high methodological rigor.

ASIL is Created in the HARA

ASIL is determined as part of the HARA. The evaluation concerns a concrete hazardous event: a hazard in a defined operating situation, caused by malfunctioning behavior of the item. Internal safety mechanisms of the item are not considered at this point.

The classification is derived from severity, exposure, and controllability. This is not a mathematical calculation, but a classification based on normative categories and an ASIL matrix. The result is then assigned to the safety goal.

Severity, Exposure, and Controllability

The three parameters describe different dimensions of risk. In structured HARA workshops, they are evaluated independently of each other and each is documented with a rationale.

Severity

Severity describes the severity of possible injuries if the hazardous event occurs.

Class	Meaning
S0	No injuries, typically property damage only
S1	Light to moderate injuries
S2	Severe, life-threatening injuries; survival likely
S3	Life-threatening or fatal injuries; survival uncertain

Exposure

Exposure describes the frequency of the operating situation or scenario. It explicitly does not refer to the frequency of an internal fault.

Class	Meaning
E0	No or incredible occurrence
E1	Very rare
E2	Rare
E3	Occasional
E4	Frequent

Controllability

Controllability describes how well an average driver or road user can control the hazardous situation without assuming technical countermeasures of the item.

Class	Meaning
C0	Generally controllable
C1	Simply controllable
C2	Normally controllable
C3	Difficult or impossible to control

A simple example: S3, E2, and C3 lead to ASIL B according to the matrix used. S3, E4, and C3 lead to ASIL D. Boundary cases in particular should not only be decided in the workshop, but justified in a traceable way.

ASIL Matrix: Combination of S, E, and C

The ASIL matrix translates severity, exposure, and controllability into the final ASIL of a safety goal. The following representation shows the classification logic defined in the strategy for S1 to S3, C1 to C3, and E1 to E4. In practice, S0, E0, and C0 do not lead to an ASIL path for functional safety.

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

The matrix makes clear why small shifts in evaluation can have major consequences. A different controllability or exposure value can turn QM into an ASIL path, or ASIL B into ASIL C. That is why the rationale behind the parameters is at least as important as the final result.

Normative Rules That Often Matter in Projects

Some normative ground rules determine in practice whether an ASIL classification holds up later or is challenged in review.

First, the evaluation is conservative. In justified doubt, the higher class is selected. This prevents risks from being argued down in the workshop only because a lower ASIL would create less effort later.

Second, safety mechanisms of the item are not considered in the HARA. An existing diagnostic, redundancy, or shutdown strategy can later be a measure in the safety concept, but it does not reduce the original HARA classification.

Third, the ASIL is assigned to the safety goal, not to the item as a whole. One item can have several safety goals with different ASIL classifications. If safety goals are combined, the highest ASIL applies to the combined consideration.

Fourth, the ASIL is carried forward along requirements derivation. From the safety goal, it is broken down to functional safety requirements (FSR), technical safety requirements (TSR) in the technical safety concept, and further to hardware and software requirements. This traceability must be comprehensible throughout the entire development.

What ASIL Triggers in Practice

In practice, ASIL is a control parameter for the development process. The higher the ASIL, the higher the development, verification, and evidence effort.

Effort increases, among other things, in these areas:

• verification evidence and test depth,
• diagnostic requirements and fault tolerant time intervals,
• hardware metrics and hardware safety analyses,
• software requirements and methodological rigor,
• traceability between safety goals, requirements, architecture, implementation, and tests,
• safety mechanisms and evidence of their effectiveness,
• architecture decisions, interfaces, and HW/SW integration,
• independence of reviews, confirmation measures, and assessments,
• tool confidence and, where needed, tool qualification,
• depth and structure of the safety case.

This does not mean that every ASIL D project automatically needs more documentation as an end in itself. It means that decisions, requirements, analyses, and evidence must withstand a higher methodological rigor. For engineering leads, ASIL is therefore also a planning parameter. It influences:

• required competencies,
• review roles,
• toolchains,
• supplier management,
• schedule and evidence risks.

ASIL is Not a Component Label

A common misunderstanding is: “This ECU is ASIL D.” As rough everyday language, this may occur, but technically it is imprecise. ASIL initially belongs to the safety goal and is then carried forward to requirements and allocated elements.

This distinction is relevant to the project. If an ECU contains multiple functions, different safety goals can trigger different ASIL requirements. Some requirements are safety-relevant, others are not. Some requirements carry ASIL D, others ASIL B, and still others QM. Without clean allocation, it becomes unclear which evidence is required for which function.

That is why ASIL traceability is a core topic. It shows which safety goal drives which FSR, TSR, hardware requirement, software requirement, architecture decision, test cases, and evidence. Without this chain, the safety case becomes weak, even if individual documents look formally complete.

ASIL Decomposition: Splitting Through Architecture

ASIL decomposition is a normatively permitted means of splitting a high ASIL safety goal value across several independent safety measures with a lower ASIL. The goal is not to weaken safety. The goal is to achieve the same or better functional safety architecturally through redundancy and independence.

A safety goal with a high ASIL, for example ASIL D, can under suitable conditions be addressed by two or more mutually independent measures whose combined effect controls the original risk. Independence and effectiveness are decisive. In practice, this concerns freedom from interference and common cause avoidance.

Robust practice examples include:

• separate sensor principles,
• separate computing instances,
• temporally or logically separated software paths,
• independent diagnostics,
• clear interfaces and documented assumptions about mutual influence.

ASIL decomposition is therefore not a trick to get rid of effort. It is an architecture concept for risk control. It must be justified, traceable, and later technically evidenced. That is exactly why concrete decomposition typically belongs at architecture and mechanism level, meaning in the technical safety concept, not in a vague anticipation during the HARA.

Rule of thumb: ASIL decomposition is allowed when independent safety mechanisms jointly control the original risk.

Common Misunderstandings

Four misunderstandings appear especially often in ASIL discussions.

The first misunderstanding: ASIL D is not a statement about the danger level of a system. ASIL describes how rigorously a safety-relevant risk must be controlled, not how dangerous a system is as a whole. A system with several well-controlled ASIL D safety goals can be more mature than a system with unclear ASIL B requirements.

The second misunderstanding: ASIL is not inherited blindly. ASIL is carried forward from safety goals to requirements and allocated system elements, but this propagation requires clear traceability and technical allocation. Not every component near an ASIL D function automatically becomes fully ASIL D.

The third misunderstanding: a QM classification does not reduce the technical responsibility for a traceable evaluation. QM means that from an ISO 26262 perspective, no functional safety activities are continued for this safety goal. Quality processes, product requirements, robustness, and classic verification remain relevant.

The fourth misunderstanding: a lower ASIL is not a project objective. A project should classify risks correctly, not optimize ratings. Anyone who keeps ASIL artificially low shifts effort into later discussions, audits, or corrective work.

How Teams Reach Robust ASIL Decisions

Robust ASIL classifications do not arise from reading tables alone. They require a clear item definition, well-described hazardous events, technically suitable operating situations, and moderated evaluation of S, E, and C.

Structured workshops document not only the result, but also the rationale. Why is exposure E3 and not E4? Why is controllability C2 and not C3? Which assumptions were made? Which scenarios were intentionally combined or separated? Such decisions are valuable later when requirements are derived, suppliers are involved, or assessments are prepared.

ASIL influences the development path early. Clean classification creates planning certainty. Weak classification creates false certainty and can become more expensive later than a conservative, well-justified safety path.

Conclusion

ASIL is the link between risk and development rigor. It is created in the HARA from the classification of a hazardous event through severity, exposure, and controllability and is assigned to the safety goal.

In practice, ASIL controls effort, methodological rigor, verification, independence, tool consideration, traceability, and safety case. It is not a component label and not a statement about general system quality, but a safety integrity level for a concrete safety goal.

Anyone who determines ASIL cleanly and carries it forward consistently creates a robust basis for functional safety requirements, technical architecture, safety mechanisms, and releases. Anyone who treats it vaguely loses clarity exactly where ISO 26262 requires traceability.

In project reality, ASIL classification determines effort, responsibilities, and argumentation lines early. The more cleanly evaluation, rationale, and propagation are documented, the more robustly safety goals, architecture, and evidence hold up - and the stronger the safety case appears in an audit or assessment.