3. Vehicle selection and configuration eligibility

In NCAP programmes, eligibility is assessed per test item and per configuration, not per vehicle nameplate. A model that appears in a brochure as a single product line may contain dozens of build combinations, and the rating authority will only accept evidence for the specific configurations that were actually tested or that can be demonstrably carried over. The selection and configuration eligibility check therefore has three linked jobs: prove that the tested vehicle represents the market, prove that untested variants legitimately inherit the tested result, and prove that every configuration-specific requirement (powertrain, seating, safety equipment, software level) is covered by evidence. Getting this wrong is one of the most common causes of a rating being refused, restricted, or annotated with a caveat.

Market representation: what "the market" actually means

Market representation is the argument that the vehicle submitted for testing is the one that customers in the target market will actually buy. It is not enough that the vehicle is available; the programme expects the tested configuration to reflect the dominant or declared sales mix, and to be representative of the safety-relevant hardware fitted to that mix. In practice, the check involves four concrete questions.

  • Market and model year. Which market(s) does the rating cover, and for which model year or production period? A rating issued for one market does not automatically transfer to another where the specification, homologation basis, or standard equipment differs.
  • Sales-mix justification. Is the tested configuration a mainstream volume variant, or a low-volume flagship? Programmes typically require the tested variant to represent a declared proportion of sales, or to be the configuration most likely to be purchased. A fully loaded trim with every optional safety pack fitted may not represent the base vehicle that most buyers receive.
  • Standard vs optional equipment. Safety features that are optional in the market cannot be assumed present on the tested vehicle unless the programme's rules treat them as standard for the rating. The evidence must state, feature by feature, whether each item is standard, optional, or part of a pack, and on which trims.
  • Production conformity. The tested vehicle must be a production-representative build, not a pre-production prototype with non-final calibration, unless the programme explicitly permits prototype testing with a conformity plan.
A useful discipline is to write the market-representation statement as a single defensible sentence before any testing begins: "The tested vehicle is a [trim], [powertrain], [drive], [seating], model year [MY], sold in [market], representing [X]% of that model's sales mix, with [feature list] fitted as standard." If that sentence cannot be completed with evidence, the configuration is not yet eligible.

Variant carryover: the rules that decide inheritance

Variant carryover is the mechanism by which an untested variant inherits the test result of a tested "parent" configuration. It is powerful but narrow. Carryover is normally permitted only when the untested variant is not less favourable than the tested one in the attributes that the test measures. The practical test is a structured comparison across the attributes that matter for each test item, not a general similarity judgement.

For frontal impact, the relevant attributes typically include: body-in-white structure and front-end geometry, restraint system hardware and calibration, seat structure and mounting, airbag fitment and deployment strategy, steering column and pedal assembly, and the presence of any structural reinforcement or battery pack that changes mass and stiffness. For side impact, add door structure, side airbag/curtain fitment, seat-mounted vs door-mounted side airbags, and battery pack side structure. For pedestrian protection, add bonnet geometry, active bonnet fitment, and front-end styling. For active safety items, the relevant attributes are sensor set, sensor mounting position and field of view, software/calibration version, and the presence of the function as standard equipment.

The carryover argument must be documented as a comparison table with a verdict per attribute. A variant that is heavier than the tested parent, or that has a different restraint calibration, or that deletes a side airbag, generally cannot carry over without additional testing or a formal engineering justification accepted by the programme. A variant that is lighter, or that adds structure, may still require testing if the change alters the load path in a way the parent test did not exercise.

Attribute Tested parent Candidate variant Carryover verdict
Kerb mass 1,620 kg 1,705 kg (+85 kg) Not less favourable — requires justification or test
Front structure Baseline BIW Identical BIW, different bumper fascia Acceptable (cosmetic only)
Restraint calibration Calibration A Calibration A Acceptable
Side curtain airbag Fitted, row 1–2 Fitted, row 1–2 Acceptable
Seat structure Standard seat Sport seat, different frame Not acceptable without test

The table above is an illustrative example, not a real dataset. Its purpose is to show the granularity the programme expects: each row is a claim that must be backed by a drawing, a bill of materials, a calibration record, or a test report.

Configuration-specific evidence requirements

Once the tested configuration and the carryover set are defined, the evidence pack must map every configuration-specific requirement to a document. The mapping is the heart of the eligibility check, because a rating is only as strong as the weakest configuration it claims to cover. The evidence categories that recur across programmes are:

  1. Build and specification evidence. VIN or build record for the tested vehicle, trim and option codes, standard/optional feature matrix, and a signed statement of the sales mix.
  2. Hardware evidence. Restraint system component list with part numbers, airbag and pretensioner fitment, seat and head-restraint specification, and any structural differences between parent and carryover variants.
  3. Software and calibration evidence. Software version and calibration identifier for each ECU that affects the tested function, plus a change-control statement confirming that the tested calibration is the production calibration.
  4. Test evidence. The test report itself, with the configuration recorded in the report matching the configuration claimed in the eligibility submission. A mismatch between the report's recorded build and the claimed build is a common and avoidable failure.
  5. Carryover justification. The comparison table, engineering rationale, and any supporting analysis or additional test data for variants that are not identical to the parent.
Do not treat the eligibility pack as a paperwork exercise completed after testing. The configuration must be locked before the test, because the test report records the build that was actually tested. If the build changes after the test — a calibration update, a supplier change, a seat frame revision — the carryover argument must be re-run, and in some cases the test must be repeated. Late configuration changes are the single most frequent cause of evidence packs being rejected at review.

Putting the check into practice

A workable sequence is to freeze the configuration matrix first, then test, then build the carryover set, then assemble the evidence map. In the configuration matrix, list every combination of powertrain, drive, seating, trim, and safety pack that will be sold in the target market, and mark which combinations are volume-relevant. Select the tested configuration from the volume-relevant set, preferring the least favourable combination within that set for the attributes the test measures. Then, for each remaining combination, run the attribute comparison and record a verdict. Finally, build the evidence map as a two-column list: requirement on the left, document reference on the right, with a named owner and a status. Any row without a document reference is an open eligibility risk, and should be closed before submission rather than explained afterwards.

Configuration eligibility decision map A decision map showing how a vehicle configuration moves from the market matrix through market representation, variant carryover comparison, and configuration-specific evidence mapping to an eligible or ineligible rating claim. From configuration matrix to eligible rating claim 1. Configuration matrix powertrain × drive × seating × trim × safety pack mark volume-relevant builds 2. Market representation market + model year declared sales-mix share justified standard vs optional stated 3. Variant carryover attribute-by-attribute compare mass, structure, restraints, calibration, sensors Not less favourable? Test variant or exclude from the rating claim No Yes 4. Evidence map build · hardware · software test report · carryover file one document per requirement 5. Rating claim tested config + carryover set each with closed evidence open rows = eligibility risk Late build or calibration change → re-run carryover and re-validate the evidence map accepted path rejected / test required change-control loop

The map above is the working logic of the eligibility check, not a substitute for the programme's rulebook. Its value is that it forces the three questions to be answered in order: is the tested vehicle representative of the market, does each untested variant legitimately inherit the result, and is every configuration-specific requirement backed by a document. When all three answers are yes, the rating claim is defensible; when any answer is no, the configuration should be tested, excluded, or explicitly caveated before submission.

← Previous 📖 Contents Next →