Configuration Control & Requirement Traceability

What Is Being Demonstrated?

Configuration control and requirement traceability demonstrate that the structural evidence — the loads, the models, the results, the margins, the reports — corresponds to a defined, controlled configuration and can be traced from requirement to conclusion through a chain of controlled revisions. This is the backbone of defensible substantiation. Without configuration control, the engineer cannot know which version of the design the evidence supports. Without traceability, the engineer cannot know which requirement the evidence addresses. Together, they ensure that the substantiation argument is not just correct at a point in time, but maintained as correct as the design evolves. A substantiation package without configuration control and traceability is a snapshot — accurate when produced, but of unknown validity at any later date.

A RESULT THAT CANNOT BE TRACED TO ITS INPUTS IS DIFFICULT TO USE AS FORMAL EVIDENCE.

Why Configuration Control Matters

Engineering design is iterative. The CAD model is revised. The load case is updated. The FE model is rebuilt. The material allowable is corrected. The requirement is reinterpreted. Each change has the potential to invalidate existing evidence. Configuration control is the process that identifies which evidence is affected by which change and ensures that affected evidence is reviewed and, if necessary, revised. Without it, changes propagate silently: a load update that should trigger re-analysis does not; a model revision that should trigger re-reporting does not; a material correction that should trigger a margin recalculation does not. The result is a substantiation package that appears complete but is actually stale — the evidence does not match the current design.

• Design is iterative — changes are normal, not exceptional.
• Each change can invalidate existing evidence — configuration control identifies what is affected.
• Without configuration control, changes propagate silently and the evidence becomes stale.
• Configuration control ensures that evidence is reviewed and revised when the design changes.

The Traceability Chain

Traceability is the property that allows any conclusion in the substantiation to be traced back through every input and every intermediate step to the requirement it addresses. The chain links the requirement to the load case, the load case to the analysis model, the model to the failure assessment, the failure assessment to the margin, the margin to the test or correlation evidence and the evidence to the compliance conclusion. Each link is a controlled relationship: if any element changes, the dependent elements are identified and reviewed. The traceability chain is what makes the substantiation auditable — an independent reviewer or an authority can follow the chain from conclusion to requirement and verify every step.

Traceability chain:

  REQ-XXX  ──►  LOAD CASE LC-XX  ──►  ANALYSIS MODEL FE-XX  ──►  FAILURE ASSESSMENT FA-XX
      │               │                    │                        │
      │               │                    │                        │
      │               │                    │                        ▼
      │               │                    │               MARGIN TABLE MT-XX
      │               │                    │                        │
      │               │                    │                        ▼
      │               │                    │               TEST / CORRELATION TE-XX
      │               │                    │                        │
      │               │                    │                        ▼
      │               │                    │               REPORT SECTION
      │               │                    │                        │
      │               │                    │                        ▼
      │               │                    │               COMPLIANCE STATUS
      │               │                    │
      │               │                    └── If FE-XX is revised,
      │               │                        FA-XX, MT-XX and the
      │               │                        report section must
      │               │                        be reviewed.
      │               │
      │               └── If LC-XX is revised,
      │                       FE-XX, FA-XX, MT-XX and the
      │                       report section must be reviewed.
      │
      └── If REQ-XXX is reinterpreted,
              the entire chain must be reviewed.

A change at any node propagates to all downstream nodes.

Elements of the Traceability Chain

Each element in the traceability chain is a controlled engineering artefact with a unique identifier, a revision and a defined relationship to the other elements. Understanding what each element represents and how it is controlled is essential to maintaining the chain.

CAD to FE Model Traceability

A common weakness in configuration control is the link between the CAD model and the FE model. The CAD model is the design definition — the geometry that will be manufactured. The FE model is an idealisation of that geometry — it may omit features, idealise fillets, merge details and use mid-surface representations. The FE model must be traceable to a specific revision of the CAD model. If the CAD is revised — a thickness change, a feature added, a fillet modified — the FE model must be reviewed to determine whether it needs to be updated. Without this traceability, the FE model may represent an outdated version of the design, and the analysis results may not apply to the current configuration.

• The FE model must reference the CAD revision it was built from.
• When the CAD is revised, the FE model is flagged for review.
• The engineer determines whether the CAD change requires an FE model update.
• If the FE model is updated, all dependent results, margins and reports are flagged for review.
• If the FE model is not updated, the engineer documents why the CAD change does not affect the analysis.

An FE model that is not linked to a CAD revision is a model of unknown configuration. The analysis results cannot be confidently associated with the design.

Load Revision Control

