3. Decision-support framing

In a deployable ML decision-support system for automotive CAE, the single most consequential design decision is not the choice of model architecture — it is the framing. Framing means translating an engineering objective ("improve crashworthiness," "reduce cabin boom") into a formal ML problem type and a precisely defined target variable. Get this wrong and no amount of hyperparameter tuning will recover the value; get it right and even a modest gradient-boosted model can become a trusted decision aid.

The four CAE disciplines that dominate body and closure development — crash, NVH, thermal, and durability — each carry a distinct objective structure. Crash is dominated by constraint satisfaction and pass/fail thresholds. NVH is dominated by continuous spectral targets and mode alignment. Thermal is dominated by transient field evolution and peak-value limits. Durability is dominated by cumulative damage and fatigue-life distributions. These differences propagate directly into the ML problem type, the label definition, and the loss function.

From Engineering Objective to ML Problem Type

The mapping is not one-to-one. A single CAE objective can often be framed as classification, regression, or ranking, and the correct choice depends on how the decision will actually be consumed downstream. Consider a B-pillar intrusion requirement: the engineer ultimately decides "does this design pass?" — a binary decision. But the same simulation output also yields a continuous intrusion value in millimeters. If the decision-support system only needs to triage hundreds of concept variants, a classifier with a calibrated probability is appropriate. If the engineer needs to trade intrusion against mass, a regressor predicting the continuous value is more useful. If the system must rank variants for a design-of-experiments campaign, a learning-to-rank formulation is the natural fit.

The practical rule is: frame the ML problem to match the decision granularity, not the simulation output granularity. Simulation outputs are continuous fields; decisions are often discrete, comparative, or threshold-based.

Target Variable Definition: The Hardest Part

Target variables in CAE-derived ML are rarely the raw solver output. They are derived quantities that encode engineering intent. Three definitional choices matter most:

  • Point vs. field targets. A single scalar (peak acceleration, max temperature) is easy to regress but discards spatial information. A field target (full displacement contour) requires dimensionality reduction — PCA, autoencoders, or proper orthogonal decomposition — before regression. For crash, scalar targets usually suffice for early-stage screening; for thermal, field targets are often necessary because the location of the peak matters as much as its magnitude.
  • Absolute vs. normalized targets. Raw values depend on load case severity, mesh density, and solver settings. Normalizing by a baseline design or by the requirement threshold makes the target transferable across projects and reduces distribution shift.
  • Deterministic vs. probabilistic targets. A single simulation run gives a deterministic value. But durability and crash often require scatter — material variability, manufacturing tolerance. If the decision must account for risk, the target should be a distribution parameter (mean and standard deviation of fatigue life) rather than a single number.
Framing checklist for a new CAE-ML task:
  1. What decision does the engineer make with this output? (pass/fail, rank, trade-off curve)
  2. What is the smallest target variable that supports that decision?
  3. Is the target scalar or field? If field, what reduction preserves the decision-relevant information?
  4. Does the target need normalization to be comparable across load cases or projects?
  5. Is a point estimate sufficient, or is a distribution required?

Discipline-Specific Mapping

The table below summarizes how the four CAE disciplines typically map to ML problem types and target variables. These are starting points, not rigid rules — the decision granularity always overrides the default.

CAE Discipline Typical Engineering Objective Common ML Problem Type Representative Target Variable Key Framing Risk
Crash Meet intrusion / acceleration limits Binary classification or regression Peak intrusion (mm), HIC, peak deceleration (g) Class imbalance when most designs pass
NVH Align modes, reduce cabin noise Regression or multi-output regression Mode frequency (Hz), SPL at driver ear (dB) Mode ordering ambiguity across variants
Thermal Keep peak temperature below limit Regression (scalar or field) Max temperature (°C), time-to-limit (s) Field target dimensionality
Durability Ensure fatigue life exceeds target Regression or survival analysis Cycles to failure, damage index Right-censored data, scatter

