2. Configuration freeze principles

A crash test program is only reproducible when the physical article, the test setup, and the data-processing chain are all pinned to the same, unambiguous state. Configuration freeze is the discipline that makes this possible. It is not a single approval signature at the end of build; it is a controlled transition from a moving configuration to a fixed, identified, and auditable one. This section explains the three pillars that support that transition: baseline definition, version control, and change management.

What "Frozen" Actually Means

Freezing a configuration means that every element that can influence the test result has been identified, recorded, and locked against uncontrolled modification. In a frontal offset impact test, that includes far more than the vehicle build level. It includes the restraint system calibration (airbag inflator lot, seat belt load limiter variant, pretensioner type), the dummy configuration (serial numbers, instrumentation channels, calibration due dates), the barrier and trolley setup, the camera and sensor placement, the ambient and dummy conditioning state, and the analysis settings used to filter and process the accelerometer data.

A useful mental model is that the frozen configuration is the set of all inputs to the test function. If two tests share the same frozen configuration, their results should be comparable within measurement uncertainty. If they do not, any difference in outcome is confounded and cannot be attributed to the design change under investigation.

Freeze scope should be defined by influence, not by convenience. A component that "probably doesn't matter" but appears in the test setup should still be recorded, because the cost of recording it is trivial compared with the cost of an unexplainable result.

Baseline Definition

The baseline is the reference configuration against which all subsequent tests, changes, and comparisons are measured. Defining it well is the foundation of the entire freeze process. A weak baseline — one that is described only as "vehicle build 7" — will produce ambiguity the moment a question arises about which seat foam or which software calibration was installed.

A practical baseline definition has three layers. The physical layer captures the as-built article: part numbers, serial numbers, supplier lots, and build date. The setup layer captures the test rig: barrier mass and face geometry, sled pulse file identifier, dummy serials and channel map, camera positions, and lighting. The data layer captures the processing configuration: filter class and cutoff, sampling rate, coordinate system convention, and the analysis script version.

Coordinate and sign conventions deserve explicit statement in the baseline, because they are a frequent source of silent error. For a vehicle-axis convention, define +X as forward, +Y as left, +Z as up, and state that accelerometer polarity follows the sensor mounting orientation. Once defined, the same convention must be used in the baseline record, the test request, and every figure in the report. Switching reference frames mid-program without a documented note is a configuration change in its own right.

The baseline should also record the tolerance around each parameter. A dummy mass tolerance of ±0.5 kg, a barrier speed tolerance of ±0.2 km/h, and a conditioning temperature window of 21 ± 3 °C are part of the frozen configuration, not afterthoughts. A test that falls outside tolerance is not a valid execution of the baseline and must be flagged.

Version Control

Version control turns the baseline from a snapshot into a traceable lineage. Every configuration state receives a unique identifier, and every change produces a new identifier with a recorded parent. The identifier scheme should be human-readable enough to survive outside a database: for example, CF-2024-017 for the seventeenth configuration freeze of the program year, with a revision suffix such as CF-2024-017-r2 for a controlled amendment.

The version-controlled record should be a single authoritative document or database entry, not a folder of loosely named spreadsheets. A minimal but complete record contains the freeze identifier, the parent identifier, the effective date, the list of controlled items with their values, the reason for the change from the parent, the approver, and the affected test requests. The following excerpt shows the structure of a controlled item entry in a machine-readable form:

freeze_id: CF-2024-017-r2
parent:    CF-2024-017
effective: 2024-06-11
items:
  - id: RESTRAINT-DAB-INFLATOR
    value: "supplier lot L24-0512, variant DAB-STD-02"
    tolerance: "lot traceability required"
  - id: DUMMY-DRIVER
    value: "Hybrid III 50th, serial H3-50-0117"
    tolerance: "calibration due 2024-09-30"
  - id: SLED-PULSE
    value: "pulse file FR-56kmh-A.pulse"
    tolerance: "delta-v 56.0 +/- 0.5 km/h"
  - id: DATA-FILTER
    value: "CFC 60, script proc_v3.2.py"
    tolerance: "n/a"
