2. Crash test data sources and formats

A crash test produces a heterogeneous bundle of measurements, and a recalculation or audit is only as trustworthy as the provenance of that bundle. Before any score is recomputed, the analyst must be able to answer three questions for every channel: where did the number originate, in what physical unit and coordinate convention is it expressed, and which metadata ties it to a specific test, vehicle build, and sensor installation. This section maps the four primary data families — accelerometer channels, load cell data, high-speed video, and facility metadata schemas — and shows how to read them so that downstream recalculation is defensible.

Accelerometer channels

Accelerometers are the backbone of occupant and vehicle response metrics. In a typical frontal barrier test, the facility records biaxial or triaxial accelerometers on the vehicle body (B-pillar, sill, tunnel, rear floor), on the crash sled or barrier face, and on the dummy (head, chest, pelvis). Each channel is stored as a time series sampled at a fixed rate, commonly 10 kHz to 20 kHz for vehicle channels and up to 20 kHz for dummy channels, with anti-alias filtering applied before digitization.

The critical format details are the sign convention and the coordinate system. Facilities generally follow SAE J211/1 conventions: the vehicle longitudinal axis is +X forward, +Y to the right, +Z downward, and acceleration is reported in g with the sign of the measured acceleration vector. A deceleration during a frontal impact therefore appears as a negative X value. Recalculation code that assumes the opposite sign will invert every injury metric. Always confirm the convention from the channel metadata rather than from the channel name alone, because names such as ACC_BPIL_X are facility-specific.

Channels also carry calibration and filter metadata. A raw channel may be delivered unfiltered, while the scored channel is filtered per SAE J211 Channel Frequency Class (CFC). For example, CFC 60 is standard for chest acceleration and CFC 180 for head acceleration in many protocols. The audit trail must record which filter class was applied and whether the delivered file is pre-filtered or requires the analyst to apply the filter. Applying CFC 60 twice silently attenuates peaks and understates injury criteria.

Load cell data

Load cells appear in two distinct roles. First, barrier or wall load cells measure the reaction force transmitted through the barrier face, often as an array of cells summed into a total force curve. Second, seat belt load cells and steering column load cells measure restraint forces on the occupant. Units are typically newtons or kilonewtons, sampled at the same rate as accelerometers, and the sign indicates tension versus compression.

Load cell data is more sensitive to zero-offset and drift than acceleration data. Facilities usually provide a pre-trigger baseline window (for example, 100 ms before T0) that the analyst can use to verify the zero offset. A nonzero pre-trigger mean on a belt load cell is a red flag: it may indicate a preloaded belt, a sensor offset, or a channel that was re-zeroed incorrectly. The recalculation should document the baseline window and the offset correction applied, if any. Barrier load cell arrays additionally require a summation rule — whether the total force is the arithmetic sum of all cells or a subset — and that rule belongs in the metadata, not in an undocumented spreadsheet formula.

High-speed video

Video is not a scored channel, but it is the primary evidence for validating that the test matched the intended configuration and for resolving anomalies in the numeric data. Facilities deliver high-speed footage at 500–1000 fps for occupant kinematics and 1000–2000 fps for barrier and deformation views, typically as H.264 or ProRes files with a sidecar file listing camera position, frame rate, and the frame number corresponding to T0.

For audit purposes, the essential metadata are the frame rate, the T0 frame index, and the synchronization source. If the video time base is derived from the same trigger as the data acquisition system, frame-to-sample alignment is straightforward. If it is independent, the analyst must record the synchronization method (clapper, flash, or trigger pulse) and the residual offset. A common audit finding is a video whose T0 frame is off by several frames relative to the data, which makes a visual "peak" appear to disagree with the acceleration peak. That discrepancy is a synchronization issue, not a data error, and the audit trail should say so explicitly.

Metadata schemas from test facilities

Every facility wraps its channels in a metadata schema. Common formats include the ISO MME (Measurement Data Format, .mf4) with channel groups and comments, DIAdem .dat/.tdm files, and vendor-specific ASCII or binary exports accompanied by a test report. The schema typically carries the test ID, date, facility, vehicle configuration, dummy serial numbers, sensor serial numbers and calibration dates, channel units, sample rates, and filter settings.

The practical rule is to treat the metadata file as the authoritative source and the channel names as convenience labels. When a facility delivers a .mf4 file, the channel group comments often contain the calibration factor and the physical quantity; when it delivers a CSV, the header row may omit units entirely. In the latter case, the accompanying test report or the facility's channel list must be attached to the audit package. A recalculation that cannot cite the unit and calibration source for a channel is not auditable.

Reading the data bundle as a whole

The figure below shows how the four data families relate to a single test record and where the audit-relevant metadata attaches. The point is not that the families are sequential, but that they share a common time base and a common test identity, and that each carries its own provenance fields.

Practical verification before recalculation

A short, repeatable check catches most provenance defects before they contaminate a score. Load the metadata file and confirm that every scored channel has a unit, a sample rate, and a calibration reference. Plot the pre-trigger window for each load cell and confirm the mean is near zero. Compare the acceleration channel's first significant deflection against the video T0 frame; a mismatch of more than a few milliseconds warrants a synchronization note. Finally, confirm that the delivered acceleration channels are either raw or filtered at the documented CFC, and record which. These four checks take minutes and produce the evidence that the audit trail needs.

When a defect is found — a missing unit, a nonzero baseline, a video offset — the correct response is to document it and, where the facility can supply a corrected export, request one. Recalculation should proceed only on data whose provenance is recorded, because the audit trail is ultimately a claim that every number in the score can be traced back to a sensor, a calibration, and a test identity.