For decades, the car industry liked its automotive development processes as it liked its factories: linear, orderly and industrial. Software-defined vehicles (SDVs) are changing this dynamic, requiring ongoing validation throughout a vehicle’s life. As a result, although the traditional “V-model” of automotive engineering endures, it’s evolving—becoming a continuous loop of development rather than a fixed process.

What is the V-model in automotive engineering?

The V-model, long the dominant framework for automotive development, suited the industry’s linear world neatly. Requirements descended on one side of the V; implementation and testing climbed the other. The method reflected an era when cars were largely mechanical, with software added late in development and rarely touched after production.

That logic is now under strain. Modern vehicles are increasingly software-defined: rolling computing platforms governed by software architectures, centralized processors and over-the-air (OTA) updates. Complexity no longer sits primarily in hardware. It resides in code, connectivity and the interactions between distributed systems. Validation therefore changes too. The V-model is not disappearing, it is mutating from a sequential process into something more continuous and evidence-driven.

Why the traditional V-model is under pressure

Software-defined vehicles are changing automotive engineering—and the V-model—by requiring continuous validation throughout a vehicle’s life cycle. Executives and engineers at Aptiv and Elektrobit make essentially the same point. The V-model’s core principle—linking requirements to proof—remains intact. What has altered is its tempo.

Jagan Rajagopalan, vice-president and head of strategy and portfolio at Elektrobit, rejects the idea that the model itself is obsolete. “We see the V-model not as a static process, but as a flexible systems-engineering backbone that must evolve for SDVs,” he says.

Others frame the change more operationally. “The V-model still works,” says Brian Witten, chief technology officer of Aptiv Intelligent Systems, Sensors & Compute. “What has changed is the pace at which it runs.”

Software updates, continuous integration pipelines and virtual testing environments mean verification can no longer occur only at the end of development. Validation now accompanies the vehicle throughout its life.

Software-defined vehicles and the need for continuous validation

How are software-defined vehicles changing automotive engineering? Software-defined vehicles evolve constantly. A traditional car effectively froze at the start of production (SOP). A software-defined vehicle does not. OTA updates can alter vehicle behavior long after sale, extending the validation burden indefinitely. The old “one-pass” V-model therefore gives way to repeated cycles of verification. A baseline safety case established before SOP must be continually revalidated after each software update.

Shift-left automotive engineering and virtual testing

The most obvious consequence of this move is the rise of shift-left engineering. Shift-left engineering in automotive development means moving testing and verification earlier in the vehicle engineering process. Simulation, virtualization and digital twins have existed in vehicle engineering for years, but software-defined vehicles make them indispensable. The complexity of modern software systems—and the impossibility of covering all edge cases physically—means traditional proving-ground testing is no longer enough.

Rajagopalan says simulation is now embedded throughout development—“from early architecture exploration to large-scale regression testing.” Aptiv’s emphasis on centralized computing platforms similarly depends on validating software continuously across thousands of permutations. Physical prototypes become less dominant; virtual environments take on much of the burden.

In powertrain engineering, the same logic applies. Mike Linehan of MAHLE Powertrain describes efforts to minimize dependence on rapid prototype hardware through up-front controls development and virtual calibration. “We aim to minimize our reliance on rapid prototyped hardware,” he says, adding that virtual calibration allows engineers “to hit the ground running.”

Physical testing remains essential but increasingly serves to confirm what models predict rather than to discover entirely new failures.

CI/CD and AI in automotive engineering: Risk or necessity?

Continuous integration and continuous delivery (CI/CD), long standard in consumer software, are also moving into automotive engineering. This creates understandable anxiety in safety-critical systems. Cars are not smartphone apps; defective code can kill people. The fear is that software-style velocity might erode vehicle engineering discipline.

Yet the companies interviewed argue the opposite. Properly implemented, CI/CD strengthens verification rather than bypassing it. ISO 26262, the automotive functional-safety standard, demands rigor and traceability, not slow development cycles.

Rajagopalan argues that “CI/CD is becoming essential even in safety-critical environments, but it must be applied thoughtfully.” Witten frames the issue this way: “ISO 26262 prescribes rigor and traceability, not cadence.”

The distinction is key. Continuous deployment may not always be appropriate for safety-critical functions, but continuous verification increasingly is. In the software-defined vehicle era, evidence itself becomes automated.

Artificial intelligence (AI) adds another complication. AI copilots are already being used to draft code, generate documentation and accelerate engineering analysis. They promise productivity gains, but they also threaten the very attributes the V-model exists to protect: repeatability, traceability and explainability.

Engineers therefore speak cautiously. “Contrary to the hype, AI is not a universal panacea,” says Linehan. “The key phrasing is AI-assist.” Human oversight remains central because accountability cannot be delegated to algorithms. “The human-in-the-loop is still essential,” he says. “Accountability sits with the engineer, not the tools.”

That concern reflects a broader truth about software-defined vehicle development. Validation is no longer simply about whether a component works. It is about whether evidence can be continuously regenerated, traced and governed across sprawling software ecosystems.

OTA updates and the end of one-pass development

This continuous cycle of validation becomes especially important as vehicle architectures evolve. Traditional automotive electronics revolved around discrete electronic control units (ECUs), each tied to a particular function. Validation could therefore occur largely at the module level. Software-defined vehicles replace much of that architecture with centralized computing and zonal systems, in which software services run across shared platforms.

The result is a shift from function-level validation to platform-level validation. Engineers must verify not merely that individual features behave correctly, but that timing, communication and resource isolation remain deterministic across the whole system.

That introduces new risks. Zonal architectures reduce wiring complexity and simplify manufacturing, but they increase dependence on software orchestration and in-vehicle networking. Ethernet timing, workload interference and fault propagation become central automotive engineering concerns.

Integration testing therefore changes character. It is no longer simply about whether one ECU communicates with another. It becomes an exercise in validating concurrency, latency and isolation boundaries across distributed computing systems.

The greatest strain on the traditional V-model arrives after production. OTA updates transform the vehicle into a permanently evolving product. Validation therefore extends beyond SOP to an ongoing operational cycle.

“With OTA updates, initial vehicle release is no longer the end of validation,” says Rajagopalan. “It is the beginning of a continuous life cycle.”

The V-model endures as a continuous loop

What is the future of automotive engineering? Witten argues that the V-model survives, but in altered form. “It marks the end of the V-model as a one-pass exercise,” he says, “not the end of the V-model as a discipline.”

The broader pattern is clear. Automotive engineering is converging with software engineering without surrendering the safety disciplines that distinguish the industry from consumer technology. Carmakers can no longer rely on development processes designed for static hardware products. But neither can they afford the casual experimentalism of Silicon Valley.

The V-model is therefore being recompiled rather than discarded.

Its original purpose—ensuring disciplined links between requirements and verification—remains indispensable. But “done” no longer means a validated product leaving the factory. It means a continuously updated body of evidence capable of keeping pace with software change.

The old V-model resembled a staircase: orderly, sequential and finite. The software-defined vehicle version looks more like a loop. Validation no longer ends at production; it becomes a continuous operational activity running alongside the vehicle throughout its life.

The car industry once treated software as an accessory to the machine. Increasingly, the machine exists to host the software. Vehicle engineering processes are adapting accordingly.

The V-model is not dead. It has simply learned to run in circles.