Worked Example: Framing a Durability Prediction Task

Suppose the objective is to predict whether a suspension lower control arm will survive a 200,000-cycle durability schedule. The CAE output is a stress history at critical locations, from which a fatigue solver computes damage. The raw output is a damage index per element — a field. The engineering decision is pass/fail against a damage threshold of 1.0.

A naive framing would regress the full damage field. A better framing: extract the maximum damage index across the component, normalize it by the threshold, and frame the task as binary classification with a calibrated probability. The target variable becomes P(damage_max > 1.0 | design parameters). This directly supports the decision, handles the threshold naturally, and allows the engineer to set a conservative probability cutoff (e.g., 0.1) for safety-critical parts.

If the team later needs to rank designs for mass reduction, the same underlying data can be reframed as regression on log(damage_max) — the log transform stabilizes variance across orders of magnitude and makes the regressor more robust to outliers.

Visualizing the Framing Decision Path

The SVG below maps the decision path from CAE objective to ML problem type and target variable. It is organized by decision granularity — the primary axis that determines framing — and shows how the four disciplines branch into different target definitions.

CAE Objective → ML Problem Type → Target Variable Framing is driven by decision granularity, not simulation output granularity Decision granularity: Pass / Fail Rank / Compare Trade-off / Optimize Risk / Distribution Crash Intrusion, HIC Peak decel Classification P(pass | design) Target: peak intrusion normalized by threshold NVH Mode freq, SPL Transfer function Multi-output reg. Mode 1, 2, 3 (Hz) Target: mode freq vector sorted, matched to baseline Thermal Peak temp, gradient Time-to-limit Regression (scalar) or field via POD Target: max temperature + location (x, y, z) Durability Damage, cycles Stress history Survival / regression log(damage_max) Target: P(damage > 1.0) or cycles-to-failure Framing Principles 1. Match decision granularity 2. Normalize targets by threshold or baseline 3. Prefer scalar over field unless location matters 4. Log-transform skewed targets (damage, life) 5. Use distribution targets for risk-based decisions 6. Validate target definition with domain engineer 7. Keep framing reversible — reframe when decision granularity changes

Common Framing Failures and How to Detect Them

Three framing failures recur in production CAE-ML systems. First, target leakage through preprocessing: normalizing the target using statistics computed over the full dataset before splitting into train and test. This inflates validation metrics and collapses in deployment. Always compute normalization statistics on the training fold only.

Second, mode-ordering ambiguity in NVH: when predicting multiple mode frequencies, the model may learn to predict the first mode as the lowest frequency, but if two modes cross over across design variants, the target vector becomes discontinuous. The fix is to match modes to a baseline by modal assurance criterion (MAC) before training, or to predict the sorted frequency vector and accept that mode identity is lost.

Third, class imbalance in crash classification: if 95% of designs pass, a classifier that always predicts "pass" achieves 95% accuracy but is useless. The target should be reframed as a calibrated probability with a decision threshold tuned to the cost of false negatives, or the problem should be reframed as regression on the continuous intrusion value.

Warning: A target variable that is easy to predict is not necessarily a target variable that is useful to predict. Always trace the target back to the decision it supports. If the decision can be made without the target, the ML problem is mis-framed.

Practical Guidance for Deployment

When deploying a decision-support system, the framing must be documented as part of the model card. Record: the engineering objective, the decision granularity, the ML problem type, the exact target variable definition (including normalization and transformation), the threshold or ranking logic, and the known framing risks. This documentation is what allows a downstream engineer to trust the system — or to reframe it when the decision context changes.

Framing is not a one-time step. As the design program moves from concept screening to detailed validation, the decision granularity shifts from pass/fail to trade-off optimization, and the ML problem type must shift with it. A well-architected decision-support system keeps the framing layer explicit and modular, so that the same underlying simulation data can be reframed without retraining from scratch.

← Previous 📖 Contents Next →