Introduction
Many people discuss the V-model, yet common concepts often generate disagreement. This article presents one perspective.
There are many development models, including incremental, prototyping, spiral, fountain, and W-model. For brevity and relevance, this article focuses on the core ideas rather than cataloging every variant.
Start from the waterfall
In essence, the most basic engineering logic is represented by the waterfall model. Many other models, including the V-model, are derived from the waterfall and still reflect its core logic.
1. Waterfall as a cognitive and engineering logic
The waterfall model, as commonly understood, embodies the simplest cognitive logic. As the name implies, development proceeds layer by layer like a cascading flow.
At a basic level it extends three foundational areas: requirements, design, and testing. Engineering activities are arranged in sequence like dominoes, where outputs from one stage drive the next until the final stage is reached.
This approach is straightforward and easy to understand, which makes it easier to manage. It suits domains with high requirements for standardization and process control, such as vehicle manufacturing, which is a typical waterfall-style domain.
For a simple, single software module where requirements are clear, the design approach is fixed, and test cases are defined, a one-pass waterfall is often the best option.
However, waterfall does not imply strictly single-threaded, unidirectional execution. Even simple mechanical part development involves parallel work and iterative corrections.
Broadly, the waterfall model has two defining characteristics:
- Linear serial order along the timeline.
- Downstream inputs depend on upstream outputs.
Thus, waterfall is not only a development model but also a way of thinking that is hard to escape.
2. The essence of the V-model
Real-world development rarely follows a perfect linear sequence. For complex systems and collaborative environments, the basic waterfall becomes less convenient as a reference.
In automotive development, with long supply chains and complex mechatronic systems, variants evolved from the waterfall. The V-model has become the most widely applied model in the automotive domain.
Industry frameworks and standards such as ASPICE, ISO 26262, and ISO/SAE 21434 also adopt architectures based on the V-model.
2.1 Layered, nested V-models in automotive development
The V-model is often considered a software development model, but in automotive contexts software cannot be discussed in isolation.
Viewed from a systems engineering perspective, the overall vehicle development is an architecture of large V-models containing smaller V-models.
Multiple vehicle-level V-models provide the backdrop for overall vehicle development, supporting activities such as vehicle attribute definition, styling, architecture design, requirements decomposition, subsystem implementation, prototype delivery, vehicle integration, and vehicle verification. These support the achievement of vehicle-level milestone goals.
Individual ECU subsystems are developed through their own smaller ECU-level V-models.
Further, each ECU subsystem can be divided into disciplines such as mechanical, software, algorithm, calibration, hardware, and subsystem integration. These disciplines operate via even smaller V-models.
Through iterative application of nested V-models, parts, subassemblies, domain systems, and the full vehicle mature until the vehicle reaches start of production.
2.2 The core of the V-model
What is the core of the V-model? Four points merit attention.
2.2.1 Decompose into layers and blocks
When a problem is hard to grasp, break it down and analyze smaller units. In engineering, this means decomposing system-level requirements into finer layers and modules.
2.2.2 Strong focus on verification and validation
Automotive and automotive software development involve extensive verification at multiple levels. Narrowly, this means engineering tests; broadly, it includes reviews, walkthroughs, milestones, audits, and test drives as parts of the validation process.
2.2.3 Division of labor and collaboration
Decomposition enables division of labor, and the pattern of collaboration reciprocally affects system hierarchy and architecture. As Conway's Law suggests, a product tends to mirror the organization’s communication structure.
2.2.4 The onset of "chaos"
However, dividing the system into layers and blocks is not an ultimate solution. The V-model and the automotive development ecosystem have reinforced each other, making the V-model the structural backbone of the industry.
As software becomes more central and architectures move toward domain consolidation and centralization, the strict hierarchy from system to component weakens and disciplinary boundaries blur.
In practice, teams often struggle to determine whether a requirement is a system-level or software-level requirement, and whether a test is a software test, hardware test, or integration test.
The conceptual chaos around layered decomposition is becoming evident.
Resolving this chaos is a current priority and may take time to restore order. During this process there is no need to hastily question the existence of the V-model itself.
3. Summary
This article presents three key points:
- The waterfall is a foundational cognitive and engineering logic.
- Complex vehicles progress toward production through nested V-models.
- The V-model is characterized by layered decomposition, strong emphasis on verification, and division of labor, but it now faces issues from blurred layering and block boundaries.
4. Final remarks
Amid disorder, concepts can become misleading and there is a tendency to favor novelty. In practice, however, engineering remains grounded in the basic logic of the waterfall, and the core ideas of the V-model continue to be fundamental for understanding automotive software today.
