
核心要点
- An ASIL belongs to a safety goal, so validation planned per goal puts test depth where the risk sits.
- Decomposition reduces the effort owed by each redundant element while the combined function is still proven at the original level.
- Repeatable fault injection on a hardware-in-the-loop bench produces the timing evidence that ASIL C and D functions depend on, with no hardware at risk.
ASIL levels decide how much proof each powertrain function owes before a vehicle ships, so your validation plan should be built around them from the first requirement.
An Automotive Safety Integrity Level, or ASIL, is the risk rating that ISO 26262, the automotive functional safety standard, attaches to a safety goal. Electrification has multiplied the number of goals that carry one. Electric car sales exceeded 17 million globally in 2024, a share of more than 20% of new cars, and every one of those vehicles has an inverter, a battery management system and a charging interface that each need a rating of their own.
Teams that treat the rating as paperwork end up short of evidence late, when the fixes are most expensive. The stronger approach is to read each ASIL as a test budget. It tells you which faults you must inject, how fast the system must react and how much of that proof has to come from hardware-in-the-loop testing instead of a prototype vehicle.
What ASIL means for an electrified powertrain function
ASIL is a four-step scale, A through D, that states how much risk reduction a safety goal needs. ASIL A is the lightest duty and ASIL D the heaviest. A function with no safety impact is labelled QM, for quality management, and follows normal development practice with no extra safety measures.
The rating belongs to a hazard at vehicle level, and the hardware inherits it. Take a traction inverter. You rate the safety goal, such as preventing unintended torque, and that goal then flows down into requirements on the current sensors, the gate drivers, the microcontroller and the software that monitors torque.
One control unit will often host functions at several levels, and each one brings its own methods, metrics and test depth. If you plan validation per box, you’ll either overtest the simple functions or underprove the dangerous ones.
“Plan per safety goal and the effort lands where the risk is.”
How the four ASIL levels are assigned to a hazard
Each hazard is scored on three factors during the hazard analysis and risk assessment. Severity describes how badly people could be hurt, exposure describes how often the vehicle is in the situation, and controllability describes how easily a driver can avoid harm. The combination sets the ASIL.
Severity runs from S1 to S3, exposure from E1 to E4 and controllability from C1 to C3. Only the worst combination of all three, S3 with E4 and C3, produces ASIL D. Lower any one factor by a single class and the result drops to ASIL C, and further reductions step down toward QM. A torque surge in a parking lot and one at highway speed will score differently, because the driver’s ability to react differs.
How electrification adds new rated functions to the powertrain
An electrified powertrain carries more safety goals than a combustion one because torque, high voltage and stored energy are all under electronic control. The inverter, the battery management system and the charger each have hazards that didn’t exist before, and each hazard gets its own rating.
Unintended acceleration from the traction inverter is typically rated ASIL C or D, since a torque error acts directly on the wheels. Battery functions such as overcharge protection and thermal event prevention commonly sit at ASIL C. Charging functions tend to rate lower because the vehicle is stationary, although protection against electric shock still carries a safety goal. Treat those as typical ranges. Your own hazard analysis sets the real number.
The same function also rates differently from one vehicle to the next. A high-power dual-motor car and a low-speed delivery van won’t reach the same answer for torque faults, because severity and controllability differ.
For planning, this means the powertrain test plan is really three or more plans with different depths. The inverter torque path needs the deepest fault coverage. Battery protection needs long, repeatable abuse scenarios that you’d never run on a real pack. Charging needs interface and isolation faults.
How ASIL decomposition spreads a requirement across redundant elements
ASIL decomposition splits one safety requirement into two redundant requirements on independent elements, each carrying a lower rating. An ASIL D requirement can become ASIL C plus ASIL A, ASIL B plus ASIL B, or ASIL D plus QM. The original level stays attached in brackets, written as B(D).
A common inverter pattern shows how it works. The main torque control path is developed to one level, and a separate monitoring path with its own sensor input and its own shutdown route is developed to another. Neither path alone meets ASIL D, but the pair does, provided a single fault can’t take out both. A shared power supply, a shared clock or a shared software library will break that independence and void the decomposition.
Decomposition lowers the development effort for each element. It doesn’t lower the proof owed by the combined function. Integration testing and the hardware fault metrics are still judged against the original level, and you also owe a dependent failure analysis showing the two paths are truly separate. Your test plan now needs cases that fault one path and confirm the other still reaches the safe state in time.
What each ASIL level requires from your test coverage
Higher levels ask for stricter methods, tighter hardware metrics and more fault injection. ISO 26262 marks each test method as recommended or highly recommended per level, so moving from ASIL B to ASIL D turns optional techniques into expected ones and raises the diagnostic coverage you must show.
| Rating | What the rating expects from validation |
| QM | Normal quality processes apply and no safety-specific test evidence is required. |
| ASIL A | Requirements-based tests and statement coverage form the baseline, with no numeric target for hardware fault metrics. |
| ASIL B | Branch coverage becomes highly recommended and the single-point fault metric target is 90% or higher. |
| ASIL C | Fault injection at hardware-software integration becomes highly recommended and the single-point fault metric target rises to 97%. |
| ASIL D | Modified condition/decision coverage is expected for software units and the single-point fault metric target reaches 99%. |
| Decomposed requirement | Each element is tested to its reduced level, while integration evidence is still judged against the original level. |
“A fault you didn’t inject on the bench is a fault your customer finds for you.”
Those targets are expensive to miss. United States regulators recorded 950 vehicle safety recalls in 2024, covering more than 29 million vehicles, and a coverage gap that surfaces after launch joins that count.
Why fault injection on a HIL bench carries the evidence

