3. Project scheduling fundamentals for CAE

CAE scheduling is not a generic project-management exercise. A crash simulation, a CFD thermal run, or a full-vehicle NVH model each consumes scarce solver licenses, HPC queue time, and a small pool of specialist engineers. The schedule must therefore express not only what analysis is required, but which resource performs it, how long the solver actually runs, and which vehicle program gate the result must feed. This chapter builds the four structural pillars of a CAE schedule: the Work Breakdown Structure (WBS), activity sequencing, dependency logic, and milestone mapping to program gates.

Work Breakdown Structure for CAE Deliverables

A WBS decomposes the CAE scope into deliverable-oriented packages. For automotive CAE, a three-level structure works well: Level 1 is the vehicle program (e.g., "Program X — Body Structure CAE"); Level 2 is the attribute or subsystem (Body-in-White durability, crashworthiness, NVH, thermal, aerodynamics); Level 3 is the individual analysis deliverable, such as "Front crash — 64 km/h ODB, BIW + closures."

The critical rule is that Level 3 packages must be estimable and assignable. "Crash CAE" is not a work package; "Frontal ODB simulation, mesh through report, 3 load cases" is. Each package should carry a unique ID, an owner, an estimated effort in engineer-days, an estimated solver wall-clock time, and the required software/license type. A practical CAE WBS dictionary entry looks like this:

WBS ID:        3.2.1
Deliverable:   Frontal ODB 64 km/h — BIW + closures
Owner:         Crash CAE Engineer (0.5 FTE)
Inputs:        CAD release R3.2, material cards v7, barrier model
Effort:        8 engineer-days (meshing 3, setup 2, run 1, report 2)
Solver:        Explicit, 16 cores, ~14 h wall-clock per run
License:       2 × crash solver tokens
Output:        LS-DYNA d3plot, intrusion report, energy balance
Gate link:     G2 (Design Freeze) — 2025-06-14

Notice that effort and solver time are separated. A common scheduling error is to treat a 14-hour solver run as 14 hours of engineer time; in reality the engineer is free during the run, but the HPC queue and license pool are not. Both must appear in the resource plan.

Activity Sequencing and Dependencies

Once packages exist, they must be sequenced. CAE activities rarely run in a simple line because geometry, mesh, and load data flow between them. Four dependency types cover almost all CAE logic:

• Finish-to-Start (FS) — the default. Mesh must finish before the solver run starts.
• Start-to-Start (SS) — parallel work with a lag. Crash setup can start once meshing is 50% complete, with a 2-day lag.
• Finish-to-Finish (FF) — the report cannot finish until the last load case finishes.
• Start-to-Finish (SF) — rare, but used when a legacy model must remain available until a new one is validated.

Two dependency traps are specific to CAE. First, data dependencies are often mistaken for schedule dependencies: a CFD engineer may wait for CAD when a simplified geometry would suffice for an early trend run. Second, resource dependencies masquerade as logic: two crash runs are not logically sequential, but they compete for the same 16-core license pool, so the schedule must serialize them through resource leveling rather than a hard FS link.

Milestone Mapping to Vehicle Program Gates

Vehicle programs run on gates — typically G0 (concept), G1 (architecture freeze), G2 (design freeze), G3 (tooling kick-off), G4 (production validation), G5 (SOP). CAE milestones are not the gates themselves; they are the analysis evidence required to pass a gate. Mapping means working backward from each gate date to place CAE milestones.

Consider G2 (Design Freeze). To support the gate decision, the program needs a crashworthiness sign-off, a stiffness report, and a thermal risk assessment. Working backward: the sign-off report needs 5 days to write and review; the final solver run needs 14 hours plus 2 days of queue contingency; the mesh needs 3 days; CAD release R3.2 arrives 10 days before G2. That leaves a negative float of roughly 2 days — a signal that either the CAD release must move earlier or the analysis scope must be reduced to a trend study for the gate.

The table below shows a compact milestone map for one subsystem. Dates are illustrative.

Each milestone must have a single accountable owner and a binary completion criterion. "Crash analysis 80% done" is not a milestone; "ODB run completed with energy balance error < 5%" is.

Building the Network and Reading Float

With packages, dependencies, and milestones defined, the schedule becomes a network. The critical path is the longest chain through the network — it determines the earliest possible gate support date. Total float on a non-critical activity tells you how much slip it can absorb before it threatens the gate. In CAE, float is usually thin on the meshing-to-solver-to-report chain and generous on exploratory studies.

The SVG below shows a representative CAE schedule network for the frontal crash deliverable, including the parallel stiffness and thermal branches, the shared HPC/license resource, and the G2 milestone where all three converge.

Reading the network: the critical path runs CAD → Meshing → Crash Setup → Crash Solver → Crash Report → G2. The stiffness and thermal branches have float, but they share the HPC pool with the crash solver. If the crash run slips by one day, resource leveling may push the stiffness solver later, consuming its float. This is why CAE schedules must be resource-loaded, not just logic-linked.

Practical Scheduling Checks

Before baselining a CAE schedule, run four checks. First, verify every Level 3 package has an owner and a solver-time estimate. Second, confirm no activity depends on a CAD release that has not been frozen — mark those as risk, not logic. Third, level resources and inspect whether the critical path changed after leveling. Fourth, trace every program gate backward to at least one CAE milestone with a binary completion criterion.

With the WBS, dependencies, and gate mapping in place, the schedule becomes a controllable instrument. The next step is to load it with realistic effort and solver-time estimates, which is the subject of capacity planning.