4. Automotive product development process

Automotive vehicle programs are governed by a phase-gate development process. Every OEM — whether it follows a customized version of APQP, a V-model, or an internal stage-gate framework — divides the journey from concept to start of production (SOP) into discrete phases separated by formal decision points. For CAE engineers and CAE managers, understanding this cadence is not optional administrative knowledge; it determines when models must be frozen, when results must be published, and what level of fidelity is expected at each review. A CAE deliverable that arrives one week after a gateway has closed is effectively worthless, regardless of its technical quality.

Phase Structure and Gateway Logic

Most passenger-vehicle programs follow a structure similar to the following, though naming conventions vary between OEMs:

Phase	Typical Gateway Name	Program Focus	CAE Expectation Level
Concept	G0 / Concept Freeze	Vehicle architecture, package, target setting	1D system models, concept-level stiffness/CRASH targets
Concept Validation	G1 / Architecture Freeze	Body-in-white (BIW) topology, powertrain layout	Concept CAE with simplified geometry, load-path studies
Design Development	G2 / Design Freeze	Detailed CAD release, material selection	Full-mesh CAE on nominal geometry, first full-vehicle results
Design Validation	G3 / Tooling Kick-off	Tooling design, supplier part release	Correlation-ready models, design-of-experiment (DOE) studies
Production Validation	G4 / Production Release	Production tooling, PPAP	Final CAE sign-off, correlation with physical test
Launch	G5 / SOP	Volume production	Change-impact assessments only

Each gateway is a formal review where the program steering committee decides whether to release the next phase of funding and resources. The gate criteria include not only CAE results but also physical test status, supplier readiness, cost, and timing. CAE's role at each gate is to provide evidence that the virtual design meets its attribute targets — or to clearly quantify the gap and propose countermeasures.

CAE Deliverable Timing and Content

The critical insight is that CAE deliverables are not a single report; they are a stream of outputs that must be synchronized with the program's decision rhythm. At G1 (Architecture Freeze), CAE is expected to confirm that the chosen architecture can meet global bending and torsional stiffness targets, crash energy management targets, and NVH modal targets. The models at this stage are typically coarse — shell meshes with simplified joints, often using beam elements for closures. The deliverable is a feasibility assessment, not a validation report.

By G2 (Design Freeze), the CAD geometry is nominally frozen. CAE must deliver full-vehicle results for all attribute domains: frontal offset deformable barrier (ODB), side impact, roof crush, rear impact, pedestrian protection, seat belt anchorage, and NVH. These results feed directly into the gate review. If a target is missed, the program must decide whether to accept the risk, delay the gate, or initiate a design change. The CAE engineer's job is to present the gap with sufficient clarity that this decision can be made.

At G3 (Tooling Kick-off), the focus shifts to robustness. CAE models must now account for manufacturing variation — material thickness scatter, yield strength variation, weld quality — and demonstrate that the design meets targets with statistical confidence. This is where DOE and Monte Carlo studies become mandatory deliverables. The model itself must be correlation-ready: mesh quality, material cards, and boundary conditions must be documented to a level that allows direct comparison with physical test results.

Model Release and Configuration Alignment

Each gateway triggers a model release event. The CAE model released at G2, for example, must correspond exactly to the CAD data set frozen at that gate. This is where configuration management becomes critical. If the CAE model uses a different CAD revision than the one released to tooling, the results are invalid for gate decisions. The release package must include:

• The CAE model file (e.g., LS-DYNA .k or .key file) with a unique revision identifier.
• A bill of materials (BOM) mapping each part to its CAD part number and revision.
• Material cards with traceable test data references.
• Boundary condition and load case definitions.
• A correlation status flag: uncorrelated, partially correlated, or correlated.

When a design change occurs after a gate — which is common — the CAE model must be updated and re-released. The configuration management system must track which model revision was used for which gate decision. This traceability is essential for audit, for root-cause analysis if a physical test fails, and for future programs that reuse the architecture.

Practical Example: Aligning a Frontal Crash CAE Deliverable with G2

Consider a frontal ODB crash CAE task for a B-segment SUV program. The G2 gate is scheduled for week 42. The CAE team receives the frozen CAD data set in week 34. The following timeline is typical:

1. Week 34–35: Mesh generation and assembly. Target: 8–12 million elements for the full vehicle. Check mesh quality (Jacobian > 0.6, warpage < 15°).
2. Week 36: Material card verification and boundary condition setup. Cross-check against the program's material database.
3. Week 37–38: Solver run on the cluster. Typical wall-clock time: 18–24 hours for a 150 ms simulation using 32 cores.
4. Week 39: Post-processing and result extraction. Key outputs: intrusion at pedal box, steering column displacement, occupant load case (OLC), and B-pillar acceleration.
5. Week 40: Internal review and countermeasure study if targets are missed.
6. Week 41: Final report publication and upload to the program data management system.
7. Week 42: G2 gate review.

If the simulation shows that the toe pan intrusion exceeds the target by 15 mm, the CAE engineer must not simply report the failure. The deliverable should include a countermeasure proposal: for example, increasing the thickness of the front longitudinal rail from 1.8 mm to 2.0 mm, or adding a reinforcement patch. A quick DOE run can quantify the effect of each option. This transforms the CAE report from a problem statement into a decision-support document.

Common Failure Modes and How to Avoid Them

The most frequent CAE-program misalignment issues are:

• Late CAD freeze: If CAD is released late, CAE meshing is compressed, leading to poor mesh quality and unreliable results. Mitigation: use pre-release CAD for preliminary meshing and update only changed parts.
• Unclear target definition: If the attribute target is not quantified (e.g., "improve stiffness" instead of "torsional stiffness ≥ 28 kNm/deg"), CAE cannot deliver a pass/fail judgment. Mitigation: confirm targets in writing at G1.
• Model-CAD mismatch: Using an outdated CAD revision invalidates the gate decision. Mitigation: enforce a configuration check in the CAE release workflow.
• No correlation plan: If CAE results are not correlated with physical test data, the model's predictive capability is unknown. Mitigation: define the correlation matrix at G2 and execute it at G3.

In summary, the gateway process is the backbone of automotive program management. CAE deliverables must be planned backward from each gate, with clear ownership, defined content, and traceable configuration. The CAE engineer who understands this cadence — and who can deliver the right result at the right time with the right level of fidelity — becomes an indispensable partner in the program, not just a simulation service provider.