1. Course overview

Automotive injury limit evaluation is the discipline of comparing occupant responses measured or simulated during a crash event against defined injury criteria, and then deciding whether each body region, dummy position, and load case passes or fails. It sits at the boundary between CAE, physical testing, and regulatory compliance, and its output directly influences restraint system tuning, seat and interior design, and homologation sign-off. This course treats the evaluation as an engineering system: a repeatable workflow that starts with raw signal data and ends with a defensible pass/fail verdict, with Excel automation carrying the repetitive computation and decision logic in between.

The scope is deliberately narrower than "crash safety" as a whole. We do not cover sled facility operation, dummy certification procedures, or the physics of injury biomechanics beyond what is needed to interpret each criterion. Instead, the course focuses on four things: the injury criteria themselves and their mathematical definitions, the data preparation required before any criterion can be computed, the pass/fail decision rules including limit selection and margin handling, and the automation layer that makes the whole process auditable and fast. By the end, you should be able to take a set of acceleration and force channels from a frontal or side impact load case, compute the relevant criteria, apply the correct limits, and produce a traceable verdict sheet without manual copy-paste.

The evaluation workflow as a pipeline

A single load case evaluation moves through five distinguishable stages, and it is worth being explicit about them because most real-world errors occur at the seams rather than inside any one stage.

Stage 1 — Channel acquisition and identification. Each measurement channel has a name, a unit, a sampling rate, and a physical location on the dummy or vehicle. A typical frontal case might include head resultant acceleration (HEAD_ACC_RES, g), chest deflection (CHEST_DEF, mm), upper neck axial force (NECK_FZ, N), and femur axial force (FEMUR_FZ_L, kN). Getting the channel-to-criterion mapping wrong is the single most common source of silent failure, because a plausible-looking number computed from the wrong channel will still pass a sanity check.

Stage 2 — Signal conditioning. Raw channels are filtered before criteria are computed. The standard practice is a low-pass Butterworth filter, and the cutoff frequency is criterion-specific: head acceleration criteria are conventionally evaluated on CFC 1000 data, while chest deflection uses CFC 180. Filtering is not cosmetic — it changes peak values, and therefore changes verdicts. The filter class, order, and any padding or transient handling must be recorded alongside the result.

Stage 3 — Criterion computation. Each criterion is a defined transformation of one or more conditioned channels. Head Injury Criterion (HIC) integrates resultant head acceleration over a sliding window; the 3 ms clip takes a moving average of the same signal; chest deflection criteria may use the instantaneous peak or a deflection-rate product. The window length, the integration convention, and the time origin all matter and must match the governing regulation or internal standard.

Stage 4 — Limit application and margin. The computed value is compared against a limit drawn from a regulation (for example, FMVSS 208 or ECE R94), an internal target, or a customer requirement. A pass is not simply "value below limit": engineering practice usually applies a margin band so that results close to the limit are flagged for review rather than silently accepted.

Stage 5 — Verdict aggregation and reporting. Individual criterion verdicts roll up into a load-case verdict, and load cases roll up into a program-level status. This is where automation earns its keep, because the aggregation logic is where inconsistent manual handling becomes visible.

Why Excel, and where its boundary lies

Excel is not the obvious tool for signal processing, and this course does not pretend otherwise. The realistic division of labour is that dedicated crash analysis software handles the raw time-series work — reading the measurement file, applying the filter, and exporting the conditioned channel or the already-computed criterion value. Excel then takes over from the point where the data becomes tabular: one row per criterion, one column per load case, with limits, margins, and verdicts alongside.

That boundary matters because it determines what the automation must be trusted to do. Excel is excellent at lookup tables, deterministic formulas, conditional logic, and producing a readable audit trail. It is poor at high-rate time-series integration and at anything requiring version-controlled code review. Placing the HIC integration inside a spreadsheet cell formula is possible but fragile; placing the limit lookup and verdict logic there is robust and highly maintainable. The course consistently draws the line at the criterion value: whatever produces that number must be validated separately, and Excel's job begins with a value it can treat as an input.

What "pass/fail automation" actually means here

Automation in this context is not a macro that presses buttons. It is a structured workbook in which four things are explicit and separated: a channel and criterion register that maps each criterion to its source channel and filter class; a limit table keyed by regulation, body region, and dummy type; a results table holding the computed values per load case; and a verdict layer that joins the two and applies the margin rule. When these are separate sheets rather than interleaved columns, changing a limit for a new regulation revision becomes a one-cell edit rather than a hunt through formulas.

A minimal but complete verdict formula for a single criterion, assuming the value is in D5, the limit in Limits!C5, and the margin fraction in Limits!D5, looks like this:

=IF(D5<=Limits!C5*(1-Limits!D5),"PASS",
   IF(D5<=Limits!C5,"REVIEW","FAIL"))

The margin is expressed as a fraction of the limit — a margin of 0.10 means values above 90% of the limit are flagged for review. This convention should be stated once and used everywhere, because mixing "margin as fraction" and "margin as absolute value" across sheets is a classic source of contradictory verdicts. The same discipline applies to units: limits for femur force are conventionally in kN while the channel may be in N, and the conversion must live in exactly one place.

Typical failure symptoms and how to read them

Three symptoms recur in practice and are worth recognising early. First, a criterion value that is suspiciously round or suspiciously low usually indicates a channel mapping error — the formula is reading a channel that is mostly zero, such as an unused or unconnected measurement location. Second, verdicts that flip between runs with no change to the input data point to a volatile reference, most often a relative cell reference that shifted when rows were inserted. Third, a load case that reports PASS while an individual criterion shows a value above its limit almost always means the aggregation formula is using AND where it should use OR, or is referencing the wrong row range.

The habit that prevents most of these is a small set of built-in consistency checks placed on the summary sheet: a count of criteria evaluated versus criteria expected, a flag for any criterion whose value is blank or non-numeric, and a check that every criterion in the register has a matching limit entry. These checks cost a few formulas and catch the majority of silent errors before a verdict reaches a design review.

How the course is organised

The chapters that follow build the pipeline in the order it is executed. Early chapters establish the injury criteria and their exact definitions, including the integration windows and filtering conventions that change results. The middle chapters develop the workbook structure: the register, the limit table, the results table, and the verdict layer, with worked examples using representative values that are clearly marked as illustrative rather than measured. Later chapters address margin policy, aggregation across load cases, reporting, and the validation of the automation itself — including how to prove that a workbook produces the same verdict as a hand calculation on a known case. Throughout, the emphasis is on decisions that can be defended: every number traceable to a channel, every limit traceable to a source, and every verdict reproducible by someone who did not build the sheet.