reason: "inflator lot change approved by supplier; no design change"
approver: "test program lead"
affected_requests: ["CTR-2024-041", "CTR-2024-044"]

Version control also applies to the test request itself. When a request references a freeze identifier, the request is bound to that configuration. If the freeze is later amended, the request must either be re-bound to the new revision or explicitly held to the original, and that decision must be recorded. This prevents the common failure where a test is executed against a configuration that has quietly moved on since the request was raised.

Change Management

Change management is the process that governs how a frozen configuration is allowed to move. The core principle is that no change takes effect on a test article or test setup without an approved, recorded decision. The process does not need to be heavy, but it must be closed-loop: request, impact assessment, approval, implementation, verification, and re-freeze.

An effective change request answers four questions. What exactly is changing, and from which freeze revision? Why is the change needed — is it a design update, a supplier substitution, a correction of an error, or a test-specific deviation? What is the impact on already-executed tests and on tests currently in the queue? And what verification will confirm that the change was implemented as approved?

Impact assessment is where most programs gain or lose value. A supplier lot change for an airbag inflator may look administrative, but if the inflator output varies with lot, previously executed tests are no longer strictly comparable to future ones. The assessment should classify the change as form-fit-function neutral, potentially result-affecting, or result-affecting, and the classification determines whether prior tests must be re-baselined or flagged in the report.

A change that is implemented on the test article but not reflected in the freeze record is worse than no freeze at all: it creates a false sense of control while the actual configuration drifts. Any deviation discovered after the fact must be recorded as a retroactive change with its own impact assessment, not silently corrected.

Test-specific deviations deserve separate treatment. Sometimes a single test must run with a deliberate departure from the baseline — for example, a dummy substitution because the primary unit is out for calibration. This should be handled as a scoped deviation tied to that request only, with the deviation documented in the test report and excluded from baseline comparability claims. The baseline itself is not amended; the deviation is an acknowledged exception.

How the Three Pillars Interlock

The three pillars are not independent procedures. The baseline defines what is controlled; version control records each controlled state and its lineage; change management governs the transitions between states. The figure below shows this relationship as a controlled state chain, with the freeze identifier as the anchor that binds test requests to a specific configuration.

Controlled Configuration State Chain Baseline CF-2024-017 physical / setup / data layers + tolerances Change Request what / why / impact classification approval + verification Re-freeze CF-2024-017-r2 parent recorded effective date set Rejected / deferred baseline unchanged Test Requests Bound to Freeze CTR-2024-041 → CF-2024-017 CTR-2024-044 → CF-2024-017-r2 re-binding decision recorded Scoped Deviation single-request exception documented in report baseline not amended

The chain makes the governance logic visible. A change request that is rejected or deferred leaves the baseline untouched, so no test request needs re-binding. An approved change produces a new revision with a recorded parent, and every affected request must be explicitly re-bound or held. A scoped deviation runs alongside the baseline without amending it, and its documentation obligation is carried into the test report.

Practical Failure Modes

Three failure modes recur in crash test programs. The first is baseline drift, where small undocumented substitutions accumulate until the "baseline" no longer describes the article being tested. The symptom is a test result that cannot be reconciled with earlier data despite no approved change. The remedy is periodic reconciliation between the freeze record and the as-built article, ideally at each build milestone.

The second is orphaned requests, where a test request references a freeze identifier that has since been superseded and no re-binding decision was made. The symptom appears at report review, when the configuration cited in the report does not match the configuration actually tested. The remedy is a binding check at request release and again at test execution.

The third is silent deviation, where a substitution is made on the test day and recorded only in a technician's note. The symptom is a result that is internally consistent but externally incomparable. The remedy is a mandatory deviation field in the test execution record, reviewed before the report is signed.

Configuration freeze is therefore best understood as a governance system rather than a document. The baseline defines the controlled state, version control preserves its lineage, and change management governs its movement. When all three operate together, a crash test result carries a defensible claim: this outcome belongs to this identified configuration, and any comparison to another result is made on a known and recorded basis.

← Previous 📖 Contents Next →