1. Deployable ML decision-support in automo

Computer-aided engineering (CAE) in automotive development produces enormous volumes of simulation data: crashworthiness runs, NVH modal analyses, CFD thermal maps, durability fatigue predictions, and multi-body dynamics sweeps. Yet the final engineering decisions — whether a BIW panel gauge can be reduced, whether a battery enclosure passes side-pole intrusion, whether a suspension bushing rate should change — are still made in meetings, design reviews, and sign-off documents. Deployable ML decision-support is the discipline of inserting machine-learning models into that decision loop in a way that is reproducible, auditable, and trusted by the engineers who must act on the output.

This chapter defines the scope of that discipline, identifies who consumes and governs it, and — most importantly — characterizes the gap between what a simulation predicts and what an engineering decision actually requires.

What "Deployable" Adds to "Machine Learning"

A surrogate model that predicts peak intrusion with 3% error is a research result. A deployable decision-support component must additionally satisfy four properties:

• Reproducibility — given the same inputs (geometry parameters, material cards, load cases), the same prediction and the same confidence interval are returned, regardless of operator or machine.
• Traceability — every prediction can be traced to a model version, a training dataset hash, and the CAE baseline it was validated against.
• Bounded validity — the system knows and communicates where it is extrapolating, and refuses or flags inputs outside the design-of-experiments (DoE) envelope.
• Actionability — the output is expressed in the units and thresholds the decision-maker already uses (e.g., "intrusion 142 mm vs. 150 mm target, margin +5.3%"), not as a raw normalized score.

The distinction matters because automotive CAE decisions carry regulatory and safety consequences. A model that is 97% accurate on average but silently wrong in the tail — exactly where crash decisions live — is worse than no model at all.

Scope: Where ML Decision-Support Fits in the CAE Workflow

It is useful to separate three layers that are often conflated:

The scope of this course is the third layer, with the second as its engine. A surrogate that never reaches a decision review has no deployable value; a decision review that ignores surrogate uncertainty is not decision-support, it is guessing with extra steps.

Stakeholders and Their Conflicting Requirements

Deployment fails most often for organizational, not algorithmic, reasons. The stakeholder map below is not decorative — each role imposes a hard constraint on the system design.

• CAE analyst — owns the baseline model. Requires that the ML layer never contradicts a validated solver result without explanation. Wants feature attribution (which parameter drove the prediction).
• Design engineer — owns the CAD parameter. Requires fast turnaround (seconds, not hours) and sensitivity direction ("increase gauge → intrusion decreases").
• Chief engineer / release authority — owns the sign-off. Requires explicit margin, uncertainty, and a clear statement of what was not evaluated.
• Functional safety / homologation — owns compliance. Requires traceability to the validated CAE model and evidence that the ML layer does not mask a regulatory failure mode.
• IT / platform — owns deployment. Requires containerized inference, versioned model registry, and no dependency on an analyst's local Python environment.

The Simulation-to-Decision Gap

The central intellectual content of this chapter is the gap. A simulation answers a physics question; a decision answers a risk question. Four concrete mismatches define the gap:

1. Deterministic vs. probabilistic. A crash run returns one intrusion value. A release decision needs the distribution — including manufacturing scatter in gauge (±0.05 mm) and material property scatter (±4% yield). A surrogate trained on nominal values inherits the nominal bias.
2. Point prediction vs. threshold comparison. The decision is not "what is the intrusion?" but "is P(intrusion > 150 mm) below the acceptable risk?" This requires calibrated uncertainty, not just a mean.
3. Single-discipline vs. multi-attribute. A gauge change that helps intrusion may hurt mass, cost, and NVH. The decision-support layer must expose the trade, not optimize one objective silently.
4. Model validity vs. design-space exploration. Optimization pushes designs toward the DoE boundary, precisely where surrogate error grows. Deployable systems must detect and report this.

The SVG below maps this gap as a signal chain: from CAE inputs, through the surrogate and its uncertainty, to the decision gate — showing where each stakeholder's requirement attaches.

A Worked Example: Gauge Reduction on a B-Pillar Reinforcement

Consider a side-impact decision. The baseline B-pillar reinforcement is 1.6 mm DP780; the program wants to evaluate 1.4 mm for a 1.8 kg mass saving. The CAE analyst has run a 120-point DoE varying gauge (1.2–1.8 mm), yield strength (550–720 MPa), and two load-case severities.

A Gaussian process surrogate is trained on peak intrusion. For the candidate (1.4 mm, 640 MPa, high severity), the model returns:

mean_intrusion   = 143.2 mm
std_intrusion    = 5.8 mm
target           = 150.0 mm
P(intrusion > 150 mm) = 0.121   # from GPR posterior, 10k samples
training_envelope = [1.2, 1.8] mm  -> candidate is INTERIOR

The decision-support layer does not say "pass" or "fail." It reports: the mean is 6.8 mm below target, but the 12.1% exceedance probability exceeds the program's 5% acceptance threshold. It also flags that the candidate sits inside the DoE envelope, so the surrogate is interpolating — a materially different statement from extrapolation.

The chief engineer now has a real decision: accept the mass saving with elevated risk, add a local reinforcement, or revert to 1.6 mm. That is decision-support. A bare "143.2 mm" would have hidden the risk entirely.

What This Course Will Build Toward

Across the following chapters, the components introduced here — DoE design, surrogate training, uncertainty calibration, envelope detection, and decision-gate logic — will be developed into a deployable pipeline. The recurring test is not model accuracy but decision quality: does the system help an engineer make a better, more defensible release decision than they could make from raw simulation output alone? Every technique in this course is judged against that standard.