Picture this. You have just joined an automotive ECU program. The requirements document lands in your inbox. On page three, buried in a table of system requirements, you see: "The steering torque output function shall be developed to ASIL D."
If you are new to automotive, your first reaction might be to treat this as a label, a compliance checkbox that the safety team manages. Your second reaction, once you start digging into what ASIL D actually demands of your code, your test strategy, and your hardware choices, is usually considerably more sobering.
ASIL is not a label. It is a set of concrete engineering obligations that cascade through every decision you make, from the microcontroller you select to the way you structure your interrupt handlers to the coverage metrics your test suite must achieve. Understanding what each ASIL level actually demands, in practical engineering terms, not just standard text, is one of the most valuable things an automotive embedded engineer can learn early in their career.
This article builds on the functional safety foundations covered in our earlier post on ISO 26262 and HARA, focusing specifically on what the ASIL classification system means in practice for the teams building automotive embedded systems.
ASIL - Automotive Safety Integrity Level, is defined by ISO 26262 and is the output of the Hazard Analysis and Risk Assessment (HARA) process. Every potential hazard in the vehicle is evaluated against three parameters:
The combination of these three parameters, via the matrix shown above, produces an ASIL rating from A (lowest requirement) to D (highest), or QM (Quality Managed) where no specific safety integrity requirement applies beyond normal quality processes.
The ASIL rating then drives a cascading set of requirements for the entire development process, hardware architecture, software design, verification, validation, and documentation.
Before stepping through the ASIL levels, it is worth being precise about QM, Quality Managed. QM does not mean "no safety requirements." It means that the risk associated with a particular hazard is low enough that compliance with normal quality management processes, good engineering practice, documented design, systematic testing, is sufficient to manage it. ISO 26262 does not prescribe specific safety measures for QM items beyond what good engineering already demands.
In practice, QM functions on an automotive ECU still need to be developed carefully. They must not interfere with ASIL-rated functions on the same ECU, ISO 26262's freedom from interference requirement applies. And many OEMs impose their own minimum quality requirements on QM items that go beyond what the standard strictly requires.
A common misconception is that QM items can be developed carelessly. They cannot. The distinction is that QM items do not require the specific, measurable safety mechanisms, coverage targets, fault detection diagnostics, architectural constraints, that ASIL-rated items do.
What triggers ASIL A: Low-to-medium severity hazards with moderate exposure and limited controllability. A typical example is the power window anti-pinch function, a failure that could cause minor injury (S1), operates frequently (E4), but is easily controlled by releasing the switch (C2). The HARA produces ASIL A.
What ASIL A demands in practice:
Hardware: Basic diagnostic coverage is required but the targets are the least demanding across the ASIL spectrum. A simple end-of-range plausibility check on a sensor input, a basic watchdog, and voltage monitoring on the supply rail will typically satisfy ASIL A hardware requirements.
Software: Source code must follow a defined coding guideline, MISRA C is the standard choice. Basic structural coverage metrics apply: typically statement and branch coverage at the 80–90% level. The software must have documented requirements, a design description, and a test specification.
Process: Design reviews and test reviews are required. Traceability from requirements through design to test must be maintained. The documentation burden is measurable but manageable for a small team.
Typical ECUs at ASIL A: Power window controller, seat heater controller, interior lighting control, some body comfort functions.
What triggers ASIL B:Moderate-to-high severity hazards where the driver retains meaningful control. ACC braking commands (S2, E4, C2), HVAC blower control in some configurations, and tyre pressure monitoring warning functions typically land at ASIL B. Many camera-based ADAS functions, where the driver is expected to remain the primary safety layer, are designed to ASIL B.
What ASIL B demands in practice:
Hardware: Diagnostic coverage targets become meaningful, single-point fault metric (SPFM) ≥ 90% and latent fault metric (LFM) ≥ 60% are typical ASIL B targets. This drives the inclusion of hardware watchdogs, voltage supervisors, CRC checks on memory, and periodic self-test routines.
Software: MC/DC (Modified Condition/Decision Coverage) is required at ASIL B, a significantly more demanding coverage criterion than branch coverage. Every Boolean condition in every decision must be shown to independently affect the decision outcome. This has a direct impact on how complex conditional logic should be structured. MISRA C compliance is mandatory. Formal software unit testing with coverage measurement is required.
Process: Independence between designer and verifier is required for some activities, the engineer who writes the code should not be the sole reviewer of that code. Design and code inspections are required, not optional.
Typical ECUs at ASIL A: Power window controller, seat heater controller, interior lighting control, some body comfort functions.
What triggers ASIL C: High severity hazards with moderate controllability. Anti-lock Braking System (ABS) control, where a failure could cause loss of directional control during emergency braking (S3, E3, C2), is a classic ASIL C application. Some airbag deployment path functions also land here.
What ASIL C demands in practice:
Hardware: SPFM ≥ 97% and LFM ≥ 80%. Achieving these numbers typically requires hardware redundancy, dual sensing paths, cross-monitoring between channels, or a dedicated monitoring processor. The hardware FMEDA calculation becomes a significant engineering activity, not a formality.
Software: Full MC/DC coverage. Formal methods for critical software modules begin to appear at ASIL C, not universally required, but strongly recommended by the standard and expected by many OEMs. Static analysis tools must be used and their findings addressed. The prohibition list for software constructs expands, dynamic memory allocation, recursion, and some pointer arithmetic patterns are excluded.
Process: Software tool qualification becomes relevant at ASIL C. If a compiler, static analyser, or test tool is used in the development of ASIL C software, its own qualification status must be assessed.
Typical ECUs at ASIL C: ABS control module, some airbag firing path elements, certain powertrain control functions.
What triggers ASIL D: Life-threatening hazards with high exposure and low controllability. Unintended steering angle at highway speed (S3, E4, C3) is the canonical example, producing ASIL D. Electronic throttle control, primary brake control, and airbag deployment triggers also carry ASIL D requirements.
What ASIL D demands in practice:
Hardware: SPFM ≥ 99% and LFM ≥ 90%. PMHF (Probabilistic Metric for random Hardware Failures) must be below 10 FIT. Achieving these targets in practice almost always requires a lockstep dual-core processor, independent monitoring circuits, redundant sensor inputs on separate electrical paths, and hardware-enforced cutoff mechanisms that operate independently of software.
Software: The full weight of ISO 26262 Part 6 applies. Formal verification methods are strongly recommended. All MISRA C rules apply with no permitted deviations without formal justification. Every requirement must be traced to a test case with evidence. The independence requirements between developer and verifier are the most stringent, for the most critical functions, the verification must be performed by a team with no involvement in the original design.
Process: A functional safety assessment by an independent assessor is expected before a safety case is considered complete. Tool qualification for all development tools is required. The documentation volume for an ASIL D ECU development program is substantial, safety plans, safety cases, DIA (Dependent Failure Analysis), and a comprehensive body of verification evidence.
Typical ECUs at ASIL D: Electronic Power Steering, Active Front Steering, primary brake controller (ESC), electronic throttle control, airbag firing circuit.
A concept that is both powerful and frequently misunderstood is ASIL decomposition. When a safety goal is rated ASIL D, it does not mean every hardware component and every line of code must be independently ASIL D qualified, that would make development prohibitively expensive.
Instead, ISO 26262 permits the ASIL D requirement to be decomposed across two independent channels, each developed to ASIL B. Written as ASIL B(D), meaning ASIL B, decomposed from ASIL D, the two channels together achieve an equivalent fault tolerance to a single ASIL D channel, provided they are sufficiently independent.
Independence is the critical constraint. The two channels must have:
In practice, decomposition is what makes the lockstep dual-core MCU architecture viable for ASIL D. Each core runs an identical computation; a hardware comparator checks for divergence. One core provides the ASIL B(D) computation channel; the comparator mechanism provides the ASIL B(D) monitoring channel.
The ASIL level of a function is not just a note in the requirements document. It directly shapes how you work every day on an automotive program:
None of this makes ASIL development slow by necessity, experienced teams build efficient processes around these requirements. But it makes the requirements real, concrete, and present in every engineering decision rather than confined to a safety team's domain.
Embien's engineering teams work across the full ASIL spectrum, from ASIL A body control applications through ASIL B telematics and ADAS functions to ASIL D chassis and powertrain ECU development. Our processes are structured around ISO 26262 compliance, with traceability tooling, MISRA C enforcement, and coverage measurement integrated into our standard development workflow. We support customers from HARA and safety goal definition through to independent verification and safety case preparation.
To discuss ASIL requirements for your ECU program or to understand how ISO 26262 compliance can be built into your development process from the start, reach out to the Embien team.
Electrical/electronic architecture, also known as EE architecture, is the intricate system that manages the flow of electrical and electronic signals within a vehicle.