2. CAE injury reporting fundamentals

An automated injury-report pipeline is only as trustworthy as the definitions it encodes. Before a single line of Python is written, the engineer must decide which physical quantity represents injury, which regulatory or consumer-test protocol governs its evaluation, and where in the solver output that quantity can be recovered. This chapter establishes those three foundations — injury metrics, regulatory standards, and data sources — and shows how each maps onto concrete fields and computations that later automation will consume.

Injury metrics: what is actually being measured

Injury criteria are biomechanical surrogates. They do not measure tissue damage directly; they compress a time history of acceleration, force, or deflection into a scalar (or a small set of scalars) that correlates with observed injury risk in cadaveric, animal, or volunteer testing. The most common family in vehicle crash CAE is head injury assessment:

• HIC (Head Injury Criterion) — the maximum over all time windows of a weighted integral of the resultant head acceleration. The classical form uses a 36 ms window; HIC₁₅ uses 15 ms and is common in pedestrian and some occupant protocols.
• a_3ms — the peak resultant acceleration sustained for at least 3 ms, used as a complementary clip criterion where HIC alone can be gamed by short spikes.
• BrIC (Brain Injury Criterion) — based on angular velocity components, addressing rotational injury that linear metrics miss.
• Chest criteria — chest deflection (absolute or normalized to half-chest depth), chest acceleration a_3ms, and the viscous criterion VC = max(v(t)·C(t)).
• Neck — Nij (combined tension/compression and flexion/extension moments, normalized by intercept values), plus shear and moment limits.
• Lower extremity — tibia index and femur axial force.

The critical engineering point is that each metric has a precise mathematical definition, and small deviations in implementation produce different numbers. HIC, for example, is defined as

HIC = max over (t1, t2) with t2 - t1 <= T of
      [ (t2 - t1) * ( (1/(t2-t1)) * integral_{t1}^{t2} a(t) dt )^2.5 ]

where a(t) is the resultant translational acceleration at the head centre of gravity expressed in multiples of g. Two implementation choices matter enormously: whether the acceleration is filtered before integration (typically SAE J211 CFC 1000 for head), and whether the search is over a fixed window or all windows up to the limit. A pipeline that silently uses unfiltered data or a fixed 36 ms window will disagree with the certification lab even when the underlying simulation is identical.

Regulatory and consumer standards

Standards define the test configuration, the dummy, the instrumentation, the filtering, and the pass/fail thresholds. They are the contract between the simulation and the certification decision. The main families an injury-report pipeline must accommodate are:

These programmes differ in dummy (Hybrid III 50th vs THOR vs WorldSID), in impact speed and barrier, and in the exact threshold values. A report generator that hard-codes a single threshold set will fail the moment the same model is evaluated against a second programme. The practical design is to externalise the standard as data: a configuration record that names the dummy, the filter class, the metric set, and the limit values, so the Python code computes metrics generically and applies limits from configuration.

Data sources: where the numbers come from

In a CAE workflow the injury metrics are not read from a single file. They are assembled from several sources, each with its own format and conventions:

• Solver time-history output — LS-DYNA nodout, elout, and rcforc; Radioss T01/T02; Abaqus .odb history output. These carry nodal accelerations, element forces, and contact forces at a defined sampling interval.
• Dummy instrumentation definitions — the mapping from node/element sets to physical channels (e.g. head CG accelerometer, upper-neck load cell). Usually a model-specific include or a sidecar mapping file.
• Filter and coordinate conventions — SAE J211 filter classes, sign conventions, and local dummy coordinate systems. These are frequently documented in the test protocol rather than the model.
• Test metadata — impact speed, barrier type, dummy position, and run identifier, needed to select the correct threshold set.

The following SVG shows how these sources converge into a single metric record, and where the standard's parameters enter the computation.

From definition to a reproducible metric record

The diagram above encodes the central architectural decision of this course: separate the physics from the policy. The left side supplies raw signals and their meaning; the right side supplies the rules; the centre computes; the output is a self-describing record. In Python terms, the computation stage should be a pure function whose inputs are arrays plus a configuration object, and whose output is a dictionary that carries provenance. A minimal illustration of the record shape:

metric_record = {
    "run_id": "FRONTAL_50KPH_R03",
    "channel": "HEAD_CG_RESULTANT",
    "metric": "HIC",
    "value": 612.4,
    "unit": "dimensionless",
    "filter": "SAE_J211_CFC1000",
    "window_ms": 36,
    "source_file": "nodout",
    "standard": "FMVSS208",
    "limit": 700,
    "status": "PASS",
}

Every field exists for a reason. filter and window_ms make the value reproducible; source_file makes it traceable; standard and limit make the verdict auditable. When a reviewer asks why a HIC differs from the lab's, the record answers the question without re-running anything.

Practical checks before automating

Three verification steps catch most early pipeline errors. First, confirm the sampling interval of the time-history output is fine enough for the filter class — CFC 1000 implies a meaningful bandwidth up to roughly 1000 Hz, so a 1 ms output step is marginal and a 0.1 ms step is safer. Second, verify the coordinate convention: a resultant acceleration is invariant to axis sign, but Nij and chest deflection are not, and a flipped sign turns tension into compression. Third, cross-check one hand-computed HIC against the pipeline on a short synthetic pulse with a known answer before trusting it on real runs.

With metrics defined, standards externalised as configuration, and data sources mapped to channels, the remaining work is mechanical: parse the solver files, apply the filters, compute the metrics, and emit records. That mechanical work is exactly what the Python automation in later chapters will handle — but it can only be correct if the definitions established here are correct first.