TN-15 · 2026-09-12 · XiL Domain Series · Part 1

One AEB Feature from Model to Production: The V-Model's Six Levels and the TTC Metric

One concrete requirement runs through this article: “AEB CIPV, ego at 50 kph, stationary vehicle ahead: the system must avoid the collision.” From model to production, this requirement passes through six test environments — what’s in the loop differs at each level, the question each level answers differs, and the faults each level can catch differ. This article first walks the requirement through the V-model’s six levels, then digs into AEB’s most classic trigger metric, TTC, and its five flaws.

1. The Chain at a Glance: One Requirement, Six Levels, Six Things to Watch

The left three levels (MIL/SIL/PIL) verify “the software itself”; the right three verify “integration and the real world.” The essence of the V-model is the left-right correspondence: unit design ↔ MIL/SIL/PIL, system design ↔ HIL, requirements ↔ vehicle acceptance — every test level validates the design artifact of the level opposite it.

2. Three Points You Must Understand

1. The same scenario is reused at every level, but each level asks a different question. “50 kph into a stationary car” runs from MIL all the way to the proving ground with its shape almost unchanged, but MIL checks the logic, SIL checks the code, HIL checks integration, and the proving ground checks the physical world. This is why the case format must be abstract and decoupled from the execution environment — the “separate the scenario description from the bus implementation” design is exactly this idea made concrete. It’s also the answer to questions like “can we skip PIL”: each level narrows the suspicion space by one; skipping a level glues the answers to two different questions together.

2. The economic pyramid decides how the work is split. A single MIL/SIL run costs almost nothing — a hundred thousand cases, no heartache; a HIL rig costs millions, and the whole company queues for it; a proving ground costs tens of thousands per day; public roads are the most expensive and the least reproducible. The industry’s entire effort is shifting coverage left — whatever SIL can catch must not be left for HIL; HIL only runs cases that “require real hardware” (fault injection, bus timing, diagnostics); the proving ground confirms, it doesn’t explore.

3. NCAP is the final acceptance standard, but it’s present from day one. Protocols like “CCRs at 50 kph, avoid the collision” are written into the system requirements at the requirements phase, rehearsed early in SIL/HIL (pre-calibration), and finally passed officially on the proving ground — the proving ground is not where you first meet them.

3. The One-Sentence Summary

MIL/SIL prove “the thinking is right,” PIL proves it “lands correctly on target,” HIL proves “the assembly is right,” and the proving ground and road tests prove “it’s right in the real world.” For a high-ASIL feature like AEB, not one of the six levels can be skipped — the level you skip will come back to find you, in an audit or in an accident.

The six levels answer “where to test, what to test.” One question runs through all of them: what do you use to judge “should it brake — did it crash”? AEB’s most classic judgment quantity is TTC.

4. TTC: Assuming Nothing Changes, How Long Until Impact

TTC (Time-To-Collision) = assuming both vehicles maintain their current motion, how long until they collide.

Car-following scenario (one-dimensional, longitudinal):

TTC = relative distance / relative speed = d / (v_ego − v_front)   (only while closing)

Intuition: 40 m of distance, you’re 10 m/s faster than the car ahead → TTC = 4 s. The precise version accounts for acceleration: solve d + Δv·t + ½Δa·t² = 0 for the smallest positive root; in engineering, the constant-speed version is the one most used.

It has two relatives: iTTC (the reciprocal of TTC = Δv/d, which avoids division by zero) and THW (Time Headway = d/v_ego, used by ACC — don’t confuse it with TTC).

5. The Classic Usage as a Trigger Condition

Threshold tiers (calibration varies by OEM; illustrative only):

TTC < 2.5s  warning (FCW)  →  TTC < 1.2s  partial braking  →  TTC < 0.6s  full braking

Every level from the first half of this article replays this judgment: MIL checks whether the thresholds and timing themselves are right, SIL sweeps the threshold boundaries with tens of thousands of cases, HIL checks whether the trigger still lands in time under real bus timing — the same metric, asked a different question at every level.

6. The Five Flaws

1. Division singularity: least stable exactly where you need it most stable (the most fundamental). As the denominator Δv→0, TTC→∞; Δv is a perception estimate carrying noise, and division violently amplifies noise in the denominator — TTC jumps between ±∞. And “speeds nearly equal” is precisely the critical state where risk is brewing: when the car ahead has just started to decelerate, TTC is completely untrustworthy; by the time Δv is large enough to read stably, time is already tight. The remedy is filtering + hysteresis + multi-frame confirmation — but filtering is latency, and AEB is a race against fractions of a second. This contradiction is congenital.

2. No prediction, only extrapolation. It assumes “the current state continues forever”: the car ahead is about to slam the brakes, is changing lanes away, is preparing to turn — TTC knows none of it. It measures “now”; it triggers on “the future.”

3. A one-dimensional quantity in a two-dimensional world. Cut-in: while there is no lateral overlap yet, the collision isn’t even defined; by the time the cut-in completes, TTC is already tiny — inherently sluggish. Crossing pedestrians (CPNCO): the directions of motion aren’t collinear, the very definition of “relative speed” becomes a problem, and you have to switch to a two-dimensional closing speed.

4. No braking physics. TTC = 1 s with Δv = 5 kph is an easy stop; with Δv = 50 kph the collision is already physically certain. TTC only answers “how long until impact,” not “can we still stop.” A serious trigger logic must combine it with the required deceleration (a_req ≈ Δv²/(2d)).

5. The threshold dilemma. Loosen it → uncertain scenes also trigger → false braking (phantom braking at highway speed gets you rear-ended — a safety incident in itself); tighten it → not enough physical time left for braking. A single parameter cannot express “how certain are we”; it must be fused with the perception side’s object confidence / existence probability.

7. Engineering Remedies: Why It’s Still in Use

iTTC or Δv-threshold clamping, multi-frame debounce, combined TTC×a_req thresholds, speed- and scenario-segmented calibration; in more modern schemes, TTC is just one input to a risk model, fused with predicted-trajectory overlap probability and object confidence for the decision. The five flaws didn’t kill TTC — they just demoted it from “one formula rules them all” to “one input among many in a risk fusion.”

8. TTC in SIL vs TTC on the Road

The same TTC is clean in SIL — distance and speed are simulation ground truth; the division singularity and the noise simply don’t exist. In the real world it’s a noisy estimate, and all five flaws show up. The same AEB case, in the two environments, has completely different “trustworthiness of the judgment quantity” — the most vivid illustration of how SIL differs from HIL and the real vehicle. When you write judgment logic, it’s worth asking: “what does this quantity look like on the real sensor side?”

Looking back: the V-model’s six levels answer “where to test, what to test”; TTC answers “what to judge with.” An AEB feature’s journey from model to production means carrying one metric through six environments of very different trustworthiness — the first half of the journey proves the function right; the second half admits the metric can lie to you, and then uses it right anyway.

Appendix: Glossary (in order of appearance)