4. Vehicle program baselines

A change impact assessment is only as trustworthy as the baseline it is measured against. Before any NCAP protocol delta can be evaluated, the program must be able to answer a deceptively simple question: what exactly is the vehicle today, and how does it currently perform against the applicable protocol? A vehicle program baseline is the frozen, traceable record of that answer. It combines three tightly coupled data domains — compliance status, test evidence, and configuration definition — and it must be established before the change is analyzed, not reconstructed afterwards.

The most common failure mode in NCAP change assessment is not a wrong engineering judgment; it is a baseline that silently drifted. A test was re-run with a different tire, a software calibration was updated after the official test, or a variant was assumed to share hardware with the base vehicle when it did not. Each of these produces an impact assessment that is internally consistent but externally wrong. The discipline of baseline capture exists to prevent that.

What a Baseline Must Contain

A usable baseline has three layers, and each layer answers a different question during impact assessment.

Compliance status answers "where do we stand against each protocol clause?" It is not a single pass/fail flag. For each applicable assessment area — frontal impact, side impact, pedestrian protection, active safety, child occupant protection, and so on — the baseline should record the protocol version applied, the achieved result (star rating, score, or sub-item performance), the margin to the threshold, and the assessment status (tested, simulated only, engineering estimate, or not yet assessed). The margin matters as much as the result: a clause passed by 0.3 points is far more sensitive to a protocol change than one passed by 4 points.

Test evidence answers "what proves that status?" Each compliance entry must point to identifiable evidence: test report ID, test date, test facility, vehicle build level, and the specific test configuration used. Evidence that cannot be traced to a build level is not evidence — it is anecdote.

Configuration data answers "which physical and software build produced that evidence?" This is the layer most often under-specified. It must capture the variant matrix (body style, powertrain, drive configuration, seating), the safety-relevant hardware (restraint systems, airbag variants, bumper and hood geometry, sensor suite), the software and calibration versions of relevant ECUs, and the test-specific setup (tire specification and pressure, loading condition, ambient conditions where relevant).

Structuring the Baseline for Change Assessment

The baseline should be organized so that a protocol change can be mapped onto it clause by clause. A clause-oriented structure works better than a document-oriented one, because impact assessment proceeds clause by clause. The following table illustrates a representative baseline extract for one assessment area; the values are illustrative examples, not measured results.

Two design choices in this structure pay off later. First, the status column distinguishes tested from simulated from estimated, so the assessor knows how much confidence to place in each margin. Second, the build level column ties every row to a specific physical and software configuration, which is what allows the impact assessor to ask the critical question: does the protocol change interact with anything in this build?

Capturing Configuration Data Without Creating a Second Truth

Configuration data almost always exists somewhere already — in PLM, in the BOM, in ECU release records, in test facility logs. The baseline should not duplicate these systems; it should reference them at a defined granularity and freeze the reference at a baseline point. The practical mechanism is a baseline snapshot record: a dated manifest that lists, for each variant in scope, the BOM level, the relevant ECU software and calibration part numbers, and the test setup parameters. When the program later asks "did the change affect this?", the snapshot answers definitively what "this" was.

Baseline snapshot: NCAP-BL-2025-Q1
Program: Midsize SUV (internal code MX-4)
Frozen: 2025-03-14
Variants in scope:
  MX4-2WD-5S   BOM level B2.3
  MX4-AWD-5S   BOM level B2.3
  MX4-AWD-7S   BOM level B2.3 (rear restraint variant R2)
Safety-relevant ECU releases:
  Airbag ECU      SW 4.7.2 / CAL 4.7.2-a
  ADAS domain ctrl SW 2.9.0 / CAL 2.9.0-c
  Brake ECU       SW 1.8.4 / CAL 1.8.4
Test setup reference:
  Tire: 235/55 R19, pressure 2.4 bar cold (per test facility log TF-2025-0211)
  Loading: kerb + 2 x 75 kg front occupants (frontal tests)
Evidence index: see TR-FR-0142, TR-AEB-0031, CAE-PED-0088

Note that the snapshot records the test setup separately from the production configuration. This distinction is essential: a test may legitimately use a tire or loading condition that differs from the sales configuration, and the impact assessor must know which one a given result reflects. Conflating the two is a frequent source of erroneous conclusions when a protocol change alters test conditions.

Establishing the Baseline in Practice

The capture process itself should be treated as a controlled activity with a defined close-out. A workable sequence is: define the protocol versions and assessment areas in scope; collect existing test reports and map each to a clause; reconcile each report against the build level it was run on; identify gaps where no evidence exists or where evidence predates the current build; and record those gaps explicitly as baseline weaknesses rather than filling them with assumptions. The output is a frozen snapshot plus a gap register.

The gap register is not a failure of the baseline — it is one of its most valuable outputs. A clause with no current evidence is precisely the clause where a protocol change will be hardest to assess, and flagging it early allows the program to schedule confirmation testing before the change analysis begins rather than discovering the gap during sign-off.

How the Baseline Feeds the Impact Assessment

Once frozen, the baseline becomes the reference surface against which the protocol delta is projected. Each changed clause is matched to its baseline row; the assessor then examines whether the change interacts with the recorded configuration (for example, a new pedestrian test point that falls on a hood geometry variant), whether the existing margin is sufficient to absorb the change, and whether the evidence status is strong enough to support a conclusion without retesting. The figure below shows this relationship: the baseline is a structured record, and the protocol change is mapped onto it clause by clause, with each mapping producing either a confident conclusion or a flagged gap.

The mapping is deliberately one-directional: the protocol change is projected onto the baseline, not the reverse. This keeps the baseline stable during the assessment and prevents the analysis from quietly redefining what the vehicle was in order to make the conclusion easier. When a clause maps to a flagged gap, the correct response is to schedule confirmation testing and record the assumption explicitly — not to substitute a result from an adjacent build level.

A well-constructed baseline therefore does more than document the past. It defines the confidence level of every future impact conclusion, identifies in advance where retesting will be unavoidable, and gives the program a defensible record if a compliance question arises after the change is implemented. The effort invested in freezing configuration data and tracing evidence to build levels is repaid the first time a protocol delta lands on a clause with a thin margin.