Managing Loads, Models & Engineering Data

Analysis Quality Depends on Data Management

The quality of an engineering analysis depends not only on the mechanics, the model and the interpretation, but on the management of the data that flows through the analysis. CAD geometry, load definitions, material data, boundary conditions, scripts, meshes, results, test data and report data all constitute engineering evidence, and each must be identifiable, traceable and reproducible. An analysis that uses the wrong geometry revision, a superseded load set or an uncontrolled material dataset is wrong regardless of the quality of the model — not because the mechanics is incorrect, but because the analysis does not represent the item it claims to represent. Data management is not an administrative overhead that can be separated from the engineering; it is an integral part of the engineering, and its failure produces the same consequence as any other engineering error: a wrong decision.

A RESULT IS ONLY AS TRACEABLE AS THE INPUT DATA FROM WHICH IT WAS CREATED. A STRESS CONTOUR DERIVED FROM UNKNOWN GEOMETRY, AN UNCONTROLLED LOAD SET AND AN UNLABELLED MATERIAL DATASET IS NOT ENGINEERING EVIDENCE — IT IS A PICTURE.

The Source of Truth

The source-of-truth principle states that for every category of engineering data — geometry, loads, materials, boundary conditions — there should be a single, identified, authoritative source from which all analyses draw. If two analysts are working from different geometry revisions, or from different load sets that purport to be the same, the analyses cannot be compared and the decisions they support cannot be reconciled. The source of truth need not be a single file — it may be a controlled database, a managed folder structure or a configuration-managed repository — but it must be identifiable, and every analysis must record which version of each source it used. Without this, the organisation is not performing analyses on a defined product; it is performing analyses on whatever data each analyst happened to find.

Naming Conventions

A naming convention allows a model file to be identified without opening it, and it allows the relationship between models, loads and results to be understood without tracing through a folder structure. The convention should be consistent, enforced and meaningful — it should encode the information needed to identify the model, not merely a serial number. A conceptual naming convention might take the form Project_Component_ModelType_Revision, where each field is standardised and the revision is controlled. The specific convention should be defined by the organisation and applied consistently across all projects; the principle is that the name tells the engineer what the model is and which revision it represents.

• Project — The programme or project identifier.
• Component — The structural component or assembly being analysed.
• ModelType — The type of model: beam, shell, solid, global, submodel, non-linear, modal, etc.
• Revision — The controlled revision of the model, incrementing with each significant change.

Model Metadata

Beyond the filename, every model should carry metadata that records the inputs and conditions from which it was built. Metadata allows the model to be understood, reproduced and assessed for currency without re-deriving its construction from the contents. The metadata should be captured at the time the model is built — not reconstructed later, when the details may have been forgotten. The minimum metadata set includes the configuration, the model revision, the load revision, the material source, the solver and version, the analyst, the date and the status.

Data Lineage

Data lineage is the chain that connects each output to the inputs from which it was created. A stress result is derived from a model, which is derived from geometry, loads and materials. A margin table is derived from the stress result and an allowable. A report is derived from the margin table. If any link in the chain changes — the geometry is revised, the load set is updated, the material dataset is replaced — every downstream output must be assessed for whether it remains valid. Without lineage, this assessment cannot be made: the engineer does not know which results depend on which inputs, and a change in a load set cannot be traced to the results it affects. With lineage, the effect of a change can be assessed precisely, and only the affected evidence needs to be regenerated.

TRACEABILITY ALLOWS CHANGE TO BE ASSESSED RATHER THAN REDISCOVERED. WHEN A LOAD SET IS REVISED, THE ENGINEER SHOULD BE ABLE TO IDENTIFY WHICH RESULTS ARE AFFECTED AND RE-ASSESS THEM — NOT RE-DERIVE THE ENTIRE ANALYSIS FROM SCRATCH.

Automated Workflows

Scripted and automated workflows can dramatically improve the consistency and efficiency of analysis — but they also propagate mistakes rapidly. A script that applies the wrong load to every model, or that uses the wrong material dataset across a batch of analyses, will produce consistently wrong results with an appearance of authority that a manual process would not carry. Automation does not introduce errors that were not possible before; it makes existing errors faster and more uniform. The defence is to apply the same engineering rigour to the script as to the model: the script should be reviewed, its inputs should be controlled, its outputs should be checked, and its effect should be verified on a representative case before it is applied to a full batch. Automation is a tool, not a substitute for engineering judgement.

AUTOMATION MULTIPLIES BOTH GOOD PRACTICE AND BAD PRACTICE. A SCRIPT THAT ENSURES EVERY MODEL HAS THE CORRECT LOAD APPLIED IMPROVES QUALITY; A SCRIPT THAT APPLIES THE WRONG LOAD TO EVERY MODEL DEGRADES IT — FASTER AND MORE UNIFORMLY THAN ANY MANUAL PROCESS.

The Data Lineage Diagram

The diagram below shows a data lineage chain from CAD through to report, and illustrates what happens when a load set is revised mid-programme. Each downstream artefact depends on the one above it. When Load Set 3.2 is superseded by Load Set 3.3, every downstream result — the FE model, the result set, the margin table and the report — must be assessed for whether it remains valid. Without the lineage, the engineer would not know which results were affected; with the lineage, the assessment is targeted and efficient.

  CAD Rev D ──────► FE Model 7 ──────► Result Set 7B ──────► Margin Table 5 ──────► Report Rev C
                    ▲                      ▲                      ▲                      ▲
                    │                      │                      │                      │
  Load Set 3.2 ─────┘                      │                      │                      │
                                             │                      │                      │
  Material Dataset 4 ──────────────────────┘                      │                      │
                                                                   │                      │
  Allowable Dataset 2 ────────────────────────────────────────────┘                      │
                                                                                          │
  (Independently checked) ────────────────────────────────────────────────────────────────┘


  *** LOAD SET 3.3 IS RELEASED ***

  Which downstream evidence needs reassessment?

  CAD Rev D ──────► FE Model 7 ──────► Result Set 7B ──────► Margin Table 5 ──────► Report Rev C
                    │                      │                      │                      │
                    │                      │                      │                      │
  Load Set 3.3      │   AFFECTED            AFFECTED               AFFECTED               AFFECTED
  (replaces 3.2) ───┘  (re-run with          (regenerate)           (recalculate           (re-issue
                         new loads)                                  margins)              if changed)

  Material Dataset 4 ── NOT AFFECTED (unchanged)
  Allowable Dataset 2 ── NOT AFFECTED (unchanged)
  CAD Rev D ──────────── NOT AFFECTED (unchanged)

  => Only the load-dependent chain needs reassessment.
     Traceability allows the change to be ASSESSED, not REDISCOVERED.

Engineering Data Types and Their Management Needs

The table below summarises the principal types of engineering data, their source, whether they need revision control, their traceability requirement, the common failure mode and the consequence of that failure. Every data type has a characteristic failure mode, and the management approach should be designed to prevent it.

ASSUMING THAT BECAUSE A MODEL FILE EXISTS ON A SERVER IT IS IDENTIFIABLE, TRACEABLE AND REPRODUCIBLE CONFUSES STORAGE WITH MANAGEMENT. A FILE ON A SERVER IS STORED; A FILE WITH RECORDED METADATA, TRACEABLE INPUTS AND CONTROLLED REVISION IS MANAGED.