2. Anatomy of a crash test anomaly report

A crash test anomaly report is not a narrative of what went wrong; it is a controlled technical record that allows an independent reviewer to reconstruct the event, verify the evidence, and decide whether the test result is admissible. Its purpose is threefold: to preserve the integrity of the test data, to isolate the anomaly from the underlying vehicle or restraint performance, and to provide a defensible basis for a retest decision. Understanding the anatomy of this document is therefore a prerequisite for writing one that survives scrutiny by a homologation authority, a test laboratory quality auditor, or an internal engineering review board.

The report sits at the intersection of three evidence streams: the test facility log, the onboard and offboard measurement channels, and the post-test inspection record. A well-structured anomaly report makes the relationship between these streams explicit, so that any conclusion can be traced back to a specific sensor, a specific timestamp, or a specific physical observation. The diagram below shows the canonical structure of the report and how each section draws on and feeds the others.

Identification and Scope

The opening section establishes the report's identity and its boundaries. It must contain the test identifier, the regulatory or internal standard under which the test was conducted (for example, a frontal offset impact per a specific regulation clause), the vehicle build level and configuration, the test facility, and the date of the run. Crucially, it also states the anomaly classification — whether the anomaly is a facility fault, an instrumentation fault, a test-article fault, or an indeterminate event. This classification is not cosmetic: it determines which downstream sections carry the burden of proof and which corrective actions are plausible.

A common failure in this section is ambiguity about the test article. If the report does not pin the exact build level, restraint configuration, and dummy instrumentation package, a reviewer cannot determine whether a retest would reproduce the same conditions. The identification block should therefore be treated as a configuration record, not a title page.

Observed Anomaly

This section describes what was seen, heard, or measured, without yet interpreting it. The discipline here is to separate observation from inference. A statement such as "the driver airbag deployed late" is an inference; the observation is "the driver airbag break-out time recorded on the high-speed video was 42 ms after trigger, against a nominal 18–25 ms window for this configuration." The report should give the timestamp, the channel or camera, the expected value or range, and the magnitude of deviation.

Where multiple symptoms appear, they should be listed in the order they were detected, with cross-references to the evidence section. This ordering matters because it often reveals causality: a power interruption at 15 ms may explain a cluster of channel dropouts that appear later in the log.

Evidence and Data

The evidence section is the evidential core of the report. It should include time-history plots for the affected channels, selected high-speed video frames with frame numbers and timestamps, raw sample excerpts where filtering or saturation is suspected, and the calibration status of the instruments involved. Each figure or table must carry a caption that states what it shows and why it is included.

For a channel dropout, for example, the report might present the raw voltage trace alongside the filtered acceleration trace, showing that the signal rail saturates at the amplifier limit before the dropout. This distinguishes an instrumentation saturation event from a genuine loss of power. The evidence section should also record the data-processing chain: sample rate, anti-alias filter type and cutoff, and any resampling applied before analysis. Without this, a reviewer cannot tell whether an apparent anomaly is an artifact of processing.

Root-Cause Analysis

Root-cause analysis converts evidence into a defensible causal statement. A fault tree is the standard tool: the top event is the observed anomaly, and the branches enumerate the possible contributing causes — sensor failure, harness damage, data-acquisition fault, test-article defect, procedural error, or environmental factor. Each branch is then marked as confirmed, excluded, or indeterminate on the basis of the evidence presented.

The report should state the confidence level of the conclusion explicitly. A confirmed cause requires direct evidence, such as a broken harness found in post-test inspection or a calibration record showing an out-of-tolerance sensor. An indeterminate cause is acceptable in a well-written report, provided the report explains what additional evidence would resolve it and why that evidence is unavailable.

Impact and Validity Statement

This section answers the question that matters most to the decision-maker: does the anomaly invalidate the test result? The report should identify which measurement channels and which performance criteria are affected, and whether the affected data can be reconstructed or substituted. If the anomaly affects a channel that is not used in the pass/fail assessment, the test may remain valid with a documented caveat. If it affects a channel that is central to the assessment, the test is invalid for that criterion.

The validity statement should be phrased as a clear proposition, for example: "The test is valid for the chest deflection criterion but invalid for the head injury criterion, because the head accelerometer channel saturated at 8 ms." This precision allows the retest decision to be scoped rather than all-or-nothing.

Recommendation

The final section converts the analysis into an action. It should state whether a retest is recommended, and if so, what must change before the retest: instrument repair, harness rerouting, procedure revision, or test-article modification. It should also specify the acceptance criteria for the retest and the disposition of the current test data — whether it is retained as informative, archived as invalid, or used for partial assessment.

A practical recommendation is often accompanied by a short corrective-action table. The table below illustrates the level of specificity expected; the entries are illustrative examples, not results from an actual test campaign.

What Distinguishes a Strong Report

The strongest anomaly reports share three characteristics. First, every claim is traceable to a named evidence item, whether a plot, a video frame, a calibration record, or an inspection photograph. Second, observation and interpretation are kept in separate sections, so a reviewer can disagree with the conclusion without having to distrust the data. Third, the recommendation is scoped and verifiable: it says what will be done, who will do it, and how the fix will be confirmed before the retest.

Conversely, the most common weaknesses are vague symptom descriptions, missing calibration context, and recommendations that amount to "retest and see." Each of these shifts the analytical burden onto the reviewer and weakens the credibility of the retest decision. Treating the report as an evidence chain rather than a narrative is the single most effective way to avoid them.