How Automotive Tier 1 Suppliers Are Managing the Transition from ICE to EV Architecture

The combustion engine took roughly 130 years to reach the level of engineering maturity it has today. Tier 1 automotive suppliers — the Boschs, Continentals, and Aptivs of the world — built empires around mastering that maturity: precision fuel injection, exhaust aftertreatment, transmission control, engine thermal management. Their toolchains, organizational structures, and institutional knowledge were shaped by that product.

Electric vehicle architecture has not given them 130 years. It has given them roughly a decade, in many cases less.

The result is one of the most acute systems engineering challenges in modern manufacturing: large, well-resourced organizations trying to retool for a fundamentally different architecture while simultaneously shipping the old one, satisfying OEM customers in both worlds, and meeting safety standards that were themselves written for technology that no longer applies cleanly.

This article examines what that challenge actually looks like in practice — not the press release version, but the engineering operations version.

What Changes When You Remove the Engine

The framing of “ICE to EV” understates the scope of the transition. Removing the internal combustion engine does not just eliminate a powertrain component. It eliminates the organizing principle around which the entire vehicle architecture was built.

In an ICE vehicle, mechanical power is primary. Electrical power is secondary — drawn from a 12V system, sized to run lights, HVAC blower motors, infotainment, and a handful of control modules. Thermal management exists to protect the engine from its own heat. Software runs embedded controllers, each with narrow responsibility and modest update cadence.

In an EV, none of that holds. High-voltage battery systems — typically 400V or 800V — become the primary energy domain. A traction inverter must convert and manage that power with switching characteristics that create electromagnetic interference profiles that simply did not exist in traditional vehicle electrical architecture. Battery thermal management becomes a first-order safety function, not a cooling efficiency problem. And software is no longer running controllers — it is the powertrain, increasingly over-the-air updatable, with functional boundaries that shift across product lifecycles.

For a Tier 1 supplier, this means that the product lines they are building — inverters, battery management systems, thermal management modules, power electronics — have requirement profiles that cut across mechanical, electrical, thermal, and software domains simultaneously. A decision in the battery chemistry domain affects the thermal system requirements, which affects the software control strategy, which affects the EMC compliance posture, which loops back to affect mechanical packaging constraints. These are not sequential handoffs. They are concurrent, interdependent constraint networks.

Where Legacy Toolchains Break Down

Most large Tier 1 suppliers have been running their systems engineering on toolchains that were assembled, not designed. IBM DOORS — in its original client form or its DOORS Next web incarnation — is present at nearly every major Tier 1. Polarion and PTC Integrity appear frequently in the software-heavy groups. These tools were designed to manage requirements as documents: structured text, attributes, coverage links, and change history organized around a folder hierarchy.

For ICE development, this was workable. Mechanical requirements were relatively stable. Electrical requirements were narrow. Software requirements were contained within module boundaries. The document model could approximate the actual system because the actual system was not especially complex in its cross-domain dependencies.

EV architecture breaks this approximation in several specific ways.

Cross-domain traceability becomes structural, not administrative. In a document-based tool, a link between a high-voltage insulation requirement and a thermal management requirement is a manually created attribute or a link object. It exists because an engineer created it. It remains correct only if that engineer — or a downstream engineer — notices when either end of the link changes and updates accordingly. In a system where battery thermal runaway prevention depends on a chain of electrical, thermal, chemical, and software requirements all remaining synchronized, manual link maintenance is not a process problem. It is an architectural one.

Requirement volatility is an order of magnitude higher. ICE powertrain requirements for a given platform were largely stable once architecture was fixed. EV requirements are not. Battery cell chemistries change between platform generations. OEM software-defined vehicle (SDV) mandates add functional requirements mid-program. Regulatory requirements for high-voltage safety (ISO 26262, IEC 61508, GB/T standards in China) are still evolving in their EV-specific interpretations. A tool that treats change as an exception — requiring manual impact analysis and re-link campaigns — creates engineering debt at a rate that compounds across a three-year program.

Software is no longer a contained subsystem. Traditional automotive software lived in ECUs with fixed interfaces. EV architecture moves toward centralized compute — zone controllers, high-performance compute platforms, and OTA update infrastructure. This means software requirements do not terminate at a module boundary. They extend into platform architecture, cybersecurity threat models, and OEM SDK integration. A requirements tool that treats software requirements as a separate silo from the system requirements creates a gap that must be bridged manually, typically through a combination of spreadsheets and program management heroics.

What Actually Happens Operationally

Inside major Tier 1 engineering organizations, the ICE-to-EV transition is producing several observable operational patterns.

Teams are proliferating tools to cover gaps. When DOORS cannot represent a thermal-electrical dependency cleanly, an engineer creates a spreadsheet. When Polarion cannot surface the impact of a cell chemistry change across twenty downstream requirements, a systems engineer runs a manual impact analysis in a PowerPoint. The official toolchain becomes a record-keeping system; the actual engineering happens outside it. Auditors see compliant documentation. Engineering teams see a different reality.

