2. Validation levels and evidence types
Subsystem-to-vehicle validation is not a single activity but a layered evidence chain. Each layer answers a different question, uses different facilities, and produces evidence with a different scope of validity. The central engineering discipline is to know which layer can legitimately support which claim — and to avoid the common failure mode of using low-level evidence to justify a vehicle-level conclusion, or demanding vehicle-level evidence for a question that a bench test can answer more cheaply and more precisely.
The hierarchy below is organized by the object under test and the degree of system integration, not by organizational convenience. As integration increases, realism increases, but controllability, repeatability, and diagnostic resolution decrease. That trade-off is the organizing principle of the entire evidence hierarchy.
The five validation levels
L1 — Component and part-level bench testing. The object under test is a single part or a small assembly: a sensor, an actuator, a pump, a bus transceiver, a bearing, a seal. Tests run on dedicated rigs — environmental chambers, shakers, hydraulic benches, HIL I/O racks — with tightly controlled inputs. Evidence produced here is high-resolution and highly repeatable, and it isolates failure mechanisms cleanly. Its limitation is equally clear: it says almost nothing about interaction effects, packaging constraints, or system-level timing.
L2 — Subsystem bench and hardware-in-the-loop (HIL) testing. The object is a functional subsystem — a braking modulator with its hydraulic unit and ECU, a thermal management loop, an ADAS perception module — exercised against a simulated or partially real environment. HIL is the workhorse of this level: the real ECU runs against a real-time plant model, with fault injection available on every signal. This is where most control-logic, diagnostic, and fault-reaction evidence is generated, because faults that would be dangerous or unreproducible on a vehicle can be injected deterministically.
L3 — System-level integration testing on test benches or in the lab. Multiple subsystems are connected and exercised together — for example, a full powertrain on a dynamometer, or a complete electrical/electronic architecture on an integration bench. The question shifts from "does this subsystem work" to "do these subsystems cooperate," including bus loading, power distribution, wake/sleep behavior, and cross-domain fault propagation.
L4 — Vehicle-level testing on the proving ground and public road. The complete vehicle operates in the real environment: real loads, real thermal conditions, real electromagnetic environment, real driver behavior. Proving-ground trials provide controlled, repeatable vehicle-level maneuvers — durability courses, brake test surfaces, handling pads, grades, and environmental chambers large enough for a full vehicle. This level produces the evidence that ultimately supports type approval and customer-facing claims, but it is expensive, slow, and offers limited diagnostic visibility when something goes wrong.
L5 — Fleet and field validation. Vehicles operate in customer or pilot use over extended time and mileage. This is the only level that captures real usage distributions, long-term degradation, and rare-event exposure. It is statistically powerful only at scale and is therefore used to confirm — not to discover — issues that lower levels have already characterized.
What each level can and cannot prove
The most consequential skill in this hierarchy is claim discipline. A component bench test that passes at −40 °C proves the part operates at that temperature under the specified electrical and load conditions; it does not prove the subsystem starts at −40 °C, because connector resistance, harness routing, and ECU wake timing are not represented. Conversely, a vehicle that passes a cold-start trial proves the integrated system works in that specific vehicle configuration and ambient profile — but with a sample size of one or a few, it provides weak statistical evidence about the population.
A useful rule: evidence supports a claim only within the boundary of the object tested and the conditions applied. When a claim crosses a boundary — from part to subsystem, from subsystem to vehicle, from one vehicle configuration to another — the evidence must be extended by test, by analysis, or by an explicitly justified similarity argument. That similarity argument is itself a deliverable, not an assumption.
Choosing the level: a worked example
Consider validating an electric park brake (EPB) subsystem against a requirement that it must hold the vehicle on a 20% grade and must detect and report a caliper actuator fault within 200 ms. A naive plan would go straight to the proving ground. A disciplined plan distributes the evidence:
- L1: Caliper actuator characterized on a bench for clamping force versus current and temperature, and for response time at 9 V, 12 V, and 16 V supply. This establishes the actuator's physical envelope and gives the plant model its parameters.
- L2: EPB ECU on HIL with a brake plant model. Grade-hold logic is exercised across mass and friction-coefficient corners; actuator faults (open circuit, short to ground, stalled motor) are injected and the 200 ms detection requirement is measured directly at the ECU pin. This is where the timing claim is actually proven, because the measurement is unambiguous.
- L3: EPB integrated with the vehicle electrical architecture on an integration bench to confirm wake/sleep behavior, bus message timing under load, and that an EPB fault does not disturb other consumers on the same supply.
- L4: Vehicle on a 20% grade at the proving ground, loaded to GVW, with hot and cold brake conditions, to confirm the integrated system holds and that the fault lamp and message behave as specified. Sample size is small; the purpose is confirmation, not statistical proof.
- L5: Fleet data on fault occurrence rates and any field grade-hold complaints.
Note what happened: the 200 ms detection claim was proven at L2, where it could be measured precisely, and merely confirmed at L4. Reversing that — trying to measure 200 ms detection on a vehicle with a stopwatch and a CAN log — produces weaker evidence at higher cost.
Evidence types and their traceability
Each level produces characteristic evidence artifacts, and the hierarchy is only as strong as the traceability between them. A practical evidence register links each requirement to the level, facility, test case, and result that discharges it.
| Level | Typical evidence artifact | Key traceability link |
|---|---|---|
| L1 | Characterization curves, environmental test reports, part specification compliance | Part number and revision → plant model parameters |
| L2 | HIL test cases, fault-injection logs, timing measurements, diagnostic coverage report | Requirement ID → test case ID → measured value vs. limit |
| L3 | Integration bench logs, bus load traces, power distribution measurements | Subsystem interface spec → bench configuration record |
| L4 | Proving-ground test reports, vehicle configuration records, ambient conditions | Vehicle build configuration → test procedure → pass/fail criteria |
| L5 | Fleet telemetry, warranty and field reports, degradation trends | Production build → field population → observed rate |
When a higher-level test fails
The hierarchy is bidirectional in practice. When an L4 vehicle test fails, the diagnostic path runs downward: reproduce at L3 to determine whether the issue is an integration effect, then at L2 to isolate control logic, then at L1 to examine the part. A grade-hold failure on the proving ground, for example, might trace to an L3 finding that the actuator supply sags during a simultaneous high-load consumer event — an interaction that no L1 or L2 test would have exposed, because neither represented the shared supply. This is precisely why the levels are complementary rather than redundant, and why a mature validation plan deliberately places interaction-sensitive requirements at L3 rather than assuming L2 coverage is sufficient.
The practical output of this chapter's reasoning is a validation plan in which every requirement has a named level, a named facility, a measurable pass criterion, and a stated boundary of validity. The next layer of the course examines how those individual pieces of evidence are assembled into a coherent argument that a subsystem is ready for vehicle integration — and, ultimately, that the vehicle is ready for the customer.