1. Crash laboratory test request fundamenta

A crash laboratory test request is the formal instrument that converts a safety requirement into a scheduled, executable, and auditable physical test. It is not a calendar booking and it is not a purchase order. It is a controlled engineering record that defines what will be tested, against which specification, with which build state, and under which acceptance criteria. The moment a test request is accepted by the laboratory, the vehicle configuration it references must become traceable and, eventually, immutable. That immutability is what the industry calls configuration freeze.

Without a disciplined request process, three failure modes appear almost immediately. First, the article delivered to the sled or barrier differs from the one that was analysed, so the correlation between CAE and physical results collapses. Second, late engineering changes silently invalidate a test that has already been paid for. Third, results cannot be defended in a homologation or type-approval review because nobody can prove which parts, software calibrations, and sensor set were present at the moment of impact. The request lifecycle exists to prevent all three.

Why the Request Exists

The purpose of a crash test request can be decomposed into four concrete functions:

• Specification binding. The request binds a test to a regulation, an internal safety target, or a customer requirement — for example a frontal offset impact per a given regulatory procedure, or an internal pole test at a defined impact velocity.
• Resource reservation. It reserves sled time, barrier configuration, dummy inventory, high-speed camera channels, and personnel. These are scarce and expensive; a typical full-scale frontal facility may run only a handful of configurations per week.
• Configuration traceability. It records the exact build level — part numbers, change levels, restraint system variant, airbag calibration, seat position, and ballast — so that the tested article is reproducible.
• Evidence generation. It defines the data deliverables: accelerometer channels, dummy injury criteria, film coverage, and the post-test teardown record.

A useful mental model is that the request is the contract between engineering and the laboratory, and the frozen configuration is the notarised version of that contract.

Stakeholders and Their Actual Responsibilities

Crash test requests fail most often at organisational boundaries rather than at technical ones. Each stakeholder owns a distinct decision, and confusing those decisions is a common source of rework.

In practice the requester and the configuration owner carry the heaviest burden, because the freeze decision is a joint one: the requester asserts that the configuration is the one worth testing, and the configuration owner asserts that it is the one that actually exists in the build system.

The Lifecycle from Initiation to Freeze

The lifecycle is best understood as a sequence of gates, each of which converts uncertainty into a committed decision. The diagram below shows the flow and, more importantly, the two feedback loops that keep it honest.

Stage 1 — Request Initiation

Initiation begins with a test intent statement that must be answerable in one sentence: which safety question does this impact answer? A well-formed request contains the test type and procedure reference, the impact conditions (velocity, barrier or pole geometry, overlap percentage, impact angle), the target occupant or pedestrian population, the acceptance criteria, and the required data channels.

Consider a representative example. A body-structure team wants to validate a revised front bumper beam. The request might specify a frontal offset impact at 64 km/h with 40% overlap against a deformable barrier, two Hybrid III 50th percentile front occupants, and a target that the driver-side tibia index remains below 1.0 while the occupant compartment intrusion at the toe pan stays under 150 mm. These numbers are illustrative teaching values, not measured results, but they show the level of specificity required: a request that says "run a frontal test" cannot be scheduled, priced, or judged.

At this stage the requester also declares the configuration intent — the design release or change level that is expected to be tested. This is a declaration, not yet a commitment. It is deliberately allowed to change until the freeze gate.

Stage 2 — Feasibility and Scheduling

The laboratory coordinator checks whether the requested conditions are physically and procedurally achievable. Key checks include barrier type and mass, sled or full-scale capability, impact velocity tolerance, dummy availability and calibration status, camera count and frame rate, and whether the facility holds the required accreditation for the procedure. A common real-world constraint is dummy inventory: if only one calibrated THOR 50th percentile dummy is available and it is already committed to a side-impact campaign, the frontal request must move.

The output of this stage is a provisional slot with a lead time. Lead times of four to eight weeks are typical for full-scale facilities, and the request should record the slot identifier so that later changes can be traced to a specific reservation.

Stage 3 — Configuration Definition

This is where the request becomes engineering rather than administration. The configuration owner assembles the test article definition: the bill of materials at a specific change level, restraint system variant, airbag inflator and calibration identifiers, seat track position, steering column setting, fluid and fuel load, ballast mass, and the measured centre of gravity. Sensor and instrumentation lists are attached, including accelerometer locations and dummy channel assignments.

A practical discipline is to record the configuration as a set of immutable identifiers rather than descriptions. "Latest bumper beam" is not a configuration; a part number with a change letter is. The same applies to ECU software: a calibration part number and version string must be captured, because restraint deployment logic can change between calibrations without any visible hardware difference.

Stage 4 — The Freeze Review

The freeze review is the decisive gate. Its purpose is to confirm that the configuration defined in Stage 3 is the configuration that will actually be built and delivered, and that no pending engineering change will alter it before the test date. Participants typically include the requester, the configuration owner, the restraint system owner, and quality. The gate produces one of three outcomes: freeze approved, freeze approved with conditions (for example, a specific part must be verified at goods-in), or freeze rejected and returned to Stage 3.

Stage 5 — Article Release and Execution

After freeze, the build or retrofit of the test article proceeds against the frozen record. At goods-in, the configuration is verified against the freeze document — part numbers scanned, calibration read back from the ECU, ballast weighed, and the centre of gravity measured. Any discrepancy triggers a deviation before the article enters the test cell. The test itself then runs under the frozen instrumentation plan, and the laboratory records the actual conditions achieved: measured impact velocity, barrier alignment, and channel status.

Stage 6 — Results and Closure

Results are reduced against the acceptance criteria declared at initiation, and the report is linked back to the freeze record so that every number is traceable to a known configuration. Closure includes archiving the frozen configuration, the deviation log, and the raw data. If the test reveals a design issue, the correct response is a new request with a new revision — not an edit to the closed one. This preserves the audit trail that regulators and internal quality systems expect.

The lifecycle therefore has a clear logic: uncertainty is progressively reduced through Stages 1 to 3, committed at Stage 4, and only then converted into physical evidence. Understanding this sequence is the foundation for every subsequent topic in crash laboratory test management, because scheduling, cost control, and result validity all depend on the integrity of the freeze decision.