3. Anatomy of a pretest dummy certification record

A pretest dummy certification record is the controlled document that proves a test dummy was in a known, valid, and traceable condition immediately before a crash or sled test. It is not a single form filled in at the last minute; it is a structured evidence package whose fields, metadata, and format are designed so that an independent reviewer can reconstruct the dummy's identity, calibration state, channel configuration, and handling history without contacting the test engineer. This chapter dissects that package field by field, explains why each block exists, and shows how to assemble a record that survives a traceability review.

The record has three logical layers. The identity layer answers "which physical dummy is this?" The configuration layer answers "how was it instrumented and set up for this test?" The validity layer answers "was it within its certified window, and who confirmed that?" A record missing any layer may still look complete on paper but will fail when a reviewer tries to link a measured channel back to a calibrated sensor.

Required fields and why each one exists

The identity block is anchored by the dummy serial number. This is the only field that must be globally unique and permanent; everything else can be re-derived from it. In practice, a record that lists only "Hybrid III 50th percentile" is unusable, because a facility may own six such dummies and their certification windows differ. The serial number should be recorded exactly as stamped on the dummy's identification plate, including any prefix or suffix, and cross-referenced to the certification certificate number issued by the calibration laboratory. Sub-assembly identifiers matter because heads, thoraxes, and knees are often certified and swapped independently; a record that captures only the parent serial number cannot prove that the installed head was the certified one.

The configuration block is where most traceability failures originate. Each measurement channel must be tied to a specific sensor serial number, not merely to a location such as "upper neck Fx." A sensor can be moved between dummies, and a channel can be re-zeroed or re-ranged between tests. The record should therefore carry a channel table with at least: channel name, sensor serial, sensor type, full-scale range, engineering units, filter class, and the data acquisition channel number. The filter class deserves explicit attention because it changes the reported peak value; a neck Fz channel filtered at CFC 1000 and one filtered at CFC 600 are not interchangeable, and a reviewer comparing results across tests will reject a record that omits it.

The validity block converts the record from a description into an assertion. It must state the certification status as of the test date, not as of the day the record was created. A dummy certified on 12 March with a 12-month window is valid through 11 March of the following year; a test executed on 14 March is out of window even if the record was signed on 10 March. The record should therefore carry both the certification expiry date and the test execution date, and a computed days-remaining value. The inspector's name, signature, and a timestamp with timezone close the loop: they identify who asserted validity and when.

Metadata: the fields that make a record reviewable

Metadata is often confused with "extra fields," but in a certification record it is the set of attributes that allow the document to be managed, versioned, and linked. At minimum, a record should carry a document identifier, a revision number, a creation timestamp, an author, and a status (draft, approved, superseded). These attributes are what let a reviewer determine whether the record they are reading is the one that was in force on the test date. Without a revision number, two records for the same dummy and same test can coexist with different channel tables, and there is no principled way to decide which is authoritative.

Linkage metadata is equally important. The record should reference the test request or run identifier, the facility and test cell, the data acquisition system identifier, and any deviation or waiver document. If a sensor was replaced after certification but before the test, the record must reference the replacement authorization; otherwise the configuration block describes a dummy that no longer matches its certificate. A useful convention is to treat every external reference as a resolvable identifier rather than free text, so that a reviewer can follow the link without ambiguity.

Format specifications

Format specifications govern how the record is rendered and stored, and they exist because a record that cannot be parsed or compared is of limited value in a review. Three format decisions dominate practice. First, date and time format: use ISO 8601 with an explicit offset, for example 2025-03-14T09:22:00+01:00, rather than a locale-dependent form such as 03/14/25. Second, units and significant figures: state units explicitly in every column header and fix the number of decimal places so that values are comparable across records. Third, identifier conventions: define a consistent pattern for channel names and sensor serials, and apply it without exception.

A practical record format is a structured table set rather than a single free-form page. The following excerpt shows the channel table portion of a record in a form that can be stored as CSV or embedded in a controlled document:

record_id: DCR-2025-0142
revision: 2
dummy_serial: H3-50-0473
cert_certificate: CAL-2024-0881
cert_expiry: 2025-11-30
test_run_id: SLED-2025-0311-A
test_datetime: 2025-03-14T09:22:00+01:00

channel,sensor_serial,sensor_type,range,units,filter,daq_channel
NECK_FX,SN-88213,uniaxial_accel,±2000,N,CFC 1000,AI-07
NECK_FZ,SN-88214,uniaxial_accel,±2000,N,CFC 1000,AI-08
CHEST_AY,SN-77410,triaxial_accel,±500,g,CFC 180,AI-12
PELVIS_AX,SN-77411,triaxial_accel,±500,g,CFC 180,AI-15

Note that the record carries both the certification expiry and the test datetime, so the validity check is computable from the record itself. Note also that the filter class is a per-channel attribute, not a global setting, because different transducer types legitimately use different filter classes.

Common defects and how to catch them

Three defects account for most traceability findings. The first is a serial mismatch: the record lists a sensor serial that does not match the physical sensor installed on the dummy. This is caught by a physical verification step in which the inspector reads the serial from the sensor body and compares it to the record before signing. The second is a stale validity assertion: the record states "certified" without a date, or states a date that precedes the test. This is caught by requiring the expiry date and test date as separate fields and computing the difference. The third is an orphan channel: a channel appears in the data file but not in the record, or vice versa. This is caught by reconciling the record's channel list against the data acquisition system's active channel list before the test, not after.

When these three layers, their metadata, and their format rules are in place, the record becomes self-evidencing: a reviewer can move from a measured channel to a sensor serial, from the sensor serial to the dummy, from the dummy to its certificate, and from the certificate to the test date, without asking the test engineer a single question. That is the standard a pretest dummy certification record is expected to meet.