How Automotive Tier 1 Suppliers Are Rebuilding Systems Engineering Competency After Decades of OEM Dependency
Software-defined vehicles are forcing suppliers to develop the system-level engineering muscle they outsourced to OEMs for a generation.
There is a quiet crisis unfolding inside the engineering organizations of major automotive Tier 1 suppliers. It is not a quality crisis in the traditional sense — parts are still shipping, programs are still launching. The crisis is structural: the skills, processes, and tools required to do genuine systems engineering work were allowed to atrophy over two decades of dependency on OEM-driven requirements, and the industry is now demanding that suppliers reacquire them on an aggressive timeline.
The immediate trigger is well understood. Software-defined vehicle (SDV) programs — led by platforms from Mercedes, BMW, Stellantis, and the German OEM alliances — are fundamentally reshuffling engineering responsibility. Where an OEM previously handed a Tier 1 a functional specification down to the subsystem level, the new model asks suppliers to own system architecture, decompose high-level vehicle functions into component requirements, and then verify that the implementation satisfies those functions. That is a fundamentally different engineering job.
The problem is that many Tier 1s have not done that job in years. Some have never done it at all for certain product lines.
The Dependency That Built an Industry — and a Blind Spot
To understand the scale of what needs to change, it helps to understand how the dependency formed.
Through the 1990s and early 2000s, the automotive supply chain became extraordinarily efficient at a specific kind of engineering work: receiving detailed technical specifications from OEM vehicle programs, translating those specs into component designs, validating to OEM-defined criteria, and delivering on cost. Tier 1s that excelled at this model — Bosch, Continental, Aptiv, ZF, Denso, Magna — grew into global engineering organizations numbering in the tens of thousands of engineers.
The efficiency gains were real. OEMs centralized system-level thinking; suppliers concentrated on execution. Everyone optimized for their role.
What eroded in the process was the supplier’s capability to independently generate requirements from vehicle-level functions. The muscles for requirements decomposition, system hazard analysis, interface definition, and cross-functional traceability weakened from disuse. In many Tier 1 engineering teams, the competency was never absent — it was present in pockets, in senior engineers who had lived through earlier eras, or in advanced engineering groups working pre-competitive concepts. But the mainstream program execution teams operating on series production had no need for it. The OEM handled that upstream.
That arrangement is now a liability.
What OEMs Are Actually Asking For
The SDV transition is asking Tier 1s to do three things they are currently not well-equipped to do.
First, own the system architecture for their domain. An OEM sourcing a zonal controller or a domain ECU is now asking the supplier to propose and defend the functional decomposition — not just respond to one they were handed. That requires functional safety architects, systems engineers who can model behavior, and tooling that supports those activities. Many Tier 1 engineering teams have the first and not the others.
Second, generate and maintain bidirectional traceability without OEM scaffolding. Under legacy arrangements, the OEM’s requirements management system was the system of record. Suppliers maintained some form of local traceability — typically in Microsoft Word, Excel, IBM DOORS, or a combination — but the authoritative chain ran through OEM tools. Under the new model, the supplier must own that chain from vehicle function to silicon, including all the change impact analysis it implies. This is a process and toolchain problem, not just a headcount problem.
Third, demonstrate system-level ASPICE compliance. ASPICE (Automotive SPICE) has always included system-level process areas — SYS.1 through SYS.5 — but assessments historically focused on software process areas because suppliers were only doing software work. As suppliers take on system-level responsibility, OEM assessors are starting to assess SYS processes in earnest. A Tier 1 that has been assessed at ASPICE Level 2 for software processes and has never been assessed for system processes is carrying compliance exposure it may not fully understand yet.
The Organizational Response: Centers of Excellence and the Two-Track Problem
The suppliers moving fastest on this transition are not trying to simultaneously retrain their entire program execution workforce and rebuild systems engineering process. That approach is too slow and too risky to active programs.
Instead, the leading organizations are running two tracks in parallel.
The first track is a systems engineering center of excellence (CoE) — a relatively small group, typically 50 to 200 engineers, insulated from day-to-day program pressure, charged with defining the new way of working. These groups are building the reference processes, the model-based systems engineering (MBSE) frameworks, the requirements management standards, and the tool stack that the broader organization will eventually adopt. They are also staffed differently: many Tier 1s are hiring systems architects and requirements engineers from aerospace and defense, where the discipline never atrophied to the same degree.
The second track is the existing program execution organization, which continues running active series production programs on current processes while the CoE builds the future-state capability. The transition plan typically involves applying new processes to new platforms starting in the next award cycle, not retrofitting running programs.
The risk in this model is well-known internally at many organizations: the two tracks can diverge to the point where the CoE produces a theoretically correct process that the program teams cannot or will not adopt. Bridging that gap requires sustained executive sponsorship and a realistic implementation roadmap — two things that are not guaranteed.
The Toolchain Problem Is Not a Tool Selection Problem
When Tier 1 engineering leaders talk about what is slowing their transformation, they often start with tooling. The toolchain they inherited — typically a combination of DOORS or DOORS Next for requirements, separate modeling tools, Excel for traceability, and Word for specifications — was not designed for the kind of bidirectional, change-aware requirements management that system-level work demands.
But the instinct to solve this by selecting a new requirements management tool first is frequently counterproductive. The Tier 1s that have gone through large-scale DOORS-to-DOORS-Next migrations, or DOORS-to-Polarion migrations, often find that they have moved data from one document-centric environment to another without changing the underlying workflow. The tool changes; the engineering behavior does not.
The more effective pattern, emerging from several Tier 1 transformation programs currently underway, is to define the target process first — what does requirements decomposition actually look like for a zonal controller program? what is the review and approval workflow? how does a change to a vehicle-level function propagate? — and then select tooling that supports that process natively rather than requiring manual workarounds to approximate it.
This is where newer tools designed around graph-based requirements models, rather than document-based hierarchies, are gaining traction. Platforms that represent requirements, their decomposition relationships, their verification linkages, and their change history as a connected graph rather than a folder of documents make impact analysis tractable at the scale SDV programs require. Tools like Flow Engineering have been adopted by systems engineering CoEs at several Tier 1s precisely because they were built for this kind of connected traceability from the start, rather than adding it as a layer on top of a document management architecture. The difference matters when a change to a high-level OEM functional requirement needs to be traced through four levels of decomposition to affected test cases — a query a graph model handles in seconds that a document model handles through hours of manual review.
That said, toolchain selection is genuinely secondary to process definition. A supplier that adopts a modern graph-based requirements tool without first defining its requirements decomposition methodology will replicate the same unstructured practices in a faster system.
ASPICE and ISO 26262: The Compliance Pressure Quantified
The regulatory and standards pressure is accelerating the timeline in ways that pure market dynamics alone would not.
ISO 26262:2018 requires system-level hazard analysis and risk assessment (HARA) and system-level safety goals to be managed by the entity responsible for the system — which, for suppliers taking on domain-level responsibility, now means the supplier, not the OEM. A Tier 1 that cannot demonstrate an auditable chain from HARA through functional safety requirements to technical safety requirements is exposed on new platform awards and, more concretely, on liability in the event of a field incident.
ASPICE Level 2 compliance for SYS processes requires, at minimum, that the supplier can demonstrate managed requirements engineering practice — requirements are identified, documented, agreed upon, and changes are controlled. Level 3 compliance, which several large OEMs are now requiring for strategic system suppliers, requires a defined and tailored organizational process, not just a project-level practice. The distance between where most Tier 1 SYS processes are today and Level 3 is significant.
The compliance pressure is useful because it creates a hard deadline for capability development. A Tier 1 that is told by a premium OEM that it will be assessed for ASPICE SYS Level 2 on its next domain controller platform has roughly 18 to 24 months to have a demonstrable process in place. That timeline is forcing decisions that market pressure alone might allow organizations to defer.
The Cultural Dimension: Engineering Identity at Tier 1s
The organizational and toolchain challenges are real and well-documented. The cultural challenge receives less attention and is equally important.
Tier 1 suppliers built their engineering identity around execution excellence — meeting specs, hitting targets, delivering parts at cost. Systems engineering work carries different markers of success: early investment in architecture, explicit documentation of assumptions, process rigor in requirements management, willingness to push back on upstream requirements that are incomplete or conflicting. These behaviors look like friction inside a culture optimized for throughput.
Senior engineers at several major Tier 1s have described the internal resistance in consistent terms: program managers see requirements management processes as overhead that delays design starts. Engineers who have been successful for twenty years executing against OEM-provided specs do not see why they need to change their approach. The new systems engineering teams are sometimes perceived as a compliance function rather than an engineering function.
This is a leadership problem before it is a process problem. The Tier 1s making the most visible progress — and the pattern is consistent across Bosch’s software-defined vehicle division, Continental’s cross-domain computing organization, and Aptiv’s advanced electrical architecture group — share one characteristic: a senior technical executive who can credibly argue that systems engineering competency is a competitive advantage on platform awards, not just a compliance cost. Without that framing at the executive level, transformation programs stall at the process definition stage.
What the Supply Chain Looks Like in 2035
The trajectory over the next decade is unlikely to be uniform across the Tier 1 landscape. The engineering and investment required to become a genuine system-level supplier is substantial. Not every Tier 1 will make that transition successfully, and not every Tier 1 needs to.
The supply chain will stratify. A smaller number of Tier 1s — likely the large global players plus several specialized competitors — will complete the systems engineering transformation and compete for domain-level platform responsibility at SDV OEMs. A larger number will continue to execute at the component level, supplying to the Tier 1 systems integrators rather than directly to OEM platforms. That is a viable business model, but it implies accepting margin pressure and reduced strategic relevance on new vehicle architectures.
The determining factor for which tier a Tier 1 ends up in will not be headcount or heritage. It will be how early and how seriously leadership treats systems engineering as a core competency investment — and whether their process and toolchain investments support the kind of bidirectional, change-aware requirements management that system-level responsibility actually requires.
The suppliers that treat this as a compliance checkbox will spend a decade doing ASPICE assessments without building genuine capability. The ones that treat it as an engineering transformation will emerge with the skills and processes to win the next generation of platform awards.
The difference between those two outcomes is already visible in how Tier 1s are structuring their 2026 and 2027 engineering investments. The patterns are not yet locked in. But the window to set the right trajectory is narrowing faster than most organizations currently appreciate.