2. Data pedigree fundamentals

In crashworthiness simulation, a CAE result is only as trustworthy as the data that produced it. A frontal impact model that predicts 62 mm of intrusion may be numerically converged, visually plausible, and still indefensible in a design review if no one can show which material card version, which coupon test, and which mesh revision fed into it. Data pedigree is the discipline that makes such questions answerable. It is the structured record of what a piece of data is, where it came from, how it was transformed, and what it is fit for — carried alongside the data itself rather than reconstructed after the fact.

The term is deliberately borrowed from genetics: a pedigree establishes ancestry and descent. Applied to simulation, it answers four distinct but interlocking questions, each with its own vocabulary.

Four Concepts, Four Questions

Definition addresses identity and semantics: what exactly is this datum, in what units, under what conventions, and for what intended use? A yield stress of 355 MPa is meaningless until you know it is true stress at 0.2% plastic offset, measured in the rolling direction, at quasi-static strain rate, on a specimen from heat lot H-2291. Definition is the contract that lets another engineer interpret the value without asking its author.

Metadata is the descriptive envelope: structured attributes attached to the data object — file format, solver version, units system, author, creation timestamp, mesh density, element formulation, contact definition, and so on. Metadata describes the object as it currently exists. It is typically stored in a sidecar file, a header block, or a database record, and it should be machine-readable so that automated checks can consume it.

Provenance is the causal history: the record of the processes and agents that produced the data. For a material card, provenance might read: tensile tests on lot H-2291 → digital image correlation reduction → Johnson–Cook parameter fit → calibration against component-level drop tower test → release to the material library. Provenance captures why the data looks the way it does, including the decisions and assumptions made along the way.

Lineage is the graph structure that connects data objects to one another: which mesh was generated from which CAD revision, which simulation deck consumed which material card, which report cited which run. Lineage is provenance made navigable — the directed acyclic graph (DAG) of dependencies that allows impact analysis in both directions: forward from a changed coupon test to every model it affects, and backward from a suspect result to its root inputs.

A useful rule of thumb: metadata describes the node, lineage describes the edges, provenance describes the path, and definition describes the node's contract. If you can answer "what is it," "what is attached to it," "how did it get here," and "what depends on it," you have a working pedigree.

Why Crashworthiness Makes This Hard

Crash simulation is unusually demanding for pedigree management for three reasons. First, the material models are highly calibrated: a Johnson–Cook or GISSMO card may contain a dozen parameters fitted from dozens of tests, and small changes in the fracture locus can shift a predicted intrusion by tens of millimeters. Second, the dependency chains are long and heterogeneous — CAD → mesh → deck → solver → post-processing → correlation report — spanning tools that rarely share identifiers. Third, regulatory and OEM credibility frameworks increasingly require traceable evidence, so an untraceable model is not merely inconvenient but non-compliant.

Consider a concrete example. A team updates the fracture strain of DP780 based on new coupon data. Without lineage, the change propagates silently: three vehicle programs, two sled models, and one published correlation study now rest on superseded inputs. With lineage, the update triggers a forward impact query that lists every dependent artifact, and the team can decide which models to re-run and which reports to re-issue. The cost of pedigree is paid once; the cost of its absence is paid at every audit.

The Pedigree Graph in Practice

The figure below shows a representative pedigree fragment for a crash model, from coupon test through to a credibility decision. Note that each node carries its own definition and metadata, while the arrows carry transformation provenance.

TEST DATA MODEL BUILD ANALYSIS & DECISION Coupon Test DP780, lot H-2291 quasi-static, RD Material Card v3.2 Johnson–Cook + GISSMO fitted, 14 parameters CAD Assembly BIW rev C, released mass 1,412 kg Crash Mesh 8 mm target, 2.1 M elem quality: 0.3% failed Solver Deck LS-DYNA, 56 km/h full frontal, 150 ms Simulation Run run ID R-2024-0417 intrusion 62 mm Correlation Report test vs. CAE, 4 channels peak Δ = 8.4% Credibility Decision fit for purpose: design comparison fit geometry ref mesh assemble material assign solve compare evidence recalibration trigger Node metadata • units: mm-t-s-MPa • solver: LS-DYNA R13 • author / timestamp • hash: 9f3c…a71e • status: released • intended use • test standard • strain rate regime provenance impact query

Two features of this graph deserve emphasis. First, the dashed orange edge is a reverse query: when the coupon test is revised, lineage traversal identifies the material card as a downstream dependent, which in turn flags the solver deck and every run that used it. Second, the metadata callout is attached to nodes, not edges — a deliberate separation that keeps descriptive attributes stable while transformation history evolves.

Making Pedigree Operational

Pedigree only creates value when it is captured at the point of creation rather than reconstructed later. In practice this means three habits. Assign stable identifiers to every artifact — a content hash plus a human-readable name — so that "the DP780 card" becomes an unambiguous reference. Record transformations as edges with the tool, version, operator, and parameters used, ideally emitted automatically by the meshing, fitting, and solver scripts. Attach a fitness-for-purpose statement to each released artifact, stating the validated range (e.g., strain rates 0.001–100 s⁻¹, temperatures 20–80 °C) outside of which the data must not be extrapolated.

A minimal, practical pedigree record for a material card might look like this:

artifact: MAT_DP780_JC_GISSMO
  id: sha256:9f3c1d...a71e
  definition:
    material: DP780, lot H-2291
    model: Johnson-Cook plasticity + GISSMO damage
    units: mm-t-s-MPa
    valid_range: strain_rate 1e-3..1e2 /s, temp 20..80 C
  metadata:
    author: jdoe
    created: 2024-03-11T09:42Z
    solver: LS-DYNA R13.1
    status: released
  provenance:
    - coupon_test: TENS-H2291-07 (ASTM E8, RD, 0.001 /s)
    - reduction: DIC v2.4, gauge length 50 mm
    - fit: JC-Fit v1.8, least squares, 14 params
    - calibration: drop tower DT-2023-19, peak force delta 3.1%
  lineage:
    derived_from: [TENS-H2291-07, TENS-H2291-08]
    used_by: [DECK_FULLFRONTAL_C, DECK_SLED_B, REPORT_CRED_2024_02]

This record is deliberately compact, but it already supports the two queries that matter most in a credibility review: can I defend this number? (follow provenance backward) and what breaks if this number changes? (follow lineage forward). Teams that adopt such records early avoid the expensive archaeology that otherwise consumes weeks before every regulatory submission.

A common failure mode is treating metadata as sufficient. A file with a complete header block but no lineage cannot answer impact queries, and a lineage graph with no fitness-for-purpose statement invites misuse of data outside its validated range. Pedigree requires all four concepts working together.

The next layer of practice is deciding how much pedigree is enough. The answer is driven by consequence: a concept-stage stiffness check may need only definition and basic metadata, while a homologation model requires full provenance, bidirectional lineage, and an explicit credibility argument. Calibrating that rigor to the decision at hand is the central judgment in pedigree management — and the subject of the chapters that follow.

← Previous 📖 Contents Next →