2. Core technical scope

When a supplier statement of work (SOW) says "perform crash CAE," it is describing an activity, not a deliverable. The gap between that phrase and a verifiable engineering result is where most outsourcing disputes originate. This section defines the technical scope that must be pinned down before any purchase order is issued: what is explicitly delivered, what is implicitly expected, which solver produces the numbers, and how much model fidelity is actually required to support the decision the CAE is meant to inform.

Explicit Deliverables: The Contractual Artifacts

Explicit deliverables are the files and documents named in the SOW and tied to acceptance. In crash CAE outsourcing, they typically fall into five categories:

• Deck and model files — the runnable input deck (e.g., model_main.key with includes), the assembled solver-ready model, and the version-controlled source geometry or mesh database.
• Results database — the binary output (d3plot, binout, or equivalent) plus the solver log and any restart files.
• Post-processing report — a structured document with intrusion plots, acceleration time histories, energy balance, and section force data.
• Correlation package — where physical test data exists, the overlay of simulation versus test, with the correlation metric and any scaling applied.
• Model documentation — mass breakdown, material card summary, contact definitions, and boundary conditions.

The critical discipline is that each deliverable must have a named format, a revision convention, and a defined acceptance criterion. "A report" is not a deliverable; "a PDF report containing the five mandatory plots defined in Appendix B, delivered within 10 business days of run completion" is.

Implicit Deliverables: The Expectations Nobody Writes Down

Implicit deliverables are the engineering assumptions and quality attributes that the customer assumes but rarely specifies. These are the most common source of rework. Typical implicit expectations include:

• Model stability — the deck runs to termination without negative volume, mass scaling beyond a threshold, or contact instability.
• Energy conservation — hourglass energy and internal energy remain within accepted ratios (commonly hourglass < 5% of internal energy).
• Mesh quality — element aspect ratios, Jacobian, and warpage within solver-recommended limits.
• Traceability — every material card, contact, and boundary condition can be traced to a source document or test.
• Reproducibility — the same deck on the same solver version produces the same result.

Solver Types and Their Scope

Crash CAE is dominated by explicit dynamic solvers, but the choice of solver and its configuration determines what physics can be captured. The table below summarizes the solver families commonly encountered in supplier programs.

For a typical full-frontal crash simulation, the explicit structural solver is the workhorse. The time step is governed by the Courant condition: dt = L_min / c, where L_min is the smallest element characteristic length and c is the wave speed in the material. A 5 mm steel element with a wave speed of approximately 5000 m/s yields a stable time step near 1 microsecond. This is why mesh refinement directly drives cost: halving element size doubles the number of elements and halves the time step, roughly quadrupling runtime.

Model Fidelity Requirements

Fidelity is not a single number; it is a set of decisions about what the model must resolve. The SOW should specify fidelity along at least four axes:

• Geometric fidelity — whether the model uses the full CAD geometry, a mid-surface simplification, or a coarse representation. For crash, the front rail, bumper, and occupant compartment typically require full detail, while rear structure may be simplified.
• Mesh fidelity — target element size in critical regions. A common specification is 5–8 mm in the crush zone and 10–15 mm in non-critical areas.
• Material fidelity — whether strain-rate-dependent plasticity (e.g., Johnson-Cook, Cowper-Symonds) is required, and whether failure criteria are calibrated to test data.
• Contact fidelity — the contact algorithm (penalty, kinematic, tied), friction coefficients, and whether self-contact is enabled.

Connecting Scope to Verification

The technical scope is only enforceable if each element maps to a verification method. The SVG below shows how explicit deliverables, implicit expectations, solver configuration, and fidelity requirements converge on a single verification gate before results are accepted.

The verification gate is the contractual mechanism that converts technical scope into an enforceable acceptance decision. Each of the five checks maps to a specific deliverable or expectation. If the deck terminates but hourglass energy is 12% of internal energy, the result is not acceptable regardless of how closely the intrusion plot matches the target — because the physics is not trustworthy.

Practical Scope Definition Example

Consider a supplier program for a full-frontal 56 km/h rigid barrier impact. A well-defined technical scope might specify:

Deliverable: Full-vehicle explicit crash model, LS-DYNA R13.0
Mesh: 6 mm target in front structure, 12 mm in rear
Materials: Cowper-Symonds for steel, strain-rate curves from
           supplier material card library (revision 4.2)
Contact: Penalty-based, friction 0.1 (steel-steel), 0.3 (steel-foam)
Output: d3plot every 1 ms, binout at 10 kHz
Acceptance: Hourglass energy < 5% internal energy at 100 ms
            B-pillar intrusion within 10% of physical test
            Deck runs to 120 ms without negative volume

This level of specificity eliminates the ambiguity that causes rework. The supplier knows exactly what to build, the customer knows exactly what to inspect, and both parties have a shared basis for accepting or rejecting the result.