3. Define DOE Factors and Levels from Engineering Requirements

From Requirements to a Formal Factor–Level Table

In a DOE-driven LS-DYNA study, the design space is only as good as the factor definitions behind it. Engineering requirements arrive as prose — "the bumper must survive a 15 km/h offset impact across the full production tolerance band" — and must be converted into a machine-consumable table that a script can later inject into the keyword template. This case builds that table for a representative frontal-crash sled model, with explicit factor names, units, bounds, and level counts, plus the reasoning that justifies each choice.

The conversion has four recurring decisions: which quantities become factors, what range each factor spans, how many levels each factor needs, and how the resulting table is validated before it feeds a design-matrix generator. Getting these wrong is expensive later: an over-wide bound produces physically meaningless runs, an under-sampled factor hides a nonlinear response, and a unit mismatch silently corrupts every run in the batch.

Step 1 — Extract Candidate Factors from the Requirements

Start from the requirement statements and the baseline deck. Each requirement that names a controllable quantity, or that is sensitive to one, becomes a candidate. For the sled model the requirements are: (a) occupant chest deceleration must stay below a target across the tolerance band; (b) the energy-absorbing rail must not bottom out; (c) mass must remain within a homologation window. Reading the baseline keyword deck (extracted in the previous step) gives the current values, which anchor the nominal point of every range.

Two candidates are deliberately rejected. The mesh seed size is controllable but is a numerical, not an engineering, variable — varying it would confound discretization error with physical response. The friction coefficient is physical but is not adjustable within the requirement scope, so it stays fixed. Documenting rejected candidates prevents them from reappearing in later reviews.

Step 2 — Set Bounds from Physical and Process Limits

Bounds must be wide enough to cover the requirement band but narrow enough that every corner of the box is a buildable, meaningful design. Use three sources in order of authority: manufacturing capability, the requirement's own tolerance statement, and engineering judgment where neither applies.

• t_rail: press-formable range for the chosen steel grade is 1.40–2.20 mm; the requirement's tolerance band maps to 1.60–2.00 mm. Use the tighter requirement band, 1.60–2.00 mm.
• L_rail: packaging allows 180–260 mm; below 180 mm the rail cannot absorb the required energy, above 260 mm it interferes with the subframe. Use 180–260 mm.
• t_beam: 1.60–2.40 mm, set so the resulting mass stays inside the homologation window at both extremes.
• v0: the severity band is 13.5–16.5 km/h, taken directly from the requirement.
• fy_scale: material scatter of ±10 % is the accepted supplier tolerance, so 0.90–1.10 (dimensionless).

Step 3 — Choose Level Counts

Level count controls both resolution and run cost. A factor whose response is expected to be monotonic and near-linear needs only two levels; a factor expected to show a threshold, plateau, or interaction needs three or more. The total run count for a full factorial is the product of level counts, so this decision directly sets the batch size.

With these counts a full factorial would need 3·2·2·3·2 = 72 runs. That is acceptable for a screening study; if it were not, the level counts — not the bounds — are the first thing to revisit, because narrowing bounds to cut runs risks excluding the true optimum.

Step 4 — Emit the Formal Table

The deliverable is a single table that a downstream script can parse without interpretation. Store it as CSV with a fixed header so the design-matrix generator can read columns by name. Values are given in the model's native units (mm, km/h, dimensionless) to avoid conversion at injection time.

factor,unit,lower,upper,levels,source,note
t_rail,mm,1.60,2.00,3,requirement,press-formable 1.40-2.20
L_rail,mm,180,260,2,capability,packaging limit
t_beam,mm,1.60,2.40,2,judgment,mass window at extremes
v0,km/h,13.5,16.5,3,requirement,severity band
fy_scale,-,0.90,1.10,2,capability,supplier scatter +/-10%

For a 3-level factor the intermediate level is the midpoint of the bounds unless a physical reason dictates otherwise; for t_rail the midpoint 1.80 mm coincides with the baseline, which is convenient but coincidental. The generator should compute midpoints from bounds rather than assume the baseline sits at the center.

Step 5 — Validate Before Generation

A factor–level table is cheap to check and expensive to get wrong. Run these checks and record the outcome:

1. Unit consistency: every unit matches the keyword field it will replace. A velocity entered in m/s against a km/h field scales every run by 3.6.
2. Baseline containment: each baseline value lies inside its bounds. If not, either the bound or the baseline is wrong.
3. Corner feasibility: the extreme combination (all factors at their bounds) still produces a buildable model — check mass and packaging at the corners, not just at the center.
4. Level arithmetic: the product of level counts equals the intended run budget, and no factor has fewer than two levels.
5. Name uniqueness: factor names are unique and match the placeholders in the keyword template exactly, including case.

Reading the Design Space

The SVG below shows the resulting five-dimensional design space as a set of factor axes with their bounds, level markers, and the baseline point, together with the two rejected candidates and the reason each was excluded. It is the visual counterpart to the CSV: the same bounds and level counts, arranged so the shape of the space — which factors are wide, which are finely resolved, and where the nominal sits — is visible at a glance.

Deliverable: Factor–Level Definition Sheet

The completed sheet below is the hand-off artifact for this case. It is the CSV above plus the decision record, and it is what the design-matrix generator consumes in the next step.

With this sheet validated, the design space is formally defined: five factors, 72 runs, every bound traceable to a requirement or capability limit, and every level count justified by the expected response shape. The next step consumes this table directly to build the run matrix.