2. Data quality dimensions for crash CAE

Crash CAE data quality is not a single property that a dataset either has or lacks. It is a composite of several independent dimensions, each of which can fail in different ways and each of which requires different detection logic. A model can be perfectly accurate in its geometry yet completely invalid in its material assignments. A result set can be complete in its output channels yet inconsistent in its unit conventions. Treating quality as one monolithic score obscures these distinctions and makes remediation impossible. This chapter defines the five core dimensions that structure the rest of the course: accuracy, completeness, consistency, timeliness, and validity.

Accuracy: Correspondence to Physical Reality

Accuracy measures how closely a CAE dataset or result reflects the physical system it represents. In crash simulation, accuracy failures are rarely gross errors; they are subtle deviations that survive visual inspection. A shell element mesh with an aspect ratio of 8:1 in a bending-dominated rocker panel will produce artificially stiff behavior without any error message. A spot weld represented by a single rigid element instead of a deformable connector will over-predict joint stiffness under peel loading.

Accuracy is assessed through comparison against reference data: physical test measurements, higher-fidelity simulations, or analytical solutions. For a frontal offset deformable barrier (ODB) test, a common accuracy check compares the simulated B-pillar intrusion at a specified time against the physical test measurement. A deviation exceeding 10–15 mm at peak intrusion typically indicates a modeling inaccuracy that warrants investigation. The key point is that accuracy is always relative to a defined reference and a defined tolerance; without both, the dimension is unmeasurable.

Completeness: Presence of All Required Elements

Completeness asks whether every required component, attribute, and output is present. In a crash CAE model, this spans multiple levels:

  • Model completeness: all structural parts, connections, and boundary conditions are present. A missing weld between the B-pillar and roof rail will not cause a solver error, but it will produce a physically wrong result.
  • Metadata completeness: material cards include strain-rate data, failure criteria, and element formulation flags. A missing strain-rate table for a high-strength steel under impact loading is a completeness defect.
  • Result completeness: all requested output channels (intrusion, acceleration, energy, section forces) are present for all required time steps.

Completeness is binary at the element level: a required item is either present or absent. This makes it the most straightforward dimension to automate, but only if the requirement set is explicitly defined. A common practice is to maintain a model manifest that lists every required part, connection type, material property, and output request, then check the actual model against this manifest programmatically.

Consistency: Internal Agreement Across the Dataset

Consistency requires that data elements agree with each other. In crash CAE, inconsistency appears in several recurring forms:

Inconsistency Type Example Detection Method
Unit mismatch Young's modulus in MPa while density is in kg/mm³ Cross-check derived quantities (wave speed, natural frequency)
Coordinate system conflict Local material orientation defined in a different frame than the element normal Compare local axes against global geometry
Naming inconsistency Part named "B-Pillar_Outer" in the model but "BPillarOut" in the result file Cross-reference model tree against output mapping
Temporal inconsistency Different output intervals for acceleration and intrusion channels Compare time-step vectors across channels

Consistency is particularly dangerous because inconsistent data often passes solver checks. The solver does not know that a density value is in the wrong unit system; it simply computes a wrong wave speed and produces a wrong result. Consistency checks must therefore be based on physical relationships, not just syntactic matching.

Timeliness: Availability Within the Decision Window

Timeliness measures whether data is available when it is needed for a decision. In crash CAE, this dimension is often overlooked because the focus is on the final result. But timeliness failures occur throughout the workflow:

  • A material card revision arrives after the simulation has already been submitted, forcing a re-run.
  • Mesh quality metrics are computed only after the full model is assembled, delaying the discovery of a critical defect.
  • Result extraction scripts run overnight, so the engineering team cannot evaluate the outcome until the next morning.

Timeliness is not about speed for its own sake. It is about aligning data availability with decision points. If a design review is scheduled for Friday, a simulation result that arrives on Monday is untimely regardless of its accuracy. Timeliness requirements should be defined per decision point, not as a global "as fast as possible" goal.

Validity: Conformance to Defined Rules and Constraints

Validity checks whether data conforms to a defined set of rules, formats, and constraints. This is the dimension most amenable to automated rule engines. In crash CAE, validity rules include:

  • Element quality thresholds: Jacobian ratio > 0.6, warpage < 15°, aspect ratio < 5:1 for shell elements in critical regions.
  • Material card syntax: all required fields present, values within physically plausible ranges (e.g., density between 1e-9 and 1e-7 kg/mm³ for metals).
  • Contact definitions: no initial penetration exceeding 0.5 mm, no missing contact pairs between adjacent parts.
  • Time-step control: mass scaling factor within acceptable limits, initial time step not exceeding the stable increment.

Validity is distinct from accuracy. A model can be valid (all rules pass) but inaccurate (rules are insufficient to capture the physics). Conversely, a model can be accurate but invalid (a rule is too strict for a specific case). Validity rules must be calibrated against known-good models and updated as modeling practices evolve.

Key distinction: Accuracy is about physical truth; validity is about rule conformance. Completeness is about presence; consistency is about agreement. Timeliness is about availability at the decision point. These five dimensions are independent: improving one does not automatically improve another, and a failure in any one can invalidate the entire analysis.

How the Dimensions Interact in Practice

The five dimensions are not isolated. A completeness defect (missing strain-rate data) can cause an accuracy failure (wrong energy absorption). A consistency defect (unit mismatch) can cause a validity failure (density outside plausible range). A timeliness failure (late material data) can force a completeness compromise (using a generic material card).

The following diagram shows the relationships between the five dimensions and the typical failure propagation paths observed in crash CAE workflows.

Five Data Quality Dimensions and Failure Propagation in Crash CAE Accuracy Physical correspondence Completeness All required elements Consistency Internal agreement Timeliness Availability at decision Validity Rule conformance Missing strain-rate data → wrong energy absorption Unit mismatch (MPa vs kg/mm³) → wrong wave speed Late material revision → forced re-run Invalid or Unreliable Simulation Result May pass solver checks but fail physical validation Validity Gate: Rule-Based Screening Catches rule violations, not physical inaccuracy Accuracy validation (test correlation) Dimension Failure mode Propagation Feedback loop

The diagram shows that completeness, consistency, and timeliness failures propagate toward an invalid or unreliable result. Validity acts as a rule-based gate that catches syntactic and constraint violations, but it cannot catch physical inaccuracy. Accuracy validation requires correlation against test data, which is a separate feedback loop that operates on a longer timescale.

Applying the Dimensions: A Practical Checklist

When evaluating a crash CAE dataset, the following questions operationalize the five dimensions:

Dimension Key Question Typical Check
Accuracy Does the result match physical reality within tolerance? Compare B-pillar intrusion against test measurement; check energy balance
Completeness Are all required parts, properties, and outputs present? Model manifest check; output channel inventory
Consistency Do all data elements agree with each other? Unit cross-check; coordinate system audit; naming cross-reference
Timeliness Is the data available at the decision point? Compare data delivery time against review schedule
Validity Does the data conform to defined rules and constraints? Element quality thresholds; material card syntax; contact penetration limits

Start with validity and completeness checks because they are the most automatable and catch the largest number of defects per unit of effort. Consistency checks require more domain knowledge but catch errors that validity rules miss. Accuracy checks are the most expensive and should be reserved for models that have passed the first three dimensions. Timeliness is a process metric, not a data metric, and should be tracked separately.

These five dimensions form the vocabulary for the remainder of this course. Every anomaly detection method, every quality metric, and every remediation workflow described in later chapters targets one or more of these dimensions. Understanding what each dimension means, how it fails, and how it interacts with the others is the foundation for building a systematic data quality program in crash CAE.