2. Crash test event timeline

Every crash test produces a single physical event, but the measurement systems observing it do not share a single clock by default. The onboard data acquisition system, the high-speed video cameras, the off-board photometric grid, the sled or barrier instrumentation, and any external labs each run on their own timebase. Synchronization is the discipline of making those independent timebases agree closely enough that a reviewer can align a frame of video with a channel sample and trust the pairing. Before any of that can be engineered, the team must agree on a shared definition of the event timeline itself.

The crash event timeline is conventionally divided into three regions relative to a defined trigger point: the pre-trigger window, the trigger point itself, and the post-trigger window. The trigger point is a single instant chosen as the reference origin, usually denoted t = 0. It is not necessarily the moment of first contact; it is whatever event the test plan designates as the reference, and that choice must be documented because every other timestamp is expressed relative to it.

Defining the three windows

The pre-trigger window captures the approach phase: vehicle or sled motion before impact, restraint system arming, and any events that establish initial conditions. Its length is set by what the test objectives require to be observable. A frontal rigid-barrier test at 56 km/h may only need 100–200 ms of pre-trigger to confirm approach velocity and bumper-to-barrier gap, while a rollover or a pedestrian-protection test may need substantially more to capture the full approach and any pre-impact braking or steering input.

The trigger point is the reference instant. Common choices include barrier contact sensed by a contact switch or accelerometer threshold crossing, a light curtain break, a breakwire, or an optical gate. The trigger source must be physically unambiguous and repeatable; a threshold crossing on a bumper accelerometer, for example, depends on the threshold value and the filter applied, so both must be specified. The trigger signal is typically distributed as a hardware pulse to every recorder so that all systems latch the same electrical event.

The post-trigger window must extend far enough to capture the complete response: occupant kinematics, airbag deployment and deflation, structural deformation, rebound, and any secondary contacts. For a 56 km/h frontal test, a 250–300 ms post-trigger record is typical; for a side impact or a far-side occupant study, longer windows may be needed to observe the full excursion and rebound.

A useful rule of thumb: size each window from the physics you must observe, then add margin for trigger latency and clock drift. Never size a window to the nominal event duration alone — the trigger may fire late relative to first contact, and drift accumulates across the record.

How test objectives drive synchronization requirements

Synchronization tolerance is not a single number applied uniformly. It is derived from the finest time resolution the test objectives demand. If the objective is to correlate an airbag deployment frame with the accelerometer channel that shows the firing command, the required alignment accuracy is on the order of one video frame period — at 1,000 fps, that is 1 ms. If the objective is only to confirm that the vehicle was moving forward at impact, 10 ms alignment is more than adequate. The requirement should therefore be stated per measurement pair, not per test.

A practical derivation proceeds in three steps. First, identify the fastest physical phenomenon that must be resolved — for example, a 5 ms airbag firing delay or a 2 ms belt-load-limiter slip. Second, set the synchronization tolerance to a fraction of that phenomenon, typically one-quarter to one-half, so that timing error cannot masquerade as a physical effect. Third, verify that every recorder's sample rate and clock stability can hold that tolerance across the full record length. A system sampling at 10 kHz has 0.1 ms resolution, but if its internal clock drifts by 50 ppm, a 1 s record accumulates 50 µs of drift — acceptable for a 1 ms tolerance, marginal for a 0.2 ms tolerance.

Crash test event timeline with pre-trigger, trigger point, and post-trigger windows A horizontal timeline showing the pre-trigger window, the trigger point at t=0, and the post-trigger window, with representative events and the synchronization tolerance derived from the fastest phenomenon. Pre-trigger window approach, arming, initial conditions Post-trigger window deployment, kinematics, deformation, rebound t Trigger point (t = 0) contact switch / threshold crossing −200 ms −100 ms +100 ms +200 ms +300 ms arming airbag fire peak decel rebound Synchronization tolerance derivation: fastest phenomenon (e.g., 5 ms airbag firing delay) ÷ 4 → tolerance ≈ 1.25 ms → verify sample rate and clock drift hold it across the full record

Worked example: deriving a tolerance budget

Consider a 64 km/h offset deformable barrier test with the following objectives: (1) correlate airbag deployment timing with the firing command channel, (2) measure occupant head excursion against the A-pillar, and (3) confirm approach velocity. The fastest phenomenon is the airbag firing delay, assumed here as an example value of 5 ms. Applying the one-quarter rule gives a target tolerance of about 1.25 ms. The video system runs at 1,000 fps (1 ms frame period), so frame-to-channel alignment must be within one frame. The onboard DAQ samples at 20 kHz (0.05 ms) with a 20 ppm clock, giving 20 µs drift over a 1 s record — well inside budget. The off-board photogrammetry system, however, may run on a separate clock with 100 ppm drift, contributing 100 µs over the same record; still acceptable, but the team should log the drift and, if the record is extended to 2 s, re-check the budget.

This is the essential discipline: the timeline is defined first, the objectives are mapped to the fastest phenomenon, the tolerance is derived as a fraction of that phenomenon, and each recorder is then checked against the budget. When a system cannot meet the budget, the fix is either a shorter record, a better clock, or a hardware trigger distribution that removes the need to rely on free-running clocks at all.

Common failure symptoms and their diagnosis

When synchronization is marginal, the symptoms are usually subtle. A video frame that appears to show the airbag already inflated before the firing command channel rises suggests the camera clock is running ahead of the DAQ clock. A channel that shows peak deceleration earlier than the corresponding video frame suggests the opposite. The diagnostic approach is to inject a common electrical pulse — a sync marker — into every recorder at a known instant and compare the recorded timestamps. If the markers land within tolerance, the free-running clocks are adequate; if they drift apart across the record, the drift rate is measurable and can be compensated or the record shortened. This marker-based check should be part of every test setup, not an afterthought.

Do not assume that a shared trigger pulse guarantees shared time. The pulse aligns the start of recording, but each recorder's internal clock continues to free-run afterward. Alignment at t = 0 does not prevent drift at t = 300 ms. Always verify drift with a second marker near the end of the record.

The timeline definition and the tolerance budget are the foundation on which every later synchronization decision rests. Once the windows, the trigger source, and the per-pair tolerance are documented, the choice of trigger distribution hardware, the sample rates, and the post-test alignment procedure all follow from them rather than being chosen by habit.

← Previous 📖 Contents Next →