4. CAE resource planning

Resource planning is where a CAE manager's technical judgment meets the company's financial reality. Unlike a single simulation project, which has a defined start and end, resource planning is a continuous balancing act across four interdependent dimensions: headcount, software licenses, HPC capacity, and budget. Each dimension constrains the others, and a plan that optimizes one in isolation will almost always fail in execution. This section provides a practical framework for building a defensible, forecastable CAE resource plan across the four core disciplines: crash, NVH, CFD, and durability.

Starting Point: Demand Modeling by Discipline

Resource planning begins with demand, not supply. Before requesting headcount or licenses, quantify what the four teams actually need to deliver. The demand drivers differ significantly by discipline:

For each discipline, build a simple demand model: annual simulation jobs = (number of vehicle programs) × (load cases per program) × (design iterations per load case). A typical passenger vehicle program might generate 200–400 crash load cases, 150–300 NVH runs, 80–150 CFD cases, and 100–250 durability jobs across its development cycle. Multiply by the number of concurrent programs (often 3–6 in a mid-size OEM) to get the total annual demand.

Headcount Planning: Skills Matrix and Utilization Targets

Headcount is the most expensive and least flexible resource. A CAE engineer fully loaded with salary, benefits, and overhead typically costs $120,000–$180,000 per year in mature markets. The planning question is not "how many people do we need?" but "what mix of skills do we need, and at what utilization?"

Build a skills matrix that maps each discipline to required competencies. For crash, you need explicit solver expertise (LS-DYNA, Pam-Crash), material modeling, and occupant safety knowledge. For NVH, modal analysis, transfer path analysis, and acoustic simulation skills are essential. CFD requires turbulence modeling, multiphase flow, and thermal management expertise. Durability demands fatigue theory, load spectrum analysis, and material fatigue data interpretation.

A practical utilization target for CAE engineers is 70–80% billable simulation time, with the remainder allocated to methodology development, validation, and administrative tasks. If your demand model shows 12,000 crash jobs per year and each job requires 6 engineer-hours (including setup, run monitoring, and post-processing), that is 72,000 engineer-hours. At 1,600 productive hours per engineer per year (80% utilization), you need 45 crash engineers. This is the kind of calculation that turns a headcount request from an opinion into a business case.

Software License Planning: Tokens, Seats, and Scheduling

CAE software licensing is often the second-largest cost after headcount, and it is frequently mismanaged. The key distinction is between node-locked seats (tied to a specific machine), floating licenses (shared across a network), and token-based licenses (consumed per job, often for HPC solvers).

For crash and durability, LS-DYNA and Abaqus are typically licensed per token or per core. A full-vehicle crash model running on 64 cores consumes 64 tokens for the duration of the run. If your peak demand is 20 concurrent crash jobs at 64 cores each, you need 1,280 tokens available simultaneously. But buying 1,280 tokens for peak demand is wasteful if average utilization is only 40%. The solution is a combination of owned tokens (covering 60–70% of average demand) and burst tokens (rented on-demand for peak periods).

For NVH and CFD, floating licenses are more common. Nastran and STAR-CCM+ are often licensed per seat with a queueing system. The planning metric here is license utilization rate: if your NVH team has 15 seats but average concurrent usage is 9, you are over-licensed. A queueing system with a fair-share scheduler can reduce the required seat count by 20–30% while maintaining acceptable wait times.

# Example: License utilization analysis (pseudo-code)
peak_concurrent = max(concurrent_users_over_30_days)
avg_concurrent  = mean(concurrent_users_over_30_days)
utilization     = avg_concurrent / total_seats

if utilization < 0.5:
    action = "reduce seats or renegotiate contract"
elif utilization > 0.85:
    action = "add seats or implement queueing"
else:
    action = "maintain current allocation"

HPC Capacity Planning: Cores, Memory, and Storage

HPC capacity is the engine that drives CAE throughput. Planning it requires understanding three sub-resources: compute cores, memory per core, and scratch storage. A crash model with 15 million elements may need 64 cores and 256 GB RAM; a CFD transient case with 50 million cells may need 256 cores and 1 TB RAM. These are not interchangeable.

The standard planning approach is to build a core-hour demand forecast. For each discipline, estimate the total core-hours per year:

• Crash: 300 jobs × 64 cores × 12 hours = 230,400 core-hours
• NVH: 200 jobs × 32 cores × 6 hours = 38,400 core-hours
• CFD: 120 jobs × 256 cores × 48 hours = 1,474,560 core-hours
• Durability: 180 jobs × 48 cores × 10 hours = 86,400 core-hours

Total annual demand: approximately 1.83 million core-hours. If your HPC cluster has 5,000 cores available for CAE (after reserving capacity for other workloads), and operates 8,000 hours per year at 85% availability, the supply is 5,000 × 8,000 × 0.85 = 34 million core-hours. This appears to be ample, but the constraint is not total capacity—it is peak concurrent demand. If all four disciplines peak simultaneously, you may need 3,000–4,000 cores at once, which is within the 5,000-core cluster but leaves little headroom for unexpected urgent jobs.

Budget Forecasting: Building the Annual Plan

With demand, headcount, licenses, and HPC capacity quantified, the budget forecast becomes a structured aggregation rather than a guess. A typical CAE budget for a mid-size OEM team of 40–60 engineers might allocate:

• Headcount (50–55%): Salaries, benefits, training, and contractor premiums for peak periods.
• Software licenses (20–25%): Annual maintenance for owned licenses plus on-demand burst tokens.
• HPC capacity (15–20%): On-premise cluster amortization or cloud compute costs, plus storage and cooling.
• Other (5–10%): Conferences, travel, hardware refresh, and contingency reserve.

The contingency reserve is not optional. CAE demand is inherently volatile: a late design change can trigger a wave of re-runs, a regulatory update can add new load cases, and a warranty issue can demand urgent durability investigations. A 10–15% contingency on the total budget is standard practice.

Putting It Together: A Rolling Forecast Process

Resource planning is not an annual event; it is a rolling process. A practical cadence is:

1. Monthly: Track actual core-hour consumption, license utilization, and headcount against plan. Flag variances greater than 15%.
2. Quarterly: Reforecast demand based on program timing changes. Adjust burst license and cloud HPC allocations.
3. Annually: Rebuild the full plan with updated program volumes, salary benchmarks, and vendor pricing. Negotiate license renewals and HPC contracts.

The goal is not a perfect forecast—that is impossible. The goal is a plan that is transparent about its assumptions, flexible enough to absorb change, and defensible when challenged by finance or program management. When a program manager asks "why do you need 45 crash engineers?", the answer should be a calculation, not an opinion: 12,000 jobs × 6 hours ÷ 1,600 productive hours = 45. That is the language of resource planning.