4. CAE project planning

CAE project planning converts a vehicle program's engineering intent into a time-phased, resource-aware analysis plan. Unlike a generic project schedule, a CAE plan must respect the physics of the development loop: geometry must exist before meshing, mesh quality must be verified before solving, and results must be interpreted before design decisions can be made. The plan therefore has to encode both task logic (what must precede what) and program logic (when the vehicle program needs the answer). When these two logics conflict, the CAE planner must negotiate scope, fidelity, or timing — not simply compress durations.

From WBS to Network Logic

Start by decomposing the CAE scope into a work breakdown structure aligned with the vehicle program's subsystem architecture. A typical body-in-white (BIW) durability scope might decompose into: load case definition, CAD cleanup, meshing, material and connection modeling, solver setup, solve, post-processing, correlation, and reporting. Each work package should have a single accountable owner, a defined input artifact, and a defined output artifact.

The critical planning step is converting the WBS into a dependency network. Four dependency types are relevant in CAE:

• Finish-to-Start (FS) — the default: meshing cannot start until CAD cleanup is released.
• Start-to-Start (SS) with lag — solver setup can begin once the first mesh region is frozen, even while other regions are still being meshed.
• Finish-to-Finish (FF) — post-processing cannot finish before the solve finishes.
• External dependencies — the CAE task depends on a CAD release, a test measurement, or a supplier model that lies outside the CAE team's control.

External dependencies are the most common source of schedule slip. They should be modeled explicitly with a required-by date and an escalation owner, not hidden inside a task duration.

Estimating Duration and Float

Duration estimates should be built from measurable drivers rather than intuition. For a linear static stiffness load case on a full BIW model, a defensible estimate uses element count, solver throughput, and a calibration factor:

Solve wall-clock (h) ≈ (DOF × iterations) / (solver_throughput × parallel_efficiency)
Example (illustrative, not measured):
  DOF            = 12.0e6
  iterations     = 1 (linear static)
  throughput     = 4.0e6 DOF/h/core
  cores          = 32
  parallel_eff   = 0.75
  → 12.0e6 / (4.0e6 × 32 × 0.75) ≈ 0.125 h solve
  Add I/O, setup, and post: total task ≈ 4–6 h

These numbers are illustrative. The point is that the estimate is traceable: if the model grows to 20 million DOF, the solve term scales predictably, and the planner can see whether the task still fits the window. Non-solver tasks — CAD cleanup, meshing, connection modeling — are usually estimated from historical throughput (for example, elements per engineer-day) and should carry a contingency proportional to geometry novelty.

Once durations and dependencies are set, run a forward and backward pass to compute early start, late start, and total float. Tasks on the critical path have zero float; tasks with float can absorb delays without moving the milestone. In CAE, the critical path frequently runs through CAD release → mesh → solve → correlation, while reporting and documentation sit on paths with float.

Milestones and Program Timing Integration

CAE milestones must be anchored to vehicle program gates. Typical program gates include concept freeze, A-surface freeze, design freeze, tooling kick-off, and start of production. Each gate imposes a decision that CAE must inform. The planning task is to work backward from the gate to determine the latest acceptable CAE result date, then forward to determine the latest acceptable model freeze date.

The "model freeze" column is the CAE planner's real constraint. If the CAD release needed for design-freeze crash analysis arrives only four weeks before the gate, the plan is infeasible and must be renegotiated — either by using a simplified model earlier, by parallelizing load cases, or by shifting the decision to a later gate with a documented risk.

Resource Leveling and Solver Capacity

CAE schedules are constrained by more than engineering headcount. Solver licenses, HPC queue capacity, and post-processing workstations are finite. A plan that schedules five full-vehicle crash solves in the same week will fail in the queue even if every engineer is available. Resource leveling should therefore treat solver hours and license tokens as first-class resources alongside engineer-days.

Baseline, Change Control, and Progress Tracking

Once the network is leveled, freeze it as the baseline. Every subsequent change — a new load case, a CAD revision, a solver version upgrade — should be assessed for its impact on the critical path before being accepted. A lightweight change log with fields for change ID, affected tasks, float consumed, milestone impact, and approver is sufficient for most CAE teams.

Progress tracking should use physical progress, not percent-complete claims. For a meshing task, physical progress is the fraction of the model volume meshed and quality-checked. For a solve task, it is the fraction of load cases converged. This distinction matters because a task that is "90% complete" for three weeks is usually a task with an unresolved modeling problem.

Visualizing the Integrated Plan

The diagram below shows how a CAE analysis network connects to vehicle program gates. It is a dependency-and-milestone view, not a simple sequence: note the SS+lag relationship between meshing and solver setup, the external CAD release dependency, and the backward-derived model freeze dates that anchor each analysis branch to a program gate.

Deliverable: CAE Planning Checklist

The following checklist can be used directly when building or reviewing a CAE project plan. Each item maps to a failure mode observed in real programs.

The checklist is deliberately narrow: it covers only the planning decisions that most often determine whether a CAE schedule survives contact with the vehicle program. Broader project management concerns — budget, procurement, staffing — are handled at the program level and should not be duplicated inside the CAE plan.