Hardware-in-the-loop testing connects the real controller to a simulated motor, battery and grid, so you can inject faults that would damage or endanger a physical prototype. It’s the practical way to produce fault reaction evidence at ASIL C and D, because every case is repeatable and nothing breaks.
Consider a phase current sensor that sticks at a fixed value during full torque. On a dynamometer, that test risks the motor and the inverter. On a simulator, it’s a parameter change. You trigger the fault at an exact rotor angle, measure how long the controller takes to detect it and reach the safe state, then repeat the run across speed, temperature and bus voltage. A bench plan for a rated powertrain function will usually cover five fault families.
- Sensor faults such as offset, drift, stuck values and lost signals
- Actuator and gate driver faults, including open and shorted switches
- Communication faults such as corrupted, delayed or missing bus messages
- Supply faults such as brownout and loss of the low-voltage rail
- Plant faults such as cell overvoltage, isolation loss and a locked rotor
OPAL-RT simulators run the motor, battery and power electronics models at the small time steps that switching-level faults need, which lets the controller see realistic currents the instant a fault lands. Every safety goal has a fault-tolerant time interval, and your evidence is the measured gap between injection and safe state, logged the same way on every run.
Planning validation effort around the rating from day 1
The most reliable programs fix the ASIL of every safety goal before they size the test campaign, then let that rating set fault lists, coverage targets and bench time. Evidence gathered this way accumulates steadily, and the safety case becomes a record of work you’ve already done.
Good judgment here is mostly restraint. You don’t need ASIL D rigour on a QM function, and you can’t accept ASIL B habits on a torque path. Teams that hold that line spend less, because they check results against a number agreed months earlier. They also keep hardware intact, since the dangerous cases run against models first and reach the vehicle only as confirmation. That’s the role OPAL-RT benches play on electrified powertrain programs, running the fault and edge cases as often as the evidence requires. A rating is a promise about risk, and disciplined, repeatable testing is how you keep it.

汽车
10 / 31 / 2026
Motor emulation on a PHIL bench for traction inverter validation
How motor emulation on a power hardware in the loop bench works, what it validates on a traction inverter at power, and where its results need a physical check.

电力电子
10 / 30 / 2026
Power shelf design for high density AI racks
How a power shelf feeds a high density AI rack, which PSU topologies and efficiency targets shape it, and how GPU load steps stress its controls.

电力电子
10 / 29 / 2026
Quasi Z source inverter modeling for renewable systems
A practical look at how a quasi Z source inverter boosts and inverts in one stage, why standard models reject its boost state, and what accurate simulation and real-time testing require.