Loads are one of the most frequently revised inputs in a structural programme. As the vehicle definition matures, the load model is updated, the load cases are refined and the load envelope may change. Each load revision has the potential to invalidate existing analysis. Load revision control ensures that each analysis references a specific revision of the load case and that when the load is revised, the affected analyses are identified and reviewed. The load document should carry a revision identifier, and each analysis report should reference the specific load revision used. If the loads are revised, the analysis is flagged and the engineer determines whether re-analysis is required.

Load revision propagation:

  Load model Rev A
      │
      ├──► Load case LC-01 (Rev A) ──► Analysis FE-01 ──► Report STR-01
      │                                        │                  │
      │                                        │                  │
      │                                   If LC-01 is revised    Report must
      │                                   to Rev B...             be reviewed
      │                                        │
      │                                        ▼
      │                                   FE-01 must be
      │                                   re-run or assessed
      │
      └──► Load case LC-02 (Rev A) ──► Analysis FE-02 ──► Report STR-02

A load revision propagates to every analysis that uses that load case.

Requirement Traceability

Requirement traceability ensures that every requirement is addressed by evidence and that every piece of evidence addresses a requirement. The compliance matrix is the primary tool — it lists every requirement, the means of compliance, the evidence reference and the status. The traceability must be bidirectional: from requirement to evidence (does every requirement have evidence?) and from evidence to requirement (does every piece of evidence support a requirement?). Analysis that is performed but not linked to a requirement is orphaned work — it does not contribute to compliance, regardless of its quality. Evidence that is referenced but does not actually address the requirement is a false link — the matrix says "closed" but the evidence does not support the claim.

Bidirectional traceability is the test: every requirement must have evidence, and every piece of evidence must address a requirement. Orphaned analysis and false links are both gaps in the substantiation.

Revision Management

Revision management is the process that controls changes to the engineering artefacts in the traceability chain. Each artefact — requirement, load case, model, report — has a revision identifier. When an artefact is changed, the revision is incremented and the change is recorded. The change record identifies what changed, why it changed, who made the change and what downstream artefacts are affected. Revision management ensures that the substantiation evidence has a clear history: the reviewer can see what has changed since the evidence was produced and whether the change has been assessed. Without revision management, the evidence is a static snapshot of unknown currency.

• Each artefact has a unique identifier and a revision.
• Changes are recorded with what, why, who and what is affected.
• Downstream artefacts are flagged for review when an upstream artefact changes.
• Superseded revisions are archived, not destroyed — the history is preserved.
• The current revision of each artefact is clearly identifiable.

Configuration Control Checklist

The following checklist addresses the essential elements of configuration control and traceability. A substantiation package that fails any of these is a package with gaps in its evidence chain.

• Each requirement has a unique identifier and is in the compliance matrix — No requirement is unstated or untracked.
• Each load case has a revision identifier — Analyses reference the specific load revision used.
• Each FE model references the CAD revision it was built from — The model configuration is known.
• Each analysis report references the model, load case and allowables used — The inputs are identified and traceable.
• Each margin table references the failure assessment and allowable — The margin source is traceable.
• Each report section references the evidence it presents — No evidence is presented without a source.
• When any upstream artefact is revised, downstream artefacts are flagged — The change propagation is identified.
• The compliance matrix references the specific revision of each evidence document — The evidence version is controlled.
• Superseded revisions are archived and identifiable — The evidence history is preserved.

Common Failures in Configuration Control

The following failures recur in structural programmes and undermine the traceability of the evidence chain.

• FE models are not linked to CAD revisions — the model configuration is unknown.
• Load revisions are not propagated — analyses use outdated loads without re-assessment.
• Reports are revised without identifying which results changed — the reviewer cannot determine what is affected.
• The compliance matrix references reports by title without revision — the evidence version is ambiguous.
• Allowable updates are not propagated — margins use outdated material data.
• Orphaned analysis exists — work is performed but not linked to any requirement.
• Changes are made informally — an engineer updates a model or a load without recording the change.

Key Takeaways

• Configuration control ensures that the evidence matches the current design — not a past snapshot.
• Traceability links requirement to load case to model to failure assessment to margin to report to compliance status.
• A change at any node in the chain propagates to all downstream nodes — the propagation must be identified and managed.
• The FE model must be traceable to a CAD revision; the analysis must be traceable to a load revision.
• Requirement traceability is bidirectional — every requirement has evidence, and every piece of evidence addresses a requirement.
• Revision management records what changed, why and what is affected — the evidence history is preserved.
• A result that cannot be traced to its inputs is difficult to use as formal evidence.