From black box to ecosystem: Engineering the unbundled vehicle

Unbundling redistributes responsibility

The structure is giving way to more varied models. An OEM may define the electrical/electronic architecture, select a system-on-chip (SoC), own portions of the software stack, source other software from specialists, and engage another partner to engineer or manufacture the physical compute platform. BCG expects the traditional tiered supply chain to evolve into an open ecosystem, with relationships varying by domain and automaker. Its research highlights pressure from multiple directions as OEMs expand further into the technology stack, Tier-2 suppliers move up, and semiconductor and software companies take on larger roles in vehicle technology platforms.

The degree of separation will not be uniform. In advanced ADAS and autonomous driving systems, for example, McKinsey notes that the computational demands, latency, bandwidth, and safety requirements of emerging AI architectures can favor tight hardware-software co-design. At the same time, its 2026 research points to a longer-term movement toward greater modularity, including independent software layers capable of operating across multiple SoCs. The question is not simply how to decouple hardware and software. It is where separation creates useful flexibility, where tighter integration creates technical advantage, and who owns the work between the two.

More choices create an execution gap

An OEM can choose its compute architecture, semiconductor platform, software stack, hardware design, and technology partners independently, but those choices still have to become a qualified automotive product. Designs must satisfy electrical, thermal, mechanical, functional safety, reliability, and production requirements. Components need to be sourced over long program lifecycles. Production processes and test strategies have to be developed and validated. Design changes need to be incorporated without losing control of configurations already in production.

The challenge grows when responsibility is distributed among several organizations. A semiconductor change can affect hardware design, software, test coverage, sourcing, or manufacturing. A hard-to-find component may require an alternate part and additional validation. A software release can expose an issue that must be traced across hardware, firmware, and production data. Even when technologies are compatible, someone still has to turn the OEM’s architecture and technology provider’s intellectual property (IP) into a product, manage changes, industrialize the design, establish the supply chain, validate production processes, and ramp production.

Develop the product and production model together

A distributed ecosystem makes it more important to bring production considerations into development early. Design for manufacturing (DfM) and design for test (DfT) can identify choices that will be difficult to execute at volume while there is still time to change them. Component decisions can account for availability, lifecycle, cost, and regional sourcing alongside technical performance. Early builds can expose assembly tolerances, process sensitivities, test limitations, and other issues that may not emerge during validation.

Production testing deserves similar attention. Test architecture, coverage, instrumentation, limits, and cycle time all affect whether a design that performs well in development can be produced efficiently at volume. Correlating engineering and production testing also creates a stronger baseline for determining whether subsequent failures originate in the design, components, manufacturing process, or elsewhere.

The objective is to develop the product and its production process in parallel. A modular sourcing strategy should not turn architecture, engineering, sourcing, and manufacturing into a series of handoffs. As responsibilities become more distributed, those disciplines need to collaborate earlier.

Build flexibility into the sourcing model

Second sourcing can help OEMs manage costs, increase supply flexibility, and reduce dependence on an individual supplier. For complex automotive electronics, however, establishing another production source rarely amounts to reproducing an existing assembly process in another factory.

A transfer may expose gaps in design documentation, test coverage, component specifications, or process knowledge. Different regional supply chains may require alternate components or suppliers. Test equipment may need to be transferred, recreated, or redesigned. Manufacturability issues accommodated within an incumbent supplier’s process may require design changes before the product can be manufactured efficiently elsewhere.

Requirements shift, components reach end of life, software advances, and product revisions continue after the second source has been established. A manufacturing partner must be able to support design changes, component qualification, test development, and process validation. Engineering depth enables a second source to absorb complexity, not simply duplicate capacity, as the program continues.

Make optionality executable

A broader, more intertwined automotive ecosystem gives OEMs more choices about what they own, what they source, who they work with, and where products are manufactured. Flex works across that ecosystem, providing the engineering support, industrialization, supply chain management, and automotive-grade production needed to carry customer-defined products into production and scale them globally.

For automotive engineers, unbundling for its own sake has never been the goal. Some technologies will benefit from greater independence, while others will require tight hardware-software coordination. With a range of choices in play, the ability to make them executable at scale will matter as much as the options themselves.