Safety case construction is becoming the critical path. ISO 26262 compliance for EV systems — particularly at ASIL C and ASIL D levels for traction control and battery management — requires a safety case that traces from hazard analysis and risk assessment (HARA) through system goals, through functional safety requirements, through technical safety requirements, into hardware and software implementation. In a document-based toolchain, assembling this safety case at the end of a program is a months-long artifact construction project. In programs where the safety case reveals gaps, those gaps surface late — which in automotive means they surface expensively.

OEM expectations are outpacing supplier toolchain capability. OEMs building SDV platforms are increasingly mandating structured requirement exchange — not Word documents, not PDF specs, but machine-readable requirement objects with semantic attributes that can be imported directly into the OEM’s own model-based systems engineering environment. Tier 1 suppliers running document-based toolchains face a translation problem: how to export structured requirement data from a system that does not natively structure it. The workaround — a dedicated team manually converting documents into exchange formats before each OEM review — is common and unsustainable.

What Leading Tier 1s Are Doing Differently

The suppliers navigating this transition most effectively share several characteristics.

They have separated the requirement model from the requirement document. Requirements are managed as objects in a graph — with attributes, relationships, and version history — and documents are generated from that model, not the other way around. This is not a new concept in systems engineering theory; it is rare in automotive supplier practice. Tools like Jama Connect and Codebeamer have made inroads here, offering better relationship modeling than flat DOORS databases while integrating with ALM toolchains that development teams are already using.

They are investing in cross-domain requirement architecture. This means explicitly modeling the interfaces between electrical, thermal, mechanical, and software domains as first-class requirements artifacts — not assumptions documented in interface control documents that no tool enforces. When a thermal requirement changes, the system surfaces which electrical and software requirements have potential impact, rather than relying on an engineer to remember to check.

Flow Engineering represents the direction this is heading for teams that want to go further. Built as an AI-native requirements management platform specifically for hardware and systems engineering, it structures requirements as a connected graph rather than a document hierarchy. For EV programs specifically, this means that a requirement touching high-voltage insulation can carry explicit relationships to the thermal management control strategy, the ASIL decomposition in the safety case, and the OEM interface specification — and when any node in that graph changes, the impact is surfaced structurally, not discovered manually. The platform’s AI layer assists with requirement quality analysis and gap detection, which is particularly valuable in the early stages of EV program architecture when teams are translating OEM functional goals into supplier technical requirements across domains they may not yet be expert in.

Flow Engineering is deliberately focused on the systems engineering and requirements layer — it is not a full ALM suite, and organizations that need deep integration with legacy DOORS databases or existing Polarion deployments will need to evaluate integration paths carefully. That focus is also its strength: it does not try to be a project management tool or a CAD integration platform, which means it does not compromise its core requirement modeling capability to serve those adjacent needs.

The Organizational Dimension

No tool discussion is complete without acknowledging that the hardest part of this transition is not the toolchain. It is the organizational structure.

Most Tier 1 suppliers evolved their engineering organizations around product lines that mapped to ICE subsystems: engine management, transmission control, exhaust systems, chassis. EV architecture does not respect those boundaries. A battery thermal management module requires mechanical packaging expertise, high-voltage electrical engineering, electrochemical knowledge, embedded control software, and functional safety architecture — simultaneously, from the same team, in the same program phase.

Organizations that have not restructured around systems engineering as a cross-functional discipline tend to replicate the problem in their toolchains: each domain manages its own requirements, links are created at program milestones rather than continuously, and integration issues surface during system integration testing rather than during architecture definition.

The leading suppliers are treating systems engineering elevation as a strategic investment, not a process improvement initiative. That means dedicated systems architects with cross-domain authority, toolchains that serve those architects rather than individual domain teams, and requirement review processes gated on cross-domain traceability, not document completion.

Honest Assessment

The Tier 1 automotive supplier community is not uniformly behind. Several large suppliers have made substantial investments in model-based systems engineering, in MBSE toolchains (Cameo, Rhapsody, Capella), and in requirements management platforms that can represent EV architecture complexity. But these are not the median case. The median case is a DOORS installation from 2009, a team that knows how to make it do what auditors expect, and a growing pile of spreadsheets doing the actual engineering work.

The suppliers that close this gap will not do it by buying better tools. They will do it by deciding that systems engineering is a technical competency worth building — and then buying tools that serve that competency rather than substituting for it.

The ICE-to-EV transition has not been kind to organizations that tried to manage it as a product extension. It will not be kind to those that try to manage it with requirements toolchains designed for a simpler architecture.

The question for any Tier 1 leadership team is not whether their current toolchain is compliant. The question is whether it can actually represent the system they are building — and whether it will surface the failures before the customer does.