1. Course overview

This course builds a complete, reproducible pipeline that turns raw CAE (Computer-Aided Engineering) solver output into structured injury reports and interactive Excel dashboards using Python. The scope is deliberately narrow and practical: we take simulation results from explicit-dynamics crash or impact models, extract the physical quantities that govern occupant injury risk, compute standardized injury criteria, assemble them into a reportable dataset, and deliver that dataset both as a formatted document and as a filterable Excel workbook. The course does not attempt to teach finite element theory or solver internals; instead it treats the solver as a data source and focuses on everything downstream of the results file.

The technical context matters because injury assessment sits at the intersection of three disciplines. Biomechanics defines what to measure — head acceleration, chest deflection, neck forces and moments, femur axial load. Standards and regulations define how to reduce those signals into scalar criteria — HIC, 3 ms clip, Nij, chest compression rate. Software engineering defines how to do it repeatably — deterministic parsing, validated formulas, versioned outputs. A pipeline that gets the biomechanics right but the file handling wrong produces plausible-looking numbers that cannot be trusted. This course treats all three as first-class concerns.

The end-to-end data path

Every chapter contributes to one continuous data path. Understanding this path up front prevents the common failure of building isolated scripts that each solve a fragment of the problem. The path has five stages:

1. Acquisition — locate and read solver output: time-history curves (accelerations, forces, displacements), nodal or element data, and metadata such as channel units, sampling interval, and model configuration.
2. Signal conditioning — apply the filtering mandated by the relevant standard (for example CFC 1000 for head acceleration, CFC 600 for chest acceleration, CFC 180 for neck forces), verify sampling adequacy, and handle time-base alignment.
3. Criteria computation — evaluate injury criteria with explicit, testable functions: HIC over a sliding 15 ms window, 3 ms clip on filtered resultant acceleration, Nij from neck force and moment interaction, and deflection-based chest metrics.
4. Report assembly — aggregate per-channel and per-dummy-position results into a tidy tabular structure with consistent identifiers, units, and pass/fail flags against configured limits.
5. Delivery — render a formatted report (Word or PDF) and write an Excel workbook with native tables, conditional formatting, and charts that update when the underlying data changes.

The following diagram shows this path together with the artifacts that flow between stages and the validation gate that each stage must pass before its output is consumed downstream.

Core concepts you will work with

Three concept families recur throughout the course and are worth fixing precisely now, because imprecise definitions cause most downstream errors.

Injury criteria are window-based reductions, not single samples. HIC, for instance, is defined as the maximum over all time windows of a fixed duration (15 ms) of a function of the resultant head acceleration. The practical consequence is that HIC cannot be computed from a peak value alone; you need the full filtered time history and a sliding-window search. Similarly, the 3 ms clip is the maximum acceleration sustained for at least 3 ms, which requires checking duration, not just amplitude. Any implementation that reports a raw peak as a criterion value is wrong, and the course will show how to detect that mistake.

Filtering is part of the definition, not a cosmetic step. A criterion evaluated on unfiltered data is not the regulated criterion. The channel frequency class (CFC) determines the low-pass cutoff: CFC 1000 corresponds to a cutoff near 1650 Hz, CFC 600 near 1000 Hz, CFC 180 near 300 Hz. Applying the wrong class, or applying a filter twice, shifts results in ways that are easy to miss and hard to defend in a report. The course implements a single, tested filter utility and routes every channel through it with an explicit class argument.

Units and sign conventions must be declared once and enforced. Acceleration may arrive in g or m/s², forces in N or kN, moments in N·m or N·mm, deflection in mm or m. Neck force sign conventions differ between tension and compression depending on the coordinate system. The pipeline carries an explicit unit field per channel and converts at the boundary, so criteria functions always receive SI-consistent inputs. This is the single most effective defense against silently wrong reports.

What the pipeline looks like in code

The course builds toward a small, readable package rather than a monolithic script. A representative entry point looks like this — the exact module names are introduced as the course progresses, but the shape is fixed from the start:

from injury_pipeline import load_run, condition, criteria, assemble, deliver

run = load_run("cases/Frontal_50kmh_ATD")          # acquisition + metadata
signals = condition.apply_cfc(run, classes={"head_acc": 1000,
                                            "chest_acc": 600,
                                            "neck_force": 180})
results = criteria.evaluate(signals, position="driver")
table = assemble.to_frame(results, limits="limits/ec24.yaml")
deliver.write_report(table, "out/report.docx")
deliver.write_dashboard(table, "out/dashboard.xlsx")

Each function has a contract: inputs, outputs, units, and failure behavior. That contract is what makes the pipeline testable. When a result looks wrong, you can isolate whether the fault lies in loading, conditioning, or criteria evaluation by inspecting the intermediate object rather than re-reading the whole script.

Technical stack and environment

The implementation uses Python 3.10 or later with a deliberately small dependency set: numpy and scipy for signal processing and windowed reductions, pandas for tabular assembly, openpyxl for Excel generation with native tables and conditional formatting, and python-docx for report rendering. Plotting uses matplotlib for static report figures and native Excel charts for the dashboard so that the workbook remains interactive without embedded images. Configuration of limits and channel mappings lives in YAML files, keeping regulatory thresholds out of code and making them auditable.

Scope boundaries and assumptions

The course assumes you have access to solver output in a tabular or columnar format and that you know which channel corresponds to which physical measurement. It does not cover model build, mesh quality, contact definitions, or solver convergence — those belong to the CAE analyst's domain. It also does not attempt to certify results against a regulator; it produces traceable, reproducible numbers that a qualified engineer can review and sign. Where a standard specifies a detail the course cannot verify (for example, a particular filter implementation's phase behavior), the course states the assumption explicitly and provides a test that exposes sensitivity to it.

By the end, you will have a pipeline that ingests a run directory, produces a criteria table with units and pass/fail flags, renders a formatted report, and writes an Excel dashboard whose tables and charts are driven by the same data — with validation gates at each stage so that a failure is caught where it occurs rather than discovered in a delivered document.