3. Feature store fundamentals for crash sim

A feature store is a serving and governance layer that sits between raw engineering data and the models or rules that consume it. In a generic machine learning (ML) context, a feature store typically manages tabular features such as user age, click counts, or transaction averages, and its main job is to keep offline training data and online inference data consistent. Crash simulation is a different animal. The "features" here are not scalar columns extracted from a database; they are physical response quantities derived from finite element (FE) models, solver runs, and post-processing pipelines. Understanding what a feature store means in this domain — and where it diverges from the generic ML pattern — is the foundation for everything that follows in this course.

What Counts as a Feature in Crash Simulation

In crash simulation, a feature is any derived, reusable quantity that describes the behavior of a structure, material, occupant, or subsystem under a defined loading condition. Typical examples include:

• Scalar response metrics: peak acceleration at a sensor location, maximum intrusion into the occupant compartment, HIC (Head Injury Criterion) value, total energy absorbed by a crash box.
• Curve-based features: force–displacement curves from a quasi-static crush, acceleration–time histories at the B-pillar, energy–time profiles.
• Field or spatial features: maximum plastic strain distribution over a component, deformation mode classification, hotspot locations.
• Configuration descriptors: material grade, thickness, gauge, joint type, and boundary conditions that define the simulation case.

The critical distinction is that these features are not stored as raw rows in a transactional database. They are produced by a chain of tools: pre-processor (mesh, boundary conditions), solver (LS-DYNA, PAM-CRASH, Radioss), and post-processor (META, HyperView, Python scripts). A crash simulation feature store must therefore capture not only the feature value but also the provenance — which model version, which solver deck, which material card, which extraction script — that produced it.

Architecture of a Crash Simulation Feature Store

A practical architecture for this domain has four layers. The ingestion layer connects to the simulation data management (SDM) system or file system, pulls solver output (d3plot, binout, ASCII curves), and runs extraction scripts. The feature computation layer applies deterministic post-processing logic — for example, filtering acceleration signals per SAE J211, computing HIC over a 36 ms window, or integrating force over displacement. The storage layer holds features in a structured form: a relational or columnar store for scalars, an object store for curves and fields, and a metadata catalog for provenance. The serving layer exposes features to downstream consumers: surrogate models, optimization loops, dashboards, or design rule checks.

The diagram below shows how these layers connect and where the crash-specific concerns — solver decks, extraction scripts, and provenance — enter the pipeline.

How This Differs from a Generic ML Feature Store

The differences are not cosmetic. They affect data model, storage format, and operational workflow.

The most consequential difference is provenance depth. In a generic feature store, if a feature value changes, you trace it back to a source row. In crash simulation, a feature value can change because the mesh was refined, the material card was updated, the solver version was bumped, or the extraction script was modified. Without capturing all four, a feature store becomes a source of silent inconsistency — two teams may believe they are comparing the same feature when they are not.

Practical Example: Extracting a HIC Feature

Consider a frontal impact simulation where the feature of interest is the HIC value at the driver-side head sensor. The extraction follows a defined sequence:

1. Read the acceleration–time history from the solver binout or ASCII output at the specified node or sensor.
2. Apply CFC 1000 filtering per SAE J211 to remove numerical noise.
3. Compute the resultant acceleration magnitude from the three components.
4. Scan all 36 ms windows and compute HIC = max over windows of [(1/(t2−t1)) ∫ a dt]^2.5 × (t2−t1).
5. Store the scalar HIC value, the window start/end times, and the filtered curve as a feature record.

A minimal feature record in JSON form might look like this:

{
  "feature_id": "hic_driver_head",
  "case_id": "FRB_56kph_001",
  "value": 742.3,
  "unit": "dimensionless",
  "window_ms": [12.4, 48.4],
  "provenance": {
    "model_rev": "BIW_v3.2",
    "solver": "LS-DYNA R13.1",
    "deck": "front_barrier_56kph.key",
    "extraction_script": "extract_hic.py@v1.4"
  },
  "timestamp": "2025-01-15T09:30:00Z"
}

If the same case is re-run with a refined mesh, the HIC value may shift by a few percent. The provenance block makes that shift traceable. Without it, the change is indistinguishable from a bug.

What to Store and What to Reference

Not every byte of solver output belongs in the feature store. A workable rule is: store scalars and short curves directly; store large fields by reference to the object store, with a checksum and a pointer. This keeps the feature store queryable and fast while preserving access to the full field when needed. The provenance catalog should record the reference, the checksum, and the extraction parameters so that any feature can be regenerated from the original solver output if required.

In the next section, we will look at how to model the entities — cases, configurations, features, and provenance — in a schema that supports both fast queries and full traceability.