4. Feature taxonomy for crash simulation
A crash simulation feature store is only as useful as the taxonomy that organizes it. Without a shared classification scheme, two teams can extract the same physical quantity, name it differently, store it in incompatible units, and never discover that their datasets are actually comparable. A well-designed taxonomy solves this by grouping features according to the physical role they play in a crash event, so that engineers can reason about coverage, redundancy, and causality before they ever train a model or run a query.
The taxonomy presented here partitions features into five families: geometric, material, loading, boundary condition, and response-derived. The first four describe the model and its environment — the inputs to a crash event. The fifth describes what actually happened — the outputs. This input/output split is the single most important structural decision in the taxonomy, because it determines which features are available at prediction time and which are only available for training or validation.
Geometric Features
Geometric features describe the shape, topology, and spatial arrangement of the structure. They are extracted from the CAD or meshed geometry and are independent of material assignment or loading. Typical examples include sheet metal thickness at a given location, cross-section area of a rail, bend radius, flange width, spot weld pitch, and the presence of beads or ribs. In a feature store, these are usually stored per component or per zone rather than per node, because node-level geometry is too granular for most engineering queries.
A practical representation is the zone-based geometric descriptor. For a front rail, you might store thickness_mm, section_width_mm, section_height_mm, weld_pitch_mm, and bead_count. These five numbers capture most of the geometric design space that governs axial crush behavior. When a new variant is proposed, the engineer can query the store for geometrically similar zones and retrieve their historical crash responses.
Material Features
Material features describe the constitutive behavior of the assigned material. For crash simulation, the most relevant are yield stress, ultimate tensile strength, elongation at break, strain-rate sensitivity parameters (such as Cowper–Symonds C and p), and hardening curve identifiers. These are not scalar constants in reality — they are curves and rate-dependent surfaces — but the feature store typically stores a compact parameterization plus a reference to the full curve.
It is critical to distinguish nominal material features (from the material card) from as-built features (from coupon tests or process simulation). A rail made of DP780 may have a nominal yield of 450 MPa, but after forming, the local yield can exceed 600 MPa due to work hardening. Storing both, with a clear provenance tag, prevents the common error of training a model on nominal properties and deploying it on as-built parts.
Loading Features
Loading features describe the external excitation applied to the structure. In crash simulation, this includes impact velocity, impact angle, impactor mass, and the shape of the impactor (flat rigid wall, pole, moving deformable barrier). These features are usually defined at the load case level, not the component level, and they are shared across all components in that load case.
A useful convention is to store loading features as a vector: [velocity_mps, angle_deg, mass_kg, impactor_type]. For a frontal offset test, this might be [64, 0, 1400, "ODB"]. For a side pole impact, [32, 90, 950, "pole_254mm"]. Keeping the impactor type as a categorical feature rather than a numeric one avoids false ordinal relationships.
Boundary Condition Features
Boundary conditions describe how the structure is constrained and connected. This includes weld and adhesive locations, bolt pretension, contact definitions, and rigid body constraints. In a feature store, these are often represented as connectivity graphs or as aggregate metrics such as weld_count, adhesive_length_mm, and constraint_stiffness_N_per_mm.
Boundary conditions are frequently the source of simulation divergence. A missing weld or an incorrectly defined contact can change the crash response more than a 10% thickness variation. Storing boundary condition features alongside geometric and material features allows the store to flag when a new model differs primarily in its connections rather than its structure.
Response-Derived Features
Response-derived features are computed from the simulation output. They are the targets of prediction and the ground truth for validation. Common examples include peak crush force, mean crush force, energy absorbed at 100 mm displacement, intrusion at the B-pillar, and acceleration at the tunnel. These features are extracted from the nodout, glstat, and secforc files and stored with their extraction method and time window.
The engineering meaning of each response feature must be documented. Peak crush force governs the deceleration pulse and occupant loading. Energy absorbed at 100 mm indicates whether the rail is crushing efficiently or bottoming out. Intrusion is a direct safety metric. Without this semantic layer, the feature store becomes a numerical database with no engineering interpretability.
provenance=corrosion tag, not as a material feature.
Cross-Family Relationships
The five families are not independent. Geometric features interact with material features to determine collapse mode. Loading features interact with boundary conditions to determine load path. Response-derived features are the integrated result of all four input families. The SVG below shows this dependency structure and the direction of influence.
Practical Implications for the Feature Store
The taxonomy directly shapes the store's schema. Each feature record should carry at minimum: feature_id, family, name, unit, extraction_method, provenance, and valid_range. The family field enables queries like "retrieve all geometric features for the front rail" or "find all load cases with velocity above 50 m/s." The provenance field distinguishes nominal from as-built, measured from simulated, and original from derived.
When populating the store, a common failure mode is family leakage: storing a response-derived quantity such as "peak force" as if it were an input feature. This happens when engineers extract features from a completed simulation and forget to separate inputs from outputs. The taxonomy prevents this by making the input/output boundary explicit. If a feature cannot be computed before the simulation runs, it belongs to the response-derived family and must be tagged as a target, not a predictor.
With the taxonomy in place, the next step is to define how features are extracted, versioned, and queried across the 30-chapter workflow. The five families provide the stable backbone; the engineering meaning attached to each feature provides the interpretability that makes the store useful for design decisions, not just data retrieval.