The Vehicle Development Process

How a car goes from a spreadsheet of targets to a million produced units — the phases, the gates, and the V-model that ties requirements to validation.

Automotive EngineeringDevelopment & CapstoneFree preview
⏱️ About 14 min
The Vehicle Development Process — illustration
Decorative illustration.

A new car takes three to five years and thousands of engineers from first target to first customer. The vehicle development process is the discipline that keeps that enormous effort on time, on cost, and on spec.

💡
The big idea: Vehicle development follows the V-model: requirements cascade down from vehicle-level targets to subsystem and component specs, then verification and validation climb back up, with program gates controlling the transition between phases.
🎯 By the end, you'll be able to
  • Outline the V-model of vehicle development
  • Distinguish verification from validation
  • Describe target cascading from vehicle to component
  • Explain program gates and the timeline
📎 Helpful to know first

The V-model

Vehicle development is the V-model from Module 1, fleshed out across years. Down the left arm, requirements are set and designed: vehicle-level targets (mass, performance, range, crash, cost) are defined, then cascaded down into subsystem targets (powertrain output, body stiffness, cooling capacity) and component specs (spring rate, gear ratio, motor power). Design proceeds subsystem by subsystem, increasingly detailed and increasingly digital (CAD, CAE simulation) before any metal is cut. At the bottom of the V, components are built and tested. Up the right arm, verification (does each part meet its own spec?) and validation (does the whole vehicle meet the original vehicle-level targets?) climb back up through integration, prototype builds, and real-world testing, until the car is signed off for production. Program gates control each transition, freezing the design at increasing levels of commitment.

vehicle targetssubsystem designcomponent build+testsubsystem verifyvehicle validatecascade downclimb upverification (meets spec) vs validation (meets the target)
The V-model: requirements and design cascade down (left), verification and validation climb up (right). The two arms meet at vehicle-level validation: 'does the whole car meet its targets?' Program gates freeze design at each level.
🔑 Verification versus validation

The two words sound similar but mean different things, and confusing them is expensive. Verification asks 'did we build the thing right?' — does each component and subsystem meet its own specification (the spring is the right rate, the motor makes the right torque, the panel is the right thickness)? Validation asks 'did we build the right thing?' — does the integrated vehicle actually meet the original vehicle-level targets (the 0–100 time, the range, the crash performance) that the customer cares about? A part can pass verification (meets its spec) yet the car fail validation (the spec was wrong, or subsystems interact badly). Both arms of the V are essential; skipping validation to save time is how cars reach customers with surprising defects.

Gates, prototypes, and the timeline

A typical program runs three to five years through a sequence of prototype builds (often named A, B, C samples of increasing maturity) separated by gates that freeze the design at each level. Early prototypes (mules, A-samples) test subsystems in isolation or in borrowed bodies; later ones (B, C) are near-production vehicles for durability, crash, and emissions validation. Simulation (CAE) front-loads as much as possible — a crash simulation costs a fraction of a physical test — but physical validation remains the sign-off authority. The timeline is dominated by long-lead tools (body-stamping dies, injection moulds) which must be committed early and are expensive to change, which is why late design changes are so costly and why the gates enforce freezing.

📝 Worked example: A vehicle-level target is a 0–100 km/h time of 7.0 s. This cascades to a required average tractive effort of (say) 5500 N at the wheels over the run. If the final-validated vehicle produces only 5100 N average, by roughly what factor does the 0–100 time miss (time scales inversely with force, roughly)?
  1. Ideal time ∝ 1/force ⇒ t_actual / t_target = F_target / F_actual = 5500 / 5100 = 1.078
  2. t_actual ≈ 7.0 × 1.078 = 7.55 s
✓ ≈ 7.55 s (misses the 7.0 s target — a validation failure to correct)
✏️ Practice: A mass target of 1500 kg cascades to a body-mass allocation of 600 kg. The verified body comes in at 640 kg (40 kg over). If nothing else changes, what is the new total vehicle mass?
kg
Solution
  1. New total = 1500 + 40 = 1540 kg (40 kg over the vehicle-level target)
  2. A component-level verification miss propagates to a vehicle-level validation miss — the V in action.

Check your understanding

1. Verification asks:
Verification checks each part against its own spec ('built the thing right'); validation checks the whole vehicle against customer-level targets ('built the right thing').
2. Program gates in the V-model exist to:
Gates freeze design at increasing commitment levels — once a gate passes, changes become expensive, which enforces discipline and protects the long-lead tooling timeline.
✅ Key takeaways
  • Vehicle development is the V-model: requirements/design cascade down, verification/validation climb up
  • Verification = 'built the thing right' (meets spec); validation = 'built the right thing' (meets vehicle target)
  • Program gates freeze design at each level, protecting the long-lead-tooling timeline
  • Simulation (CAE) front-loads testing, but physical validation remains the sign-off authority
➡️ The process understood, the next lesson covers making the design buildable and serviceable — design for manufacture and assembly.