ISO 26262 is the functional safety standard for road vehicle electrical and electronic systems. Its central concept is the Automotive Safety Integrity Level, or ASIL, which is the dial that sets how much safety rigor a given function requires. Everything downstream in a 26262 program — the depth of the safety analysis, the hardware metrics you must hit, the verification methods you must use, the independence of your reviewers — scales with ASIL. Get the determination wrong and you either over-engineer a benign function or under-engineer a dangerous one.
ASIL is derived, not decreed. The standard defines four levels, ASIL A through ASIL D, plus QM (Quality Management) for functions where no safety requirement applies. ASIL D is the most stringent — reserved for hazards that can kill and that the driver cannot control. QM means standard automotive quality processes are sufficient because a failure poses no safety risk. The determination is made during the Hazard Analysis and Risk Assessment (HARA), and it is a function of three parameters evaluated for each hazardous event: Severity, Exposure, and Controllability.
Severity (S0 to S3) rates the harm a hazardous event could cause. S0 is no injuries. S1 is light to moderate injuries. S2 is severe injuries, survival probable. S3 is life-threatening or fatal injuries. Severity is judged for the specific hazardous event in a specific driving situation — unintended braking on a highway is a different severity than unintended braking in a parking lot, and each operational situation is assessed on its own.
Exposure (E0 to E4) rates how often the vehicle is in the operational situation where the hazard could occur. E0 is incredible — the situation essentially never arises. E1 is very low probability. E2 is low. E3 is medium. E4 is high probability — the situation occurs during almost every drive. A hazard that only matters while towing a trailer down a mountain pass has low exposure; a hazard that matters every time the car is moving has high exposure. Exposure is about the driving situation, not about the failure rate of the component.
Controllability (C0 to C3) rates how well a typical driver can act to avoid the harm once the hazard manifests. C0 is controllable in general. C1 is simply controllable — most drivers can react. C2 is normally controllable — most drivers can act, but not all. C3 is difficult to control or uncontrollable — most drivers cannot avoid the harm. A steering function that fails gradually with warning is more controllable than one that fails instantly at speed.
The three parameters combine through the ASIL determination table in ISO 26262 Part 3 to produce the ASIL. The logic is intuitive: the highest ASIL (D) requires the worst combination — high severity, high exposure, low controllability (S3, E4, C3). As any parameter improves, the required ASIL drops. A hazard that is severe (S3) but rarely encountered (E1) and easily controllable (C1) may land at QM. The table is deterministic — given S, E, and C, the ASIL falls out. The engineering judgment lives in rating S, E, and C honestly, not in picking the ASIL.
The determination is not one HARA line per function — it is one per hazardous event in each operational situation. A single function can produce multiple hazardous events (fails high, fails low, fails intermittently), and each event can occur in multiple situations (highway, urban, parking). Each combination gets its own S, E, and C rating and its own ASIL. The function inherits the highest ASIL across all its hazardous events. This is why a HARA is not a small exercise — a modern ADAS function can generate dozens of hazardous-event-by-situation rows, each independently rated.
ASIL decomposition is the automotive analog of software segregation, and it is where the real engineering trade lives. ISO 26262 allows you to decompose a safety requirement into redundant, sufficiently independent elements that each carry a lower ASIL, provided their combination still meets the original ASIL. An ASIL D requirement can decompose into ASIL B(D) plus ASIL B(D), or ASIL D plus QM(D), and so on, following the standard's decomposition rules. The parenthetical (D) is not decoration — it records that the element was decomposed from an ASIL D requirement and must preserve the independence that justified the decomposition. Done well, decomposition lets you build a dangerous function from more affordable elements. Done carelessly, it hides a single point of failure behind two nominally independent paths that share a common cause.
The ASIL drives concrete, measurable targets. For hardware, ASIL C and D impose quantitative single-point fault metric and latent fault metric targets, plus a probabilistic metric for random hardware failures. For the development process, higher ASILs mandate specific verification methods, more rigorous reviews, and independence between the people who develop and the people who assess — at ASIL D, the safety assessment must be performed by a party independent of the development team. Lower ASILs relax these. The standard tables in Parts 4 through 6 spell out, method by method, what is recommended and what is highly recommended at each ASIL. The ASIL is the index into those tables.
The safety case is the deliverable that ties it all together, and it is structured around the ASILs. You must show a complete argument, backed by evidence, that each safety goal (derived from the top-rated hazardous events) is satisfied at its ASIL. That means tracing from safety goals to functional safety requirements to technical safety requirements to hardware and software implementation, with verification at each level performed by the methods the ASIL requires. When a requirement changes, the impact ripples through this chain, and the standard expects you to demonstrate you reassessed it. Maintaining this traceability across a program with hundreds of safety requirements at mixed ASILs is where teams relying on documents and spreadsheets lose the thread.
Common ASIL pitfalls: inflating severity or exposure "to be safe," which drives unnecessary ASIL D rigor across the program and blows the budget; rating controllability optimistically because the test drivers are experts, when the standard asks about a typical driver; treating decomposition as a paperwork exercise without genuinely verifying the independence it claims; and freezing the HARA early and never revisiting it as the design and operational scope evolve. The HARA is a living analysis — new features, new operational situations, and new failure modes all feed back into the ASIL determination.
Hitt Hosting SE's Automotive pack is built around the 26262 workflow. Hazardous events carry their Severity, Exposure, and Controllability ratings, and the ASIL is determined from them against the standard table rather than typed in by hand. Safety goals, functional and technical safety requirements, and their implementation are linked in a traceability chain that preserves the ASIL and any decomposition rationale at every level. When a requirement or a HARA rating changes, the affected safety requirements and verification activities are flagged for reassessment. The safety case artifacts — the HARA, the safety requirements at their ASILs, the verification evidence, and the independence records — generate from the live data, so the argument you present to an assessor is the same argument the data actually supports.