What ASIL Actually Means
Think of ASIL as a “difficulty setting” for safety work. A video game might have Easy/Normal/Hard/Extreme modes—ASIL uses QM/A/B/C/D. Each level prescribes increasingly strict requirements for:
- Development process rigor (reviews, independence, formal methods)
- Verification depth (test coverage, fault injection, architectural analysis)
- Documentation completeness (traceability, rationale, safety case evidence)
- Hardware safety metrics (fault tolerance, diagnostic coverage, random failure rates)
Higher ASIL means more effort, more time, more cost—but also more confidence that your system won’t kill anyone.
A common misconception: ASIL is derived from hazards, not assigned to components arbitrarily. You don’t “make” something ASIL D—you discover through HARA that a hazard has ASIL D severity, then allocate that requirement to the safety goals and their implementing components.
The Five ASIL Levels
| Level | Meaning | Safety Requirement | Typical Scenarios |
|---|
| QM | Quality Management | No specific ASIL requirements—standard automotive QM processes sufficient | Infotainment volume control failure, interior mood lighting glitch |
| ASIL A | Lowest functional safety | Basic hazard analysis, standard V-Model verification | Rear wiper intermittent failure (limited visibility impact) |
| ASIL B | Moderate functional safety | Enhanced verification, architectural analysis, increased independence | Electric window anti-pinch failure, headlight aim degradation |
| ASIL C | High functional safety | Mandatory independent assessment, hardware safety analysis, extensive testing | Electronic stability control (ESC) degradation, adaptive cruise control failure |
| ASIL D | Maximum functional safety | Proven-in-use components, formal methods, exhaustive testing, safety manager gates | Unintended acceleration, brake-by-wire total failure, AEB failure to detect pedestrian |
How ASIL is Determined: The Three-Dimensional Risk Matrix
ISO 26262-3:2018 defines ASIL as the output of a three-input risk assessment:
ASIL = f(Severity, Exposure, Controllability)
Severity (S0–S3): Injury Outcome
| Class | Description | Examples |
|---|
| S0 | No injuries | Cosmetic damage, minor inconvenience |
| S1 | Light to moderate injuries | Whiplash, minor lacerations, bruising |
| S2 | Severe injuries (survival probable) | Broken bones, severe cuts requiring surgery, concussion |
| S3 | Life-threatening or fatal injuries | Head trauma, internal bleeding, spinal injury, death |
Exposure (E0–E4): Operational Situation Probability
| Class | Probability Range | Examples |
|---|
| E0 | Incredible (practically impossible) | Simultaneous GPS failure + map database corruption + manual override disabled |
| E1 | Very low (<1% of operating time) | Driving on ice in desert climate, extreme fog in arid region |
| E2 | Low (1–10% of operating time) | Heavy rain, nighttime highway driving |
| E3 | Medium (10–50% of operating time) | Urban traffic, parking maneuvers |
| E4 | High (>50% of operating time) | Normal cruising, stop-and-go commuting |
Controllability (C0–C3): Driver’s Ability to Avoid Harm
| Class | Avoidance Probability | Examples |
|---|
| C0 | >99% of drivers can avoid harm | Minor torque fluctuation with 5+ seconds to react, gentle steering pull |
| C1 | >90% of drivers can avoid harm | Slight brake pedal feel change, gradual power reduction with warning |
| C2 | >60% of drivers can avoid harm | Moderate steering torque spike, delayed throttle response requiring evasive maneuver |
| C3 | <90% of drivers can avoid harm | Sudden brake failure at highway speed, unintended acceleration in traffic, total steering lock |
C-rating must account for driver awareness time, required action complexity, and environmental conditions. Emergency braking on dry pavement (C1) becomes C3 on black ice. Always assess the worst-case realistic scenario.
The ISO 26262 ASIL Determination Matrix
ISO 26262-3:2018 Table 4 defines the normative ASIL lookup. Here’s the complete matrix:
Severity S1 (Light/Moderate Injuries)
| E1 | E2 | E3 | E4 |
|---|
| C1 | QM | QM | QM | A |
| C2 | QM | QM | A | B |
| C3 | QM | A | A | B |
| E1 | E2 | E3 | E4 |
|---|
| C1 | QM | A | A | B |
| C2 | A | B | B | C |
| C3 | A | B | C | C |
| E1 | E2 | E3 | E4 |
|---|
| C1 | A | B | B | C |
| C2 | B | C | C | D |
| C3 | B | C | D | D |
- Any combination with S0 (no injuries) → QM
- Any combination with E0 (incredible exposure) → QM
- Any combination with C0 (>99% avoidance) → QM
This matrix is hardcoded in TestAuto2’s HARA Risksheet as an automatic formula—you select S/E/C dropdowns, the ASIL cell updates instantly.
ASIL Lifecycle: From Hazard to Hardware
ASIL flows downstream through the V-Model via inheritance and decomposition:
Key principle: You can never lower ASIL without approved decomposition. If a hazard is ASIL D, derived safety goals start at ASIL D. You may decompose D → C+B or D → B+B+B using architectural redundancy, but arbitrary downgrading violates ISO 26262.
In TestAuto2, ASIL inheritance is automatic: Safety Goal work items use the inheritASIL formula to pull ASIL from their parent hazard via derivedFrom link role.
ASIL Decomposition (Advanced)
ISO 26262-9 allows ASIL decomposition—splitting a high-ASIL requirement into multiple lower-ASIL components with architectural independence:
- ASIL D → ASIL C + ASIL B (two independent implementations, dual-redundancy)
- ASIL D → ASIL B + ASIL B + ASIL B (three-way voting, triple-modular redundancy)
Requirements for valid decomposition:
- Architectural independence (no common-cause failures between decomposed elements)
- Freedom from interference (one element’s failure cannot cascade to others)
- Sufficient redundancy (voting/monitoring detects failures before harm occurs)
While decomposition reduces per-component development cost (ASIL B verification is cheaper than ASIL D), it increases system complexity—you now have 2-3 components to integrate, verify for independence, and analyze for common-cause failures. Only decompose when architectural redundancy is already justified.
Color-Coded Visual System
TestAuto2 applies progressive color-coding to ASIL values for instant visual risk assessment:
- QM: Gray (#808080) — No safety requirement
- ASIL A: Green (#58FF59) — Lowest functional safety
- ASIL B: Orange (#FFA500) — Moderate functional safety
- ASIL C: Light Red (#FF6347) — High functional safety
- ASIL D: Dark Red/Purple (#8B0000) — Maximum functional safety
This color scheme appears in:
- HARA Risksheet cells (ASIL column and row headers)
- Dashboard summary cards (ASIL distribution statistics)
- Reports (ISO 26262 HARA Report, Safety Readiness Scorecard)
- Traceability matrices (safety goal → requirement allocation views)
The gradient follows automotive industry convention: green = acceptable risk, red/purple = critical risk requiring maximum rigor.
Common Misconceptions
”We can assign ASIL based on component cost”
False. ASIL is derived from hazard analysis, not component value. A 2sensorcanbeASILDifitsfailurecausesalife−threateninghazard(e.g.,brakepressuresensor).Conversely,a500 infotainment module is QM if its failure only affects entertainment.
”ASIL D means zero defects”
False. ASIL D prescribes process rigor, not perfection. It requires probabilistic hardware safety metrics (e.g., <10 FIT random failure rate for single-point faults), extensive verification (e.g., MC/DC code coverage), and architectural constraints (e.g., dual-redundancy). Defects can still occur—ASIL D ensures they’re rare and detectable.
”All automotive components are ASIL-rated”
False. Only safety-related components (those whose failure contributes to hazards with S1+ severity) receive ASIL ratings. Door lock motors, seat heaters, USB charging ports—typically QM or not safety-rated at all.
”ASIL A is easy, so we can skip verification”
False. ASIL A still requires ISO 26262 compliance—hazard analysis, architectural design per Part 4, verification per Part 8. It’s less rigorous than ASIL D (e.g., no mandatory independence, reduced test coverage), but it’s not a free pass.
Practical Application in TestAuto2
To work with ASIL in TestAuto2:
- During HARA: Open the HAZID Risksheet, assess S/E/C for each hazard—ASIL calculates automatically per ISO 26262 matrix
- Derive Safety Goals: Link Safety Goal work items to hazards via
derivedFrom—ASIL inherits automatically
- Allocate to Requirements: Refine safety goals into functional safety requirements, preserving or decomposing ASIL
- Track with Dashboards: Home Dashboard shows ASIL distribution (percentage of hazards at each level)
- Generate Reports: ISO 26262 HARA Report includes ASIL matrix, color-coded hazard register, and distribution summary
For step-by-step instructions:
Reference Materials
