THE ARCHITECTURE PROBLEMThe industry is adding software-defined capabilities to a fragmented foundation – separate controllers, separate software, separate suppliers. Every new capability brings more compute, integration, dependencies, and validation, increasing what it costs to develop, build, and update the vehicle.
The industry is still building a fragmented car, built one box at a time
Traditional vehicle architectures were created for a simpler purpose: connect dedicated hardware to largely fixed mechanical and electrical functions.
The modern vehicle is expected to operate as a connected, intelligent platform supporting digital cockpits, advanced driver assistance, AI-driven functions, continuous software updates, personalized experiences, connected services, and capabilities that continue evolving after the vehicle leaves the factory.
An outdated foundation creates compounding complexity, slows software development, locks in technology decisions, and drives cost across the vehicle lifecycle.
RISING ECONOMIC PRESSUREThese were some of the industry’s most serious attempts to change how vehicles are developed.
No amount of software investment can out-engineer a fragmented architecture underneath it.
The cost of architecture is not recorded in one component or one budget. It is distributed across engineering hours, integration programs, validation cycles, material costs, manufacturing operations, supplier coordination, and years of lifecycle support.
COMPOUNDING COMPLEXITYAs new capabilities are introduced, the vehicle accumulates another controller, processor, software image, network interface, and supplier-owned environment. Besides that, every additional box also brings physical requirements: pins, connectors, wiring, power, cooling, packaging, and space.
Furthermore, a vehicle harness is specific to its model. That means even the simplest change creates repeated physical and engineering work across an entire vehicle portfolio.
Zonal reduces wiring, consolidates some functions, and removes some electronic control units from the vehicle. But each controller is still a computer with its own software, interfaces, security requirements, validation obligations, and lifecycle responsibilities.
Zonal rearranges and reduces the boxes, but the car is still fragmented – just into fewer, larger pieces.
As the number of systems increases, complexity grows through the relationships between them. A change in one function can affect multiple controllers, interfaces, configurations, and validation requirements. And that is carried throughout the vehicle lifecycle.
SLOW, LOCKED-IN SOFTWAREWhen functions remain distributed in a fragmented vehicle, a software change can trigger cross-controller integration, supplier coordination, regression testing, safety verification, and vehicle-level validation. The result is a fundamental mismatch: software is expected to evolve continuously while the architecture remains tied to vehicle-program cycles.
When hardware, software, and supplier-owned functions are tightly coupled, changing a processor, sensor, supplier, or software stack can require redesign, reintegration, and revalidation.
The longer a decision remains embedded in the architecture, the more expensive it becomes to change.
A DIFFERENT FOUNDATIONIncrementally improving a fragmented architecture can reduce individual symptoms, but it does not eliminate the underlying structural problem.
A different architectural model is required to reduce hardware/software coupling, consolidate compute, simplify integration, and allow software and hardware to evolve more independently.
