2. Vehicle program context

A CAE exploration campaign does not exist in isolation. It is a service function embedded in a vehicle development program, and its value is measured by how well it informs the decisions that program must make at each milestone gate. A campaign that produces elegant DOE results three weeks after the gate decision has been made is worthless, no matter how rigorous the statistics. The first planning task, therefore, is not to choose a sampling method or a solver — it is to map the campaign onto the program's decision calendar.

Milestone gates as the campaign's time backbone

Most OEMs run a gate structure that is broadly similar across programs, even if the labels differ. A typical passenger-car program passes through a concept gate (architecture and package frozen at a coarse level), a styling/feasibility gate (surface and hardpoints converge), a design freeze or data-judgment gate (all major geometry released for tooling), a validation gate (physical prototypes confirm CAE predictions), and a launch gate. Each gate has an entry condition and an exit decision, and each exit decision consumes a specific class of CAE evidence.

The critical planning insight is that the evidence a gate consumes must be produced one gate earlier. At the concept gate, the program decides body architecture, material strategy, and powertrain mounting concept. The CAE evidence supporting those decisions — stiffness envelope studies, material trade-off sweeps, global mode targets — must therefore be delivered during pre-concept, when geometry is still a stick model or an implicit surface. Planning a detailed mesh-based DOE for the concept gate is a schedule error that cannot be recovered by adding CPU cores.

Attribute targets: translating program language into CAE quantities

Program targets arrive in customer-facing language: "the door should close with a solid feel," "the vehicle should feel planted at highway speed," "no squeak or rattle over cobblestone." These must be decomposed into measurable CAE quantities before a campaign can be designed. The decomposition is not a one-to-one mapping; a single subjective attribute typically depends on several CAE responses, and a single CAE response often feeds several attributes.

Consider a body torsional stiffness target. The program states a target of 28 kN·m/deg for the body-in-white. That number is itself a derived quantity: it comes from a cascade that starts with a handling/ride target, passes through suspension attachment stiffness requirements, and lands on a global body stiffness allocation. The CAE campaign planner must know where in that cascade the target sits, because it determines the boundary conditions. A 28 kN·m/deg target measured with the body clamped at the rear shock towers is not the same physical quantity as one measured with free-free boundary conditions and inertia relief. If the campaign uses the wrong boundary condition, the DOE will produce a beautifully converged answer to the wrong question.

For each attribute, the planner should produce a target card containing: the attribute name, the CAE response quantity, the target value and tolerance, the boundary condition definition, the load case, the frequency range (for NVH), and the gate at which the target must be demonstrated. This card becomes the contract between the CAE team and the attribute owner.

Cross-functional deliverables and the interface map

A CAE exploration campaign rarely delivers to a single customer. The same DOE run may produce stiffness sensitivities for the body structures group, joint loads for the closures team, and modal data for the NVH group. Planning the campaign means planning these interfaces explicitly, because each consumer needs a different output format, a different level of detail, and a different delivery date.

The most common failure mode is not technical — it is a mismatch between what the CAE team considers "done" and what the receiving function considers "usable." A body structures engineer needs a sensitivity ranking with respect to gauge and material, expressed in engineering units. An NVH engineer needs mode shapes and frequencies in a format that can be imported into the full-vehicle model. A manufacturing engineer needs to know which design variables are robust to stamping variation. These are three different deliverables from one campaign, and they must be specified in the campaign plan, not discovered at delivery time.

Building the campaign plan: a worked structure

With the gate map, target cards, and interface list in hand, the campaign plan itself becomes a scheduling and scoping exercise. A practical structure for a body stiffness exploration campaign at the design-freeze gate might look like this:

1. Decision statement: "Select gauge and material grade for 14 body panels to meet the 28 kN·m/deg torsional target with minimum mass, robust to ±0.15 mm stamping thickness variation."
2. Design variables: 14 panel gauges (continuous, 0.6–2.0 mm), 3 material grades (discrete: mild steel, HSLA 340, DP 590).
3. Responses: torsional stiffness (kN·m/deg), bending stiffness (kN/mm), first global mode (Hz), mass (kg).
4. Sampling: Latin Hypercube with 120 points for the continuous gauges, crossed with the 3 material grades at a reduced 40-point set, giving 160 total runs.
5. Model: full trimmed body, 2.1 million elements, implicit linear static for stiffness, Lanczos eigensolver for modes.
6. Deliverables and dates: sensitivity ranking to body structures (week 6), mode shape set to NVH (week 7), joint load envelope to closures (week 7), robustness report to manufacturing (week 8).
7. Gate alignment: all deliverables due 2 weeks before the design-freeze gate review, leaving time for the attribute owner to review and for one confirmation run if a target is marginal.

The 2-week buffer is not padding. It is the minimum time required for the receiving function to review the results, ask a clarifying question, and for the CAE team to run a confirmation analysis on the recommended design point. Campaigns planned without this buffer routinely deliver on the gate date and are therefore useless.

Common planning failures and their symptoms

Three failure patterns recur across programs. First, fidelity mismatch: the campaign uses a model too coarse to resolve the design variable's effect. Symptom: sensitivity rankings that are dominated by numerical noise, with R² below 0.6 for the metamodel. Remedy: refine the mesh in the load path of the variable, or reduce the variable range to the region where the coarse model is valid.

Second, boundary condition drift: the target card specifies clamped rear towers, but the model uses free-free with inertia relief because that was faster to set up. Symptom: predicted stiffness is 15–20% higher than the target card value, and the team spends a week reconciling before discovering the mismatch. Remedy: enforce the boundary condition in the target card as a hard input to the model setup, and verify it with a single baseline run before launching the DOE.

Third, deliverable format mismatch: the NVH group receives mode shapes in a solver-specific binary format they cannot import. Symptom: a two-week delay while the CAE team re-exports. Remedy: specify the output format in the interface map at planning time, and produce one sample deliverable early to confirm the receiving function can consume it.

The campaign plan is a contract. It commits the CAE team to producing specific evidence, in a specific format, by a specific date, to support a specific program decision. When the plan is built from the gate structure backward — rather than from the solver forward — the exploration campaign becomes what it should be: a decision-support instrument, not a simulation exercise.