The Quiet Revolution in Automotive Functional Safety: How OEMs Are Moving ASIL Decomposition Earlier
For most of the past decade, ASIL decomposition in automotive programs followed a predictable, uncomfortable rhythm: vehicle concept work happened in PowerPoint and Word, safety goals were captured in standalone FMEA spreadsheets, and ASIL ratings trickled down to suppliers months after sourcing decisions were already locked. The supplier learned their safety obligation at kickoff. Everyone scrambled.
That rhythm is changing. A cohort of leading OEMs — primarily in Europe and increasingly in North America — is moving the center of gravity of ASIL decomposition to the vehicle concept phase, treating safety goals and their decomposed ASIL ratings as first-class architectural inputs rather than downstream compliance documentation. The change is quiet because it does not require a new standard. ISO 26262 always permitted this. What changed is the organizational will, tooling maturity, and the competitive pressure of complex vehicle architectures that make late ASIL decomposition genuinely dangerous.
This article analyzes what the shift looks like in practice, what it means for system-level requirements quality, how it is reordering the OEM–Tier 1 relationship, and where the practice still fails — often badly — due to gaps in tooling and process.
What Early ASIL Decomposition Actually Means
ASIL decomposition, as defined in ISO 26262-9, is the process of splitting a safety goal’s ASIL requirement across two or more independent elements. An ASIL D requirement can be decomposed into ASIL B + ASIL B (with independence criteria met), reducing the burden on any single element. The standard has always been agnostic about when in the development lifecycle this happens.
In practice, decomposition has traditionally been deferred to the system design phase, once hardware architectures and supplier boundaries were known. The reasoning was pragmatic: you cannot decompose until you know what you are decomposing into. But that reasoning contains a hidden assumption — that the architecture is determined independently of safety obligations. For commodity vehicle systems, that was defensible. For zonal E/E architectures, domain controllers, ADAS stacks, and software-defined vehicle platforms, it is not. The architecture is the safety argument.
Early ASIL decomposition inverts this. Instead of asking “how do we satisfy these safety goals with this architecture?”, OEM safety and systems engineers ask “what architecture options allow us to satisfy these safety goals with acceptable decomposition?” The safety goals, expressed as Functional Safety Requirements (FSRs) with ASIL ratings attached, become inputs to architecture selection — not outputs of it.
Concretely, this means safety goals are being captured in requirements management tools at the vehicle concept phase with ASIL ratings, independence assumptions, and allocation hypotheses stated explicitly. The hazard analysis and risk assessment (HARA) is treated as a living artifact that feeds requirements, not a document produced for compliance review.
What This Does to System-Level Requirements Quality
The quality improvement from upstream ASIL decomposition is not subtle. It addresses several specific failure modes that practitioners in the field will recognize immediately.
Ambiguous allocation. When ASIL decomposition happens late, the allocation of safety obligations to subsystems is often implicit. A supplier receives a system-level requirement that says something like “the braking system shall achieve ASIL D.” Whether that means the supplier’s component is solely responsible for ASIL D, or whether the OEM is providing an independent monitoring channel, is often underdocumented. Disputes arise during assessment. When decomposition is captured upstream and structured into the requirements themselves — “Element A: ASIL B, Element B: ASIL B, independence criterion: no shared power supply, no shared software” — the allocation becomes unambiguous before anyone quotes the program.
Missing rationale. Late decomposition is often performed by safety engineers working at a remove from the vehicle-level use case. The rationale for why a particular decomposition strategy was chosen — rather than a different architecture that might have avoided decomposition entirely — is frequently absent or buried in meeting notes. Upstream decomposition, embedded in systems engineering tools alongside the originating hazards and safety goals, retains that rationale in a traceable form.
Untestable requirements at the FSR level. Safety goals stated vaguely (“the system shall not cause unintended acceleration”) decompose into FSRs that are equally vague unless there is deliberate effort to make them measurable at the point of decomposition. OEMs doing early ASIL decomposition report that the discipline of stating FSRs in a structured requirements tool — where completeness and testability are reviewed before the HARA is baselined — forces specificity that would otherwise emerge only during supplier assessment, if at all.
How the OEM–Tier 1 Relationship Is Changing
This shift is not just a process improvement internal to the OEM. It is restructuring the commercial and technical relationship with Tier 1 suppliers in ways that will be felt for years.
Safety intent is becoming a sourcing constraint. OEMs doing early ASIL decomposition can now enter RFQ processes with structured safety packages — formal Safety Work Products aligned to ISO 26262 Part 3 and Part 4, with ASIL ratings, decomposition rationale, and independence assumptions stated. Tier 1s are being evaluated on their ability to receive and respond to these packages. A supplier whose development process requires them to derive their own ASIL ratings from scratch, because they cannot ingest structured safety goals from the OEM, is a liability. That is beginning to appear in sourcing criteria, not just assessment checklists.
The DIA negotiation is front-loaded. The Development Interface Agreement (DIA) — the document that formally partitions safety activities between OEM and supplier — has historically been negotiated post-award, sometimes awkwardly. When ASIL decomposition is captured upstream and the OEM has already made explicit what they are providing (e.g., an independent monitoring path) and what the supplier must provide (e.g., ASIL B main function), the DIA becomes much more tractable. The negotiation moves from “what do we each owe?” to “do we agree this structure is correct?” That is a faster, cheaper conversation.
Tier 1s with weak requirements capability are being exposed. The supply base is not uniformly capable of receiving and acting on structured safety requirements. Some Tier 1s operate engineering teams that are comfortable with ASIL compliance as a documentation exercise but are not structured to receive machine-readable, ASIL-annotated requirements and propagate them into their own development systems. As OEMs increasingly deliver requirements in structured formats — rather than Word documents and PDFs — the gap between capable and less capable suppliers becomes visible in program execution, not just audit results. OEMs in the vanguard of this shift report early evidence that Tier 1 requirements compliance quality correlates strongly with the supplier’s ability to ingest structured requirement inputs.
Where the Practice Still Breaks Down
The trend is real and directionally sound. The execution is uneven, and the failure modes are specific.
Tool incompatibility at organizational boundaries. The single most common breakdown point is the requirement handoff between OEM and Tier 1. An OEM may capture ASIL-annotated FSRs in a requirements management tool with full traceability to the originating HARA. When that information must cross the organizational boundary to a Tier 1, it is frequently exported as a PDF or Excel file, losing the structural relationships, ASIL metadata, and traceability links in the process. The Tier 1 re-enters requirements manually into their own tool. Traceability is broken. The discipline of early ASIL decomposition is largely wasted at the point where it matters most.
This is not a minor operational inconvenience. When an ASIL B + ASIL B decomposition depends on independence criteria that must be verified across OEM and supplier scope, and neither organization has a shared model of what those criteria mean in requirements form, the independence argument exists only in documents that both parties interpret differently. Assessment bodies are beginning to flag this.
HARA as a static artifact. Early ASIL decomposition requires the HARA to be a living document that updates as architectural assumptions change. In practice, most HARA processes are still built around producing a document for a milestone gate, not maintaining a model that feeds downstream requirements continuously. When architecture changes after the HARA is baselined — which is nearly always — the ASIL decomposition may no longer reflect the current architecture, and there is no automated mechanism to surface the inconsistency.
Organizational misalignment inside OEMs. Upstream ASIL decomposition requires safety engineering and systems architecture teams to work in close integration at the concept phase. At many OEMs, these are separate organizations with separate tools, separate milestone schedules, and separate reporting chains. Safety engineers may complete a HARA while systems architects are still exploring architecture options. The outputs do not connect. The promise of early decomposition depends on organizational integration that program structures often do not support.
Decomposition without architecture commitment. Some OEMs are capturing ASIL decomposition at the concept phase with allocation hypotheses that are not yet committed architecture. The decomposition says “Element A: ASIL B, Element B: ASIL B” before it is certain that elements A and B will be independent subsystems rather than integrated into a single domain controller. When architecture consolidates later, the decomposition strategy may be invalid, and the rework cost to update downstream requirements is high.
The Tooling Infrastructure Requirement
Making upstream ASIL decomposition work at scale requires tooling that most legacy requirements management platforms were not designed to provide.
The core need is a requirements model where ASIL ratings, decomposition rationale, independence criteria, and traceability to originating hazards exist as structured, queryable attributes — not text fields — and where changes to upstream safety goals automatically surface impacts on downstream allocations. Document-based tools like traditional IBM DOORS or Jama Connect in document-centric configurations can store this information, but they do not model the relationships in ways that make impact propagation automatic or cross-organizational sharing structurally reliable.
Graph-based requirements models are better suited to this problem because ASIL decomposition is inherently a graph problem: safety goals decompose into FSRs, FSRs allocate to architectural elements, architectural elements carry independence constraints that link back to the hazards that originated the decomposition. When those relationships are modeled as a graph rather than a document hierarchy, the impact of an architectural change on ASIL decomposition can be computed, not manually traced.
Flow Engineering, built explicitly for complex systems engineering programs, implements requirements and their attributes as a graph model with structured traceability linking requirements to their originating hazards and downstream allocations. For OEM teams managing ASIL decomposition upstream, this means changes to safety goals propagate visibly to the FSRs that depend on them, and AI-assisted analysis can identify decomposition gaps or independence assumption conflicts before they survive into supplier packages. It is the kind of infrastructure that makes the discipline of upstream ASIL decomposition sustainable beyond the initial program that adopted it.
Honest Assessment
The move toward upstream ASIL decomposition is sound engineering practice. ISO 26262 was always intended to be a systems engineering standard, not a documentation compliance exercise, and anchoring safety goals with ASIL ratings at the concept phase is closer to the spirit of the standard than most industry practice has been.
The benefits are real: better requirements quality, cleaner DIA negotiations, earlier exposure of supplier capability gaps, and architecture decisions that incorporate safety obligation as a genuine constraint rather than a post-hoc compliance burden.
The risks are also real. Done poorly — with ASIL ratings assigned at the concept phase but not maintained as the architecture evolves, or with decomposition captured in OEM tools but unable to cross the supplier boundary intact — early ASIL decomposition creates false confidence. A HARA that is baselined and frozen while architecture continues to evolve is worse than a late HARA, because it implies a safety argument that does not reflect the actual system.
The OEMs that are executing this well share two characteristics: organizational integration between safety engineering and systems architecture that begins at program kickoff, and tooling that models requirements relationships as structured data rather than documents. The OEMs that are struggling are attempting upstream ASIL decomposition with legacy document workflows and finding that the discipline demands more from their tools than the tools can provide.
The industry is moving in the right direction. The gap between intent and execution remains significant, and it will be closed by process discipline, organizational change, and tooling infrastructure in roughly equal measure. The programs that close it first will have a structural advantage in delivering complex vehicle architectures with defensible safety arguments — and that advantage compounds over the program lifecycle.