4. Vehicle categorization and fleet segmentation

Frontal crash configuration selection is only meaningful when it is applied to a defensible vehicle population. Before any barrier type, impact speed, or overlap percentage is chosen, the safety program must decide which vehicles the configuration is meant to represent. A single "representative vehicle" is rarely sufficient: a fleet typically spans several mass classes, body styles, and structural architectures, and each of these dimensions changes how a frontal impact loads the occupant compartment. Vehicle categorization is therefore the first analytical step in configuration selection — it converts a heterogeneous fleet into a small number of internally consistent groups, each of which can be assigned a crash configuration that is technically appropriate and programmatically justifiable.

Three Segmentation Axes: Mass, Geometry, and Structural Architecture

Mass is the most consequential axis because it governs momentum exchange in two-vehicle collisions and the kinetic energy that must be managed in a fixed-barrier test. A practical segmentation uses curb mass bands rather than individual models. For a typical passenger-car and light-truck program, bands of roughly 200–250 kg are workable: for example, <1,200 kg (A-segment / mini), 1,200–1,450 kg (B-segment), 1,450–1,700 kg (C-segment), 1,700–2,000 kg (D-segment / compact SUV), 2,000–2,500 kg (mid-size SUV / pickup), and >2,500 kg (full-size body-on-frame). The exact cut points should be set from the actual fleet distribution — a histogram of curb mass by model-year sales volume — so that each band contains enough volume to be programmatically relevant and enough internal homogeneity to be technically meaningful.

Geometry captures what mass alone cannot: bumper height, hood line, and the vertical alignment of the primary load paths. Two vehicles of similar mass but different front-end geometry interact very differently in a car-to-car impact. Geometry segmentation should record at minimum: bumper beam height above ground (measured at the center and at the corners), hood leading-edge height, and the vertical position of the longitudinal rails. These values determine whether a configuration pair will produce underride, override, or well-aligned engagement.

Structural architecture is the axis most often under-specified in early program planning, yet it drives the validity of any CAE or physical test result. At minimum, distinguish:

  • Unibody passenger car — body-in-white carries the load; rails and shotgun/upper load paths are continuous with the cowl and A-pillar.
  • Unibody crossover/SUV — similar topology but with a raised ride height, taller front structure, and often a subframe-mounted powertrain.
  • Body-on-frame (BoF) light truck — separate ladder frame; the frame rails, not the body, are the primary crash load path, and the body mounts introduce a compliance that changes the deceleration pulse.
  • Battery-electric (BEV) platform — a skateboard or dedicated EV architecture with a front subframe, no engine block, and a structural battery enclosure that alters front-end crush length and mass distribution.

These four categories are not interchangeable for configuration selection. A 2,100 kg BoF pickup and a 2,100 kg unibody SUV may fall in the same mass band, but their frontal stiffness, load-path height, and pulse shape differ enough that a single barrier configuration cannot credibly represent both.

Building the Segmentation Matrix

The three axes are combined into a segmentation matrix. Each cell represents a vehicle group that will receive its own configuration decision. In practice, the matrix is populated from a fleet database containing, per model-year and body style: curb mass, wheelbase, track width, bumper height, hood height, rail height, architecture type, and projected sales volume. The matrix is then pruned: cells with negligible volume are merged into the nearest technically compatible group, and cells that are technically distinct but low-volume are retained only if they are required by regulation or by a known field-performance concern.

A worked example makes the process concrete. Suppose a program's fleet database yields the following simplified distribution (values are illustrative, not measured):

Group Mass band (kg) Architecture Bumper height (mm) Share of fleet
G11,200–1,450Unibody car48022%
G21,450–1,700Unibody car50028%
G31,700–2,000Unibody SUV56024%
G42,000–2,500BoF pickup62018%
G51,700–2,000BEV crossover5408%

G3 and G5 share a mass band but differ in architecture and bumper height; they must remain separate because the BEV's front structure and mass distribution produce a different pulse. G1 and G2 are both unibody cars and could in principle be merged, but the 250 kg difference and 20 mm bumper-height offset are large enough that a single configuration would under-represent the lighter group's compatibility risk. The matrix therefore retains five groups, each of which will be assigned a configuration in the next stage of the program.

From Groups to Configuration Decisions

Once the groups are defined, each group is mapped to a configuration set. The mapping is not one-to-one: a group may require a full-overlap rigid-barrier test for restraint validation, an offset deformable-barrier test for structural compatibility, and a car-to-car or MPDB (mobile progressive deformable barrier) test to represent its interaction with the rest of the fleet. The segmentation matrix tells the program which groups need which configurations, and — critically — which groups can share a configuration without invalidating the result.

The figure below shows the segmentation logic as a decision structure: fleet data flows into the three axes, the axes combine into groups, and each group resolves to a configuration set. The key visual point is that mass alone does not determine the group; architecture and geometry act as qualifiers that can split a mass band.

Fleet segmentation logic for frontal crash configuration selection Fleet data is segmented along mass, geometry, and structural architecture axes, combined into vehicle groups, and each group is mapped to a configuration set. Fleet database curb mass · wheelbase bumper/hood/rail height architecture · sales volume Mass axis 200–250 kg bands Geometry axis bumper · hood · rail height Architecture axis unibody · BoF · BEV Segmentation matrix prune low-volume cells merge compatible groups G1 · G2 unibody cars G3 unibody SUV G4 BoF pickup G5 BEV crossover Configuration set per group Full-overlap rigid restraint validation 50 km/h Offset deformable structural compatibility 40% overlap MPDB / car-to-car fleet interaction mass-paired Mass bands define candidate groups; geometry and architecture qualify or split them before configuration assignment.

Practical Checks and Common Failure Modes

Segmentation errors are usually silent: they do not produce a failed test, they produce a test that passes while representing the wrong population. Three checks catch most of them. First, verify that every group's mass band is populated from actual curb-mass data, not from marketing segment labels — a "compact SUV" can span 300 kg across model years. Second, verify that geometry values are measured at a defined reference (typically unladen, at the bumper beam centerline) and recorded with the measurement method, because bumper height varies with loading and with optional equipment. Third, verify that architecture classification is based on the load-path structure, not on the body style name: a unibody crossover and a BoF SUV can share a silhouette but not a crash pulse.

A frequent failure is merging a BEV group into its mass-equivalent ICE group because the two share a body style. The BEV's missing engine block, different front crush length, and lower center of mass change both the pulse and the compatibility behavior; the merged group will under-test the BEV and over-generalize the result.

When a group is found to be internally inconsistent — for example, a bimodal distribution of bumper heights within one mass band — the correct response is to split the group and re-run the configuration mapping, not to average the geometry. Averaging produces a configuration that fits neither sub-population. The segmentation matrix should be treated as a living artifact: it is revised whenever the fleet database is updated, and each revision should record which groups changed, why, and which configuration decisions were re-opened as a result.

Record the segmentation rationale alongside the matrix: for each group, note the mass band source, the geometry measurement reference, the architecture classification rule, and the volume threshold used for pruning. This makes the configuration selection auditable and reproducible when the fleet changes in a later model year.

The output of this stage is a documented set of vehicle groups, each with a defined mass range, geometry envelope, architecture class, and fleet share, plus a mapping from each group to the configuration set it requires. That mapping is the input to the next stage of the program, where the specific barrier, speed, and overlap parameters are selected and validated.