📚 Course ContentsChapter 1 Program delivery framework

1. Program delivery framework

Occupant restraint CAE–test correlation is not a single simulation task; it is a delivery program that must produce defensible evidence that a CAE model reproduces physical sled or vehicle crash behavior within agreed tolerances. The program delivery framework is the contract that makes this evidence repeatable, auditable, and usable for design decisions. Without it, correlation degenerates into isolated curve overlays that cannot support restraint system sign-off.

This chapter establishes the three pillars of that framework: scope definition (what physical tests, configurations, and responses are in play), stakeholder mapping (who owns each input, decision, and deliverable), and acceptance criteria (the quantitative thresholds and evaluation windows that determine pass or fail).

1. Scope Definition: From Test Matrix to Correlation Envelope

Scope begins with the physical test matrix. For an occupant restraint program, a typical correlation envelope covers:

Load cases: frontal 56 km/h rigid barrier, frontal offset 64 km/h ODB, side MDB 50 km/h, rear 32 km/h, and rollover if applicable.
Restraint configurations: belt-only, belt + driver airbag, belt + airbag + pretensioner + load limiter, and seat-integrated variants.
Occupant positions: 50th percentile male (Hybrid III), 5th percentile female, and child restraint (CRS) positions where regulated.
Response channels: head CG acceleration (a_x, a_y, a_z), chest deflection, pelvis acceleration, belt force at retractor and anchor, airbag pressure, and seat track displacement.

The scope statement must also fix the correlation boundary: which subsystems are modeled explicitly (belt, airbag, seat, steering column) and which are represented by boundary conditions or lumped parameters. A common failure mode is an ambiguous boundary — for example, modeling the seat frame as rigid while the physical test shows seat cushion compression that alters pelvis kinematics. The scope document should record this as an explicit assumption with a sensitivity note.

Practical rule: If a response channel is not measured in the physical test, it cannot be correlated. Scope must be limited to instrumented channels, or the test plan must be extended before correlation begins.

2. Stakeholder Map and Responsibility Assignment

Correlation programs fail more often from unclear ownership than from solver limitations. A workable stakeholder map assigns a single accountable owner per artifact:

Artifact	Accountable Owner	Key Inputs Provided
Physical test data package	Test engineer	Filtered channels, instrumentation metadata, test photos, setup sheet
CAE model baseline	CAE model owner	Deck, material cards, subsystem meshes, boundary conditions
Correlation metrics	Correlation analyst	Objective rating scores, time-history overlays, sensitivity summary
Acceptance decision	Restraint system lead	Signed correlation report, open issues list, risk statement
Model update approval	CAE manager	Change log, re-run evidence, regression impact

The stakeholder map should also define the data handoff format. Test data delivered as unfiltered ASCII with inconsistent time bases is a frequent source of rework. Specify channel naming, units (mm, ms, kN, g), sampling rate, and filter class (e.g., SAE J211 CFC 60 for occupant accelerations, CFC 180 for belt forces) before any correlation run.

3. Acceptance Criteria: Quantitative and Defensible

Acceptance criteria convert correlation from opinion into a measurable gate. A robust criteria set combines objective rating and engineering judgment:

Objective metrics: CORA (Correlation and Analysis) rating, ISO/TS 18571, or a program-specific weighted score. Typical target: CORA ≥ 0.80 for primary injury channels, ≥ 0.70 for secondary channels.
Peak and timing tolerances: peak value within ±15%, peak time within ±10 ms for head and chest; belt force peak within ±10%.
Phase and shape: no systematic phase lag greater than 5 ms after t = 20 ms; no sign inversion in the primary loading phase.
Energy consistency: initial kinetic energy and absorbed energy within ±5% of test-derived values.

Criteria must be defined before correlation runs. Post-hoc threshold adjustment is the most common way correlation programs lose credibility. The acceptance table below is a representative example for a frontal driver-side configuration; actual values must be agreed with the restraint system lead and regulatory context.

Channel	Metric	Target	Evaluation Window
Head CG a_x	CORA	≥ 0.85	0–150 ms
Chest deflection	CORA	≥ 0.80	0–150 ms
Belt force (retractor)	Peak deviation	≤ ±10%	Peak region
Pelvis a_x	Peak time	≤ ±10 ms	0–120 ms
Airbag pressure	Phase lag	≤ 5 ms	20–80 ms

4. The Delivery Workflow as a Closed Loop

The framework is only useful if it drives a repeatable workflow. The diagram below shows the correlation delivery loop: test data and CAE baseline feed a correlation run, which produces metrics evaluated against the acceptance criteria. A pass closes the loop; a fail triggers diagnosis, model update, and re-run — with every iteration recorded in the correlation log.

5. Making the Framework Operational

To move from framework to execution, the program should maintain a correlation log with one row per iteration. A minimal but complete log entry contains:

Iteration: 03
Date: 2025-03-14
Model version: RST_FR_DAB_v07
Load case: Frontal 56 km/h rigid, driver 50th
Changed: seat cushion stiffness 0.8x, belt slip friction +0.05
Head CG ax CORA: 0.82 -> 0.87
Chest defl CORA: 0.76 -> 0.81
Belt force peak dev: +12% -> +7%
Decision: PASS primary channels; secondary pelvis ax CORA 0.68 (open)
Owner: J. Chen
Next action: pelvis sensitivity study, re-run by 2025-03-21

The log is the audit trail. When a regulator or internal reviewer asks why a model is considered correlated, the log plus the acceptance table answers the question without re-running anything.

Common pitfall: Treating correlation as a one-time event. Restraint systems change — belt geometry, airbag fold pattern, seat foam — and each change invalidates prior correlation. The framework must define a re-correlation trigger list: any change to restraint geometry, material card, or boundary condition that affects occupant kinematics requires a new correlation run against the original test data.

6. Summary of the Delivery Framework

A defensible CAE–test correlation program rests on three interlocking definitions. Scope fixes the load cases, configurations, occupant positions, and instrumented channels that will be correlated, and records explicit modeling assumptions. Stakeholders assign one accountable owner per artifact and standardize the data handoff format. Acceptance criteria set quantitative thresholds — CORA ratings, peak and timing tolerances, phase limits — before any run, and are enforced through a correlation log that records every iteration and decision.

With these three pillars in place, the remaining chapters of this course can focus on the technical work: building the CAE baseline, processing test data, running objective correlation metrics, diagnosing mismatches, and updating the model. The framework ensures that this technical work produces evidence, not just curves.