3. Test request intake

Test request intake is the point where an informal demand for crash testing becomes a controlled, auditable engineering record. Everything downstream — the configuration freeze, the sled or barrier setup, the instrumentation plan, the post-test correlation — depends on the accuracy of what is captured here. A request that arrives as "we need a 64 km/h ODB test on the new front end" is not yet a test request; it is an intention. Intake converts that intention into a structured dataset that the lab can schedule, cost, and execute without further interpretation.

The intake record has three interlocking layers: requirements (why the test exists and what must be demonstrated), vehicle build specifications (exactly which physical article will be tested and in what configuration), and test matrix parameters (the loading conditions, impactor types, and measurement channels). These layers must be captured together because they constrain each other. A requirement for Euro NCAP frontal assessment fixes the impactor and speed; the vehicle build determines mass and inertia; the matrix parameters then determine sled pulse or barrier alignment. Capturing them in isolation is the most common source of rework.

Layer 1 — Requirements capture

Requirements should be recorded as verifiable statements with an explicit source. Typical sources are a regulation (ECE R94, FMVSS 208), a consumer protocol (Euro NCAP, C-NCAP, IIHS), an internal durability or validation standard, or a development investigation such as a competitor benchmark. For each requirement, capture the source document and revision, the acceptance criterion, and the responsible engineer. A requirement without a revision identifier is a latent nonconformity: protocols are updated annually, and a test executed against the wrong protocol revision may be technically valid but commercially useless.

Distinguish mandatory requirements (type-approval, homologation) from informational ones (correlation data for CAE). This distinction drives instrumentation density and data delivery format, and it should be visible in the intake record rather than buried in an email thread.

Layer 2 — Vehicle build specification

The build specification is the identity card of the test article. At minimum it must pin down:

• VIN or build ID, plus the engineering change level of the body-in-white and closure panels.
• Kerb mass and measured test mass, with the ballast plan (location, mass, fixing method) and the target mass window from the protocol.
• Powertrain and fuel/battery state — for ICE vehicles, fuel fill level and displacement; for BEVs, state of charge and the high-voltage safety procedure reference.
• Restraint configuration — airbag variants, seat belt pretensioner/load limiter part numbers, seat position and H-point coordinates.
• Dummy set and seating positions, including dummy serial numbers and calibration due dates.
• Deviation log — any departure from series production, such as hand-built brackets or missing trim, recorded with its expected effect on the result.

The deviation log deserves emphasis. A hand-modified bumper beam may be acceptable for a development test but invalidates a homologation run. Recording deviations at intake, rather than discovering them during teardown, is what allows the lab to flag the test's evidentiary status before money is spent.

Layer 3 — Test matrix parameters

Matrix parameters define the loading. For a frontal ODB test the essential fields are impactor geometry (barrier face, honeycomb grade, overlap), impact speed with tolerance, impact angle, and the barrier-to-vehicle lateral offset. For side impact, add the moving deformable barrier mass, wheelbase, and impact point referenced to the vehicle coordinate system. For sled tests, the pulse table itself — acceleration versus time, with the tolerance corridor — is a matrix parameter and must be attached, not referenced.

Measurement channels belong here too. Specify channel count, sensor types (accelerometers, load cells, displacement), sampling rate, and the coordinate convention. State the convention explicitly: for this course, +X is forward along the vehicle longitudinal axis, +Y is to the driver's left, +Z is upward, with the origin at the vehicle datum defined in the build specification. Every sensor location and every reported result must use this convention consistently; a sign flip between intake and reporting is a classic correlation failure.

Worked intake example

Consider a development request for a frontal offset assessment of a mid-size SUV. The requirement source is an internal validation standard, revision C, with a mandatory acceptance criterion on occupant injury indices and an informational requirement for CAE correlation. The build specification records a measured test mass of 2,145 kg against a target window of 2,100–2,180 kg, ballast of 60 kg in the rear cargo area, and a deviation: prototype front bumper beam, 1.2 mm thinner than series. The matrix specifies a 64 ± 1 km/h impact, 40% overlap, deformable barrier per the standard's annex, and 42 channels at 20 kHz.

The intake engineer should immediately flag the thinner bumper beam: it changes the front-end stiffness and therefore the pulse, which affects both the injury outcome and the CAE correlation value. The correct action is not to reject the request but to annotate the record so that the result is interpreted as a prototype-configuration data point, not a series-representative one. This annotation is what the configuration freeze will later lock down.

Consistency checking before acceptance

Intake is complete only when the three layers agree. Run a short cross-check: does the requirement's protocol revision mandate the impactor and speed recorded in the matrix? Does the measured mass fall inside the protocol window, and if not, is the deviation documented? Does the channel plan cover every measurement the acceptance criterion references? Does the dummy set match the seating positions and the protocol's dummy specification? Each "no" is either a correction or a documented deviation — never a silent pass.

A practical failure mode illustrates the cost of skipping this step. A request specifies a 50 km/h frontal rigid barrier test but attaches a pulse table generated for a 64 km/h ODB condition. The mass and channel plan are correct, so the record looks complete. The sled is run, the pulse is applied, and the resulting occupant loads are lower than expected — not because the restraint system performed well, but because the loading was wrong. The root cause is traceable to intake: the pulse attachment was never checked against the stated impact condition. A single consistency question at intake would have caught it.

Deliverable: intake record template

The following field set is a workable minimum for a crash lab intake record. It is deliberately compact; extend it only where the protocol demands.

Once this record is approved, it becomes the input to the configuration freeze. The freeze does not re-derive the requirements or re-measure the vehicle; it locks the approved intake record and controls any subsequent change through a formal deviation process. That is why intake discipline matters disproportionately: every ambiguity left open here becomes a change request later, and every change request after freeze carries schedule and cost consequences.