2. Injury metric fundamentals

Occupant injury metrics translate raw acceleration, force, and displacement signals into numbers that correlate with real-world injury risk. In a Python-based workflow, these metrics are the bridge between the time-history data produced by a crash simulation or a sled test and the pass/fail statements that appear in a final report. This section establishes what each metric physically represents, how it is computed, and where its biomechanical basis comes from. The goal is not to memorize formulas but to understand why each metric is shaped the way it is, so that later chapters on parsing, filtering, and reporting rest on a solid foundation.

Head Injury Criterion (HIC) and Its Time Windows

The Head Injury Criterion is the most widely cited head injury metric in automotive safety. It is defined as:

HIC = max over (t1, t2) of [ (t2 - t1) * ( (1/(t2-t1)) * integral(a(t) dt) )^2.5 ]

where a(t) is the resultant translational acceleration at the head center of gravity, expressed in g, and the integration runs from t1 to t2. The exponent 2.5 and the linear time weighting are empirical: they were fitted to experimental head-impact data to produce a quantity that scales with observed injury severity. The resultant acceleration is computed from the three orthogonal channels as sqrt(ax^2 + ay^2 + az^2), which means the metric is independent of head orientation — a deliberate simplification that makes HIC robust but also blind to rotational effects.

The time window is the critical parameter. HIC15 restricts the search to intervals no longer than 15 ms, while HIC36 allows up to 36 ms. The shorter window captures short-duration, high-magnitude pulses typical of hard contact with a stiff structure; the longer window captures longer, lower-magnitude events such as airbag ride-down. Because the formula rewards longer windows when acceleration is sustained, HIC36 is generally larger than HIC15 for the same signal. Regulatory and consumer programs specify which variant to use: FMVSS 208 and many NCAP protocols reference HIC15, while older or research-oriented criteria often cite HIC36. In Python, the practical implication is that the window length must be a configurable parameter, not a hard-coded constant, because the same acceleration trace can yield different pass/fail outcomes depending on which window is applied.

A subtle but important implementation detail is that the maximum is taken over all valid (t1, t2) pairs, not just the single peak. A naive peak-picking approach will under-report HIC. The standard approach is a sliding-window search: for each candidate start sample, extend the window up to the limit and track the maximum. This is computationally heavier but correct, and it is the reason HIC calculation is usually vectorized with cumulative integrals rather than written as a nested loop.

a3ms: The Three-Millisecond Clip Criterion

The a3ms criterion asks a different question: how long does acceleration stay above a threshold? It is defined as the maximum acceleration level that is not exceeded for more than 3 ms cumulatively. In practice, the metric is computed by finding the highest acceleration value such that the total time spent at or above that value does not exceed 3 ms. This is a duration-at-level metric, not an integral.

The biomechanical rationale is that sustained acceleration is more damaging than a brief spike of the same magnitude. A 60 g spike lasting 1 ms may be tolerable, but 60 g sustained for 5 ms is not. The 3 ms window was chosen because it approximates the duration over which the human body can tolerate high acceleration without cumulative injury. In Python, a3ms is typically computed by sorting the acceleration samples in descending order, accumulating their time durations, and finding the level at which the cumulative duration crosses 3 ms. The result is reported in g.

a3ms is applied to multiple body regions — head, chest, and pelvis — and the threshold differs by region. For the chest, a common limit is 60 g; for the head, 80 g. These are not universal constants but depend on the regulatory or consumer protocol in use, so the reporting layer must carry the threshold as metadata rather than assume a single value.

Nij: Normalized Neck Injury Criterion

Nij addresses neck injury, which is driven by a combination of axial force and bending moment. The criterion is:

Nij = Fz / Fzc + My / Myc

where Fz is the axial force (tension or compression) and My is the bending moment about the lateral axis. Fzc and Myc are critical values that depend on the direction of loading and the occupant size. The result is a dimensionless number; a value of 1.0 corresponds to the threshold of injury. Because tension and compression have different critical values, and because the sign of the moment matters, Nij is actually four separate criteria — tension-extension, tension-flexion, compression-extension, and compression-flexion — and the reported value is the maximum of the four.

The critical values are not constants. They are functions of the axial force itself, which makes Nij a coupled criterion: the moment tolerance decreases as axial force increases. In practice, this is handled by evaluating the criterion at each time step using the instantaneous force to look up the appropriate critical moment. A Python implementation therefore needs both the force and moment time histories, plus a table or function that maps force to critical moment. Getting the sign convention wrong here is a common source of error: the direction of positive Fz and My must be defined once and applied consistently across all channels.

Chest Deflection

Chest deflection measures the inward displacement of the sternum relative to the spine during impact. It is a direct measure of thoracic compression, which is the primary mechanism of rib fracture and internal organ injury. The metric is reported in millimeters, and the threshold is typically around 50–60 mm for a 50th-percentile male, though this scales with occupant size.

Unlike HIC and a3ms, chest deflection is not derived from acceleration. It comes from a displacement sensor or a computational measurement between two points in the model. In a simulation, this is often the relative displacement between a node on the sternum and a node on the spine. The sign convention matters: positive deflection usually means compression (inward), and the reported value is the peak compression, not the peak absolute displacement. A Python pipeline must therefore know which direction is compression and extract the maximum in that direction, not the maximum of the absolute value.

The biomechanical basis is straightforward: the chest can tolerate a certain amount of compression before ribs fracture. The threshold is age-dependent, which is why advanced reporting may apply scaling factors. For the purposes of this course, the key point is that chest deflection is a displacement metric with a directional sign, and it must be handled differently from the acceleration-based metrics.

How the Metrics Relate

These metrics are not independent. They are computed from overlapping signal sets and are often evaluated at the same time steps. A single crash event produces a head acceleration trace, a chest acceleration trace, a neck force/moment trace, and a chest deflection trace. Each metric extracts a different feature from its trace: HIC extracts a windowed integral, a3ms extracts a duration-at-level, Nij extracts a coupled force-moment ratio, and chest deflection extracts a directional peak. The reporting layer must keep these extractions separate and traceable, because a change in filtering or window length affects each metric differently.

Practical Implications for a Python Pipeline

Three implementation decisions follow directly from the material above. First, the time window for HIC must be a parameter, not a constant, because HIC15 and HIC36 are both required in different reporting contexts. Second, the sign conventions for neck force/moment and chest deflection must be defined once and documented, because a sign error silently produces a plausible but wrong number. Third, the filtering applied before metric calculation must be recorded alongside the result, because HIC and a3ms are sensitive to filter cut-off frequency, and a report that omits the filter specification is not reproducible.

A useful sanity check when implementing these metrics is to verify that HIC36 is greater than or equal to HIC15 for the same signal, that a3ms is less than or equal to the peak resultant acceleration, and that Nij is non-negative. If any of these fail, the most likely cause is a window-length error, a sign error, or a missing resultant calculation. These checks are cheap to implement and catch the majority of common mistakes before they reach a report.

The next section moves from the definitions to the data structures that carry these metrics through a Python pipeline, including how to represent time histories, how to attach metadata such as filter frequency and threshold values, and how to keep the calculation traceable from raw signal to final reported number.