3. Domain-specific terminology and ontology

Crash simulation archives are only searchable if the vocabulary used to describe them is consistent. A natural-language search layer cannot reliably map a query such as "frontal offset impact on a B-pillar with high-strength steel" to the correct simulation records unless the underlying archive exposes a controlled, structured vocabulary. This section defines the four terminology pillars that dominate crash simulation metadata — materials, load cases, boundary conditions, and result metrics — and shows how to organize them into a lightweight ontology that a retrieval system can traverse.

Why a Controlled Vocabulary Is Necessary

Raw simulation archives accumulate heterogeneous labels. One engineer writes MAT_24, another writes Piecewise_Linear_Plasticity, and a third writes steel_HSLA_340. All three may refer to the same constitutive behavior applied to a similar alloy. Without normalization, a natural-language query will either miss relevant records or return noisy matches. An ontology solves this by separating the concept (a material class with defined mechanical behavior) from the instance (a specific card, grade, or dataset).

The ontology should be shallow enough to maintain but deep enough to support inference. A practical structure uses four top-level classes — Material, LoadCase, BoundaryCondition, and ResultMetric — each with typed properties and controlled enumerations. Relationships between them (for example, a load case requires certain boundary conditions, and a result metric is measured on a specific component) allow the search engine to expand a query without guessing.

Materials: From Constitutive Model to Grade

Material terminology in crash simulation must capture both the constitutive formulation and the physical alloy. The constitutive model determines how the solver computes stress; the alloy determines the parameter values. A useful ontology node therefore carries:

• Constitutive model — e.g., *MAT_PIECEWISE_LINEAR_PLASTICITY (LS-DYNA MAT_24), *MAT_JOHNSON_COOK (MAT_15), *MAT_PLASTIC_KINEMATIC (MAT_3), or *MAT_CRUSHABLE_FOAM (MAT_63).
• Material class — steel, aluminum, magnesium, composite, polymer, foam.
• Grade or designation — e.g., DP780, HSLA340, AA6061-T6, CFRP-T700.
• Key parameters — density, Young's modulus, yield stress, ultimate tensile strength, failure strain, strain-rate sensitivity (Cowper–Symonds C and p, or Johnson–Cook A, B, n, C, m).

For search purposes, the ontology should record the parameter set as a named profile. A query like "DP780 with strain-rate sensitivity" can then resolve to a material profile that carries both the grade tag and a non-zero rate-sensitivity coefficient, rather than relying on free-text matching.

Load Cases: Encoding Impact Scenarios

Load cases describe the physical event being simulated. In crash simulation, the dominant standardized families are:

Load case family	Typical designation	Key parameters
Full frontal rigid barrier	FMVSS 208, Euro NCAP FRB	Impact speed 56 km/h, 100% overlap, rigid wall
Offset deformable barrier	Euro NCAP ODB, IIHS moderate overlap	64 km/h, 40% overlap, deformable barrier
Side impact	Euro NCAP AE-MDB, FMVSS 214	50 km/h, 950 kg trolley, 90° impact angle
Pole impact	Euro NCAP side pole	32 km/h, 75 mm pole diameter, 75° angle
Rear impact	FMVSS 301, ECE R34	80 km/h, 70% overlap, moving deformable barrier
Pedestrian protection	Euro NCAP pedestrian	40 km/h, legform/headform impactors

Each load case node should store the impact velocity vector, overlap ratio, barrier type, and impact angle. These are the parameters that a natural-language query most often references, and they must be stored as numeric fields rather than embedded in a description string.

Boundary Conditions: Constraints, Contacts, and Initial State

Boundary conditions define how the model is constrained and how interacting surfaces behave. In crash simulation, the most consequential boundary conditions are:

• Rigid wall definition — *RIGIDWALL_PLANAR or *RIGIDWALL_GEOMETRIC, with normal vector and friction coefficient.
• Contact definitions — *CONTACT_AUTOMATIC_SINGLE_SURFACE, *CONTACT_AUTOMATIC_SURFACE_TO_SURFACE, with static and dynamic friction coefficients, and penalty stiffness.
• Constrained nodes — *CONSTRAINED_NODAL_RIGID_BODY for lumped masses, or *BOUNDARY_SPC for fixed degrees of freedom.
• Initial velocity — *INITIAL_VELOCITY applied to a node set or part set, with translational and rotational components.
• Gravity and preload — *LOAD_BODY_Z for gravitational acceleration, and preload curves for suspension or seat structures.

The ontology should link each boundary condition to the load case it supports. A side-impact load case, for example, requires a moving deformable barrier with a defined mass and velocity, a contact definition between the barrier and the vehicle side structure, and a fixed ground plane. Capturing these dependencies allows the search engine to answer queries like "side impact simulations with a 950 kg barrier" by traversing the load case → boundary condition relationship.

Result Metrics: What the Simulation Produces

Result metrics are the quantities extracted from the simulation output and used for assessment. They fall into three groups:

• Structural response — intrusion (mm), deformation energy (kJ), peak force (kN), and section force.
• Occupant response — Head Injury Criterion (HIC), chest deflection (mm), chest acceleration (g), femur force (kN), and neck injury criterion (Nij).
• Component-level — plastic strain, stress triaxiality, and failure flags on specific parts.

Each metric node should record the extraction method (e.g., *DATABASE_CROSS_SECTION, *DATABASE_HISTORY_NODE, or a post-processing script), the component or node set it applies to, and the acceptance threshold if one exists. This makes it possible to search for "simulations where HIC exceeds 700" or "cases with B-pillar intrusion above 150 mm" without scanning raw result files.

Building the Ontology: A Minimal Working Structure

The four classes connect through a small set of relationships. The diagram below shows the core ontology graph, including the properties that carry searchable values.

The graph is intentionally minimal. In practice, additional classes such as VehicleModel, Component, and SimulationRun can be attached, but the four core classes above are sufficient to support the majority of natural-language queries in a crash archive.

From Ontology to Search Index

Once the ontology is defined, the retrieval layer can map free-text queries to structured filters. A query like "offset frontal impact on DP780 B-pillar with HIC above 700" decomposes into:

1. LoadCase = offset frontal (overlapRatio ≈ 0.4, barrierType = deformable)
2. Material = DP780 (grade tag)
3. Component = B-pillar (part or node set)
4. ResultMetric = HIC, value > 700

The search engine then traverses the ontology: LoadCase → BoundaryCondition (to confirm the barrier and contact definitions), Material → ResultMetric (to confirm the material profile was applied to the relevant part), and returns matching simulation records. Without the ontology, the same query would require brittle keyword matching across inconsistent metadata.

Practical Checklist for Ontology Maintenance

• Every material record must include at least one constitutive model identifier and one grade or designation.
• Every load case must include impact speed, overlap ratio, barrier type, and impact angle as numeric fields.
• Every boundary condition must reference the load case it supports and the contact or constraint type used.
• Every result metric must include a unit, an extraction method, and the component or node set it applies to.
• Relationships between classes must be directional and named (e.g., usedIn, requires, produces, affects).

With this structure in place, the archive becomes queryable in a way that respects the actual engineering semantics of crash simulation, rather than relying on string matching over inconsistent labels.