3. Configuration management fundamentals

Configuration management (CM) in automotive CAE is not an administrative afterthought—it is the discipline that makes a simulation result traceable, reproducible, and defensible. A crash simulation that predicts a BIW intrusion of 142 mm is worthless in a design review unless you can state exactly which mesh revision, material card, solver version, and boundary-condition deck produced it. This chapter establishes the four CM pillars as they apply specifically to CAE artifacts: configuration items, baselines, version control, and change control.

3.1 Configuration Items: What Actually Gets Managed

A configuration item (CI) is any artifact that must be identified, stored, and controlled because it affects a deliverable. In software CM, CIs are source files and build scripts. In CAE, the CI set is broader and more heterogeneous, because a single result depends on a chain of inputs that live in different tools and formats.

For a typical full-vehicle frontal-impact model, the CI set includes:

• Geometry and CAD references — the released CAD revision (e.g., BIW_Door_Rear_LH_RevC.stp) that the mesh was built from.
• FE mesh and assembly — the solver deck (.key, .inc, .bdf) plus include-file hierarchy.
• Material and property cards — *MAT_024, *MAT_123, spot-weld and adhesive definitions, with their source (test report ID, coupon data).
• Boundary and initial conditions — barrier position, initial velocity, gravity, contact definitions.
• Control and output cards — *CONTROL_TERMINATION, *DATABASE_ requests, timestep settings.
• Solver and environment — LS-DYNA version, compiler, MPI configuration, hardware.
• Post-processing setup — the session file or script that extracts the reported metrics.

The practical rule: if changing it could change a reported number, it is a CI. This is why a CAE CI is best represented as a manifest rather than a single file—a bill of materials for the simulation.

3.2 Baselines: Freezing a Known-Good State

A baseline is an immutable snapshot of a CI set at a defined point, approved for a specific purpose. Baselines give you a stable reference to compare against and a rollback point when a change goes wrong.

In automotive CAE, baselines typically align with program milestones:

Once a baseline is declared, its contents are read-only. Any further work happens on a branch derived from it, never by editing the baseline in place. This is the single most important behavioral rule in CAE CM: baselines are immutable.

3.3 Version Control for CAE Artifacts

CAE version control differs from software version control in three ways: files are large and binary, diffs are rarely line-based, and the meaningful unit is often a set of files rather than one file. A practical scheme combines a version control system (Git, SVN, or a PLM-managed vault) with a manifest that pins every CI to an exact revision.

A manifest is the anchor. Here is a minimal example for one load case:

# manifest: FV_Frontal_50kph_RevC.yaml
loadcase: FV_Frontal_50kph
baseline: Design_Baseline_2024Q2
solver:
  name: LS-DYNA
  version: smp_d_R13.1
  mpi: 8
deck:
  main: model/main.key
  includes:
    - model/biw.inc
    - model/closure.inc
    - model/chassis.inc
  revision: git:9f3c2a1
materials:
  - id: 1001  card: "*MAT_024"  source: MAT-TR-2023-041
  - id: 1002  card: "*MAT_123"  source: MAT-TR-2023-057
boundary:
  velocity_kph: 50
  barrier: MDB_950kg_RevB
outputs:
  - GLSTAT
  - MATSUM
  - secforc
kpi:
  intrusion_mm: 142
  peak_accel_g: 48.3

With this manifest, anyone can reconstruct the exact run. The revision field (git:9f3c2a1) is the key: it ties the deck to a specific commit, so "which version did we use?" has a single unambiguous answer.

3.4 Change Control: Governing Modification

Change control is the process that decides whether, when, and how a CI may be modified. Without it, a mesh update made to fix a warning can silently invalidate a correlated baseline.

A workable CAE change-control loop has four stages:

1. Request — a change request (CR) states the CI, the reason, and the expected impact on KPIs.
2. Impact assessment — the CAE owner evaluates which load cases, baselines, and downstream reports are affected.
3. Approval and implementation — the change is made on a branch, tested, and merged only after review.
4. Verification and re-baseline — the change is validated against the KPI, and if accepted, a new baseline is declared.

The impact assessment is where CAE differs most from software. A single material card change can ripple across dozens of load cases. A practical impact matrix records, for each CR, the affected load cases and whether each must be re-run.

3.5 How the Four Pillars Interlock

The four concepts are not independent. Configuration items define what is controlled. Version control records how each item evolves. Baselines freeze a known-good set at a milestone. Change control governs how the set may move forward from that frozen state. Remove any one and the chain breaks: without CIs you cannot know what to freeze; without version control you cannot reconstruct; without baselines you have no reference; without change control you cannot trust that a baseline still means what it did.

3.6 A Practical Baseline and Change Workflow

The following sequence is a realistic, tool-agnostic workflow for a CAE team using Git for decks and a PLM system for CAD and test data.

1. Assemble the manifest. For each load case, list every CI with its source and revision. Store the manifest alongside the deck.
2. Declare the baseline. Tag the repository (e.g., git tag Design_Baseline_2024Q2) and record the tag in the PLM baseline record. Mark the baseline read-only.
3. Raise a change request. Example: "Update rear-door inner panel gauge from 0.7 mm to 0.8 mm to address side-impact intrusion."
4. Assess impact. The CAE owner identifies affected load cases (side impact, door slam, stiffness) and flags which must be re-run.
5. Branch and implement. Create a branch from the baseline tag, update the material/property card, and re-run the affected cases.
6. Verify against KPI. Compare the new intrusion value to the baseline. If the KPI improves and no regression appears, proceed.
7. Merge and re-baseline. Merge the branch, tag a new baseline (e.g., Design_Baseline_2024Q3), and update the manifest.

Two verification criteria matter at step 6: the target KPI (did the change achieve its goal?) and the regression check (did any unrelated load case degrade?). Both must be recorded in the change record, not just the final number.

3.7 Common Failure Modes

• Editing a baseline in place. Symptom: two engineers report different KPIs from the "same" baseline. Fix: enforce read-only tags and branch-based changes.
• Missing solver version in the manifest. Symptom: results shift after an IT upgrade. Fix: pin solver version and MPI configuration as CIs.
• Untracked material card edits. Symptom: correlation study cannot be reproduced. Fix: treat every material card as a CI with a source document ID.
• No impact assessment. Symptom: a "small" mesh fix invalidates a homologation baseline. Fix: require an impact matrix for every CR.

Configuration management for CAE is ultimately about trust: trust that a number in a report can be traced to a specific, reproducible set of inputs. The four pillars—configuration items, baselines, version control, and change control—are the mechanism that makes that trust possible.