ASIL DECOMPOSITION EXPLAINED WITH EXAMPLES

ASIL decomposition is used when a safety goal or requirement assigned a higher integrity level is allocated to multiple sufficiently independent elements with lower decomposed ASILs. The purpose is not to reduce safety work casually. The purpose is to support a defensible architecture when independent safety mechanisms can jointly satisfy the original safety intent.

For example, a high-integrity safety goal may be implemented through a primary function and an independent monitoring path. If the independence argument is credible, the team may decompose the safety requirement across the paths. The engineering challenge is proving that common cause failures, shared assumptions, and hidden dependencies do not undermine the decomposition.

What ASIL decomposition is not

ASIL decomposition is not a shortcut for reducing process rigor. It is not a spreadsheet trick. It is not something an AI model should decide by itself. Decomposition changes the safety argument and must be documented, reviewed, and traced to architecture and verification evidence.

Independence is the central question

The practical question is whether the decomposed elements can fail independently enough for the argument to hold. Shared power, shared sensors, shared software assumptions, shared timing dependencies, common calibration data, or the same development error pattern can weaken the case. Reviewers should ask what evidence supports independence, not only whether a decomposition label appears in the table.

Example pattern

Imagine a safety goal that requires preventing unintended acceleration. One architectural concept might combine command plausibility checks in the control function with an independent monitoring function that can request a safe reaction. The decomposition argument would need to show that the monitor is sufficiently independent from the primary path, that it can detect the relevant fault class, and that the safe reaction is effective in time.

The exact ASIL values and decomposition patterns must be handled according to the applicable ISO 26262 rules and project context. What matters for tooling is that the original safety goal, decomposed requirements, independence rationale, architectural allocation, and verification evidence remain connected.

How to document decomposition decisions

Where SafeForge helps

Aegis SafeForge is designed to keep decomposition-related decisions connected to safety goals, requirements, review state, and evidence. AI can help draft rationale, but decomposition approval remains a human engineering decision supported by traceability and audit history.