4. Metadata schemas for CAE artifacts

In an automotive CAE data management system, a simulation result file without metadata is nearly worthless for traceability. A solver output such as job_4821.odb or crash_frontal_50kph.dat tells you almost nothing about which vehicle build it belongs to, which solver version produced it, or whether the boundary conditions match the approved load case. Metadata schemas solve this by defining a structured, machine-readable contract that every CAE artifact must satisfy before it enters the repository. This chapter focuses on the five metadata domains that carry the most engineering weight: solver version, boundary conditions, material cards, mesh statistics, and load case definitions.

Why a Schema, Not Just a Folder Structure

A folder hierarchy can encode project, vehicle program, and subsystem, but it cannot enforce that a Nastran run used the correct solver patch level or that a material card references an approved revision. A schema does. It defines required fields, data types, allowed enumerations, and relationships between artifacts. When the schema is enforced at ingestion time — typically through a validation hook in the data management platform — non-compliant artifacts are rejected or flagged before they pollute downstream traceability queries.

A practical schema for automotive CAE is usually expressed in JSON Schema or as a relational model with foreign keys. The choice depends on whether the repository is document-oriented (common for file-centric CAE stores) or relational (common when linking to PLM/BOM systems). Either way, the same five domains must be captured.

Solver Version Metadata

Solver version is not a single string. For traceability, capture at least: solver product name, major.minor.patch version, build date, platform/OS, and any relevant license feature. For example, an Abaqus explicit run might record product: Abaqus/Explicit, version: 2023, patch: HF5, build: 2023-08-14, platform: linux-x86_64. The reason is reproducibility: a contact algorithm change between patch levels can shift intrusion results by several millimeters, and without the patch level you cannot explain the difference.

Store solver version as a structured object, not a free-text field. Free text inevitably produces variants like "Abaqus 2023", "abaqus2023", and "ABAQUS 2023.0" that break queries. A controlled vocabulary plus a version parser normalizes these at ingestion.

Boundary Condition Metadata

Boundary conditions (BCs) are where traceability most often fails, because they are frequently applied in the pre-processor GUI and never documented outside the input deck. The schema should capture each BC as a record with: BC type (constraint, prescribed displacement, velocity, acceleration, symmetry, etc.), application region (node set or surface set name), coordinate system, magnitude and units, and time-dependence (constant, tabular, or amplitude curve reference).

For a frontal crash load case, a typical BC record might be:

{
  "bc_id": "BC-REAR-CLAMP",
  "type": "constraint",
  "region": "NSET_REAR_STRUCTURE",
  "dof": [1, 2, 3],
  "coordinate_system": "GLOBAL",
  "magnitude": 0.0,
  "units": "mm",
  "amplitude": null
}

The critical discipline is that the region name in the metadata must match the set name in the solver deck. A mismatch means the metadata describes a different model than the one actually solved. Automated cross-checking between the input deck and the metadata record catches this class of error.

Material Card Metadata

Material cards are the most safety-critical metadata in automotive CAE. A side impact simulation using an outdated steel grade card can under-predict or over-predict failure. The schema should link each material card to: material ID, material name, standard designation (e.g., DP780, AA6061-T6), constitutive model (Johnson-Cook, GISSMO, MAT_24, etc.), card revision, source (test lab report ID or supplier datasheet), and validation status.

Rather than duplicating the full card content in metadata, store a hash of the card file plus a reference to the approved material library entry. This keeps the metadata lightweight while still allowing verification that the card used in the run matches the approved revision. If the hash differs, the run is flagged as using an unapproved material.

Mesh Statistics Metadata

Mesh statistics serve two purposes: quality gating and run comparability. Capture element count by type (shell, solid, beam), minimum and maximum element size, aspect ratio distribution, Jacobian threshold violations, and total node count. For a full vehicle model, a typical record might show 8.2 million shell elements, 1.1 million solid elements, minimum size 2.5 mm, and 340 elements below the Jacobian warning threshold.

These statistics allow a reviewer to quickly judge whether two runs are comparable. If run A used a 5 mm mesh and run B used a 3 mm mesh, the results are not directly comparable without a mesh convergence study. The metadata makes this visible without opening the model.

Load Case Definition Metadata

A load case definition ties together the BCs, initial conditions, and solver settings into a named, versioned scenario. The schema should capture: load case ID, name (e.g., FMVSS208_FRONTAL_50KPH), regulation or internal standard reference, impact velocity, impact angle, barrier type, initial temperature, and the list of BC IDs and material card IDs used. This creates a complete, queryable description of what was simulated.

A load case record is the join point of the schema. It references BCs, materials, and solver settings, so a single query on a load case ID can retrieve everything needed to reproduce or audit the run.

Schema Enforcement in Practice

Enforcement happens at two points: ingestion and retrieval. At ingestion, a validation service checks required fields, data types, and referential integrity (e.g., every BC ID referenced by a load case must exist). At retrieval, the schema supports queries like "show all runs using material card revision older than R3" or "list all frontal crash runs with solver patch level below HF4." These queries are only possible if the metadata was captured structurally from the start.

A common failure mode is partial adoption: some teams fill metadata manually, others rely on solver log parsing. The result is inconsistent coverage. The robust approach is to generate metadata automatically from the solver input deck and log files wherever possible, and require manual entry only for fields that cannot be derived, such as validation status or test correlation reference.

CAE Artifact Metadata Schema — Five Domains and Their Relationships Solver Version product, version, patch build date, platform license feature Boundary Conditions type, region, DOF coordinate system magnitude, units amplitude reference Material Cards material ID, standard constitutive model revision, hash, source validation status Mesh Statistics element count by type min/max element size aspect ratio, Jacobian node count Load Case Definition load case ID, name regulation reference velocity, angle, barrier BC IDs, material IDs solver settings ref references references uses produced by CAE Artifact result file (.odb, .dat) input deck (.inp, .key) report, image, animation + metadata record describes Schema Validation Gate required fields, types, referential integrity ingest

Practical Schema Skeleton

The following JSON skeleton illustrates how the five domains combine into a single artifact metadata record. It is a teaching example, not a production schema, but it shows the required structure and relationships.

{
  "artifact_id": "RUN-2024-004821",
  "solver": {
    "product": "Abaqus/Explicit",
    "version": "2023",
    "patch": "HF5",
    "platform": "linux-x86_64"
  },
  "mesh": {
    "shell_elements": 8200000,
    "solid_elements": 1100000,
    "min_size_mm": 2.5,
    "jacobian_warnings": 340
  },
  "boundary_conditions": [
    {"bc_id": "BC-REAR-CLAMP", "type": "constraint", "region": "NSET_REAR_STRUCTURE", "dof": [1,2,3]}
  ],
  "materials": [
    {"material_id": "MAT-DP780-R3", "standard": "DP780", "model": "GISSMO", "hash": "a3f9..."}
  ],
  "load_case": {
    "id": "FMVSS208_FRONTAL_50KPH",
    "velocity_kph": 50,
    "barrier": "rigid_wall",
    "bc_refs": ["BC-REAR-CLAMP"],
    "material_refs": ["MAT-DP780-R3"]
  }
}

When this record is validated and stored alongside the result file, any engineer can later query the repository and reconstruct exactly what was simulated, with which solver, which materials, and which boundary conditions. That is the foundation of traceability in automotive CAE.

Start by enforcing only the fields that directly affect result interpretation: solver patch, material revision, and load case ID. Expand the schema once the ingestion pipeline is stable. Over-specifying too early creates friction that leads teams to bypass the system entirely.
← Previous 📖 Contents Next →