2. Traceability fundamentals for CAE

In vehicle development, a CAE result is only as credible as the evidence chain behind it. A crashworthiness simulation that predicts a 42 mm intrusion may support a design decision worth millions in tooling, but if no one can reconstruct which mesh revision, material card, solver build, and boundary condition set produced that number, the result is effectively unverifiable. Traceability is the discipline that makes every CAE result defensible: it records where data came from, how it was transformed, who touched it, and whether the same inputs can regenerate the same output.

This chapter defines the four foundational traceability concepts — data provenance, lineage, audit trails, and reproducibility — and shows how they interlock in a vehicle program. These are not abstract governance terms; they map directly to concrete CAE artifacts such as solver decks, material cards, load cases, and post-processing scripts.

Provenance: Where Did This Data Come From?

Provenance answers the question of origin and ownership for a single data object. For a CAE model, provenance captures the source of each constituent input: the CAD geometry release it was meshed from, the material test report that generated a stress-strain curve, the tire model supplier and version, and the engineer who authored the original deck. Provenance is object-level metadata — it describes a thing, not a process.

A practical provenance record for a material card might include:

• Source type: physical coupon test, supplier datasheet, or reverse-engineered from a validated model
• Test standard: e.g., ISO 6892-1 for tensile testing, with specimen orientation relative to rolling direction
• Strain rate: quasi-static (0.001 s⁻¹) versus high-rate (100 s⁻¹), since automotive steels are strain-rate sensitive
• Originator and date: the responsible engineer and the date the card was frozen
• Approval state: draft, reviewed, or released for program use

Without provenance, a downstream analyst cannot judge whether a material card is appropriate for a 50 km/h frontal impact or only for a quasi-static stiffness study. The card may be numerically valid but physically misapplied.

Lineage: How Did We Get Here?

Lineage is the directed graph of transformations linking inputs to outputs. Where provenance describes a node, lineage describes the edges. A single CAE result typically sits at the end of a chain: CAD release → geometry cleanup → meshing → assembly → boundary conditions → solver run → post-processing → report. Each edge represents a transformation that can change the result.

Lineage matters because it exposes derived dependencies. If a body-in-white mesh is updated to fix a distorted element, every downstream result — stiffness, modal, crash — inherits that change. A lineage-aware system can answer: "Which of the 340 open CAE results are affected by mesh revision R17?" Without lineage, this question requires manual archaeology across folders and email threads.

Audit Trails: Who Did What, and When?

An audit trail is an append-only, timestamped record of actions performed on data. It captures events rather than states: a material card was modified, a load case was approved, a solver run was submitted, a result was exported. Audit trails serve two purposes in vehicle programs: internal quality assurance and external regulatory or customer defensibility.

For CAE, a useful audit trail entry is not merely "file saved." It should record the actor, the action, the object, the before/after state where relevant, and the reason. A representative entry might read:

2024-03-11T14:22:07Z | j.okafor | MODIFY | MAT_DP600_1.2mm_v3.k
  field: strain_rate_table
  before: [0.001, 0.01, 0.1]
  after:  [0.001, 0.01, 0.1, 1.0, 100.0]
  reason: "Added high-rate points per test report TR-2024-0188"
  approval: pending

This level of detail lets a reviewer reconstruct not just that a change occurred, but why, and whether it was authorized. In safety-critical CAE — occupant restraint, battery enclosure intrusion, structural integrity — audit trails are often the difference between a result that can be submitted to a regulator and one that cannot.

Reproducibility: Can We Get the Same Answer Twice?

Reproducibility is the ability to regenerate a result from its recorded inputs and environment. It is the ultimate test of traceability: if provenance, lineage, and audit trails are complete, reproducibility should be achievable. In practice, CAE reproducibility fails for subtle reasons — solver version drift, compiler-dependent floating-point behavior, missing include files, or undocumented pre-processing steps.

A reproducibility package for a CAE run should contain, at minimum:

Reproducibility does not require bit-identical results in all cases; for explicit crash solvers, small numerical differences from parallel decomposition are expected. The practical standard is engineering reproducibility: the same inputs produce results within a defined tolerance, and any deviation is explainable.

How the Four Concepts Interlock

These four concepts are not independent checkboxes. Provenance without lineage tells you what a material card is but not which results depend on it. Lineage without audit trails tells you the transformation graph but not who authorized each change. Audit trails without reproducibility document activity but cannot prove the result is regenerable. Only when all four are present does a CAE result become fully traceable.

Consider a concrete failure mode. An analyst updates a spot weld failure criterion in the assembly model, reruns a frontal impact, and reports improved occupant compartment integrity. If the audit trail records the change but the lineage graph does not flag which other load cases share that assembly, a side impact result submitted two weeks earlier may now be inconsistent with the current model state — yet still appear valid in the report. Traceability systems prevent this by propagating change impact through the lineage graph and requiring re-validation of affected results.

Reproducibility Requirements in Vehicle Programs

Different CAE domains demand different reproducibility rigor. A modal analysis for NVH may tolerate solver version drift of a few percent in frequency. A crashworthiness result used for homologation typically requires exact solver version locking and documented tolerance bands. A battery thermal runaway simulation may require coupled solver versions and material properties validated against physical test.

Programs commonly define reproducibility tiers:

• Tier 1 — Exploratory: provenance and lineage recorded; reproducibility best-effort. Used for concept studies.
• Tier 2 — Design decision: full provenance, lineage, and audit trail; reproducibility package archived. Used for gate reviews.
• Tier 3 — Regulatory / safety-critical: all of Tier 2 plus independent re-run by a second analyst, solver version locked, and tolerance documented. Used for homologation submissions.

The tier assignment is a program management decision, but the CAE engineer must know which tier applies before starting work, because it determines what metadata must be captured and when. Retrofitting traceability after a result is produced is expensive and error-prone.

What This Means for Daily CAE Work

Traceability is not a separate task performed after simulation; it is embedded in how models are built, run, and reported. Practical habits include: freezing material cards with version numbers before use, recording solver version and run command in the job submission, hashing input decks, and linking every result to its parent model revision. These habits cost minutes per run but save days during a program audit or a design change cascade.

The next chapter builds on these fundamentals by examining how CAE data management systems implement provenance, lineage, and audit trails in practice — including metadata schemas, revision control, and change propagation.