1. Injury metrics and CAE performance KPIs

Crashworthiness engineering produces two very different kinds of numbers. The first are injury metrics: physical quantities extracted from a simulated or physical crash that describe how severely an occupant or pedestrian would be loaded. The second are CAE performance KPIs: the engineering targets, thresholds, and pass/fail judgments that a program uses to decide whether a design is acceptable. Confusing the two is one of the most common sources of error when building a reporting model, because they live at different levels of the data hierarchy and are governed by different change control rules.

This chapter establishes the vocabulary and the data architecture that the rest of the course depends on. It defines the metric families used in frontal, side, and pedestrian protection load cases, describes where those numbers come from in a typical CAE workflow, and explains precisely which calculations belong in Power BI and which must remain in the solver or the post-processor.

Injury metrics: what the numbers physically mean

Injury metrics are time-domain or frequency-weighted quantities derived from accelerometer and load-cell channels in a dummy or impactor. The most frequently reported families are:

  • Head injury: HIC15 and HIC36 (Head Injury Criterion over a 15 ms or 36 ms window), peak resultant head acceleration, and 3 ms clip acceleration. HIC is a maximum over all window start times, so it is a reduction of a time series to a single scalar, not an average.
  • Neck: Nij (combined axial force and bending moment interaction), neck tension and compression, and shear force.
  • Chest: chest deflection in millimetres, chest acceleration, and the viscous criterion V*C for soft-tissue loading rate.
  • Lower extremity: femur axial force, tibia index, and knee displacement.
  • Pedestrian protection: HIC computed on the headform impactor, and bending angle or moment for legform tests.

Each metric has a defined window, a defined filter class (for example CFC 1000 for head acceleration, CFC 180 for chest deflection), and a defined sign convention. These three attributes must be captured as metadata, not assumed. A HIC value computed from unfiltered data is not comparable to one computed from CFC 1000 data, and a chest deflection reported as positive-inward in one solver and positive-outward in another will silently invert a pass/fail decision.

CAE performance KPIs: the judgment layer

A KPI wraps a metric in a target and a comparison rule. Typical forms include a simple threshold (HIC15 ≤ 700), a normalized margin (Nij ≤ 1.0), or a rating curve that maps a continuous metric to a star score. KPIs also carry program context: which load case, which occupant position, which vehicle variant, and which regulation or internal standard the target comes from.

The distinction matters operationally. Metrics are measured; KPIs are assigned. When a regulation revision changes a threshold, every KPI row changes but no metric row does. A well-designed Power BI model keeps these in separate tables so that a target update does not require re-importing simulation results.

Treat the metric table as append-only fact data and the KPI target table as a slowly changing dimension with effective-date columns. This makes historical comparisons valid even after a target revision.

Where the data comes from

In a typical CAE workflow, the chain runs from solver output to a structured results database, and only then to Power BI. Understanding each hop prevents the classic mistake of trying to recompute HIC inside DAX.

  1. Solver output: LS-DYNA, PAM-CRASH, or Radioss write nodout, elout, and interface force files. These are large time-series files, often gigabytes per run.
  2. Post-processing: a scripted post-processor (HyperGraph, Animator, or a Python/numpy pipeline) applies the correct filter, extracts the window, and computes the scalar metric. This is where HIC, Nij, and V*C are actually calculated.
  3. Results database: the scalars, plus run metadata (model version, load case ID, dummy position, solver version, run date), are written to a table — commonly a CSV export, a SQL table, or a data lake parquet file.
  4. Power BI semantic model: the results table is imported or connected via DirectQuery, joined to KPI targets and a load-case dimension, and exposed through DAX measures.
Solver Output nodout / elout interface forces time series, GB scale Post-Processing CFC filter + window HIC, Nij, V*C, deflection scalar extraction Results Database metric scalars run metadata CSV / SQL / parquet Power BI semantic model DAX measures KPI evaluation Metric computation zone filters, windows, time-series reduction — not in DAX KPI evaluation zone margins, pass/fail, aggregation, trend — in DAX KPI Target Table threshold, standard, effective date Example row (illustrative values) load_case=FRB_64, pos=DRV, HIC15=612, Nij=0.87 target: HIC15 ≤ 700, Nij ≤ 1.00 → PASS
Figure 1 — Separation of responsibilities: metrics are reduced from time series before Power BI; DAX evaluates KPIs against targets.

What DAX should and should not do

DAX is a formula language over tables, not a numerical computing environment. It has no native filtering, no windowed maximum over a continuous time axis, and no efficient way to scan a million-row time series per visual. Attempting to compute HIC in DAX by iterating over candidate window start times is technically possible with MAXX and FILTER, but it is slow, hard to validate, and duplicates logic that already exists in the post-processor.

The correct division of labour is:

  • Outside DAX: filtering, window selection, time-series reduction, unit conversion at source, and any metric whose definition is regulated.
  • Inside DAX: margin calculation, pass/fail classification, aggregation across load cases, worst-case selection, trend over model versions, and compliance rate reporting.

A representative measure set for the KPI layer looks like this:

KPI Margin % =
DIVIDE (
    MAX ( Targets[Threshold] ) - MAX ( Results[MetricValue] ),
    MAX ( Targets[Threshold] )
)

KPI Status =
VAR m = [KPI Margin %]
RETURN
    SWITCH ( TRUE (),
        ISBLANK ( m ), "No data",
        m >= 0.10, "Pass – margin",
        m >= 0,    "Pass – marginal",
        "Fail"
    )

Worst HIC15 by Load Case =
MAXX (
    VALUES ( Results[LoadCaseID] ),
    CALCULATE ( MAX ( Results[HIC15] ) )
)

Note that KPI Margin % uses MAX on the target rather than SELECTEDVALUE, because a visual may legitimately show several load cases at once and the margin should be evaluated per row context supplied by the visual, not collapsed to a single value. The SWITCH pattern with an explicit blank branch prevents the common failure where missing simulation results are silently classified as passes.

Never derive a pass/fail flag from a metric that has not been validated against its filter class and window. A HIC15 computed from CFC 600 data can read 8–12% lower than the CFC 1000 value and will flip marginal cases to green.

A minimal semantic model for this course

The model used throughout the following chapters has four tables. Results is the fact table, one row per run per metric, with columns for RunID, LoadCaseID, OccupantPosition, MetricName, MetricValue, ModelVersion, and RunDate. Targets holds LoadCaseID, MetricName, Threshold, Standard, and EffectiveDate. LoadCases is a dimension describing impact type, speed, and barrier. Calendar is a standard date table marked as such.

Relationships run from LoadCases and Calendar to Results, and from Targets to Results on the composite key of LoadCaseID and MetricName. The composite key is the detail that most first attempts miss: without it, a HIC target will be joined to a Nij result and every margin will be meaningless.

With this structure in place, a single measure can answer the question the program actually asks — which load cases are failing, by how much, and since which model version? — without recomputing a single physical metric. That separation is the foundation for everything that follows.

← Previous 📖 Contents Next →