2. DMAIC roadmap for CAE-driven product development

In a CAE-driven automotive program, DMAIC is not a standalone quality ritual that runs parallel to product development. It is a governance overlay that gives simulation work the same discipline as physical testing and manufacturing: every phase produces evidence, every gate is a decision point, and every change is traceable. The practical challenge is that CAE teams often operate on a different cadence than APQP (Advanced Product Quality Planning) and engineering change management (ECM). This section shows how to align the three so that simulation results become auditable inputs to program decisions rather than late-stage opinions.

Mapping DMAIC Phases onto the APQP Timeline

APQP organizes launch into five phases: plan and define, product design and development, process design and development, product and process validation, and feedback/assessment. DMAIC phases do not map one-to-one onto these, and forcing a rigid mapping creates artificial gates. A more workable model is to treat DMAIC as the analytical spine that runs through APQP phases 1–4, with each DMAIC phase closing on a defined evidence package.

In practice, the Define phase typically overlaps APQP phase 1 and the start of phase 2. The Measure phase aligns with concept and preliminary design, where baseline CAE models, mesh standards, and correlation data are established. Analyze spans detailed design, where DOE and sensitivity studies identify dominant design parameters. Improve covers design verification loops and process window studies. Control hands off to validation and production, where simulation models become reference baselines for change impact assessment.

The critical governance rule is that a DMAIC phase gate should never be opened on the basis of a single simulation run. Each gate requires a defined deliverable set, a named approver, and an explicit statement of what the evidence does and does not cover. This is where many CAE organizations fail: they present contour plots as conclusions without documenting assumptions, boundary conditions, or model fidelity.

DMAIC Gates Embedded in the APQP Timeline APQP Phase 1: Plan & Define Phase 2: Product Design Phase 3: Process Design Phase 4: Validation DMAIC Define CTQ, scope, baseline Measure Model fidelity, correlation Analyze DOE, sensitivity, root cause Improve Design verification loops Control Baseline, handoff G1 G2 G3 G4 Gate Deliverables G1 — Define exit • CTQ tree & target values • CAE scope statement • Baseline model inventory G2 — Measure exit • Mesh convergence study • Test–CAE correlation report • Measurement system check G3 — Analyze exit • DOE / sensitivity matrix • Verified root-cause ranking • Design parameter windows G4 — Improve exit • Optimized design evidence • Robustness assessment • Change request package Control • Frozen CAE baseline • Re-run triggers • ECM linkage Engineering Change Management ECR raised → impact scope CAE re-run against baseline Delta report → ECO decision Baseline update baseline feeds ECM

Gate Deliverables: What Must Be in the Package

A gate deliverable is not a slide deck. It is a structured evidence package that a reviewer who was not involved in the analysis can audit. For CAE, four artifact classes recur across gates, and their content matures as the project progresses.

Model definition records. At G2 (Measure exit), the package must include the mesh convergence study, element type justification, material model source (test data, supplier card, or literature with traceability), and boundary condition rationale. A common failure is a correlation report that shows good agreement on one load case while ignoring a second load case where the model diverges by more than 15%. The gate reviewer should ask for the full correlation matrix, not the best-performing curve.

Assumption and limitation logs. Every CAE result carries assumptions: linear material behavior, idealized welds, omitted thermal effects, rigid fixtures. These must be listed with their expected direction of influence. If a suspension lower control arm is modeled with rigid bushings, the log should state that this overestimates load transfer into the subframe and therefore produces conservative stress at the attachment. This transforms an assumption into a usable engineering statement.

Decision traceability. At G3 (Analyze exit), the DOE or sensitivity study must show which design parameters were varied, over what range, and with what statistical design (full factorial, fractional factorial, Latin hypercube). The output is not just a Pareto chart of main effects; it is a statement of which parameters the design is sensitive to and which can be frozen. For example, a crashworthiness study might show that front rail gauge contributes 62% of the variance in intrusion, while the bumper beam material grade contributes 8% within the tested range. That ranking directly informs where the Improve phase should spend its budget.

Change-ready baseline. At G4 and Control, the CAE model must be frozen in a configuration-managed state: version tag, solver version, input deck checksum, and a documented re-run procedure. This is the artifact that engineering change management depends on. Without it, every ECR triggers a rebuild from scratch, and the program loses the ability to distinguish a real design effect from a modeling change.

Integrating with Engineering Change Management

The most valuable integration point is the ECR impact assessment. When a change request is raised—say, a 0.3 mm gauge reduction on a B-pillar reinforcement—the ECM workflow should route to the CAE baseline owner with a specific question: does this change affect any validated CAE conclusion? The answer is produced by re-running the frozen baseline with only the changed parameter, then comparing against the stored reference results.

A practical delta-report format includes the changed input, the affected load cases, the quantitative delta in the primary response (e.g., peak intrusion increases from 142 mm to 151 mm, a 6.3% change), and a judgment against the CTQ limit. If the CTQ limit is 155 mm, the change passes with margin; if it is 148 mm, the change fails and the ECR is rejected or redesigned. This is where DMAIC Control phase discipline pays off: because the baseline was frozen with a checksum and documented solver settings, the delta is attributable to the design change alone.

A useful gate-review question for any CAE deliverable: "If I changed one boundary condition by 10%, would this conclusion still hold?" If the presenter cannot answer, the sensitivity study is incomplete and the gate should not close.

Common Integration Failures and Their Symptoms

Three failure patterns appear repeatedly in automotive CAE programs. First, gate compression: the program schedule forces G2 and G3 to be reviewed in the same meeting, so correlation and root-cause analysis are conflated. The symptom is a correlation report that already contains design recommendations, meaning the team skipped the measurement-system validation step. Second, orphaned baselines: the Control phase freezes a model, but ECM does not reference it, so changes are assessed against whatever model happens to be current. The symptom is inconsistent delta reports for similar changes. Third, deliverable inflation: gate packages grow to hundreds of pages, and reviewers stop reading them. The remedy is a one-page gate summary that states the decision requested, the evidence supporting it, the limitations, and the residual risk—with the detailed artifacts as appendices.

The DMAIC roadmap succeeds in CAE-driven development only when the gates are real decision points with named approvers, the deliverables are auditable evidence rather than presentations, and the Control-phase baseline is the same object that engineering change management uses for impact assessment. When these three conditions hold, simulation stops being a late-stage verification activity and becomes a continuously maintained source of design truth.

← Previous 📖 Contents Next →