3. Resource mapping for occupant safety programs

An occupant safety program rarely fails because engineers lack skill. It fails because the program plan assumes resources that are already committed elsewhere. A sled test campaign scheduled for the same week as a full-vehicle barrier series, a CAE cluster saturated by a different platform's mesh convergence study, or a restraint calibration loop that lands in the middle of annual budget lock — these are resource conflicts, not technical ones. Resource mapping is the discipline of making those conflicts visible before they become schedule slips.

This chapter treats resource mapping as a four-layer problem: people, test facilities, CAE hardware, and budget cycles. Each layer has its own unit of capacity, its own booking mechanism, and its own lead time. The goal is a single map that shows, for any given week, whether the program's demand fits inside the available capacity — and where it does not.

Why a Single Map Beats Four Schedules

Most organizations already track these resources, but in separate systems. Headcount sits in an engineering resource plan, sled and barrier slots sit in a test facility calendar, compute sits in a cluster queue, and money sits in a finance system. The problem is that a restraint engineer's week is consumed by all four simultaneously. A single map forces the program to answer one question per week: can this work package actually execute?

The map is not a Gantt chart. It is a capacity-versus-demand view. For each resource layer, you define a capacity unit, a demand unit, and a booking horizon. The figure below shows how the four layers connect to a common program timeline and where the binding constraint typically appears.

Layer 1 — People: Skill-Constrained, Not Headcount-Constrained

Counting engineers is misleading. A restraint calibration engineer and a barrier test engineer are not interchangeable, even if both sit in the same department. The correct capacity unit is the qualified engineer-week for a specific skill. In practice, three or four skills dominate an occupant safety program:

• Restraint CAE — model build, dummy positioning, restraint parameter sweeps.
• Sled test engineering — pulse definition, fixture design, instrumentation plan.
• Full-vehicle barrier test engineering — barrier setup, high-speed camera, post-test teardown.
• Dummy and instrumentation technicians — calibration, channel verification, data quality checks.

A useful mapping practice is to record, for each skill, the available weeks and the committed weeks per program. If a skill is above 85% committed for more than three consecutive weeks, that skill is a candidate binding constraint. The 85% threshold is a working heuristic, not a rule — it leaves room for rework, which in occupant safety is common because a single failed channel can invalidate a test.

Layer 2 — Test Facilities: The Longest Lead Time

Sled bays and barrier halls are the least flexible resource in the program. A sled bay cannot be expanded by working weekends if the fixture is already mounted for another program. Booking horizons of 8–12 weeks are typical for a shared facility. The mapping task here is to convert test matrix entries into facility slots and check them against the facility calendar.

Consider a simplified example. A frontal occupant program plans 14 sled tests and 4 full-vehicle barrier tests. Each sled test occupies one half-day slot including setup and teardown; each barrier test occupies one full day. If the program targets completion by week 12 and the facility has two sled bays and one barrier hall, the demand is 7 sled-days and 4 barrier-days. Spread across 12 weeks, that is well within capacity — unless another program has already booked the barrier hall in weeks 8–10. That overlap, not the total count, is what breaks the schedule.

Layer 3 — CAE Hardware: Queue Time Is the Hidden Cost

CAE capacity is usually measured in core-hours, but the number that matters for scheduling is wall-clock turnaround. A 2,000 core-hour explicit crash simulation may run in 4 hours on 500 cores or in 40 hours on 50 cores. If the cluster partition is shared, queue time can add another 6–24 hours. For a restraint parameter sweep of 30 runs, the difference between a dedicated partition and a shared queue is often several days.

Mapping practice: for each CAE work package, record the estimated core-hours, the target partition, and the expected queue time. Then convert to wall-clock days. A work package that needs 5 wall-clock days but is scheduled in a 3-day window is a conflict, even if core-hours are available.

Work package: Frontal restraint sweep, 30 runs
Per-run cost:        2,000 core-hours
Total core-hours:   60,000
Partition capacity:    500 cores
Compute time:       60,000 / 500 = 120 h = 5 days
Queue allowance:     +1 day (shared partition)
Wall-clock need:     6 days
Scheduled window:    3 days  ->  CONFLICT

Layer 4 — Budget Cycles: The Constraint That Moves Slowest

Budget does not consume engineering time directly, but it gates the resources that do. Sled tests, barrier tests, dummy calibration, and cluster expansion all require committed spend. The mapping task is to align the program's spend profile with the organization's budget cycle — typically quarterly commitments inside an annual plan.

Two failure modes are common. First, a test campaign is scheduled in Q3 but the spend was not requested in the Q2 forecast, so the facility booking cannot be confirmed. Second, a CAE hardware expansion is approved but arrives two quarters late, forcing the program to use a shared partition with long queue times. Both are budget-cycle mismatches, not technical failures.

Building the Map: A Worked Procedure

The following procedure produces a one-page resource map for a program. It is deliberately lightweight — the goal is visibility, not precision.

1. List work packages. Break the program into packages that consume at least one resource layer (e.g., "frontal restraint calibration," "side impact barrier series," "pedestrian headform CAE").
2. Assign demand per layer. For each package, record engineer-weeks by skill, facility slots, core-hours and wall-clock days, and committed spend by quarter.
3. Plot demand against capacity by week. Use the program timeline as the x-axis. Mark capacity as a horizontal band and demand as bars.
4. Identify binding constraints. Any week where demand exceeds capacity in any layer is a conflict. Rank conflicts by lead time — facility conflicts are hardest to resolve, budget conflicts second, people third, CAE queue fourth.
5. Resolve in lead-time order. Shift facility bookings first, then adjust budget forecasts, then rebalance people, then tune CAE partitioning.

What the Map Should Reveal

A well-built resource map answers three questions at a glance. First, which layer is binding this week? Second, how far ahead must a decision be made? Third, what is the cost of a one-week slip? In occupant safety programs, a one-week slip in a barrier test often cascades into a two-week slip in restraint calibration, because the calibration depends on barrier test data. The map makes that dependency visible before it is discovered in a status meeting.

The map is also a communication tool. When a program manager can show that the barrier hall is booked in weeks 8–10 by another program, the conversation shifts from "why is the schedule slipping" to "which program moves." That is a resource decision, and it belongs in the resource map — not in a post-mortem.